Bug 194539 – Add support for <link rel=prefetch>

• Status: NEW
• Component: Page Loading

[Alexandre Dieulot]

<link rel="prefetch"> can enable a site to make its page load near-instantly very easily. Users respond strongly to faster loading pages, as detailed in the first footnote on https://instant.page/ (it’s often been reported that 100 ms less latency results in 1% more sales).

https://instant.page/ prefetches a page on mouseover/touchstart and can make web pages near-instant in just one minute of work. It was released three days ago and got great responses (1200 points and #1 on Hacker News, #1 on Product Hunt).

https://github.com/GoogleChromeLabs/quicklink prefetches links that are in the viewport. It was released two months ago and amassed 5900 stars on GitHub.

So <link rel="prefetch"> gives tremendous results and there’s demand for it.

Maciej Stachowiak told me on Twitter that “WebKit has code to support link prefetch, but it's not enabled on macOS or iOS”, which is a bummer.

Firefox got it in 2006, Chrome in 2010, IE in 2013. Safari is the only one missing on it.

[Radar WebKit Bug Importer]

<rdar://problem/48001099>

[Alexandre Dieulot]

instant.page’s CDN served the script to 63 400 000 persons in the last 30 days (over 1% of internet users). Quicklink has twice has many stars on GitHub than instant.page. So enabling <link rel="prefetch"> in Safari is guaranteed to improve lots of people’s experience with the web.

[Brady Eidson]

(In reply to Radar WebKit Bug Importer from comment #1)
> <rdar://problem/48001099>

<rdar://problem/3176096>

[Alexandre Dieulot]

Another use case for this is to make a browser extension to speed up web browsing, like FasterChrome: https://chrome.google.com/webstore/detail/fasterchrome/nmgpnfccjfjhdenioncabecepjcmdnjg

[Alexandre Dieulot]

instant.page’s CDN served the script to 150 000 000 persons in the last 30 days, that’s over 3% of internet users.

[Vasa K]

This is Vasa from Walmart.com. We implemented <link rel=prefetch/> to prefetch scripts  in our customer journey and saw some pretty good TTI improvement across pages. We have a large % of users consuming our site using Safari on mobile. Would be great if we can leverage prefetch for Safari users as well. Any plans of adding this feature in the near future? That would help with expand our gains across our user base.

[Andy Davies]

It's available behind a flag in Safari but it's prioritisation is quite broken when used in markup with a HTTP/2 that doesn't support HTTP/2 prioritisation e.g Netlify

Don't think the issue affects late-injected prefect hints such as instant.page uses

This old Webkit bug is stuff relevant https://bugs.webkit.org/show_bug.cgi?id=49238

[Alexandre Dieulot]

Hmm, guys?

IIRC someone paid Igalia to work on this and it shipped in 13.0 disabled by default.

Safari 14.0 just came out, and it’s still disabled by default.

If you deign enable it in your mid-cycle update around April it will have been 18 months of prefetch languishing there. This is quite surprising — even for an already skeptic person of Apple’s execution on the web platform. It sure doesn’t send a good signal to contributors and wannabe-contributors (including me) that contributing to WebKit is appreciated.

May we know what’s going on?

instant.page’s CDN delivered the script to 223 million people in the last thirty days — to 4% of internet users. A good chunk of my users are US sites and other developed nations, so it’s definitely been delivered to over 5% of Safari users.

[Dima Voytenko]

+1 to find out the state to enable this feature by default.

[Brent Fulgham]

From othermaciej:
"""
The original reason we didn't support it was because it's broken with cache partitioning, which Safari has had longer than other browsers. This post gives the details: <https://www.jefftk.com/p/why-prefetch-is-broken>

See this issue for why the spec is broken for browsers that do HTTP cache partitioning (which will soon be all browsers) and some discussion towards fixing it (including Google, Apple, and Mozilla folks). <https://github.com/whatwg/html/issues/6723>

The prefetch spec doesn't allow implementations to support it only for same-origin . So we didn't really think about that option. We could think about it, but a partial implementation could be poorly received. The partitioning problem will likely be solved in the spec soon.
"""

So, I think we need to let the spec work finish. Once we have an agreed upon plan, we can work to enable this by default.

[Alexandre Dieulot]

> So, I think we need to let the spec work finish. Once we have an agreed upon plan, we can work to enable this by default.

I don’t think so. I think you can enable it as soon as possible only on same-origin (and/or only with documents, whatever *your* issues are). Zero problem.

> The prefetch spec doesn't allow implementations to support it only for same-origin . So we didn't really think about that option.

The prefetch resource hint is progressive enhancement. There’s no penalty to enable it partly.

It’s an API from 2006, this bug ticket didn’t get an answer for three years, implementing it partly is utterly NOT going to be poorly received.

Also, given that Safari 15 might be the last version available on a lot of devices and that this is an API to improve responsiveness, it would be nice to have it in part (the most important part!) as soon as possible.

I’ll try to bring on this issue other folks who make libraries that use prefetching to ask them if they care about waiting on having a perfect spec implementation of if they would rather be able to speed up navigations and save humanity loads of time sooner rather than later.

[Alexandre Dieulot]

My understanding is that cross-origin prefetching works in Safari right now (with the experimental flag on) for top-level navigations. If your issue is that it might at any point stop working and thus stop respecting the spec, that’s no problem (relative to having no prefetching at all). Absolutely no problem.

[Noam Rosenthal]

I'm currently tasked with revamping the spec and WPTs to help flesh out these issues and make them interoperable. Follow at https://github.com/whatwg/html/issues/5229

[Anne van Kesteren]

To be clear: that work has now completed with HTML defining the `prefetch` feature and Fetch defining some of the integration aspects, including the `Sec-Purpose` HTTP request header.

[Michael Hagar]

Any update on enabling the flag by default?