Ultimate Guide to Page Experience

Page Experience is a set of factors that measure how satisfactory it is for a user to interact with a page. 

Google coined the term by joining some of the experience indicators previously used in ranking, such as mobile-friendliness, HTTPS, intrusive interstitials and safe browsing, and three web performance metrics known as Core Web Vitals: First Input Delay, Largest Contentful Paint, and Cumulative Layout Shift.

 

Page Experience vs. UX

Page Experience is a subset of User Experience.

While it doesn’t capture UX aspects like content quality or visual design, Page Experience is focused on the technical aspects of web products that typically influence the User Experience.

All the Page Experience signals are essentially in control of the developer team building the website. And they all have a direct impact on the overall User Experience.

This is one reason why Google’s initiative to promote Page Experience is bound to positively impact the web. We need performance metrics that correlate with business metrics to get buy-in from non-technical team members.

I believe that having a common language about web performance metrics will help hugely with executive buy-in. I’ve already heard from multiple customers that CWV are becoming the most important KPIs for site speed at an executive level.

source: Simon Hearne

Google Page Experience

Starting in May 2021, Google will use Page Experience signals for ranking purposes. These signals will include:

• Mobile Friendliness,
• Safe Browsing,
• HTTPS,
• Intrusive interstitials,
• Core Web Vitals, namely First Input Delay, Cumulative Layout Shift, and Largest Contentful Paint.

Google has already been using some Page Experience signals in the past. These signals included Mobile Friendliness, Safe Browsing, HTTPS, and Intrusive interstitials.

However, these signals didn’t capture those aspects of the User Experience related to Web Performance. And performance has been essential for Google since the early days of Chrome.

So, the Google Page Experience Update was announced on May 28th, 2020.

The most important part of the announcement was that Core Web Vitals would be used as ranking criteria for mobile Google Search.

These three performance metrics will be combined with existing UX signals to a unified set of signals for Page Experience. In the future, they may be joined by other metrics that are still being developed.

The Google Page Experience Update goes live in May 2021. As it was announced on November 10th, Google gave everyone six months to prepare.

Why you should worry

Page Experience signals influence your rankings on Google. Core Web Vitals will soon become part of these signals. And there are good reasons to think that this change will significantly impact the SERP landscape.

It’s rare for Google to inform us of the upcoming changes to the ranking algorithm.

And it’s even more significant if the announcement comes a full year before the algorithm update is implemented, with a specific date stated six months before it goes live. It indicates that Google wants everyone to have enough time to get prepared.

This doesn’t mean that Web Performance will now become a key ranking factor – it’s always been a minor signal. But the bigger picture suggests that Web Performance will only grow in significance in the near future.

The business impact of Page Experience

The biggest selling point is the hard truth that you have less than 8 seconds to get a user to complete a task on their mobile device before they get distracted. Sites that [meet the recommended CWV targets] have 24% fewer abandoned page loads.

source: Jamie Indigo

Because the Page Experience initiative has the weight of Google behind it, it certainly seems to have reached beyond just SEOs and developers. This set of signals is now discussed so widely that product owners, marketing managers, and even CEOs have noticed the web performance trend.

It seems that there is a growing awareness about Web Vitals and other experience signals among the managers. However, will this affect the budget of their development teams? That is yet to be seen.

What I would like to see are developers who make performant websites without pressure from the managers. This would require additional resources, but they can now be gained from the bottom up, backed by Google’s statements and ranking implications.

source: Bartłomiej Kudyba

Improving technical aspects that have an impact on Core Web Vital scores and Page Experience metrics certainly requires buy-in and developer resources, which can be a huge struggle, no matter the business size! Not only this, but the cruciality of performance was never fully taken seriously. I believe that Google has witnessed these struggles and has intelligently pushed the importance by making it transparent in their reports and elevating it to be a ranking signal. 

As SEOs, we should use this to our advantage to help our stakeholders truly see the importance of technical buy-in. But we have to use them responsibly! Rather than scaring executives with red scores and sending vague tickets to developers, let’s use this as a chance to start a meaningful conversation. 

The Page Experience update is a massive crossover of technical and UX aspects which SEOs can leverage to get a firmer standing in their organization. Learn how and why Core Web Vitals characterize poor user experiences, use the tools Google makes available for us to diagnose performance properly, find out more about your tech stack and implementation processes, and then derive your educated assessment and optimization possibilities. Reach out to your web developers with these suggestions and get their opinions on the matter. Pitch the TL;DR version to executives so that they’re on the same page, and that they understand the risks and why you’re an advocate for such improvements. 

