When it comes to making the Internet a better experience for all, you need to take advantage of every opportunity to enhance website performance. In this article, we look at browser hints like prefetch and prerender along with the newer preload directive to see how they can potentially improve performance. We also take into consideration what that means for synthetic and real browser monitoring.
What is a browser hint, and how does it help with web performance?
Browser hints (also called resource hints and speculative fetch) aren’t anything new; Mozilla introduced prefetch in 2006 in its Firefox browser. A browser hint tells the browser about possible future navigations. Browser hints allow the browser to use idle time to retrieve or prepare to retrieve resources in anticipation of the user’s next action. The browser decides if it will process the hint based on the user’s device, available bandwidth, and other environment variables. Browser hints come with very low priority, and sometimes the browser ignores them completely.
We’ve included the most frequently used types in this article, but you can find a complete list of possible types at the W3Schools. The options for browser hints include:
Prefetch
Prefetch is a browser suggestion meaning that the URL is the most likely target of the next navigation. The browser, if it chooses to act on the hint, places the response into the device’s cache and will not perform any processing on the response. For example, while in the checkout process, the user is currently on a page where they review the contents of their cart. The next page collects the shipping information and preferences. You can improve the performance of the shipping page by having the browser retrieve some resources needed for the shipping page while the user contemplates their cart. Once the visitor navigates to the shipping page, the browser only needs to retrieve the previously fetched resources from the browser’s cache.
Prerender
Prerender is similar to a prefetch, except prerender retrieves the entire page instead of designated resources. Prerender directs the browser to process the content and store it in the device’s memory. When using prerender, you want to be certain that the visitor will navigate to the prerendered page; otherwise, you’re overtaxing your server and wasting your visitor’s data plan and bandwidth.
Alex Painter in his article, “Should you use prerender on your website” says, “Simply adding rel=”prerender” to a <link> element in the HTML may also not be the best way to implement the technique. Instead, consider using JavaScript to delay prerendering until the original page has finished loading or even adding an event handler to a hyperlink so that prerendering will be triggered when the user hovers over it.”
DNS Prefetch (dns-prefetch)
A DNS prefetch works just like a regular prefetch, but it only resolves the DNS. The hint tells the browser that it should resolve the DNS for the user’s future navigation. By making this necessary round trip early, you can shave valuable time off of the front end processing time.
Preconnect
This takes the DNS prefetch a bit further and tells the browser to go ahead and resolve the DNS, make the TCP handshake, and TLS negotiation (if any) for the user’s next navigation.
Next and prev
If a page is part of a series of pages such as a photo gallery, an article that spans multiple pages, or a product catalog with pagination, the next and prev hints tell the browser about the possible future user navigation. Also, Google uses next and prev to improve indexing for the pages in the series.
Preload or declarative fetch
Browser hints as described above tell the browser that the next page may need these resources, but preload tells the browser that it needs the resource for the current page. A preload forces the browser to retrieve the resource as soon as possible instead of waiting until the resource is needed later in the page. For example, a resource may not reside in the HTML, but deep in a CSS or script file, and waiting for the CSS or script file to load and then retrieving the resource wastes valuable load time. A preload directive tells the browser about the resource early so that it can get the resource as soon as possible. Preloads are especially useful when using web fonts.
Reported benefits of using preload
Addy Osmani, an engineer with Google, wrote a great article on preload, and he reports several use cases where the preload directive made significant improvements in performance.
- Housing.com saw a 10% improvement in performance when they began preloading late-discovered scripts.
- Shopify saw a 50% improvement (1.2 seconds) to first meaningful paint when they used preload to fetch web fonts.
- Treebo saved one second by preloading their header image and webpack bundles.
Using browser hints and preload on your site
You declare browser hints and preload directives using the <link> tag. The link tags sit in the page <head>. The link tag’s relationship (rel) attribute tells the browser which type of hint it would like used.
<link rel=“prefetch” href=“//www.yoursite.com”>
<link rel=“dns-prefetch” href=“//www.yoursite.com”>
<link rel=“prerender” href=“//www.yoursite.com”>
The browser sets the priority for the link based on the relationship attribute. Prefetch, prerender, preconnect, next and prev all receive a low priority while preload may receive a high priority based on the preload link’s “as” attribute. If there is no “as” attribute, the resource gets a high priority while as=“script” may get downgraded to a medium or low priority. There are many possible directive types:
as=“audio”as=“video”as=“font”as=“script”as=“image”
You can view a complete list of “as” attribute types in the Preload W3C Candidate Recommendation.
As mentioned earlier, browser hints (not preload) typically receive very low priority by the browser. You can improve the chances of the browser acknowledging the hint by setting the “pr” attribute. The “pr” attribute tells the browser the probability that it will need the resource by ranking it from 0 to 1. For example, the link tag below has an 80% probability of being needed for the next navigation.
<link rel="preconnect" href="http://www.yoursite.com" pr="0.8">
How do browser hints and directives affect my monitoring?
You may wonder how preload and browser hints affect your monitoring results. The effect, if any, depends on the type of monitor. Monitor types such as SSL, DNS, and external server monitors are not affected in any way since they do not use a web browser, but your Real User Monitoring and some Synthetic Monitoring may show some differences. When a monitor uses real browser technology, the entire page is loaded into a native browser (Chrome, IE, Firefox, Phantom JS) by the checkpoint just like your actual users do when accessing your site, so any hints or directives will also get processed and may influence performance for some monitor types.
Browser hints
Because browser hints like prefetch and dns-prefetch do not execute until after the current page loads, your Full Page Checks and Availability Monitoring will not show any differences in performance (that’s because we start every synthetic check with a clear cache). Transaction monitors that span multiple pages may show improved performance after the initial navigation request if the first page includes browser hints. Because browser hints are only suggestions, you may see shifts in performance based on whether or not the browser chose to follow the suggestion.
Preload
A browser hint is optional for the browser, but a preload directive isn’t a mere suggestion to the browser but a requirement, so the browser must follow the directive to retrieve the resource. The preload directive has the browser retrieve the resource asynchronously while it downloads the rest of the page, so your real browser monitors like the Full Page Check and Web Application monitors will hopefully see a performance boost. The preloaded resource will appear early in the Full Page Check’s waterfall report. In the waterfall example below, resource 3 is a script file. Resources 4 and 5 are also script files, but 4 and 5 use the preload directive while resource 3 does not. Script files are render blocking which means that the browser waits until the resource completes loading before requesting the next resource (notice resource 6 doesn’t start until resource 3 completes). Because resources 4 and 5 use the preload directive, the browser can go ahead and downloaded them while it processes the previous render-blocking resource. Without the preload directive, these scripts wouldn’t load until later, and they too would become render-blocking elements.
What about my Real User Monitoring?
Real User Monitoring (RUM) works off a script located on each monitored page. If users enter the page directly, they will not receive the benefits of any browser hints, but they will see improvements based on preload directives. Once on your site and if the subsequent page is also RUM enabled and utilizes the resources defined in the user’s current page, the user should see improvements and those performance enhancements will affect your Real User Monitoring results. Because Uptrends aggregates your performance data, your reports will show you the performance results based on every page visitor, not just those coming from pages with browser hints for the page.
A note about prerender
When you conduct a prefetch, the resource is retrieved and stored in the browser cache, but the browser doesn’t process the resource until the browser needs it. For a prerender hint, the browser downloads and fully processes the page and then stores the complete page in cache. Microsoft describes the process as being like opening the page in a hidden browser tab with all the resources downloaded, the DOM created, the page laid out, the CSS applied, and the JavaScript executed. If the user navigates to the pre-rendered page, the hidden page is displayed, and it appears to the user to have loaded instantly. Instant loading is great for the end user, but if you use prerender on a page that uses analytics and the user never actually navigates to the prerendered page, your analytic reports still may register the page view because the script file was executed as part of the prerender process. Although prerender has limited browser support (see the table below), if your visitors use a browser that supports prerender and the browser chooses to execute the prerender, your reports will show the page view.
Closing thoughts
Browser hints, when used responsibly, are a powerful way to improve the user’s experience on your site. You need to consider the options carefully so as not to abuse the user’s bandwidth and data plan, and you don’t want to put an undue burden on your servers. Sérgio Gomes, a developer at Google, has an excellent article on browser hints that includes lots of additional tips and caveats for you to consider before electing to employ some of these optimizations in your code.
You will see the performance gains for preload in your Full Page Check waterfall reports, and your site visitors will see the enhancements browser hints can make as they click their way through your site. After all, it’s the quality of the user’s journey that keeps them on your site and keeps them coming back. Improve their journey with preload directives and browser hints, and assure a fast and successful journey with monitoring from Uptrends. With Uptrends you will know the moment that your website, web service, or API experiences a problem. Early warning with Uptrends’ many alerting options can help you minimize outages, preserve performance, and keep your users happy.
Leave a Reply