We use every trick in the book to speed up our websites. Optimizing images. CDNs. GZIP. Caching. But as sites become more complex and burdened by page weight, reactively responding to user interactions is not enough. We need to be proactive\u2014we need to predict what users want, and even get that content ready for them before they ask for it.<\/p>
With resource hints and directives, you can do just that\u2014tell browsers to fetch and download resources for your pages ahead of time for better actual and perceived website performance. This technique is known as prebrowsing<\/strong>.<\/p> In this post, we\u2019ll explore three key resource hints: preload, prefetch, and preconnect<\/strong>, along with how they work, their benefits, and how to use them.<\/p> Steve Souders coined the term prebrowsing<\/a> (from predictive browsing<\/em>) in 2013.<\/p> Prebrowsing is all about anticipating user actions and preparing content on your site that they might want before they actually need it. It\u2019s a concept that\u2019s a step toward a faster internet, as A List Apart\u2019s Santiago Valdarrama writes in his article, One Step Ahead: Improving Performance with Prebrowsing<\/a>:<\/p> \u201cBrowsers are already working behind the scenes, looking for patterns in our sites to make navigation as fast as possible. Prebrowsing builds on that: we can combine the insight we have on our own pages with further analysis of user patterns. By helping browsers do a better job, we speed up and improve the experience for our users.\u201d<\/em><\/p> You might be wondering, \u201cisn\u2019t this what caching is for?\u201d Well, yes. Browser caching is essential for the fast loading of pages. But there are times when caching needs a little help:<\/p> Fortunately, browsing techniques can help you get around these issues.<\/p> Have you ever wanted to tell the browser about an important font or script without delaying the page\u2019s onload event?<\/p> With preload<\/a>, you can do just that. This directive tells the browser that a resource is needed as part of the current navigation, and that it should start being fetched as soon as possible.<\/p> As Yoav Weiss,<\/a> a principal architect at Akamai who worked on this web standard, explains:<\/p> \u201c[Preload provides] more granular loading control to web developers. It gives developers the ability to define custom loading logic without suffering the performance penalty that script-based resource loaders incur.\u201d<\/em><\/p> When you specify a resource is needed via preload, it is downloaded as a priority and stored in the browser, waiting until it\u2019s referenced in the DOM, JavaScript or CSS.<\/p> The as attribute tells the browser what type of resource it will be downloading so it can be handled correctly. Without it, the browser won\u2019t use the preloaded resource. Possible values include:<\/p> <link rel=”preload”> supersedes <link rel=”subresource”>, which, according to Google<\/a>, had significant bugs and drawbacks. It was never implemented in browsers other than Chrome. As such, Chrome 50 removed support for it in March 2016.<\/p> It\u2019s also important to know preload is a compulsory instruction<\/em> to the browser. Unlike the other resource hints we\u2019ll look at in this post, preload is something the browser must do, rather than optionally.<\/p> Weiss published a definitive guide to preload prior to its release in Chrome. If you\u2019re interested in learning how to use this resource hint effectively, I highly recommend reading his guide<\/a>.<\/p> Don’t forget that preloading is also useful to optimize the Largest Contentful Paint score<\/a>.<\/p> Think you can predict what the user will click or interact with next?<\/p>What is Prebrowsing?<\/h2>
1. Preload<\/h3>
2. Prefetch<\/h3>