Not only will this stronger communication aim to prepare your website for the Page Experience update, but this type of planning will also help you and your organization commit to better processes for technical improvements in the long run.

source: Izzi Smith

Site speed is a business problem with technical roots.

source: Andy Davies

Core Web Vitals attempt to make the web performance landscape a little more straightforward. The fact that Google chose those metrics indicates that Google considers them to be the most impactful in their respective categories.

Core Web Vitals are a set of three web performance metrics: 

• Largest Contentful Paint (LCP),
• First Input Delay (FID),
• Cumulative Layout Shift (CLS).

These metrics are supposed to “provide unified guidance for quality signals that are essential to delivering a great user experience on the web.”

We can expect Core Web Vitals to evolve and Google to add more metrics to the set.

It’s worth noting that Core Web Vitals are currently only compatible with Blink-based browsers (Chrome, Edge, Opera) and are not compatible with Safari and Firefox, among others.

You can check the compatibility of the APIs needed to measure Core Web Vitals here:

• PerformanceEventTiming API (FID)
• LargestContentfulPaint API (LCP)
• LayoutInstability API (CLS)

Largest Contentful Paint

Largest Contentful Paint (LCP) measures the time (in milliseconds) until the page’s largest content element is rendered in the viewport. 

It’s one of the many metrics that quantify how long it takes for users to see what they’re looking for rendered on the screen. 

Similar metrics include First Contentful Paint, First Meaningful Paint, and Speed Index. The problem is, each of those metrics comes with its own bias towards a particular type of web page. Because how do you determine which element of the page is vital for the user to see first, on a large scale?

I personally like Speed Index as I feel it’s an excellent representation of the visual render process. However, it is very resource-expensive to measure it on a large scale, so LCP is a better choice in that case.

source: Bartłomiej Kudyba

After researching this topic, the creators of this metric concluded that it’s usually true that the largest element in the viewport is the one that the user needs to see immediately.

There are still a fair number of edge cases where LCP doesn’t report correctly, or the largest piece of content isn’t the main user content (background images, for example), and it doesn’t represent the full user experience. Still, it’s certainly one of the best metrics we have these days.

source: Patrick Meenan

How a bad LCP score impacts Page Experience

Largest Contentful Paint is a render performance metric. It’s one of the best ways to measure how quickly your pages appear in the browser.

You cannot provide your users with an excellent page experience if they are frustrated, waiting for your content to render.

If your LCP score is outside of Google’s recommendations, it means your users have to wait longer than expected to see the critical content of your page. In addition, long render times are known to cause users to bounce. If a user has to navigate through several pages on your website, this poor experience accumulates and will undoubtedly negatively impact your conversions and even your brand’s perception.

Largest Contentful Paint does correlate well with bounce rate and session length.

source: Simon Hearne

There’s no official confirmation that bounce rate and similar behavior metrics are ranking factors. But it goes without saying that if your users leave your page because it loads too slowly, improving your rankings shouldn’t be your top priority.

How LCP is measured

To measure the Largest Contentful Paint, the browser looks for the largest element in the viewport as the page is loading. 

The lack of browser compatibility makes LCP a tricky metric to go “all-in” on. LCP should be quite close to DOM Content Loaded but will be a better metric for pages which have hero elements that depend on videos, web fonts, and CSS background images.

source: Simon Hearne

How render time is measured

LCP looks for the largest element in the viewport throughout the page load.

When LCP is measured in a real-world situation, the measurement stops when the user interacts with the page. So elements that may appear or disappear because of the interaction are not considered when calculating LCP. 

Lab tools that report LCP use a complex heuristic to decide when to stop measuring since no user interaction is involved.

If the largest element is an image, render time is the time of the paint that immediately follows the image’s onload. This means progressive loading of images doesn’t help with reducing LCP. The final paint is considered.

If LCP is a text element, the earliest font load is considered. So the font can update, and LCP render time stays the same. 

If you’re using CSS font-display: block; the measurement waits until the text is visible. 

Which element is the largest

The size of the element is its width multiplied by its height. Margin, padding, and border don’t affect the size of the element.

A couple of exciting caveats when it comes to the LCP element size are:

• If you downsize an image (e.g., use a larger image to produce a thumbnail), the reduced version is considered.
• If you upsize an image, the original version is considered.
• If parts of your element are clipped outside of the viewport, only the portion within the viewport is considered.

If an element that’s already loaded changes its size or position, only its initial size and position are considered.

LCP is still in development. Therefore, when using it, you need to be aware that LCP may falsely identify the largest element.

I’ve seen examples where lazy-loaded background images are considered to be the relevant element for LCP when another element would be more appropriate. But it’s a good place to start and gives an overall picture of how quickly a page loads.

