FAQ

Is quicklink guaranteed to make your web pages load faster?

No. quicklink attempts to use a heuristic (links in the user's viewport) to decide what links to prefetch for an experience. These may be pages your user is going to visit next, but there is no guarantee this is the case. With this in mind, we recommend measuring the impact quicklink can have on your experience (tools not rules and all that.. :))

If you are looking for a more advanced set of heuristics to decide whether resources should be prefetched, we also recommend trying Guess.js which takes an analytics-driven approach to this problem.

How can I measure the impact quicklink has on my site?

WebPageTest supports measuring page-load performance from one page to another (via it's support for scripting and this is the mechanism we use to determine if quicklink improved performance for an experience.

For example:

navigate    https://example.com
sleep    30
navigate    https://example.com/page-2.html
sleep    30
navigate    https://example.com/page-3.html

A baseline test might measure how long it takes to load and navigate from the homepage -> page-2 -> page-3. A comparison might look at whether quicklink improved how quickly page-2 or page-3 could load up when prefetched.

What kind of performance improvements can I expect to see if I use quicklink?

This can vary based on the architecture of your site and links within the viewport users actually end up navigating to. That said, we can look at a case study of using quicklink on some leaf pages for a re-hosted version of some sites for science.

We cloned some pages from The Guardian, re-hosting them on Firebase. For the same user-flows (navigating between three pages), a page prefetched with quicklink was able to fully load on 3G network connection/Moto G4 in just 1.3s (bottom row). Compare that to the 1.9s it took without any prefetching (top row).

WebPageTest traces for the before and after are both available.

For demo purposes, we also deployed a version of the Google Blog on Firebase hosting. We then deployed another version of it, adding quicklink to the homepage and benchmarked navigating from the homepage to an article that was automatically prefetched. The prefetched version loaded faster.

Here's a WebPageTest run for our demo improving page-load performance by up to 4 seconds via quicklink's prefetching. A video comparison of the before/after prefetching is on YouTube.

Please note: this is by no means an exhaustive benchmark of the pros and cons of in-viewport link prefetching. Just a demo of the potential improvements the approach can offer. Your own mileage may heavily vary.

Does quicklink improve the first-load experience of web pages?

quicklink is focused on attempting to improve the user-experience of subsequent navigations on a site. This means that it won't improve page load performance for the first page in a funnel loading it, but it should hopefully improve perceived latency of the next page (if it is a page that met the criteria for being prefetched).

Doesn't eagerly prefetching pages waste bandwidth and system resources?

quicklink intentionally checks if a user has opted into a Data Saver mode or is on a network connection that is effectively slow. If this is the case, we bail on prefetching entirely. We want to be mindful of your data usage. If however you're on a connection that is effectively faster (think 4G, WiFi etc) and you haven't turned on a Data Saver mode for your browser, we do prefetch.

Shouldn't browsers explore automatically using some of these types of optimizations?

Some browsers have (but don't necessarily use the same heuristics quicklink does). Chrome has supported opting into a Use a prediction service to load pages more quickly mode.

Is quicklink guaranteed to only prefetch resources when a user isn't on a slow connection or when they don't have Save-Data on?

quicklink relies on the Network Information API for signals about a user's effective network connection type (e.g 2G/3G/4G) and whether Save-Data is on. As this API is available in Chromium browsers (e.g Chrome, Brave, Yandex) but not say, mobile Safari, there is a chance you're going to prefetch resources for a user on an iPhone that might be on a slower connection.

There are patterns that can be used to work around this. For example, one option is to only prefetch using quicklink if a browser supports these signals:

if ("connection" in navigator) {
  if (navigator.connection.effectiveType || navigator.connection.saveData) {
    // Won't run on browsers without sufficient Network Information API support
    quicklink();
  } 
}

Is it important for users to be able to opt-out of prefetching on a site?

Data Savers allow users to signal to a site if they would prefer lighter data-usage where possible. quicklink respects Save-Data preferences where navigator.connection.saveData is supported by the browser.

What if your users aren't likely to know about or use the built-in Data Saving features available in your browser? Or, what if you'd like to offer users a cross-browser data-saving experience? This is also an option.

Twitter Lite has a Data saver feature that you can turn on in the settings menu to load lightweight previews of images and help you save up to 70 percent on data usage.

Large sites like Twitter have shipped custom data-saver modes that don't rely on navigator.connection.saveData.

There are a number of UX options you have here, including providing users an opt-in guard for quicklink prefetching.