AMP

Innovation in navigation on the web platform

Web Standards

In this third post in our series on contributing back lessons learned from AMP to the whole web, we’ll dive into the topic of innovating on the concept of navigation for web content. Additionally, we’re taking a look at how new primitives in the web platform are helping to make AMP simpler and “less of a thing”.

If you haven’t read the first or second post, we’d suggest to hop over there before reading this.

For as long as the web has existed, navigation meant that when the user clicked a link, the browser would paint white, and eventually it would paint the new page and update the URL bar. While this is an amazing model, more sophisticated interaction patterns have emerged on mobile. So far it has only been possible to implement these on the web using complicated “single-page app” patterns that use iframes for third-party content. Iframes are a great asset to the web platform. They enable composability, one of the SLICE special powers of the web. Unfortunately, the composability enabled by iframes inherently results in restrained user experiences. An iframe is like a fixed window: it lets you see into another world, but since it can’t be opened it doesn’t let you cross to the other side. The Chrome team took notice of an early exploration called iframe promotion which was designed to give iframes the ability to be navigated to. After a few rounds of discussion to build on this idea, the Chrome team identified a way to avoid the architectural complexity of a solution based on iframes and proposed a similar approach called Portals which allows for unfettered composability.

https://blog.amp.dev/wp-content/uploads/2019/06/portals_h264.mp4
Portals demo

We’ve seen a lot of interest about Portals from the web community, if only because they’ll allow for applications with the simplicity and robustness of having single pages per URL with the interaction fidelity of single-page apps.

With Portals we hope to be able to implement experiences like Google’s Top Stories carousel without having to rely on application layer solutions like AMP. Beyond that there are a lot of exciting use cases for Portals such as payment or single-sign-on solutions that are visually integrated into a website, but when activated show the user the true origin they are interacting with such as their payment provider.

Simplifying AMP

Putting all the things we introduced in this and previous posts together, one cool side-effect of the web platform getting more powerful is that we are getting ready to make large chunk of AMP literally go away and be replaced by simple platform primitives.

One example that is within arm’s reach is the removal of amp-img as a web component. With lazy loading, priority hints, and intrinsic sizing being implemented in browsers, it is possible to see a future in which there is no longer a need for the custom component–and while it’ll stick around for backward compatibility, it makes us incredibly happy to make AMP less complicated and instead focus even more on providing high level components in an easy to use framework, as opposed to the platform magic on top to make it all work.

Summary

A lot of progress has been made over the last year in advancing web standards along various dimensions. Above we highlighted the areas that the AMP team together with our friends from Chrome and Igalia have invested the most time on, but we also want to recognize that lots of other folks in the entire web community are doing awesome work on web standards which are helping make the web better every day. The AMP team is learning a lot from the web community and is currently most excited about isInputPending, display locking, and Animation Worklet.
Concrete proposals for privacy-preserving instant loading, innovative navigation, performance assessment, and development guardrails are now on the table and in varying stages of implementation. We hope that these projects are a step in the right direction to help all web developers create more delightful experiences regardless of implementation choices. We are eager to hear your feedback and can’t wait for the progress that will be made in the next year!

Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Software Engineer at Google 

Privacy-preserving instant loading for all web content

Web Standards

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 

A year into contributing back lessons learned from AMP to the whole web

Web Standards

In March of 2018 we wrote about our effort to contribute back the things we learned from AMP for the benefit of all web developers by addressing gaps in the web platform. In this work we’ve collaborated with the Google Chrome team, Igalia, who is helping us with implementation work in WebKit, and, of course, the wider web standards community. We’ve also learned a lot from the community and have seen a lot of exciting work that we can’t wait to apply. This is an update on how that effort is going.

Our work has focused on bringing the benefits that AMP implemented on the application layer to the whole web platform (AMP or otherwise):

  • Measuring performance and user experience: Make it possible to objectively measure high load performance and certain UX properties, such as a stable loading experience without content that is shifting around as it loads.
  • Privacy-preserving instant loading: Allow the preloading of web content, before a user clicks, without leaking the user’s interest in the page to the page author until the user navigates.
  • Innovation in navigation: Navigation from one web page to another through means other than the traditional click. E.g. by swiping through a carousel or scrolling from one article to another one.
  • Guardrails: Provide a mechanism for development teams to avoid the use of certain legacy features of the web platform that are harmful to UX. Give development teams  similar control over the behavior of third-party code.

We’ve made significant progress distilling our original wide-ranging ideas and worked with the web community to turn them into concrete standard proposals. This is a lot to go through, so we’ll split things up into a series of posts starting with the topics Measuring performance and user experience and Guardrails today.

Measuring performance and user experience

The AMP team often gets the question: Why don’t you just measure whether a page is fast instead of relying on AMP? And we agree, that is a good question.

One of the big changes in the web space since AMP was created is that there are now tools like the Chrome User Experience Report, which do, in theory, provide a way to get performance data for most sites on the web. Looking at this further we realized, however, that the existing metrics are insufficient to really make statements about the desirable user experience properties of web pages.

Legacy metrics like onload aren’t great proxies for user-perceived performance. Pages can both appear loaded long before onload fires and can appear NOT to have loaded long after onload fires.

One modern metric, First Contentful Paint (FCP), is the only currently available candidate metric for measuring perceived performance at scale. Unfortunately, while good user experiences always have a good FCP, having a good FCP is insufficient to really know whether a page is fast. FCP should probably have been called First Not-Completely-Trivial Paint because it is clear that users would in many instances not consider a page to be sufficiently rendered at the time of its FCP. For example, a loading indicator would trigger FCP, but the user wouldn’t be happy at this stage.

For these reasons we invested in defining additional metrics that would paint a more holistic image of user perceived performance. The two metrics currently under discussion are Largest Contentful Paint (LCP, name subject to change), which fires when the largest element of text or image on a page has painted, and Layout Stability, which is an indicator for how stable the layout is during page load. We’re hoping that these metrics, together with First Input Delay, which is further along in standardization, would allow one to say with reasonable confidence whether a page is fast and well-behaved from a user point of view.

An example of a page doing badly on the layout stability metric.

Guardrails

AMP introduced the AMP validator to ensure that documents complied with a range of best practices and to give helpful error messages when they didn’t. Based on earlier work by Tim Kadlec and Yoav Weiss on the Content Performance Policy idea, the notion of Feature Policies was developed through discussions with the web community. They provide both a way to turn off harmful legacy features, such as synchronous XHR, and to report violations of best practices, such as loading images that are much bigger than necessary, to the development team of a website.

A whole range of Feature Policies are in the works now covering many aspects of web development. One interesting aspect for Feature Policies that while wide browser support is desirable for enforcement, for reporting only mode, where you get notified about issues with your website, partial browser support is often sufficient to solve the identified issues for users of all web browsers.

Summary

This ends part 1 of our series of posts on contributing back lessons learned from AMP to the whole web. Thanks to the whole web community for the amazing help in getting these standards proposal on track and the great feedback to make them much better than we could have ourselves!

Next up in this series of posts is Privacy-preserving instant loading and Innovation in navigation. They’ll be posted on this blog in the coming days.

Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Software Engineer at Google