Google's 'page experience' algorithm previously touted for May 2021 will now be rolled out between June and August
In an announcement this week, Google has pushed back their page experience update, which includes the new Core Web Vitals (CWV), from May this year until mid-June. Furthermore, the rollout of this update will be done gradually between June and August 2021.
While this may come as a frustration to some website owners; many of whom will have invested in getting their sites in good shape and in the hope to get a jump on their competitors, it will also undoubtedly be good news for others.
In this piece we will take you through:
- What this means for your SEO performance
- The new Page Experience Dashboard
- Core Web Vital Data – Page Speed Insights vs Search Console
- What are the other changes in the rollout?
If you’re interested in learning more about the individual Core Web Vitals, you can read our explainer here. Core Web Vitals, which include the new metrics for LCP, CLS and FID can be hard to optimise for. In some cases existing website platforms and themes simply don’t have good foundations in place to deliver the best performance metrics in the eyes of Google, many of which require significant resources or complete re-builds which takes time to plan and deliver.
This delay appears to be a clear indication from Google that they think more grace time should be afforded to site owners to “help you continue to make refinements to your website with page experience in mind”.
What does this mean for your SEO performance?
The gradual nature of the rollout also means it is less likely we’ll see any sudden changes in rankings… not that there should be anyway, Google has made it clear not to expect ‘drastic changes’, similar to the mobile-friendly update or the speed update – reiterating that page experience is only one of many factors in the overall ranking mechanism.
It’s more likely the page experience update will have a larger effect for sites that have really poor CWV scores, or in competitive searches where other ranking factors are more finely balanced. This diagram sums it up best:
This isn’t to say that the Core Web Vitals aren’t important, as you can see above, they can be critical for beating your competition. The importance of these will increase with each update Google rolls out.
However, with these extra few months, will we see much of a renewed effort around Core Web Vitals? I think this is unlikely, given we’ve already had the best part of a year’s notice for this new ranking factor and those who really care or are concerned about these new signals would have already planned for the May update.
A new page experience dashboard
To help us prepare for these upcoming updates, a new page experience report has been released for Search Console. This combines data from the Core Web Vitals report with existing page experience signals for mobile-friendliness, security and the use of HTTPS.
The graph at the top provides a useful summary, by day, of the proportion of pages that fall within the ‘good’ threshold for Core Web Vitals. If any page fails to meet the good threshold for either LCP, FID or CLS they will be flagged as a ‘failing URL’.
Selecting the Core Web Vitals panel will take you to the Core Web Vitals report where you can view all pages that either ‘need improvement’ or are ‘poor’.
Understanding which pages are failing helps determine where to direct our efforts. While it may not be feasible to address every single page, it may be possible to isolate specific templates or groups of pages that share common issues. We would sometimes use this along with top traffic pages to analyse where any further development work to improve speed will have the most impact. We’ll then address these pages and test the Core Web Vitals within Google’s PageSpeed Insights.
Why is Page Speed Insights and Search Console showing different data?
If you’ve been using tools such as PageSpeed Insights to test performance, you may notice discrepancies between how a web page’s CWV metrics are given in Insights when compared with the reporting in Search Console.
Ultimately it comes down to Lab Data vs Field Data.
From Google’s Martin Splitt “Field data is coming from real users, whereas lab data comes from a quite strong machine with probably good internet from somewhere around the world. So you might not see the same results.”
Unlike the ‘lab’ report in Insights which measure these metrics in a simulated environment, the Core Web Vital scores in Search Console are based on actual ‘field’ data gathered by real users from CRUX. It is common therefore to see differences between how these metrics are reported and can be down to a number of reasons. These could include:
- Metrics measured through CRUX may be aggregated across the whole site and likely to be different to the values from specific pages being tested in Insights.
- Actual devices being used by real users and reported in CRUX are likely to have different CPU and processing capabilities than the simulated device in Insights. This can impact the FID metric especially, and it is common to see higher scores for interactivity metrics in Insights lab test results.
- Resolutions and screen sizes will vary massively between different users, unlike the single mobile and desktop resolution in Insights. This means the largest LCP element can change at different resolutions and breakpoints. If the LCP is a hero image, for example, make sure the image is responsive and the correct size is preloaded at different resolutions.
- Insights does not take into consideration scrolling or click behaviour whereas CRUX records a user’s experience throughout their journey. If content is loaded, or an element shifts as a user scrolls down the page or interacts with an element, this could result in higher CLS values in Search Console and CRUX reporting.
Which one should I use?
Do these differences mean one reporting tool should be used over another? We like to use both. Insights is best to analyse specific pages and measure the impact of any improvement made to key pages, whereas CRUX data within Search Console can be great to flag issues across an entire site and identify specific templates which need attention.
What are the other changes in the rollout?
But page experience isn’t the end of it. Other changes due for this gradual rollout include
1. Top Stories no longer requires AMP
This is a big one for news publishers. Currently, only articles published as AMP are eligible to appear in the Top Stories carousel feature in search engine results. When the page experience rollout occurs, AMP will no longer be a requirement and any article will be eligible providing News policies are met. This requirement is also being dropped from the Google News app.
This means publishers aren’t forced to use a specific technology if they want this extra visibility in the SERPs. Creating AMP content can be hard to implement, so removing this requirement creates a more level playing field.
2. Removal of the AMP badge
The AMP badge, the small lightning symbol shown in search results to indicate AMP content is also being removed. Instead, Google will ‘test other ways to help identify content with a great page experience’. I wouldn’t be surprised to see a different icon popping up in search results to indicate top-performing sites that pass all Core Web Vitals and other page experience measurements. This could have a big effect on click-through rates and would really encourage site owners to take another look at CWV.
3. Support for signed exchanges for all content on Google Search
Part of the underlying technology used by Google to create blazing fast pages for AMP was the ability to ‘prefetch’ assets from Google Search results, so key resources required to display and render a web page to the user can be loaded before the user actually navigates to the page.
One of the most exciting aspects of this week’s announcement is that this ‘SXG’ technology used to deliver AMP is being made available for general use and not restricted to AMP only content. If the main site’s HTML and CSS have been loaded for example before a user has reached it, this could shave hundreds of milliseconds off a site’s load time when it is navigated to from Google Search.
Although SXG itself will not be a ranking factor, if it creates higher scores and a better page experience as a result, it could indirectly improve rankings.
While we were ready and eager for the page experience updates to land next month, we understand the reasoning behind the delayed rollout and it does give us all a little more chance to prepare our sites for a better page experience.
We are also keen to try out these new reports and the newly announced support for SXG could shave valuable milliseconds off-page render times and definitely something we will be exploring further, so stay tuned for updates!
If you want to know more about how we can help you improve your website’s page experience, get in touch with us or check out some of the related articles below.