The other related aspect that impacts the overall user experience is Page Experience. e.g. How long does it take for your page to load and become interactive.
We refer to this as Page Experience, because it’s not just a single measure about how fast the page actually loads, it is this and more, as it includes a series of inter-related measures that attempt to measure how quickly a page is perceived to load.
In May 2020, Google announced that it will be rolling out the Google Page Experience update in 2021 and Core Web Vitals will be ranking factors next year.
Core Web Vitals is the new way to see (in real time) and measure the performance of a website. Some of you may already be familiar with the three elements you have seen in Google Search Console:
Largest Contentful Paint (LCP)
First Input Delay (FID)
Cumulative Layout Shift (CLS)
Core Web Vitals, also called Web Vitals are the performance metrics that affect User Experience including how fast the page loads, the visual stability (if the page jumps) and the interactivity. Google has introduced this as many sites are still loading incredibly slowly. The speed of a site affects bounce rates, time on site and conversions. So no more slow sites! If your site is still performing poorly by then, it will be harder for it to appear higher in the SERPs.
Take a few examples of some of the key pages on your site and check their performance using Lighthouse, GT Metrix or Google Page Speed Insights.
Tip 1 – Test your key Page Templates
Ideally you should select a number of page templates that cover a large proportion of your overall site pages. This way by fixing the obvious issues with a few templates you can have a positive impact on many pages. This is important as Google will use average Web Vitals data for your site if it doesn’t have data from enough real users for a specific page.
Tip 2 – Don’t focus on the overall headline score for mobile and desktop! It fluctuates!
Google recommends taking a couple of readings every time you make a change to get a more consistent view of progress. Honestly, if you focus on the overall score it will drive you mad, as you will make a change that you think improves the overall score and it will go backwards – or it will improve the Desktop score and make the Mobile score worse.
Instead focus on the key metrics for the Core Web Vitals:
- First Contentful Paint (FCP) is an important, user-centric metric for measuring perceived load speed because it marks the first point in the page load timeline where the user can see anything on the screen—a fast FCP helps reassure the user that something is happening
- Speed Index measures how quickly content is visually displayed during page load.
- Largest Contentful Paint (LCP) is a Core Web Vitals metric and measures when the largest content element in the viewport becomes visible. It can be used to determine when the main content of the page has finished rendering on the screen. The most common causes of a poor LCP are: Slow server response times
- Time to Interactive measures how long it takes a page to become fully interactive. A page is considered fully interactive when:
- The page displays useful content, which is measured by the First Contentful Paint,
- Event handlers are registered for most visible page elements, and
- The page responds to user interactions within 50 milliseconds.
- Total Blocking Time (TBT) metric measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread was blocked for long enough to prevent input responsiveness.
- Cumulative Layout Shift (CLS) measures the instability of content by summing shift scores across layout shifts that don’t occur within 500ms of user input. It looks at how much visible content shifted in the viewport as well as the distance the elements impacted were shifted.
Then focus on solving the issues raised by your page speed reporting tool. I recommend using at least two tools.
Once you have found a friendly web developer and fixed all the obvious issues, then finally, think about what changes you could make that would create a better user experience – and by better, I mean making your page templates load faster and be ready for a user to interact with sooner.
Striving for 100/100 is not completely unrealistic, I have seen a few examples of sites with home pages that score this well, but it may not even be necessary to go to the nth degree.
Eventually the law of diminishing returns applies.
Google itself says that going from a score in the 90s to 100 can take a huge amount of effort and even Google’s own search page does not score top marks!
Tip 3 – Benchmark against your competitors page templates or key landing pages and just focus on ensuring you out score your competitors!
Tip 4 – Use Google’s Lighthouse calculator to see the weighting of each of the Core Web Vitals and to work out how great an improvement you need to make to get everything in the green zone, scoring 90 – 100.
Set yourself a realistic goal of beating your competitors’ pages. Run a report first and then click on the ‘See calculator’ link below the Core Web Vitals in the Lab Section, as then the calculator will show your performance levels and it’s easier to drag and drop the sliders to see what you need to do to reach your goals.
Tip 5 – Implement AMP to accelerate your mobile pages.
Tip 6 – Prepare for your performance to drop in the future!
I’m afraid you cannot just fix and forget this. You will do all this work and then someone will change something on your website and your performance levels and scores will drop again.
After all your website should be regularly updated with fresh content and features; so it’s highly likely someone will inadvertently undo your good work on improving the page experience for your users.
So either set yourself some alerts that automatically check your scores and performance levels against your attained benchmarks and/or use Lighthouse’s CI tool (or some cloud based tools that do the same) to set a Page Experience budget that is integrated as part of the cContinuous Integration and testing framework built into your development process. For larger sites, this should ensure that any future site changes do not cause a regression in your page experience performance levels.