Bug 194539 - Add support for <link rel=prefetch>
Summary: Add support for <link rel=prefetch>
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Enhancement
Assignee: Nobody
Keywords: InRadar
Depends on:
Blocks: 42501 49238 102936 199162 202320 226382
  Show dependency treegraph
Reported: 2019-02-12 06:48 PST by Alexandre Dieulot
Modified: 2024-01-24 07:32 PST (History)
15 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Dieulot 2019-02-12 06:48:37 PST
<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.
Comment 1 Radar WebKit Bug Importer 2019-02-12 08:11:51 PST
Comment 2 Alexandre Dieulot 2019-06-27 06:54:00 PDT
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.
Comment 3 Brady Eidson 2019-06-27 09:25:46 PDT
(In reply to Radar WebKit Bug Importer from comment #1)
> <rdar://problem/48001099>

Comment 4 Alexandre Dieulot 2019-07-28 07:01:38 PDT
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
Comment 5 Alexandre Dieulot 2020-02-22 16:15:59 PST
instant.page’s CDN served the script to 150 000 000 persons in the last 30 days, that’s over 3% of internet users.
Comment 6 Vasa K 2020-04-20 23:51:39 PDT
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.
Comment 7 Andy Davies 2020-07-23 11:59:44 PDT
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
Comment 8 Alexandre Dieulot 2020-09-29 20:34:58 PDT
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.
Comment 9 Dima Voytenko 2021-07-21 09:36:04 PDT
+1 to find out the state to enable this feature by default.
Comment 10 Brent Fulgham 2022-02-08 23:05:14 PST
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.
Comment 11 Alexandre Dieulot 2022-02-12 08:39:55 PST
> 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.
Comment 12 Alexandre Dieulot 2022-02-12 08:57:34 PST
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.
Comment 13 Noam Rosenthal 2022-02-13 05:40:15 PST
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
Comment 14 Anne van Kesteren 2023-01-25 05:04:17 PST
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.
Comment 15 Michael Hagar 2024-01-24 07:32:08 PST
Any update on enabling the flag by default?