source: Andy Davies

Optimizing LCP

To reduce LCP, you need to do everything to make your largest element appear as fast as possible.

This means you first need to spot the opportunities to improve.

Starting at the very beginning of the process, look into your server setup. Are you running expensive code server-side before the HTML can be sent to the browser?

Maybe you should be using a Content Delivery Network (CDN) to make sure users from all over the world are served fast.

You should get a detailed understanding of how your assets are loaded. It often happens that the browser unnecessarily loads unused CSS or JS resources before it can load the content that matters.

First Input Delay

FID tracks the time from when a user first interacts with a web page after entering it to when the browser can start processing that interaction.

An example of a high FID situation is when you click or tap on a link on the page, and the browser reacts to your action with a significant delay.

FID helps you discover how long tasks running on the browser’s main thread result in a poor experience for your website’s users.

Because FID requires user interaction to be measured, you can’t simulate it in a lab environment. However, Total Blocking Time (TBT) and Time to Interactive (TTI) are proxy metrics used to anticipate possible FID scenarios.

[Compared to FID] TBT is much more consistently measured between lab and field settings. TBT is also conceptually easier to optimize: reduce main-thread blocking scripts during the page load! Reducing TBT should have a positive impact on FID.

source: Simon Hearne

How a bad FID score impacts Page Experience

FID captures the first impression of how responsive your website is. 

It’s no secret that users tolerate waiting for the UI to update if they see a reaction to their interaction. 

But if the interaction is followed by even a small fraction of a second of delay, we instantly notice. 

A bad FID score means your users perceive your website as unresponsive and janky.

How FID is measured

Types of input measured

FID measures the time from a concrete user interaction like a keypress, click, or tap. Other interactions, such as scroll or zoom, are not considered because they aren’t necessarily processed on the main thread.

Is processing measured?

FID disregards the actual processing time needed to respond to user interaction. It also ignores the time it takes the browser to update the user interface.

What if there is no interaction during the page load?

Some pages may not offer any user interaction, so they won’t have any FID reported.

If the interaction occurs once all resources necessary to process it are already loaded, FID reported will be minimal. On the other hand, if a user interacts as soon as possible, they may experience a substantial delay.

For these reasons, you should track your website’s FID with more attention to detail than in the case of other metrics. Instead of looking at the mean value, look for the edge cases to spot scenarios that most dramatically need to be addressed.

How to optimize FID

First Input Delay is primarily optimized by reducing the time the browser’s main thread is blocked as your page is loading.

This involves breaking up long tasks, minimizing your JS assets, using web workers, and utilizing various strategies of spreading the main thread work throughout the page’s lifecycle.

I often suggest that my customers use FID as the measure of performance and TBT as the leading indicator.

source: Simon Hearne

Cumulative Layout Shift

CLS measures the visual stability of content. 

A score of 0 means the page’s contents are fully static during the page’s lifecycle, while a higher score means the contents are moving. It’s recommended that you keep your CLS score under 0.1.

Cumulative Layout Shift doesn’t account for the movements caused by user interaction. The API has a mechanism built to prevent the CLS score from being affected by shifts within 500ms from user interaction.

How a bad CLS score affects Page Experience

CLS has a very negative impact on the way users perceive your website.

If a layout shift occurs while the user is trying to interact with a page, it may cause them to accidentally click on a link or a button they didn’t intend to click. This may result in navigating away from the page unintentionally or even accidentally buying a product.

We’ve all experienced it, and we know how painfully irritating it can be. If your website’s content significantly shifts during loading, users will immediately take notice.

How CLS is measured

When you look into how CLS is measured, it might seem tricky. But in fact, it’s relatively straightforward.

The layout shift score for a single animation frame is determined by measuring the area of the viewport impacted by the shift and multiplying it by the distance of the element’s movement relative to the viewport.

And when it comes to CLS, it’s merely a sum of all the layout shift scores that are measured throughout your page’s lifecycle.

Keep in mind that while most layout shifts occur while the page is loading, they may still happen later, which will also influence your score.

I expect to see CLS refined further, as currently it’s measured for the whole lifetime of a page, and some layout shifts may be more important than others.

source: Andy Davies

How to optimize CLS

To optimize CLS, you should first and foremost check if all the images and videos on your page have their width and height attributes defined.

If your page is loading ads, you should also predefine their space in your layout.

When it comes to loading dynamic content, make sure it doesn’t load above any other content previously loaded.

Measuring Core Web Vitals

Core Web Vitals are reported by many tools, including some of the crawlers like Ryte.

But the easiest way to start getting your CWV data is to use Google’s tools:

