5 Mar 2014
Like most clickbait, the title of this post isn’t quite accurate. For one thing, this post isn’t about a trick, it’s about a technique that’s been painstakingly developed and tested over the course of the past six years. And it isn’t weird — unless you think really, really smart ideas are weird.
But the bit about making pages up to 70% faster is true.
Our FastView solution offers an acceleration treatment called auto-preloading. This feature sometimes gets mistaken for a well-known performance feature called browser preloading. But aside from sharing a bit of nomenclature and some philosophical similarities, the two features have very little in common. In this post, I want to clarify how these two features are different and why they’re complementary. (Our VP Acceleration, Kent Alstad, has also written an excellent post that takes a much deeper dive into the history and anatomy of auto-preloading, which I strongly encourage you to check out.)
How the browser preloader works
Browser preloading isn’t new: it’s been around since 2008. If you’ve spent any time in the performance space, you already know all about the browser preloader. If you don’t, Andy Davies has written the most informative post about it I’ve encountered. As Andy points out, “the pre-loader (also known as the speculative or look-ahead pre-parser) may be the single biggest improvement ever made to browser performance.” In the very simplest terms, browser preloading takes advantage of time that the browser spends waiting for scripts to download and execute by finding and retrieving other page resources (e.g. images, CSS, scripts) and downloading them in the background, so they’re ready to render as soon as the main HTML parser gets to them.
As you might deduce from the name, browser preloading is initiated at the browser, meaning that it’s the purview of browser vendors. As Andy mentions in his posts, there are a few ways you can influence the preloader, but historically, these have been pretty limited.
This seems like a good segue into auto-preloading, so let’s talk about that now.
Auto-preloading: The best web performance technique you never heard of
While browser preloading is initiated by the browser and focuses solely on the current page, auto-preloading happens near the origin and focuses on subsequent pages in a user’s path through a website or application.
And while browser preloading delivers up to 20% improvement, according to Mozilla and Google, we’ve found that auto-preloading delivers up to 70% acceleration gain even when we’ve turned off every other FastView treatment.
Here’s an extremely simplified version of how it works…
Auto-preloading takes advantage two key things:
- The highly intelligent, dynamic analytics engine already present in our FastView technology
- The time a user spends viewing a page
The FastView engine observes and records every single user path made by every single user who visits a website. As you can imagine, this generates a massive amount of traffic-related data. Based on this massive amount of data, the engine can predict with an extremely high degree of accuracy where a user is likely to go based on the page they’re currently on and the previous pages they’ve visited. FastView then quietly loads the resources for those “next” pages in the visitor’s browser cache, so they’re waiting on standby.
Here’s a very simple example: On a typical ecommerce site, the FastView engine might see that 90% of users coming to a site via the home page visit the search page next. FastView then delivers all the individual resources for the search page to the user’s browser, so they’re waiting in the cache. When the user gets to the search page, all those resources have already made the trip from the host to the browser.
When you consider the fact that a typical web page can contain dozens of images alone, and that images comprise about half a page’s weight, it’s easy to see how auto-preloading images into the browser cache can deliver significant performance gains. It’s an awesome workaround for the latency problem, which is arguably the number-one enemy of performance.
Auto-preloading also works around some of the gotchas created by other performance techniques. Resource consolidation, for example, is a common optimization best practice. Similar page resources, such as images, are consolidated and sent together in a single bundle from server to browser, minimizing server roundtrips. But simple consolidation doesn’t help with multiple page visits in a user’s path through a site. For example, a bundle that delivers all the images needed by the first page in a flow may contain only a few of the images needed by the second page, meaning that a new bundle needs to be created for page two — wasting an opportunity to leverage efficiencies in sending resources that would be used by both pages.
Learn more about auto-preloading
This feature wasn’t developed overnight, and its history is fascinating. I encourage you to read Kent’s excellent post about the anatomy of auto-preloading, which includes details of how we overcame roadblocks such as how to make it work with the unique requirements of every browser and how to create perfect preload lists on the fly. And if you’re looking for product-related information, auto-preloading is a feature in our FastView technology, as well as the latest release of our Alteon ADC.