Why Facebook Is Loading Faster on Chrome, Firefox

Have you noticed improvements in speed when accessing Facebook via Google Chrome or Firefox? If you have, here’s why:

Infrastructure engineer Ben Maurer and software engineer Nathan Schloss penned a detailed blog post about how Facebook worked with Google and Firefox parent Mozilla on performance improvements, specifically in the areas of browser caches and revalidation.

Maurer and Schloss defined revalidation as when browsers repeatedly request the same content, such as logos or JavaScript code that are reused across multiple pages, and they discussed how they tweaked the browsers’ expiration times and validators for that content so that unnecessary time and bandwidth was not devoted to downloading the same content over and over.

The results of Facebook’s work with Google and Mozilla were:

• Both Chrome and Firefox recently launched features that make their caches significantly more efficient both for Facebook and for the entire web.
• Facebook was able to reduce static resource requests made to its servers by 60 percent, giving those servers more CPU space to load the rest of the web page.
• Due to examining and improving reload button behavior, Chrome in particular went from having 63 percent of requests being conditional to 24 percent of them being conditional.

The blog post went into heavy detail, and some highlights follow:

To stop unnecessary downloads, HTTP servers can specify an expiration time and a validator for each request that can indicate to a browser that it doesn’t need to download until later. An expiration time tells the browser how long it can re-use the latest response and is sent using the Cache-Control header. A validator is a way to allow the browser to continue to re-use the response even after the expiration time. It allows the browser to check with the server if a resource is still valid and re-use the response. Validators are sent via Last-Modified or Etag headers.

A not modified (304) response is sent if the resource has not been modified. This has benefits over downloading the whole resource again, as much less data needs to be transferred, but it doesn’t eliminate the latency of the browser talking to the server. Every time a not-modified response is sent, the browser already had the correct resource. We want to avoid these wasted revalidations by allowing the client to cache for longer.

Revalidation raises a difficult question: How long should your expiration times be? If you send expiration times of one hour, browsers will have to talk to your server to check if your resources have been modified every hour. Many resources like logos or even JavaScript code change rarely; every hour is overdoing it in those cases. On the other hand, if your expiration times are long, browsers will serve the resource from cache, potentially showing users out-of-date resources.

To solve this problem, Facebook uses the concept of content addressed URLs. Rather than our URLs describing logical resources (“logo.png,” “library.js”), our URLs are a hash of our content. Every time we release our site, we take each static resource and hash it. We maintain a database that stores those hashes and maps them to their contents. When serving a resource rather than serving it by name, we create a URL that has the hash. For example, if the hash of logo.png is abc123, we use the URL http://ift.tt/2kxewOl.

Because this scheme uses the hash of the contents of a file as the URL, it provides an important guarantee: The contents of a content addressed URL never change. Therefore we serve all of our content addressed URLs with a long expiration time (currently one year). Additionally, because the contents of our URLs never change, our servers will always respond with a 304 not-modified response for any and all conditional requests for static resources. This saves on CPU cycles and lets us respond to such requests quicker.

Chrome’s and Firefox’s measures have effectively eliminated revalidation requests to us from modern version of those browsers. This reduces traffic to our servers but, more important, improves load time for people visiting Facebook.

This was a tricky issue because we were asking to modify long-standing web behavior. It highlights how web browsers can, and do, work with web developers to make the web better for everyone. We’re happy to have such a good working relationship with our friends on the Chrome and Firefox teams, and are excited about our continuing collaborations to improve the web for everyone!

Readers: Have you noticed any improvements in Facebook’s performance on Chrome or Firefox?

Image courtesy of temizyurek/iStock.

from SocialTimes http://ift.tt/2jVrWo9
via IFTTT