Google Search recently announced a new Search ranking signal centered around page experience. We’re excited by the potential for Google’s page experience signal to guide and empower developers to build a better web. Because AMP was developed to help enable development of user-first sites, we believe AMP is a cost-effective and simple solution for publishers to create a great page experience. In today’s post, we want to step through what the announced changes to Google Search mean for the AMP community as well as the web ecosystem.
How AMP can help you create a strong page experience
Google’s page experience signal relies on a suite of metrics collectively known as Core Web Vitals, in addition to signals such as mobile-friendliness, safe-browsing, HTTPS-security, and intrusive interstitial guidelines. This emphasis on improving user experience across the greater web aligns well with the vision and lessons learned from AMP. Google performed an analysis using the Chrome User Experience Report showing that the majority of AMP page loads will meet the Core Web Vitals, and even more still when you allow for AMP cache-delivered page loads.
Earlier this month we detailed how AMP can help site owners meet the recommended performance targets outlined by Core Web Vitals. However, there are aspects of handling performance that are out of AMP’s control, such as image-optimization and server response times, that may result in a suboptimal page experience. Make sure to check out the guidance in this blog post to optimize your AMP pages for a great page experience.
AMP Project contributors will continue working hard to ensure site owners get the strongest performance and user experience when creating AMP pages. With AMP, site owners can access these improvements without having to further invest money or engineering time. For example, recently we optimized numerous AMP components to improve measures of Cumulative Layout Shift (CLS), a Core Web Vitals metric that will contribute to the page experience signal.
Google’s continued investment in AMP
Google will continue to invest in AMP, and strongly believes in the AMP Project’s goal to make it easy to create web pages that provide a great user experience. When available, Google Search will continue to direct users to the AMP versions of web pages in the mobile Top Stories feature. This behavior keeps in place hallmarks of the AMP experience, such as privacy-preserving pre-rendering that can happen when content is served from an AMP cache. This also means that the page experience signal for a given search result will be evaluated based on the performance of the AMP page when available.
The AMP Project will continue to focus on creating strong page experiences. AMP’s always up-to-date “evergreen” release schedule means AMP users will get future performance benefits as we make them, without investing additional engineering resources.
Google’s roadmap for page experience is an exciting milestone for any web site or framework that prioritizes performance and user experience, including the AMP Project. We believe AMP makes it easy to not just create pages that are optimized for page experience, but do so with minimal on-going effort.
Please let us know if you have questions or feedback regarding these recent announcements.
In the meantime, we hope you are all staying safe.
Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Principal Engineer at Google
This week Google announced the Web Vitals initiative, a collection of guidelines highlighting what Google believes is essential to a good user experience on the web. Since the AMP Project’s goal has always been to ensure that the “web works better and faster for everyone, everywhere”, we wanted to share how AMP can help site owners meet the recommended performance targets outlined by Web Vitals. We will dive into the work that goes into making the web feel instant, and share what you should be doing to make it even better.
What are the Core Web Vitals?
There is a lot to Web Vitals! We are going to be covering Core Web Vitals in this post; you can learn about the difference on web.dev. Here is the most relevant information from that site:
Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools. Each of the Core Web Vitals represents a distinct facet of the user experience, is measurable in the field, and reflects the real-world experience of a critical user-centric outcome.
The metrics that make up Core Web Vitals will evolve over time. The current set for 2020 focuses on three aspects of the user experience—loading, interactivity, and visual stability—and includes the following metrics (and their respective thresholds):
Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.
First Input Delay (FID): measures interactivity. To provide a good user experience, pages should have a FID of less than 100 milliseconds.
Don’t get lost in the jargon, the key point is that these metrics help you make sure that a site is meeting critical user experience expectations, and they can be measured in the field via new cross-browser APIs.
All of these can (and should) be measured in the field, so you can keep track of what your users are really experiencing, not just results from a lab. Now that we know what makes up these new guidelines, let’s look at what AMP does to meet them.
First Input Delay
Having a low FID score means that when users click on a button, or tap on an input, they don’t have to wait and the site responds near instantly. According to the documentation on web.dev, the goal here is 100 milliseconds at the 75th percentile. That means that the first time a user interacts with an input, it takes less than 100ms to react for at least 75% of the time when that page is viewed. Like all of the Core Web Vitals, this information needs to be collected from your users. If you aren’t already, you should be looking at reports for your real user data (hint: PageSpeed Insights is a great place to start) to see if you are meeting these thresholds, not just what’s measured on your development machines.
In fact, FID can’t be measured in development – the only way to get meaningful data is by seeing how long real users’ interactions take on your site. Total Blocking Time is a good analog to use while developing. They don’t measure the same thing, but if you reduce TBT, you will likely reduce FID! If you are seeing a lot of high FID values, it usually means the browser’s main thread is busy doing something else like parsing code, loading third party resources, etc. You can learn more about how to improve your FID score on web.dev
AMP works to keep your FID score low in a number of ways:
AMP’s code won’t block your users
AMP implements process chunking to make sure that long running tasks get split up, and don’t lock up your page. By keeping big tasks split into bite sized versions, AMP keeps your site feeling responsive to every interaction.
Sandboxes for everything else
If code from outside of AMP is needed, it has to run in its own iframe. By running that code in its own container, it can’t block the user from interacting with your page. That means that slow ads or code heavy video players won’t stop users from actually being able using your site.
Cumulative Layout Shift
You may have seen our recent deep dive into CLS on the AMP Blog. Web pages jumping around due to slow loading content, or oversized images and video leads to all sorts of real world user frustration today. That is why having a good CLS score is a critical part of a well built site. Google’s recommendation is that your CLS stays below 0.1. This is a bit more complex of a measurement than the other Core Web Vitals, so I encourage you to read the web.dev documentation to get a better understanding. The key thing to understand is that a low CLS means that what your user sees is a stable and predictable, not jumping around.
CLS is another area where AMP really shines. It’s been built from the ground up to avoid the most common pitfalls of sites that score poorly on CLS. It has a number of rules in place that help you keep this number low, including:
Statically-sized layout system
AMP’s layout system is built on the goal that it be able to infer the size of resources before it downloads them. For example, AMP requires any images, video, iframes – anything other than text, to be loaded via built-incomponents, which requires developers to tell the browser the height and width of these resources.
By making sure these attributes are included before the content is downloaded, AMP can make sure the browser can lay out the page how it will look once the images are loaded. Without them, the browser will inevitably need to shift the layout as it downloads and determines how much room is needed for each element.
Interaction required for dynamic content
All updates to a page that potentially cause a re-layout need to be triggered by a user interaction. You can’t have a widget pop up right before the user taps on something. By restricting updates to happen in response to interactions, your users are a lot less likely to get an unpleasant surprise.
Efficient font loading
Largest Contentful Paint
When a user loads your page, they can’t see network callbacks or other performance indicators. They just see the visual output, or lack of it. LCP measures when the largest element was rendered. Measuring when LCP occurs will give you a lot of insight into just how fast your page actually feels to your users. That is why LCP is such an important metric. The recommendation from web.dev is for LCP to occur within 2500 milliseconds at the 75th percentile.
AMP has a number of optimizations in place to make your Largest Contentful Paint happen as fast as possible, including:
Intelligent resource loading
AMP’s goal has always been to feel instantaneous. One of many things it does to achieve this is to make sure images and ads are only initially downloaded when they are above the fold, or if the user is likely to quickly scroll to them. By limiting the amount of resources being fetched when a page is loaded, AMP can make sure that it is prioritizing the content that users will actually be viewed. The result is a site that feels faster to your users.
Preloading and prerendering
When AMP pages are hosted on an AMP cache, a number of optimizations are added to the page to make sure that it is as fast as possible, like preloading the content. So by the time a user usually taps on a prerendered AMP page, the browser has already downloaded and rendered the entire thing — it just feels instant.
Pushing your AMP pages further
So far, we have just looked at what AMP does out of the box. However, there are a few development practices that our team believes to be essential to a great user experience that just can’t be implemented at runtime. While we try very hard to make AMP perform well beyond the expectations set out by the Core Web Vitals, it is still possible to fall short. To push AMP that much further, there are a number of additional optimizations you can perform yourself. In our research, we have found that developers have headroom to further optimize how they serve their AMP pages. The most common opportunities include:
Addressing slow server response times
If your server is slow, then almost everything will be slow. AMP caches help optimize delivery, like a CDN, but nearly all AMP sites have some traffic outside of an AMP cache. That means making sure your server is fast and responsive is essential to Core Web Vitals success.
Avoid using oversized images
For your site to be as fast as possible, you should avoid using images that are larger than they will be displayed on the website. Websites that load unoptimized images often increase the download size by hundreds of kilobytes, which can directly hurt their LCP results in Core Web Vitals. Make sure your users’ time and bandwidth are being respected by optimizing the images on your AMP origin.
AMP caches will optimize your code to avoid these types of issues, but keep in mind that the optimizations are only performed on caches. Anyone that visits your site directly, whether through a link shared on social media or just directly navigating to your site, won’t get the same experience. In order to ensure that you are getting great Core Web Vitals scores for all your users, it is very important to optimize your site at the origin!
Tools to make AMP even better
The AMP team provides a number of open source tools to optimize your site.
The AMP Optimizer is a great option to improve AMP rendering performance. With features like server-side rendering and code minification, the AMP Optimizer is a great first step to making sure your site is loading fast.
AMP for WordPress Plugin
If you are on WordPress and interested in AMP, you should check out the official AMP plugin. Developed and maintained by the AMP team, it brings AMP content generation into WordPress, the WordPress way, and gives you a turnkey option to publish fast AMP pages, without requiring deep technical expertise in performance optimization! The Official AMP plugin also provides developers with advanced tooling to help them with AMP development in WordPress.
The earlier you add performance optimizations, the better. By using tools like the ones mentioned above, you can make sure every user gets a fast and smooth experience, not just the ones who come to it via a cached page.
Web Vitals and Core Web Vitals are an important step forward in helping site owners understand where and how to improve user experience on the web. Not only will they help developers improve and maintain great user experiences today, but they will also keep developers informed about the latest performance expectations on the web as they are updated in the future.
AMP Project contributors around the world are dedicated to ensuring site owners are getting the strongest performance guarantees when creating AMP pages. The AMP team continuously monitors how AMP pages are performing on the web, and regularly updates the AMP library with performance enhancements. And since AMP is an always up-to-date “evergreen” library, it means that without any added effort on your part, you and your users will always benefit from the latest AMP improvements.
Posted by Katharina Familia Almonte, Global Product Lead at Google on the AMP Project
Last year, Chrome announced its plans to introduce a cookie classification scheme as part of its ongoing effort to improve privacy and security across the web, which is expected to take effect with Chrome 80 in February 2020. Mozilla has affirmed their support of the new cookie classification model with their intent to implement the SameSite=None; Secure requirements for cross-site cookies in Firefox. Microsoft has announced plans to begin implementing the model starting as an experiment as soon as Microsoft Edge 80.
The AMP team is committed to protecting user privacy and this blogpost will explain how you can support greater transparency and user choice with the upcoming browser changes, while also maintaining a good user experience with AMP. With Chrome 80 expected to launch in February, this blogpost will focus on Chrome’s changes specifically.
Chrome’s new cookie settings explained
Chrome’s new secure-by-default model assumes that all cookies should be protected from external access unless otherwise specified. Developers must use a new cookie setting, SameSite=None, to designate cookies for cross-site access, and an additional Secure attribute so cross-site cookies can only be accessed over HTTPS connections. Chrome will treat cookies that have no declared SameSite value as SameSite=Lax cookies. Only cookies with the SameSite=None; Secure setting will be available for external access, provided they are being accessed from secure connections. For more detail on the new model, read this developer blog post.
If your site needs to access your own first party cookies on AMP pages rendered in the AMP Cache, we recommend assessing carefully whether the upcoming browser changes will impact your user experience. This could be the case, for instance, when users transition from the AMP cache to the origin domain and a paywall, login state, measurement or shopping cart functionality relies on first party cookie access. There are two different solutions you could employ, but which one is best for your site will depend on your specific use cases and can change over time.
Designating cookies for cross-site access
One solution for AMP publishers affected by Chrome’s cookie classification changes, is to set your first party cookies on AMP pages to SameSite=None; Secure. This will designate the first party cookies for cross-site access and avoid disruptions in user experience:
The benefit of this approach is that it is the easier one to implement, but if browsers proceed to offer users fine-grained controls to manage cookies accessed by a single site separately from cookies accessed across multiple sites, there is a higher risk that users will clear your first party cookies on cached AMP pages since they will be marked for cross-site access.
Signed Exchange offers help
Alternatively, publishers can use Signed Exchange to achieve a state where first party cookies are treated as such on AMP pages rendered in the AMP Cache. Signed Exchange is an emerging technology that can be used to attribute the page’s URL to the original publisher domain, even when the page is delivered via the AMP cache with all of the loading speed benefits it provides (see blog post and guide). The benefit of Signed Exchange here is that when browsers start preventing cookies from external access unless they are specified otherwise, Signed Exchange will ensure that your first party cookies don’t require designation on pages rendered in the AMP Cache. But Signed Exchange does not currently address all use cases as it is not supported in the Top stories carousel at the time of writing.
In summary, Chrome is planning to introduce its new SameSite=None; Secure cookie settings in February. To ensure an optimal user experience on pages in the AMP cache that need to access first party cookies, we recommend publishers designate cookies for cross-site access via these new settings or implement Signed Exchange. We hope this blog post helps you maintain a good user experience while also supporting the path to greater privacy controls for users, as browsers start adopting the new cookie classification model. For more details on how to use and test Chrome’s SameSite cookies check out the guide on web.dev and the tips in the Chromium SameSite Updates.
Posted by Jeffrey Jose, Product Manager at Google on the AMP Project
The California Consumer Privacy Act (CCPA) is a new data privacy law that establishes various rights for California state residents. The law applies to companies that do business in California and meet one of several criteria related to revenue, data processing, and other factors.
Updates to the AMP consent framework
Based on the feedback we heard from publishers, we’ve updated the AMP consent framework to obtain the consent publishers might deem necessary for CCPA compliance. With these new updates, publishers can include multiple consent prompts and trigger the right prompt based on the location of the user.
Consent across multiple surfaces
Publishers who wish to keep user consent in sync between multiple surfaces can store the user’s consent on the server-side and expose the information to <amp-consent> via the checkConsentHref attribute. You can configure AMP to check your endpoint first and the response determines whether a user-consent prompt is displayed or not. Additionally, the previously obtained user consent can be passed from the server to the ads and analytics vendors configured on the page.
Support in AMP Stories
For AMP Stories, publishers can create links to their CCPA opt-out page within a story to collect user consent.
To make development easier, we plan to extend <amp-geo> in the future by providing US state level detections of users. As always, we invite you to submit new ideas by filing an issue. If you’re a vendor who wants to customize how your AMP extensions behave based on user controls, please get started by following our contribution guidelines.
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”.
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.
We’ve seena lot ofinterest 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.
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.
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
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.
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.
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.
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
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.
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.
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!