• Google Search Console has a CWV report that gives you an overview of your performance based on Real User Data measured by the Chrome User Experience Report.

• PageSpeed Insights reports both a 28-day aggregate Real User Data of all pages on your website and lab data measured on the spot.

• Chrome User Experience Report is the most comprehensive Real User Data source about your Core Web Vitals performance. It allows you to access your website’s historical data, look at specific metric intervals, and even get data for particular devices and countries where your website is accessed. Accessing it requires the ability to query with SQL using Google BigQuery. Data from the Chrome User Experience Report can also be accessed using the CrUX API and PageSpeed Insights API.

Limitations of Core Web Vitals

Compatibility

As previously mentioned, Core Web Vitals can’t replace all your other metrics. The best reason for that is that they are currently only supported by Blink-based browsers, which means you can’t measure any of them on Safari or Firefox.

Single Page Applications

There are various issues with measuring the performance of SPAs using the Core Web Vitals. Chrome User Experience Report doesn’t measure soft navigations that SPAs may rely on. So these websites may have particularly bad LCP and CLS scores.

Currently, the biggest gap in web performance is our ability to capture metrics about the speed of SPAs, so I’m hopeful that we’ll begin to make some progress on standard ways of measuring them.

As SPAs vary in scope from ones that replace a whole site (complete with their own internal navigation) though to smaller components on a page (a checkout, for example), then I think it’s something we’ll see addressed in steps with some iterations of metrics along the journey.

source: Andy Davies

Core Web Vitals will still improve

Keep in mind that these metrics are still in development, and they will likely get more reliable.

Many changes are happening already, for example, reducing false positives for CLS and improving the measurement of LCP. I’d also be interested to see if FID gets replaced by TBT in the long term.

source: Simon Hearne

I think the team is on a good track, and if they continue to focus on the edge cases that don’t work well currently, then we will be in really good shape.  I think trust and accuracy in the current metrics matter a lot more than creating new metrics. 

source: Patrick Meenan

Mobile-friendliness

We’ve all seen the data: the global mobile browsing market share hovers around 50%, and it will most likely grow in the future. In many countries, mobile traffic far exceeds desktop traffic.

It may have taken a hit in 2020 as people spent more time at home in lockdowns, but by now, it’s pretty much at the previous levels.

So it makes sense that Google uses mobile-friendliness as a ranking factor, particularly for mobile search results.

What is mobile-friendliness

Mobile-friendliness is a set of factors that determine whether the mobile version of your website is user-friendly. These factors genuinely define the mobile user experience.

Mobile devices and browsers are more limited than their desktop counterparts. This difference primarily comes down to the size of the viewport,  computing power, and connection speed.

For these reasons, you need to take particular actions to ensure your Page Experience is just as great on mobile devices as it is on desktop.

Building a mobile-friendly website

Having a mobile-friendly website starts with the best practices of accessibility and user-driven design.

Here are some resources to get you started on designing websites mobile-first:

• Responsive Web Design is the best approach to building websites that adapt to the user’s viewport.
• Web Content Accessibility Guidelines cover things you should consider when designing an accessible, user-friendly website.
• Hubspot picked 21 great mobile-friendly websites that demonstrate everything great about designing with a mobile user in mind – large icons, fonts, clear and spacious mobile-optimized layout. Learn from the best!

How to improve your website’s mobile-friendliness

Using Google’s tools to audit your mobile-friendliness is an excellent place to start.

URL-level

Using Lighthouse, you can find out if your website:

• Uses incompatible plugins,
• Doesn’t have the viewport property set,
• Has viewport set to a fixed width,
• Has content that’s wider than the screen,
• Has text that’s too small to read,
• Has buttons or links that are too close together.

An alternative tool to use is the Mobile-Friendly Test. It has the benefit of showing you the rendered version of your page, but other than that, MFT reports are similar to Lighthouse reports.

However, I recommend using both Lighthouse and Mobile-Friendly Test to get the full picture of your website’s mobile-friendliness, as both tools may slightly differ in their findings.

Site-level

If you want to know how the entirety of your site is performing when it comes to mobile-friendliness, use Google Search Console’s Mobile usability report.

The report gives you a list of issues to address and the number of affected pages.

Safe browsing

A safe-browsing website doesn’t host malware or unwanted software and doesn’t contain “social engineering” content.

Google’s Safe Browsing initiative was launched in 2007 to protect users against malicious downloads. Over time it evolved to cover unwanted downloads and social engineering attacks, such as phishing, deceptive content, and insufficiently labeled third-party services.

The easiest way to check if your website doesn’t contain malicious software or content is to use Google Search Console. In the Security & Manual Actions section, navigate to the Security issues report.

