On Tuesday Microsoft Researcher James Mickens discussed Silo, a framework for using hashing and delta-updates to dramatically reduce the number of round-trips to the server needed when loading a website. The technology works in today’s browsers without the need for plugins.
Due to flaws in the current design of the HTTP protocol, requests for related files are not automatically batched. Individually requesting files, especially small files, can result in serious performance problems due to network latency. As you know, even networks with a high capacity can suffer latency issues. This can also causes problems with the server if it needs to authenticate and/or authorize each request.
There are three options for reducing the round-trips to the server.
- Reduce the number of CSS and JavaScript objects… but that means reverting to a poorer user interface.
- Aggressively inline JavaScript and CSS files… but this interferes with browser caching.
Silo introduces a third option: Use the DOM storage for caching instead of the browser’s cache.
Normally control over caching is not possible with website. There is simply no exposed API beyond the basic hints about cache expiration. But with DOM storage developers have complete control. They cannot only decide if a file is to be cached, they can decide how it is cached.
When Silo caches a file, be it HTML, CSS, or JavaScript, it does so in chunks. Each chunk is given an id based on its hash so that it can be reconstructed later. Chunks are not of a fixed width, as that would preclude adding or removing data within a chunk. Instead it uses content-delimited chunks. James writes,
In these systems, chunk boundaries are induced by special byte sequences in the data. LBFS popularized a chunking method in which applications push a sliding window across a data object and declare a chunk boundary if the Rabin hash value of the window has N zeroes in the lower-order bits. By varying N, applications control the expected chunk size. With content-based hashing, an edit may create or delete several chunks, but it will not cause an unbounded number of chunk invalidations throughout the object.
Using a custom server and matching JavaScript libraries, Silo can dramatically reduce the number of round-trips to the server. By default it now takes only two round trips to get all the necessary textual data, once for the list of needed objects and once for the aggregated delta itself. (Note that non-textual data such as images will still need separate round trips.)
When cookies are enabled everything can be done in a single round-trip. If the cache if cold, everything needed to render the page is sent in one request. The browser can then break the objects into chunks and cache them. If the cache is warm, a cookie is sent with the list of cache ids (based on the hash of the chunks) is set to the server on the original request. The server uses the cache ids to determine what chunks are needed and sends just those.
Caching is fine-grained. Since it caches chunks instead of whole files only the deltas need to be send when information changes.
In terms of effectiveness the results vary widely by site. Sites like BBC, CNN, eBay, and IMDB would see significant improvements in loading a page when the cache is cold. For sites like Wordpress blogs, Wikipedia, and Twitter there is limited or no improvement. The difference is based on the number of CSS/JavaScript files, both in absolute terms and in proportion of total files. For warm cache scenarios the benefits are minimal, Silo is tuned primarily for first-visit scenarios.
You can learn more about Silo on Microsoft Research and Channel 9. Currently there are no active plans to turn this into a product but discussions to that effect are ongoing between Microsoft and Microsoft Research.