automatically inline assets based on a cookie #81

lsmith77 opened this Issue Jun 29, 2011 · 9 comments


None yet
3 participants

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:

they will have to wait for not only the html to return, but they will also have to wait for all the standard assets to load like icons, logos, css, javascript etc.

alternative approaches:
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

better approach:
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.

whats needed:

  1. a way to define the assets that should be handled this way
  2. output twig filters need to be aware of which assets need to be inline based on this configuration and the configurable cookie name
  3. javascript module to handle the async loading

sanity check:
this should be a feature request with very low priority as its a pretty extreme optimization that most people dont need.


kriswallsmith commented Jun 29, 2011

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 commented Jun 29, 2011

@lsmith77 So in case the user has not loaded e.g. additional-styles.css those would be inlined into the page and than once the page is send to the browser and rendered be loaded asynchronously by the browser with javascript and mark the asset as loaded so that we can add it as external resource on the next request?

@marijn: yes ..

marijn commented Jun 29, 2011

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 :)


kriswallsmith commented Jul 8, 2011

I explored adding a tag that dumps an asset inline, but quickly realized we cannot determine the target path in this case. Typically this defaults to something like js/asdf.js for Javascript, although you can customize it with the output option. We could set the target path at runtime using a value from $_SERVER, but that doesn't seem right. Additionally, this would create an asset in the asset manager that should NOT be dumped to the web directory when using the AssetWriter or Symfony's assetic:dump command; there's currently no support for this.

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


kriswallsmith commented Jul 15, 2011

See #87 for private assets, related to my concern that these assets not be dumped to the web directory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment