What is Google’s Page Experience Update?
Whereas Google’s traditional ranking factors were originally focused on the informational value of pages and trust signals such as backlink profiles, page experience is yet another step that Google is taking to measure how users actually experience the pages that they are being shown in the SERPs.
Google wants to provide its users browsing the SERPs with the best onwards experience possible. Page experience is being introduced as a ranking factor in 2021 to help them do that more effectively, and to ensure that high-quality, fast-loading and mobile-friendly sites are promoted to reach more users.
An important thing to note is that content quality and relevance to searcher queries will still be crucial for rankings. A page with low-quality content that loads fast won’t necessarily rank higher than a page with high-quality, relevant content.
However, strong page experience signals can help to boost a page’s rankings if it has a similar content quality and backlink profile as its competitor pages. For example, an ecommerce category page that has a similar content and product offering as an equivalent competitor page – as well as having a similar number and quality of backlinks – could edge out its competitors and be ranked higher if it has stronger page experience signals.
For example, if the competing category pages below had similar backlink profiles and an equivalent quantity and quality of on-page content, from optimising page experience signals, one of these pages could start outranking the other.
Page experience is made up of five different signals which focus on the quality of a user’s experience of a page. These signals are:
- Core Web Vitals
- Safe browsing
- No intrusive interstitials
Google’s Core Web Vitals
Core Web Vitals are a set of speed metrics that measure the user’s experience of a page loading. This initiative was launched by Google in May 2020 to provide guidance for measuring and improving the user experiences that our websites provide.
Core Web Vitals are important metrics to analyse because they help us to shift our focus from actual page load to perceived page load. Traditional site speed metrics alone don’t always tell the whole story of page load, and this is why we need a wider variety of more nuanced metrics that can help to tell the real story of how users actually perceive the loading of a page.
For example, if you were looking at page load time as a measure of page performance, a tool might tell you that the pages below loaded in 6.5 seconds and 6.4 seconds, respectively.
However, a user would think that the page on the left had loaded much faster because the above-the-fold content populated quickly, and everything else loaded in the background without obstructing their experience of the site.
To the user, the page on the right actually loaded in 1.2 seconds, not 6.4 seconds.
Core Web Vitals are tangible, quantifiable metrics that allow us – and Google – to measure user experience.
The Core Web Vitals metrics cover three areas of page load experience:
- Loading: this is measured by Largest Contentful Paint
- Interactivity: this is measured by First Input Delay
- Visual stability: this is measured by Cumulative Layout Shift
To start investigating your website’s Core Web Vitals scores, the old ‘Speed’ report in Google Search Console has been renamed to Core Web Vitals, and can be found in the ‘Enhancements’ reports.
The Core Web Vitals report provides a useful breakdown of your site’s LCP, FID and CLS performance, and buckets them into three groups:
- Need improvement
Mobile and desktop scores may differ significantly, so I always recommend running separate audits for desktop and mobile.
Now let’s explore the three Core Web Vitals metrics in more detail.
Largest Contentful Paint (LCP)
LCP measures the time when the largest element of the page is rendered on the screen. This could be an image, a video or a block of text, depending on how much of the viewport it takes up. This metric has been introduced by Google to measure when a page appears to be visually loaded for users.
You can identify the LCP element of a page by inspecting it in Chrome DevTools. In the ‘Performance’ tab, you’ll find the timings of different metrics. If you hover over the LCP timing, the corresponding element of the page will be highlighted.
In this waterfall view, you can also identify tasks and dependencies that are preventing LCP from happening sooner.
Google recommends making sure that LCP should occur within the first 2.5s of a page loading.
The main issues that impact LCP timings to watch out for are:
- Slow server response times: this can be improved by preloading key requests to help the browser prioritise what to load first, such as the LCP element on a page and important above-the-fold content, which the user needs to see to perceive that a page is visually ready.
- Slow resource load times: tactics like compression to reduce file sizes and preloading can help to increase the load speed of key elements like images.
First Input Delay (FID)
FID measures the time between when a user first interacts with a page, to when the browser is actually able to respond to that interaction. This metric focuses on the delay that occurs between when a user clicks or taps on a button on the site, and then when the browser interacts accordingly.
A page that visually loads quickly but isn’t usable for a significant amount of time provides a negative user experience. It can almost be more frustrating for a user to see a page that they can’t do anything with if it doesn’t respond to their actions.
FID can’t be simulated with lab data as it requires user interaction, so to measure it, you need tools that use field data such as PageSpeed Insights, which gathers real-world data through the CrUX report. However, Total Blocking Time (TBT) is a metric that can be gathered from lab data, which can be an indicator of FID issues.
The best practice FID timing is less than 100ms, according to Google.
The most common causes of long FID timings are:
- Main thread blockages: watch out for long tasks, as these are instances where the main thread is being blocked for a significant amount of time. This delays the time in which the browser can respond to user interactions and can cause the page to freeze. You can identify these in the performance tab of Chrome DevTools.
- Resource-intensive third-party code: remove or defer loading of third-party scripts which can otherwise delay rendering of the main page content. These can often include tracking scripts and resource embeds. This is something you can easily find in PageSpeed Insights.
- Large request counts and transfer sizes: the number of network requests and how much data is being transferred while a page loads can give an indication of its performance. This is reported on in Lighthouse. Ship only the code you need and implement performance budgeting to tackle this issue.
- Server-side rendering with delayed re-hydration: any delays between content being visually rendered by the server, and then re-hydration happening to allow for client-side handling of interactivity, needs to be monitored and reduced as much as possible.
Cumulative Layout Shift (CLS)
CLS is a score that measures the overall layout shifts that occur on a page between when it starts and finishes loading. CLS isn’t a timed metric like LCP or FID, it’s a score that’s given to a website based on how much the visible content shifts within the user’s viewport during the loading process.
Visual stability is a newer area of user experience and performance optimisation, which SEOs will benefit from learning more about since Google has introduced CLS as a Core Web Vitals metric.
The visual comparison feature in WebPagetest is great for visualising layout shifts on a page during loading and can highlight differences between your page templates and those of your competitors.
The optimal CLS score of a page is less than 0.1.
The most common causes of poor CLS scores are:
• Images without dimensions: specifying image dimensions helps the browser to more accurately plan the layout of the page without it shifting too much as images load.
• Ads, embeds, and iframes without reserved space: when a page element doesn’t have a reserved space to load into, it shifts the rest of the page content that has already appeared on the page so they can fit in.
• Dynamically injected content: avoid inserting new content above existing content as the page loads, unless the appearance of this content is in response to user input.
• Web Fonts causing FOIT (flash of invisible text) or FOUT (flash of unstyled text): using ‘font-display’ and the Font Loading API helps to resolve issues where fonts disappear or are swapped out as they load, causing layout changes.
Mobile-friendliness is one of the user experience criteria that has already been incorporated into Google’s ranking algorithms. The mobile-friendliness of a page is determined by how easy the page is to use and navigate on mobile devices.
Since mobile traffic overtook desktop traffic back in 2016, it has been even more important to focus on optimising website experiences for mobile devices, as this is where the majority of traffic comes from – depending on the vertical of a website.
Also, with the introduction of mobile-first indexing by Google, websites will be crawled with smartphone user agents by default, so this is yet another reason why focusing on mobile usability is important.
To assess mobile-friendliness on a page-by-page basis, you can run URLs through Google’s Mobile-Friendly Test.
Google Search Console’s Mobile Usability report provides a useful top-level view of how mobile-friendliness is trending across all pages on your site. Here is an example of the mobile usability issues we found for one of our clients when we performed a page experience audit on their website:
These are the key errors that are flagged in Google Search Console’s Mobile Usability report – which would be beneficial to monitor for page experience:
- Uses incompatible plugins: plugins are used that are not supported by most mobile browsers.
- Viewport not set: the page does not have a viewport property set, which tells the browser how to adjust the page’s dimension depending on screen size.
- Viewport not set to device-width: a fixed-width viewport is set, which means it can’t be adjusted for different screen sizes.
- Content wider than screen: users need to scroll horizontally to see all of the page’s content, as it doesn’t scale to their device.
- Text too small to read: the font size is so small that users would be required to zoom in to read it legibly.
- Clickable elements too close together: buttons and links are so close to each other that they can’t be easily tapped individually without selecting a neighbouring element.
Safe browsing relates to whether there is any malicious or deceptive content detected on the website in question. This includes security issues like malware and phishing content.
Auditing safe browsing
To assess whether or not a site is safe, check the ‘Security issues’ report in Google Search Console. This report will highlight instances of hacked content, malware and unwanted software, and social engineering content that tricks visitors into revealing confidential information or downloading software. It will also provide a sample of affected pages to help you identify where these issues are coming from.
All sites should be served via HTTPS rather than HTTP to ensure secure connections for users. This is something that Google advises as well, as HTTPS has been used as a light ranking signal for years now.
You can spot check the connection security by looking at the icon next to the URL in the Chrome browser. If any URLs have the ‘Info’, ‘Not secure’ or ‘Dangerous’ icons, then this will need to be investigated and fixed.
To gain a more holistic view of non-HTTPS pages, you can also run a full website crawl which includes the resources on your site such as scripts, images, and forms that require the input of user data. All internal links to HTML pages and scripts should be filtered down to the HTTP protocol to identify any URLs that need to be migrated to HTTPS.
Screaming Frog has a dedicated ‘Insecure Content’ report that can be exported and can help you when auditing website security and HTTPS.
The following advice from a Google Search Console help guide can form a good foundation for HTTPS auditing:
Interstitials that cover crucial content and impede the user’s journey on a site should be avoided. As part of a mobile usability update in 2017, Google introduced an interstitial penalty, which would demote pages in organic rankings that didn’t have their content immediately accessible to users.
Intrusive interstitials are frustrating for users as they block the content that they expect to see after clicking through to a result from Google search. With the inclusion of interstitials within the page experience update, it’s more important than ever for sites to audit the interstitials and banners used to assess content accessibility for users and search engines.
Auditing intrusive interstitials
It’s important to test Google’s rendered output of key page templates to make sure it’s able to access all of the key elements of the pages. Also, cookie banner designs need to be analysed to make sure they don’t take up too much of the viewport. The aim should be to make sure that the most important hero element of a page remains unobstructed by interstitials for users.
You can use the URL Inspection Tool in Google Search Console to check the how Google is rendering pages and see if interstitials are hiding any content behind them.
To test interstitials on key page templates, just load up a few pages from each template and manually review them on different devices. For example, the homepage, two category pages, two product pages and two blog pages.
Don’t wait to optimise page experience
To make sure my clients are ready for the upcoming algorithm update next year, I’ve been running page experience audits now to identify any problem areas that can be fixed ahead of time.
By focusing on page experience now, this also accounts for long development queues. The duration of your development lifecycle will dictate how early you will need to start these communications with your developers.
Does it normally take 6 months or more between raising a development request and the fix being implemented? Then you’d better get started and get those tickets logged now!
While implementing these improvements should improve the signals of pages, optimising for page experience isn’t solely about keeping up with Google; it’s about nurturing our users and providing them with the best online experiences possible to build brand loyalty so that they keep coming back.
User experience should be factored into our day-to-day work as SEOs. Focusing on enhancing how users interact with your site is the way to go to future-proof your digital marketing strategies against search engine updates.
Thanks for getting this far and learning about web vitals. I hope you’ve enjoyed this guide! If you found this helpful, why not share this with your inner circle? Just click on the social icons below. If you’d like support with making sure your website is prepared for the fast-approaching Web Vitals update then get in touch, we’d love to help!