In this second post in our series on contributing back lessons learned from AMP to the whole web, we’ll dive into the topic of instant loading. If you haven’t read yesterday’s post, we’d suggest to hop over there before reading this.
So what is privacy-preserving instant loading? It can be summarized as:
- Instant loading means link navigations work instantly without any perceivable wait time.
- In general that means they work without going to the network, because the network may be slow.
- But not going to the network when the user clicks means to request the page some time before the user really initiated the navigation.
- This may leak sensitive information to the page, such as that the user is interested in it, without user consent.
- Privacy-preserving instant loading is instant loading where this information leak does not happen.
For more on this topic, see our post on privacy and user choice in AMP’s software architecture.
Below we describe a set of changes that combined enable content sharing websites, social media platforms, and search engines, such as Google Search, to provide privacy-preserving instant loading for web content that is not based on AMP.
After an extensive process where both AMP and Chrome teams identified and assessed potential solutions, encouraged by W3C TAG’s recommendation, Chrome’s web platform team eventually convinced us to explore the emerging Web Packaging standard and its component Signed Exchanges (SXG), and further invest in its standardization and implementation. SXGs help with privacy-preserving instant loading by allowing the referring site (such as the search engine) to load a resource from a trusted server without leaking any additional information to a third-party. Then, once the user navigated to the SXG, everything behaves just like any other web navigation (except for the faster load).
SXG support has recently landed in the stable version of Chrome, but is not yet available in non-Chromium based browsers. SXGs are a big step for the web platform: They disentangle attribution (who created a piece of content) from initial delivery (how is the initial view of the content delivered to the user), and guarantee content integrity (the content distributor cannot change it). While this creates exciting new opportunities like a more decentralized web, it also creates new security challenges that need to be worked through diligently.
On top of SXG support, we’ve worked with Igalia on making prefetching available across browsers. While <link rel=prefetch> had been specified for a while and widely used, it wasn’t available in browsers like Safari because of incompatibilities with double-key caches. The Chrome team proposed and discussed a change that makes prefetching compatible with double-keying, and Igalia’s patch just landed in WebKit.
Additionally, the Chrome team worked with the community on clarifying the spec for nested prefetches, i.e. when a prefetched resource schedules additional sub-resources to be downloaded. A Chromium contributor subsequently added support to preload for image srcsets after discussion with other w3c members and our partners at Igalia, who help us with implementing web features in WebKit, have recently landed similar patches in WebKit.
Summary
This was part 2 in our series of contributing lessons learned from AMP to the whole web. We’ve now discussed how to measure performance at scale and how to enable instant loading for web content. In the next post in the series we’ll talk about ideas for how to innovate on the concept of navigation.
Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Software Engineer at Google