GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
i am sure i read this approach in some article but i cannot find it atm.
the basic issue this is trying to solve is users coming to the site with an empty cache:
now one approach to reduce the impact of this issue is to use chunked response like rails 3.1 will support:
however this adds severe limitations on how templating can work.
relying on a revers proxy to handle this (varnish 3.1 may support chunked responses with ESI) is also not ideal since for example its quite tricky to then serve up a proper <title> tag to make SEO guys happy
at any rate another approach which afaik is used by some of the big guys is to basically store in a cookie which assets are loaded already. then you can automatically decide to inline the assets that are not yet marked as loaded in the cookie.
now when the page is loaded, the client can receive a list with assets that are not yet checked off in the cookie and start loading these assets asynchronously after the user has already received the final page with the inlined assets. as these assets finish loading they are added to the cookie.
on the next request again you check which assets you need are not yet loaded which again get inlined. but obviously as things get loaded asynchronously eventually no asset will need to be inline anymore as the cache will be fully primed.
the assets remembered in the cookie can be fully versioned which will also deal with users having the cache go cold as assets might expire or will get updated.
this should be a feature request with very low priority as its a pretty extreme optimization that most people dont need.
This sounds smart, but I don't see anything that fits in Assetic core here. I would write a Symfony2 bundle to implement this. What do you think?
yeah .. it could (and maybe should) be separate .. but it probably should built on the assets defined by assetic and overload the assetic twig helpers. anyway .. just spend a while talking about this on #symfony-dev and just wanted to be able to link to a game plan next time. so even if its not going to be implemented in assetic .. it probably will be build on top, so if you are ok with leaving this issue open for now that would be cool. but i will also not be upset of you close it .. since i can still link to it then :)
@marijn: yes ..
Ok, but that won't play nice with caching will it..? I mean, we can't add any response to a shared cache as they will be different for each user depending on what resource the have and haven't cached...
Either I don't get it yet or I'm not convinced :-/ Given your track record it's probably the former ;-)
you just have to add the cookie to the cache lookup. but that does mean in theory you could have to cache a few permutations. but as i said above this is a fairly extreme optimization for when everything else has been done and you still need more :)
thx for having a go at it. sounds like 1) there are more low hanging fruits to pick for quite some time 2) a solution for this might need to add some constraints
See #87 for private assets, related to my concern that these assets not be dumped to the web directory.