Cookie preferences

Skip to content
SearchCub
  • On-page SEO
  • Explainer

Does Page Speed Affect SEO? Core Web Vitals for Bloggers

Editorial responsibility: SearchCub

Created: Edited:

Page speed does affect Google rankings, as part of page experience: Google's ranking systems use Core Web Vitals, but Google still aims to show the most relevant page even when its page experience is sub-par. Treat speed as something that helps a good post compete, not as a way to rank a post that misses the search. This guide covers what Google says, what the three Core Web Vitals measure, and how to check and fix one post with Google's free tools.

What Google says about speed and rankings

Google's page experience documentation is direct: "Core Web Vitals are used by our ranking systems." It also says there is no single page experience signal. Its core ranking systems draw on a range of signals instead.

The same page explains how much this weighs against relevance: Google Search always aims for the most relevant result, even when that page's experience falls short. For the many searches where lots of helpful content is available, it adds, a strong page experience can help a page succeed. So a slower page that answers the search can still outrank a fast page that doesn't.

Google also warns against chasing scores. In its view, your time may be better spent elsewhere than on perfecting a score purely for SEO, and good results in Search Console or third-party tools don't promise a top ranking. The relevance work comes first, and what is SEO starts there.

The three Core Web Vitals in plain words

Core Web Vitals measure how a page feels to real visitors: how fast the main content appears, how quickly the page reacts, and how much it jumps around (Google: Core Web Vitals). Google's web.dev guides publish three bands for each one:

  • Largest Contentful Paint (LCP). What it measures: loading, when the largest image, video or text block in view appears. Good: 2.5 seconds or less. Needs improvement: over 2.5, up to 4.0 seconds. Poor: over 4.0 seconds.

  • Interaction to Next Paint (INP). What it measures: responsiveness, how long the page takes to respond visibly to a click, tap or key press. Good: 200 milliseconds or less. Needs improvement: over 200, up to 500 milliseconds. Poor: over 500 milliseconds.

  • Cumulative Layout Shift (CLS). What it measures: visual stability, how much visible content moves unexpectedly. Good: 0.1 or less. Needs improvement: over 0.1, up to 0.25. Poor: over 0.25.

The bands come from web.dev's pages on LCP, INP and CLS. Two details change how you read any report. First, a page's value is the one that 75% of its visits met or beat, so a page is Good only when at least three in four visits are. Second, mobile and desktop are measured separately, so a post can pass on one and fail on the other.

Field data and lab data give different answers

PageSpeed Insights, Google's free page test, shows two kinds of results, and they can disagree:

  • Field data comes from the Chrome User Experience Report (CrUX): real Chrome users' visits over the previous 28 days. Chrome's documentation says CrUX data feeds into the page experience ranking factor in Google Search (CrUX overview).

  • Lab data comes from Lighthouse, which loads the page under simulated conditions: for the mobile test, a mid-tier phone on a mobile network. Google describes it as useful for debugging, because the conditions are controlled.

So the field data is the closer view of what your readers experience, and the lab data tells you why. A lab test has no real visitor clicking, so it can't measure INP; Lighthouse reports Total Blocking Time (TBT) as its stand-in (web.dev: Web Vitals).

Small blogs can run into one gap. CrUX includes only pages and sites that are publicly discoverable and have enough visitors. A recently published post, or one with few visits, may lack enough data; PageSpeed Insights then falls back to data for the whole site, which it calls the origin. If the origin lacks data too, there is no field data at all. Then the lab results are all you have: use them to find problems, without treating their score as the data Google ranks on.

Check one post in PageSpeed Insights

Pick one post that matters: one that already gets search visits, or one you are about to promote.

  1. Open PageSpeed Insights, paste the post's full address and run the test. Look at the mobile result first if most of your readers use phones, then at desktop.

  2. Read the field data before anything else. Note whether it describes this URL or the whole origin.

  3. Read the Core Web Vitals assessment. It passes when the 75th-percentile values of LCP, INP and CLS are all Good, or LCP and CLS when there is not enough INP data.

  4. Note which metric is not Good. That tells you what kind of problem to look for: loading (LCP), responsiveness (INP) or movement (CLS).

  5. Use the lab section to diagnose it. A Performance score of 90 or above counts as good, 50 to 89 needs improvement, and anything below 50 is poor. The audits in each category explain what to improve.

If the field data passes and only the lab score is middling, your readers are already getting a good experience, and a higher lab score is not worth chasing for SEO alone.

If you use Google Search Console, its Core Web Vitals report shows real-user data for pages across your site, split into mobile and desktop. Similar pages are combined into URL groups labelled Poor, Need improvement or Good, and each group takes the status of its worst metric. Only indexed URLs appear, and groups without enough data are left out, so a small blog may see "No data available". If a post you expected is missing because it isn't indexed, why Google hasn't indexed your page covers that problem.

Fix the usual blog culprits

Match the metric that is not Good to its likely cause. Each fix below comes from Google's web.dev guides.

  • LCP. Blog cause to check: a large featured or hero image. What to change: serve it at the size it is shown, compress it, use a format such as WebP or AVIF, and never lazy-load it.

  • LCP. Blog cause to check: a slow server response. What to change: cut redirects, ask your web host about response times, and consider a content delivery network (CDN).

  • CLS. Blog cause to check: images without dimensions. What to change: give every image width and height attributes.

  • CLS. Blog cause to check: ads and embeds such as YouTube videos, maps and social posts. What to change: reserve space for each slot before it loads.

  • INP. Blog cause to check: scripts from your theme, plugins, ads and analytics. What to change: remove scripts that add no clear value.

Images and loading. If a post opens with a large featured image, that image is likely to be its LCP element, so how soon it starts loading, how long it takes to download and how quickly it renders all count toward LCP. web.dev recommends serving the right size, compressing, and using modern formats, and it warns: "Never lazy-load your LCP image" (web.dev: Optimize LCP). If your theme or an image plugin lazy-loads images, exclude the first image in view. The same guide suggests fetchpriority="high" on the image you expect to be the LCP element.

Server response. Nothing can appear before the page's first bytes arrive. web.dev says a slow time to first byte (TTFB) can make a 2.5-second LCP hard or impossible, and lists multiple redirects and distance from the server among the causes. A CDN puts copies of your files closer to readers.

Ads and embeds. web.dev calls ads "one of the largest contributors to layout shifts on the web" (web.dev: Optimize CLS). Embeds often don't know their size until they load, so the text below them jumps. Give each ad or embed container a minimum height, and keep the space even when no ad is returned, because collapsing it shifts the page too. If you can't reserve the space, place late-loading content lower on the page.

Themes and plugins. Every script your theme, plugins, ad network or analytics adds has to be downloaded, parsed, compiled and run. Long tasks on the browser's main thread delay its response to taps and clicks, which raises INP (web.dev: Optimize INP). For third-party scripts, web.dev's advice is to remove any that don't add clear value and load the rest with async or defer (web.dev: third-party JavaScript). It also suggests lazy-loading embeds and ads below the fold. On a blog, a practical way to apply this is to audit plugins one at a time: deactivate one you can do without, retest, and keep the change if the results improve.

After a fix, give field data time

Lab results change as soon as you retest. Field data catches up slowly: PageSpeed Insights reports the previous 28 days of real visits, so a fix shows as new visits replace old ones. In Search Console, after fixing an issue on every affected page, you can click Start Tracking to begin a 28-day validation of that issue.

Write down the date of each change and what you changed, so you can compare like with like later. How to measure an SEO page refresh sets out a fair before-and-after comparison.

Where to go next