How to Read Core Web Vitals in Google Search Console and Improve Website Speed

Google Search Console (GSC) is a free tool where Google shows you how it perceives your website in search results. This includes a view on speed, specifically the Core Web Vitals metrics. This is precisely where many non-experts get lost.

This article is for those responsible for website speed who find themselves fumbling around in Search Console. It's for developers, marketers, project managers, and website owners who need to read Core Web Vitals data and understand what to do next.

Why us? At PageSpeed.ONE, we've successfully optimized dozens of both large and small client websites. Search Console is our second most important tool, right after our own speed monitoring. We take it seriously because we regularly observe a connection between Core Web Vitals and SEO results, PPC click costs, and conversions.

What is Google Search Console and Why Bother?#

Google Search Console is a suite of reports about how your website performs in Google Search. You'll see which queries display your site, which pages Google has indexed, technical issues with the site, and how it rates the user experience, including speed.

For webmasters, it's crucial for a simple reason: these are data directly from Google, not third-party estimates. When Google says some of your pages are "poor" regarding Core Web Vitals, it's the same signal reflected in search rankings.

And why especially for speed? Speed is one of the ranking signals. It affects SEO and PPC click costs, as a slow landing page worsens the Quality Score in Google Ads. We repeatedly see the impact of Core Web Vitals on business, such as with the e-shop Denatura, where we combined speed optimization with ongoing analysis in Search Console and gradually saw improved search positions.

Search Console quickly reveals where Google perceives problematic URLs or groups of pages.

How Google Measures Speed#

Before diving into the reports, it's crucial to understand how Google measures speed. Without this understanding, you'll find yourself lost in the numbers.

Basics: Metrics, CrUX, and the Worst-Metric Rating#

Speed is described by three Core Web Vitals metrics: loading speed (LCP), interaction responsiveness (INP), and visual stability (CLS). Each has thresholds for "good", "needs improvement", and "poor" values. We explore these in detail in standalone articles about LCP, INP, and CLS.

The source of the numbers is key. They are not one-time tests but data from real Chrome users, sourced from the Chrome UX Report (CrUX). Google collects speed data as experienced by actual visitors over the past 28 days, separately for mobile and desktop.

Beware of a rule that confuses even the advanced: a group of pages is rated by the worst metric. If a group has a poor CLS but excellent INP, the entire group is "poor". Just one problem, and the whole group falls into the red zone.

Three Levels of Speed Measurement#

Speed isn’t measured at just one level. It pays to distinguish among three, as each answers a different question and uses different tools:

• Domain Level shows the state of the entire website. You find this data in PageSpeed.ONE monitoring and other tools using CrUX.
• Page Group Level identifies which types of pages drag the site down. This is the domain of the Core Web Vitals report in Search Console.
• Specific Pages are dealt with when you need to fine-tune a single URL. For this, use the website speed test (Insights) or the CrUX API.

Three levels of website speed measurement. Search Console mainly covers the middle level, the page groups.

We elaborate on each level and where to obtain the data below.

Principles: How Data is Assigned#

Google doesn't assign speed uniformly to all pages. It works in steps:

• If a specific page has enough traffic, it's evaluated based on its own Core Web Vitals.
• If the page lacks its own data, Google assigns it to a group of similar pages (visible in Search Console) or uses the domain rating. The domain value covers most URLs on the site, hence its importance.
• Note, however, that even a domain might lack CrUX data. For new or sparsely visited sites, Google simply doesn't have enough measurements.

These principles lead to further CrUX rules, which are somewhat peripheral here, but worth knowing: data runs in a 28-day cumulative window, so changes appear with a delay, and in single-page applications (SPAs), some metrics are measured differently. Details are in the article on Chrome UX Report.

Speed Reports in Google Search Console#

Now the main part: where to find reports and how to read them correctly to avoid drawing the wrong conclusions.

Core Web Vitals Report#

You’ll find the report in the left menu of Search Console under Page Experience, item Core Web Vitals. It opens a summary divided into mobile and desktop. Always address both parts separately, as mobile and desktop experiences usually differ.

Clicking on mobile or desktop leads you to individual groups of pages with a problem description (e.g., "LCP longer than 2.5s"). This is the biggest hint of what to optimize. Google also offers examples of specific URLs for each group.

Beware of the Misleading Core Web Vitals Graph#

The graph in the Core Web Vitals report is misleading. Novices believe it shows the metric value. It does not. It shows the number of pages in green, orange, and red zones.

This has practical implications. Moving pages from orange to green may mean improving LCP from 2.51s to 2.49s, merely crossing a threshold, but the actual speed remains practically unchanged. Conversely, a large jump in the graph may not reflect a significant change in perceived speed.

