How to Improve a Poor PageSpeed Score
A poor or fair PageSpeed score means your pages load and respond slowly for real users, which drags down Core Web Vitals (LCP, INP, CLS). Google uses field data from real Chrome visits as a ranking input, so this affects search position, bounce rate, and how reliably AI crawlers can fetch and render your content. Fix it by shrinking and prioritizing the largest visible element, cutting render-blocking and unused JavaScript, compressing images, reserving space to stop layout shift, and speeding up server response.
What this means
Your audit flagged the page with poor_pagespeed or fair_pagespeed, which maps to a low Google PageSpeed Insights Performance score (0-49 is poor/red, 50-89 is needs-improvement/orange, 90-100 is good/green). That score is a weighted roll-up of lab metrics, but the metrics that actually drive ranking are the three Core Web Vitals, measured on real visitors:
- LCP (Largest Contentful Paint) — how long until the biggest visible element (usually a hero image, heading, or banner) finishes rendering. Good is under 2.5s.
- INP (Interaction to Next Paint) — how quickly the page responds to taps and clicks. Good is under 200ms. INP replaced First Input Delay in March 2024 and is now the most commonly failed vital.
- CLS (Cumulative Layout Shift) — how much the layout jumps around while loading. Good is under 0.1.
A poor score usually traces to one or more of: an oversized or lazily-loaded hero image, render-blocking CSS/JS, heavy third-party scripts (chat widgets, analytics, ad tags), a slow server (high TTFB), or images and embeds with no reserved dimensions. The single lab number in PageSpeed Insights is a simulation. Google ranks on the field data from the Chrome User Experience Report, taken at the 75th percentile of your last 28 days of real traffic.
Why it matters
Page speed is a confirmed ranking input, not a vanity metric. Google's page experience signal uses Core Web Vitals, and it evaluates them on real-user field data rather than the lab score. When fewer than 75% of your visitors clear the "good" thresholds, you lose the tie-breaker against faster competitors on the same query, and slow pages measurably increase bounce and abandonment before a visitor converts.
The AI-visibility angle matters just as much now. AI answer engines and their crawlers (Googlebot for AI Overviews, OAI-SearchBot and GPTBot for ChatGPT, PerplexityBot) fetch your HTML on a budget. A slow TTFB, or a page whose main content only appears after heavy client-side JavaScript runs, means the crawler may time out, capture a partial render, or skip the page. Your content then never makes it into the model's answer. Fast, server-rendered, lightweight pages are easier for both Google and AI engines to fetch, render, and cite, so speed pays off in classic rankings, conversion rate, and AI answer inclusion at once.
How to fix it
- 1
Read the field data, then fix the failing metric first
Run the page through PageSpeed Insights at pagespeed.web.dev and read the field data section before the lab score. It tells you which of LCP, INP, or CLS is actually failing for real users, so you don't waste effort. Open the Diagnostics and Opportunities lists, which name specific files and elements to fix, ordered by estimated savings. Fix the metric that's failing before chasing a higher overall number.
- 2
Fix LCP: optimize and prioritize the largest element
The LCP element is usually your hero image or main heading. Serve images in a modern format (WebP or AVIF), size them to their actual display dimensions, and never lazy-load the LCP image, since that is one of the most common causes of slow LCP. Add
fetchpriority="high"to the hero image and preload it, and set explicitwidthandheightso the browser reserves space. If a web font blocks the heading, addfont-display: swapand preload the font file. - 3
Cut render-blocking and unused JavaScript/CSS
Every blocking
<script>and<link rel="stylesheet">in the<head>delays first paint. Adddefer(orasyncwhere order doesn't matter) to non-critical scripts, inline the small amount of critical CSS needed for above-the-fold content, and load the rest asynchronously. Audit third-party tags, since chat widgets, A/B tools, heatmaps, and duplicate analytics scripts are frequent INP killers. Remove what you don't use and load the rest after interaction or via a tag manager with a delay. - 4
Compress and cache what the server sends
Enable Brotli (or at least Gzip) compression on your server or CDN so HTML, CSS, and JS transfer smaller. Put a CDN in front of the site to cut latency and offload static assets, and set long
Cache-Controlheaders on images, fonts, and versioned bundles so repeat visits are near-instant. Compression and caching are usually a one-time config change with an outsized payoff. - 5
Eliminate layout shift (CLS)
Give every image, video, iframe, and ad slot explicit
widthandheightattributes (or a CSSaspect-ratio) so the browser reserves space before the asset loads. Reserve fixed space for anything injected late, such as cookie banners, sticky headers, and lazy-loaded embeds, instead of letting it push content down. Preload fonts and usefont-display: swapto reduce text reflow when the custom font arrives. - 6
Speed up the server response (TTFB)
A high Time to First Byte caps how fast everything else can be. Enable full-page or object caching, upgrade off shared or oversold hosting, and put a CDN with edge caching in front. On database-backed CMSes, cache rendered pages so the server isn't rebuilding HTML on every request. If your content is heavily client-rendered, move to server-side rendering or static generation so both users and AI crawlers get real HTML in the first response.
Example
<head>
<!-- Preload the LCP image and the critical web font -->
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">
<link rel="preload" as="font" href="/fonts/inter.woff2" type="font/woff2" crossorigin>
<!-- Inline only the critical above-the-fold CSS; load the rest async -->
<style>/* critical CSS here */</style>
<link rel="stylesheet" href="/main.css" media="print" onload="this.media='all'">
<!-- Non-critical JS never blocks first paint -->
<script src="/analytics.js" defer></script>
</head>
<body>
<!-- LCP image: modern format, explicit dimensions, high priority, NOT lazy-loaded -->
<img src="/hero.avif"
width="1200" height="600"
fetchpriority="high"
alt="Product dashboard overview">
<!-- Below-the-fold images: dimensions set, lazy-loaded to save bandwidth -->
<img src="/feature.avif" width="800" height="450" loading="lazy" alt="Reporting view">
</body>Prioritize the LCP hero image, defer non-critical JS, and reserve image space to prevent layout shift.
Platform-specific steps
Yoast and Rank Math handle metadata, not speed, so pair them with a dedicated performance stack. Install a caching plugin (WP Rocket, LiteSpeed Cache, or W3 Total Cache) and turn on page caching, Brotli/Gzip, CSS/JS minification, and defer JavaScript. Add an image-optimization plugin (ShortPixel, Imagify, or Smush) to auto-convert to WebP/AVIF and lazy-load below-the-fold images, but exclude your hero/LCP image from lazy-load. Cut plugin bloat, since every active plugin can add front-end CSS/JS, so deactivate anything unused. Put Cloudflare or another CDN in front, and choose quality managed hosting, because cheap shared hosting is a common TTFB culprit.
You can't touch server config, so focus on the theme and apps. Use a lightweight, up-to-date theme, since heavy premium themes with sliders and animations tank LCP. Audit installed apps, because each injects scripts and uninstalled apps often leave code behind, so remove them fully. Compress images before upload (Shopify serves WebP automatically but won't fix oversized source files), and avoid autoplaying video heroes. Minimize third-party tracking pixels and review Liquid customizations that add render-blocking assets.
Server and caching are managed for you, so your levers are content and layout. Replace large hero images and background videos with compressed, correctly-sized versions, and limit heavy animations, sliders, and embedded widgets that add JavaScript. Remove unused third-party embeds and marketing scripts. These platforms handle image formats and some lazy-loading automatically, so the highest-impact move is usually cutting the number and weight of elements on the page rather than low-level tuning.
Use next/image (or a similar responsive-image pipeline) for automatic format negotiation, sizing, and lazy-loading, and set priority on the LCP image so it isn't lazy-loaded. Prefer Server Components, SSR, or static generation so crawlers and users get real HTML instead of waiting on client hydration. Use next/font to self-host and preload fonts with font-display: swap. Code-split with dynamic imports to shrink the initial JS bundle, defer third-party scripts via next/script with strategy="lazyOnload", and enable Brotli plus long-lived cache headers at your CDN or edge.
Frequently asked
90-100 is good (green), 50-89 is needs improvement (orange), and 0-49 is poor (red). But the single lab score is a simulation. What Google actually ranks on is your field data: real-user Core Web Vitals from the Chrome UX Report at the 75th percentile. Aim to pass all three Core Web Vitals in the field data rather than obsess over the exact lab number.
No. Google's bar is passing Core Web Vitals (LCP under 2.5s, INP under 200ms, CLS under 0.1) for 75% of real users, not scoring 100 in the lab. Chasing 100 has diminishing returns and can force trade-offs that hurt UX. Get into the good range on field data, then spend the rest of your effort on content and links.
PageSpeed tests mobile on a throttled connection and a slower simulated CPU, which is closer to how many real users browse. Mobile is also where render-blocking JS and oversized images hurt most. Since Google indexes mobile-first, prioritize the mobile score. Fixing it usually improves desktop as a side effect.
The lab test runs in a simulated environment, so network conditions, third-party scripts, and server load cause run-to-run variation. That is expected. For a stable read, run it a few times and rely on the field data, which is aggregated over 28 days of real traffic and doesn't bounce around like a single lab run.
AI crawlers fetch on a time and resource budget. A slow server response, or content that only appears after heavy JavaScript, can cause the crawler to time out or capture a partial page, so your content never enters the model's answer. Fast, server-rendered pages with quick TTFB are easier for both Google and AI engines to fetch, render, and cite.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.