Client side CSS/JS caching

[Swaagie]

Ideally we would like to have the browser cache each CSS/JS resource. This could be done by just supplying a CSS/JS file, but this is suboptimal as each file will trigger request overhead.

Bundling script or style tags on the other hand will prevent any caching. Resulting in new

As pagelets will require html5 anyway, localStorage seems like an ideal candidate, but there are some caveats, like:

• how to ensure the latest version of css/js is sent/available
• add fallback if localStorage has no assets
• pagelets should be aware of what is in localStorage by cookies

[3rd-Eden]

We should take in mind that Internet Explorer has rather painful limitations when it comes to adding CSS dynamically to the page.

• It's limited to 31 style tags / links per page.
• Each stylesheet can only have 31 imports.
• A single stylesheet can be limited to 4.5k rules.

So implementing this could lead to potential disasters, so I don't know if it's worth the time and effort to implement this.

[Swaagie]

Which version of IE are we talking about and how high is the risk of this actually happening. If you go from 1 style per pagelet, someone would have to do that many pagelets in one page, which sounds a bit unlikely to me.

[3rd-Eden]

IE 6/7/8 i dont know about 9/10/11 as they changed some stylesheet limitations

Sent from my iPhone

On Jul 22, 2013, at 8:07 AM, Martijn Swaagman notifications@github.com wrote:

Which version of IE are we talking about and how high is the risk of this actually happening. If you go from 1 style per pagelet, someone would have to do that many pagelets in one page, which sounds a bit unlikely to me.

— Reply to this email directly or view it on GitHub.

[3rd-Eden]

The limit has been removed in IE10: http://blogs.msdn.com/b/ieinternals/archive/2011/05/14/internet-explorer-stylesheet-rule-selector-import-sheet-limit-maximum.aspx and set the limit to 4095 stylesheets per document.

[okayzed]

i think localStorage makes sense! i've been wondering how to do the same, some thoughts i've had:

schema

the data that will be necessary to store in localStorage seems to be:

• a timestamp for each resource's gen time on the server
• a hash identifier for each resource
• a mapping from resource ID (module name, css name, etc) -> hash ID for resource
• a global counter for 'invalidating' builds from one page load to the next (in case something goes wrong)

types of caching

• non-prioritized: check cache for module, if module is in it, use it, otherwise fallback to a server request (this is how appcache works.)
• prioritiy cache: check to see that version in cache is up to date, if not get from server before using the module. (this is how browser cache works today)

these both have pros and cons and can be used in isolation or mixed by the caching mechanism. (not sure how much you care about one or the other).

enforcing asset freshness

• whenever you recognize the need for an asset on the server (say during pagelet generation), you can also generate the hashes for the asset and send them down in the same payload. (lets call this 'incremental' hash tree delivery). this allows you to skip the initial roundtrip of finding out if the asset in cache is fresh or not, that the browser might otherwise have to do.
• if an asset is used solely on the client... say a component is loaded lazily as part of logic in rendering, the server will not have the opportunity to notify the client of the latest asset version. for this case, i think specifying if the asset is 'priority' or not would inform whether a server round trip needs to happen before using the component.

[tomByrer]

There are JS utils to help with caching files in the browser, that use localStorage by default, & will use other storage methods for fall backs on older browsers. Would using an outside util, rather than baking in the function, be better?

[3rd-Eden]

Yes localStorage makes sense. But there are couple of reasons of why localStorage would not be an option in every browser:

• Browser is to old and doesn’t support localStorage, fallbacks and polyfills could be used they would add unnecessary bytes to core library.
• LocalStorage might be full. It has a limitation of 5MB which we need to share with the application that is actually using BigPipe as a framework. So we might even need to make this opt-in/out.
• LocalStorage is not enabled or throws when you run in private browsing mode.

@okayzed

I don’t think that a timestamp would be needed in the localStorage if we’re already providing it with an hash. This hash could also be used as an id.

As we’re already sending the file names (which are hashes of the content) to the server we can simply check if the hash is available in localStorage. When it is, we could serve that instead of doing a server request. So I think that an non-prioritized cache check might make more sense for us.

As for enforcing asset freshness, i’ve been looking at DynoSRC: https://github.com/DynoSRC/dynosrc to see if that would be a solution for us. An alternate and older solution like DynoSRC is diffable which is something that the Google Maps was/is using for their assets: http://www.stevesouders.com/blog/2010/07/09/diffable-only-download-the-deltas/

This might be a great solution for this whole issue as it would already cache assets locally and only transfer the diff to the client.

[okayzed]

@3rd-Eden the timestamp is to help with resolving the case of two (or more) open tabs trying to write their versions to localStorage. the timestamp lets each tab know if their version is the newest or not. otherwise, there might be a sync war while they try to figure out who's version of the site is right. (just having hash makes it difficult to know which version to evict from storage).

i use 'local storage' loosely, but i menerally gean 'client storage', whether it is indexdb, localStorage, sqlite, what have you.

re: dynosrc: it looks really cool but is still a layer above the storing in client storage optimizations. (let's call it the 'sync assets to server' version layer and can be implemented on top of whichever solution :-)

a thought off the top of my head is: how important is sending 'diff' updates? it makes sense when using large bundles (or huge libs, like highcharts, jquery, etc), but if each module of the app is cached in localStorage, will it be a big deal? i'm thinking that most modules will not be larger than 1 - 5K, unless they are vendor libraries.

another note is (maybe importantly): won't it grow really large to be able to fast forward any number of clients to the current version? it seems a nightmare to maintain the database of diffs unless some severe restrictions are placed on the recency of modules that you are allowed to fast forward.