Google's search team announced today that it is adding a "page experience" signal to ranking, and that three measurements called Core Web Vitals will be part of it. The Chrome team introduced these metrics at the beginning of the month. Rankings are not changing yet: Google states that the change will not occur before next year and that it will give at least six months' notice.
The timing is unusual. Many small businesses are closed or attempting to sell online for the first time, and page speed is not a priority for most of them this week. The announcement is nonetheless welcome. For years, the question "why does my site feel slow?" has received only vague answers and an imprecise PageSpeed score. Google has now named and quantified the issue, and confirmed that the figures matter.
The announcement contains a further element that news publishers will note: once the change takes effect, pages will no longer need to be built in AMP to appear in the Top Stories carousel on mobile. The page experience score is intended to take over that role.
What do Core Web Vitals measure?
The web.dev page on Web Vitals is the official explanation and is worth ten minutes of reading. The following is a summary for business owners.
Largest Contentful Paint (LCP): does the main content appear quickly?
When someone opens your page, how long does it take for the largest piece of content to appear? This is usually the large photo at the top or the main block of text. Google's target is 2.5 seconds or less. On many small business sites, that photo is a four-megabyte file taken directly from a camera, and the LCP is very poor. On such sites, the top of the page loads gradually in horizontal strips.
First Input Delay (FID): does the page respond when tapped?
This measures the delay between the first tap or click and the page actually responding. The target is 100 milliseconds. Pages loaded with scripts (chat widgets, trackers, sliders, pop-ups requesting an email address) appear ready but remain unresponsive while the phone processes all that code.
Cumulative Layout Shift (CLS): do elements move unexpectedly?
A user is about to tap a button, an ad loads above it, the button moves down, and the user taps the wrong element. This is layout shift. Google assigns it a score, with a target of 0.1 or less. Of the three metrics, this is the one users understand immediately, because nearly everyone has experienced it.
Google also states that the set of metrics will evolve over time, likely once a year. We therefore recommend focusing less on these three specific metrics and more on the principles behind them, speed, responsiveness and stability, which will remain relevant.
Why does real user data count more than your own test?
This is the aspect most likely to be overlooked.
PageSpeed Insights provides two kinds of figures. The first comes from a lab test, a simulated load on a simulated phone. The second is field data, collected from real Chrome users who visited the page over the past 28 days. The field data reflects your actual visitors, and Google's own guidance is to look at the 75th percentile. In other words, most of your visitors need a good experience, not only those with fibre connections.
Two consequences follow.
A small site with little traffic may have no field data at all. In that case, the lab score is only an indication and is not cause for concern.
Your own experience is also of limited relevance. A business owner typically has reliable Wi-Fi and a recent laptop. The person checking your hours on an older phone, on LTE, parked on a rural road with a weak signal, is the person these figures describe.
As of yesterday, Search Console includes a Core Web Vitals report that replaces the former Speed report. It groups pages as good, needs improvement or poor, using real-user data where Google has it. For businesses that have never opened Search Console, this is a good reason to begin.
Will Core Web Vitals significantly change rankings?
We expect the effect to be smaller than many in the SEO industry will claim over the coming months.
Google states in the same announcement that excellent content still outranks a page that is fast but unhelpful, and this is consistent with its approach. We expect page experience to act as a tie-breaker between pages that are otherwise comparable. If a competitor provides the better answer, a faster site will not compensate.
This does not make it unimportant. The ranking signal was never the main benefit; the visitor is. A page that appears in two seconds and remains stable retains visitors. A page that takes eight seconds loses a significant share of them before they see anything, and no ranking improvement can offset that loss.
Where should a small business start?
Do not attempt to bring every page into the green. On most small sites, that effort is not worthwhile. Focus instead on the worst-performing pages that matter.
- Open the new Core Web Vitals report in Search Console and identify which pages are flagged.
- Identify the pages that bring in customers: the home page, main service pages, the menu and the booking page. Set aside a 2017 blog post that receives no visits.
- Review the images first. Resize and compress them, and stop uploading camera originals. This step alone resolves many slow LCP results.
- Count your scripts. Every widget, tracker and pop-up has a cost. Remove those you do not use; there is often a script still loading from a service cancelled two years ago.
- Reserve space for images, ads and embeds so the page does not shift as they load.
On WordPress, many of the issues we observe stem from heavy themes and accumulated plugins, installed years ago and never cleaned up. Regular site maintenance identifies most of these before they become problems. For persistent issues, a thorough technical SEO review examines each page individually.
The main benefit of today's announcement is that speed is no longer a matter of preference. Design choices such as fonts can be debated at length, but a load time of 6.8 seconds is an objective measurement.