The report in Search Console shows how many URLs fall into the "needs improvement" range, not the average domain metric value.

So, how to read it correctly? Focus on the proportion of orange and red pages. If more than 10% of URLs are orange or red, it’s certainly worth addressing, so you don't lose unnecessary points with Google.

Backend Response Report#

The second important report is hidden and again somewhat misleading. You’ll find it in Settings under Crawl Stats, where Google reports the average server response time. It's essentially TTFB, the time before the server starts responding. Although the report is tucked away, it’s crucial for two reasons.

Firstly, server response directly affects Core Web Vitals metrics. A slow backend delays loading and especially impacts LCP. Secondly, it affects the so-called Crawl Budget, the number of pages and how frequently Google is willing to crawl. The slower the server, the less Google manages. The concept and recommendations are described in Google's Crawl Budget documentation.

How to interpret the response time?

• If it's consistently above 0.8s, definitely address it with infrastructure, developers, or experts.
• If spikes in worse numbers correlate with traffic, bolster infrastructure, as your server can't handle peaks.
• If spikes are unrelated to traffic, they may be due to bot traffic. Increasingly, these are AI bots, for which we have a Strategy for AI Bots.

How to Measure Speed with Google Search Console#

Search Console is an excellent piece of the puzzle, but alone it’s insufficient. Let's go through what to extract from it and how to complement it.

You Need Domain Data#

The domain view, or how the entire website's speed fares over time, is inadequately handled by Search Console. This must be sourced elsewhere, in monitoring. Key elements are alerts, long-term measurement with data history, and debugging information for developers.

In PageSpeed.ONE, the Domain Report provides complete CrUX data. You’ll see trends by days and months and debugging data, like LCP breakdowns into individual parts. There's also a free trial version, Watchdog, which alerts you to deteriorations, and additional functions. This is precisely what Search Console doesn’t cover, making independent monitoring essential for serious speed work.

For one-time assessments, the PageSpeed.ONE website speed test or Google's PageSpeed Insights suffice. They're suitable for quick checks, not for monitoring long-term trends.

Individual URLs#

We recommend addressing specific URLs only for truly important pages, typically the homepage, or for websites where domain and group data (see below) are already in order. It’s senseless to tweak one page while entire groups remain broken.

You Need Page Groups#

Page groups are the domain of Search Console; you won’t find them neatly compiled elsewhere. Work with the two reports described above: the Core Web Vitals report and the backend response report. The first tells you which types of pages are problematic, and the second reveals a slow server.

Fixed the Problem and Google Search Console Still Shows It?#

Search Console often has delays and isn’t perfectly accurate, so fixes might not show up immediately. Don’t panic. After fixing issues, you can click the Start Tracking button in the Core Web Vitals report. This initiates a 28-day monitoring window to automatically verify whether the fix worked. URL statuses will appear as Pending, Passed, or Failed.

What "No Data Available" Means#

Sometimes, you’ll encounter "No data available" in the report. This means one of two things: either the property in Search Console is new and Google has nothing to show yet, or the site has low traffic and insufficient data in CrUX. In both cases, supplement the domain view with synthetic measurements in monitoring.

Practical Checklists#

Finally, here are two checklists to guide you in practice.

Regular Actions#

• Monitor Domain Data. The domain view on speed gives you the quickest overview of the entire website’s status. Ideally from a tool that alerts you automatically.
• Monitor Page Groups in Search Console. Here you’ll see which types of pages drag down ratings and where to start with fixes.
• Check Impact on SEO and PPC. Correlate speed improvements or deteriorations with data from the Performance report in Search Console. See if it affects positions and clicks.
• Choose the Right Frequency. A small site suffices with monthly checks; a large site might need weekly or even daily checks. The ideal scenario is tools that notify you: PageSpeed.ONE monitoring does this, but you must manually check Search Console.

Actions for Orange or Red Core Web Vitals Groups#

• Prioritize These. These are the URLs receiving lower ratings. Find specific page examples in the group; Search Console provides them.
• Monitor These URLs. Keep them under watch to see trends, not just a snapshot.
• Look at Debugging Data. Combine synthetic measurements and debugging CrUX data to pinpoint exactly what ruins the metrics.
• Test the Page in a Browser. How-to described in the article on Web Vitals in the Browser.
• Use Our Guides. Based on the problematic metric, check optimization for LCP, INP, or CLS. For a quick start: for LCP, address image size and format and server response; for INP, remove unnecessary JavaScript and third-party code; for CLS, always specify image dimensions and reserve space for late-loading elements.
• Overwhelmed? Contact Experts. We assist with optimization and data interpretation as part of our services.
• After Fixing, Use Start Tracking. In the Core Web Vitals reports, initiate monitoring and let Google verify the fix.