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.
Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, pages should maintain a CLS of less than 0.1.
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 only allows asynchronous JavaScript. We make sure it isn’t accidently performing slow or computationally heavy operations that could otherwise block your users from actually using your site.
Deferred layout
AMP delays rendering elements that are not likely to be seen right away during load to keep the site feeling instant. That means AMP won’t block the user from clicking and tapping because it is processing a heavy, JavaScript-powered video player at the bottom of your site right when your site loads.
Chunked processes
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-in components, which requires developers to tell the browser the height and width of these resources.
<amp-img height="200" width="400" src=...Code language: HTML, XML (xml)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
Many websites use external fonts to style their page. Having to download an external CSS file, find the reference, and download the font can easily cause jittery, jumpy page loads and can lead to a disorienting experience for users. AMP mitigates this by requiring all CSS to be inline, at the top of web site’s source code. Any fonts are quickly discovered and downloaded. Additionally, the async loading of JavaScript mentioned in our FID exploration means that JavaScript also being downloaded won’t block the browser from handling custom fonts.
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.
AMP Optimizer
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.
Next.js
Next, you just need to add a single line of code to turn any React site into an AMP site! Doing so automatically provides you with a wealth of performance optimizations like server side rendering (for a faster LCP), AMP Optimizer integration, and more. Check it out!
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.
Conclusion
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.
If you have any questions, please do let us know, otherwise make sure you are up-to-date with any of the other exciting changes coming to AMP by following us on Twitter, or signing up for our newsletter.
Written by Patrick Kettner, Developer Cheerleader, The AMP Project, Google