What (not) to Prefetch/Prerender

This post outlines a number of edge-cases we have encountered while developing <link rel=prefetch> libraries like Quicklink. We believe most of these edge-cases apply equally to efforts leveraging <link rel=prerender> or “prefetching” from script. In Summary:

• Avoid prefetching pages for authentication
• Avoid over-prefetching to limit accidental DOS
• Avoid prefetching pages key to checkout
• Avoid prefetching large resources
• Avoid prefetching cross-origin resources

We would recommend any efforts that try to prefetch resources consider supporting these edge-cases. They are quite common in the wild and can, at minimum, make the user-experience less pleasant or at worst, break it when they are not factored in.

Avoid prefetching pages for authentication

Configuration that keeps these classes of pages in mind will avoid running into accidental logouts or session expirations. Even on the same origin, users can find it confusing to login, navigate from a->b and suddenly be kicked out because c (logout) was prefetched.

The fix for this is to detect and ignore pages involved in the authentication flow. Specifically:

• Detect login pages (/login, login.js, login.php etc)
• Detect logout pages
• Detect password reset pages
• Detect sign-up pages

Avoid over-prefetching to limit DOS

Where a server may restrict/limit access due to abuse

Avoid prefetching too often from the same server during a window of time-length N (e.g N=10 minutes). Servers frequently have DOS protections in place these days to avoid abuse from a single IP making too many requests. A heuristic to only prefetch semi-regularly from the same origin may help avoid these issues.

Where a server may not have the capacity to handle so many requests

Avoid creating a large waterfall of requests to the same server on every navigation. It’s hard to determine how well sites can handle the additional traffic that comes from prefetching. Large sites are likely better able to due to their infrastructure.

Avoid prefetching links to pages key to checkout/revenue

• e.g e-commerce carts (e.g /cart, cart.php etc). Doing so can skew their server impressions for how often users are actually trying to view what’s in their cart vs not. It could be argued that this is very edge-case, but including.
• Prefetching “add to cart” links can end up adding items to a shopping cart without user consent. These functionalities are sometimes implemented with <input> or <button> tags, but can also be implemented with links.

Avoid prefetching links to resources known to generally be large

e.g mp4, gif, zip, pdf. Downloading files without user’s consent is not acceptable in most scenarios. This can be particularly harmful in sites that list several files to download (for example, video or music playlist).

Avoid prefetching cross-origin links

Double-keyed caching will heavily impact your ability to do this, but in general, try to avoid doing so as this can leak the user’s browsing history to third parties.

Avoid prefetching Ads

• Prefetching ad links, can make it count as an ad click on ad-servers, leading to inflated metrics, like CTR.
• Ads are usually served inside iframes, which can be ignored by automatic prefetching tools, but sometimes they are inserted in the top level document directly by the site’s author.

Avoid prefetching links to protocols other than http/https:

e.g. tel:, mailto:, javascript:, market:, intent:. Depending on the browser, prefetching these links might trigger actions by the browser in response to them.

By Addy Osmani and Demian Renzulli