Summary: | Add support for <link rel=prefetch> | ||
---|---|---|---|
Product: | WebKit | Reporter: | Alexandre Dieulot <adieulot> |
Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Enhancement | CC: | ad, annevk, barry, beidson, bfulgham, dvoytenko, marcelduran, me, michael.hagar, mjs, noam, rik, tomac, vasa.httpster, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
See Also: |
https://bugs.webkit.org/show_bug.cgi?id=102936 https://bugs.webkit.org/show_bug.cgi?id=51940 |
||
Bug Depends on: | |||
Bug Blocks: | 42501, 49238, 102936, 199162, 202320, 226382 |
Description
Alexandre Dieulot
2019-02-12 06:48:37 PST
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. (In reply to Radar WebKit Bug Importer from comment #1) > <rdar://problem/48001099> <rdar://problem/3176096> 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 instant.page’s CDN served the script to 150 000 000 persons in the last 30 days, that’s over 3% of internet users. 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. 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 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. +1 to find out the state to enable this feature by default. 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. > 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. 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. 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 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. Any update on enabling the flag by default? |