HTTPS

This aspect of Page Experience speaks for itself. Serve your pages over the HTTPS protocol!

HTTPS stands for Hypertext Transfer Protocol Secure, and it’s an internet communication protocol that’s secured via SSL/TLS.  These encrypting protocols ensure that the data sent between the user and the server cannot be interjected and stolen, or modified.

How HTTPS affects Page Experience

Google doesn’t care for websites with no encrypting certificate. So yes, using HTTPS gives you a ranking boost. But there’s much more to lose for not using it.

Google Chrome marks all HTTP websites as “not secure.”

And Firefox has an “HTTPS-only” mode, which will prevent you from visiting HTTP websites without explicit consent.

This is a big deal for site owners. Users might not even consciously notice the warning label next to the address bar, but you don’t want them to subconsciously associate your website with spam, malware, or phishing.

And in many cases, users may actively look for the lock symbol that represents security. If you’re asking your users for private information like name, e-mail, or address, and you’re not using HTTPS, you’re doing it wrong.

In the era of growing online privacy concerns, you should make migrating your website to HTTPS an absolute priority. Migrating is a complex process, but it won’t hurt you if it’s done correctly.

Intrusive interstitials

Intrusive interstitials make it harder for users to access the main content of your page. Google penalizes using them, as they negatively impact Page Experience and, more generally, User Experience.

But does that mean you cannot display popup ads at all without being penalized? And what about the interstitials that you’re legally bound to display, such as cookies information or age verification?

To a certain degree, it’s a judgment call, but Google does provide some guidance about what’s okay and what’s not.

Examples of intrusive interstitials

• intrusive popups that obscure the main content of the page
• standalone interstitials that need to be dismissed for accessing the main content
• putting an ad in the above-the-fold part of the content and putting the main content below the fold

Examples of interstitials that don’t get penalized

• popups you’re legally bound to display: cookies, age verification, etc.
• hiding the main content behind a login or a paywall
• popups that occupy a reasonable amount of screen space

How to audit your website for intrusive interstitials

It might not always be obvious whether an interstitial is appropriately sized or where exactly it appears in the layout of your page.

For this reason, you should audit your pages using the URL Inspection Tool. It allows you to see your page the way Google renders it during the indexing process.

Remember that intrusive interstitials hurt your rankings on Google for a reason. They are very damaging to the experience of interacting with your pages.

Awesome people to follow and blogs about Web Performance

• web.dev, forever and always
• Jake Archibald at jakearchibald.com
• Jamie Indigo
• Izzi Smith
• Simon Hearne at simonhearne.com
• Andy Davies at andydavies.me
• Philip Walton at philipwalton.com
• Patrick Meenan
• Everyone on this list of web performance experts on Twitter.

Page Experience resources

• Check out this FAQ from Google about Page Experience and Core Web Vitals.

Core Web Vitals

• This introduction to user-centric metrics on web.dev can help you understand what needs to be measured and the difference between lab and field data. It also lists the metrics and APIs you can use to measure your performance.
• Web.dev also has excellent articles that will introduce you to LCP, FID, and CLS, as well as separate resources for optimizing those metrics:
  1. Optimize LCP
  2. Optimize FID
  3. Optimize CLS
• We also have good primers on all three Core Web Vitals on our blog: What is LCP, What is FID, and What is CLS.
• If you want to improve both LCP and FID, it’s useful to get familiar with code evaluation strategies, such as:
  1. Lazy evaluation
  2. Eager evaluation
  3. Idle-until-urgent
• Watch this presentation by Paul Irish to get a thorough understanding of what LCP measures.
• Simon Hearne, who was very kind to answer my questions about CWV for this article, has a great post about these metrics on his blog.
• This post has everything you need to pick your preferred method of monitoring Core Web Vitals and start gathering your data.

Mobile-friendliness

• Mozilla has a great article that serves as an introduction to the concept of mobile-friendliness.
• The same goes for this article on Google Search Central.
• If you want to audit your website using the Mobile-Friendly Test, read this article first.

Safe browsing

• This resource will introduce you to Google’s Safe Browsing initiative.
• If it’s not clear to you what exactly counts as malware, unwanted software, or social engineering attacks, I’ve got you covered.

HTTPS

• If you’re still not convinced, read Tomek Rudzki’s 6 Reasons Why You Must Switch to HTTPS
• Google Search Central has an article that covers literally everything you need to know to switch to HTTPS

Intrusive interstitials

• See examples of interstitials that Google labels as intrusive and the ones that are okay to use.
• Read how to use the URL Inspection Tool to see how Google renders your page.