Why Your Website Fails Google PageSpeed — And the Complete Fix

You ran the test. You got the red score. Here is exactly what it means and exactly how to fix it — for any website, any platform, anywhere.

You ran your website through Google PageSpeed Insights, expecting a green tick and a pat on the back. Instead you got a number in the 30s or 40s, three metrics glowing red, and a list of recommendations written in language that sounds like it was generated for engineers rather than for the business owner who just wants to know why their site feels slow on a phone. This guide exists to translate that report into plain language and then walk through, metric by metric, exactly what is broken and exactly how to fix it.

72% — of websites in 2026 fail Google's Core Web Vitals performance threshold (BrightEdge)

Only 33% — of websites worldwide currently pass all three Core Web Vitals thresholds simultaneously

7% — drop in conversions for every additional second of load time, compounding

This is not a niche technical problem affecting a small minority of poorly-built sites. It is the default state of the web in 2026. Two out of every three websites fail the standard Google uses to decide how much to reward a page in search rankings — and every one of those failures is translating directly into lost visitors, lost rankings, and lost revenue. The good news is that the fixes are well understood, mostly inexpensive, and entirely within reach regardless of what platform your site is built on.

1. What Core Web Vitals Actually Measure

Core Web Vitals are three specific, quantifiable metrics that Google uses to assess the real-world experience of loading and using a web page. They were introduced because traditional speed metrics (like "time to first byte") measured technical events that did not necessarily correlate with what a human actually experiences when a page loads. Core Web Vitals were designed to measure the human experience directly.

1.1 Largest Contentful Paint (LCP) — "How long until I can see the main thing?"

LCP measures the time from when a page starts loading to when the largest visible content element — usually a hero image, a heading, or a block of text — has fully rendered on screen. It answers the question every visitor is implicitly asking: "How long until I can see what this page is actually about?"

• Good: under 2.5 seconds

• Needs improvement: 2.5 to 4 seconds

• Poor: over 4 seconds

1.2 Interaction to Next Paint (INP) — "How quickly does the page respond when I tap something?"

INP measures the time between a user interaction (a tap, a click, a key press) and the moment the page visually responds to that interaction. It replaced an older metric called First Input Delay (FID) in 2024 because it captures responsiveness across the entire page lifecycle, not just the first interaction. A high INP means a visitor taps a button and the page takes a perceptible, frustrating moment to react — or worse, appears to do nothing, causing the visitor to tap again, sometimes triggering the action twice.

• Good: under 200 milliseconds

• Needs improvement: 200 to 500 milliseconds

• Poor: over 500 milliseconds

1.3 Cumulative Layout Shift (CLS) — "Does the page jump around while I'm trying to read or tap it?"

CLS measures the total, unexpected movement of visible elements during the page's loading lifecycle. The classic example: a visitor starts reading the first paragraph, and then an advert or an image loads above it, pushing the text down the page — or worse, the visitor goes to tap a button and an element shifts at the last moment, causing them to tap the wrong thing entirely. CLS is scored as a unitless number representing the magnitude of movement.

• Good: under 0.1

• Needs improvement: 0.1 to 0.25

• Poor: over 0.25

💡 TIP — Why this matters for rankings, not just user experience

Since the 2021 Page Experience Update, Core Web Vitals have been a confirmed Google ranking factor. A page that fails all three metrics is being actively deprioritised relative to a competitor page covering the same topic that passes them. This means two pages with identical content quality can rank very differently based purely on technical performance — which is precisely why this guide treats Core Web Vitals as inseparable from SEO, not a separate technical concern.

2. How to Actually Read Your PageSpeed Insights Report

Go to pagespeed.web.dev, enter your URL, and run the test. Always test the mobile result first — Google primarily uses the mobile version of your site for ranking purposes (mobile-first indexing), and mobile scores are almost always worse than desktop because mobile devices have less processing power and typically slower network connections.

The report gives you a Performance score out of 100, color-coded green (90-100), orange (50-89), or red (0-49). Below the score, you will see the three Core Web Vitals metrics plus two supporting metrics (First Contentful Paint and Total Blocking Time). Below that, a list of "Opportunities" — specific, prioritised recommendations, each with an estimated time saving. This is the most useful section of the report and the one most people skip because it looks intimidating. The next sections of this guide translate the five most common opportunities into plain language and specific fixes.

3. Fixing LCP: The Five Most Common Causes

3.1 Cause: Unoptimised Hero Images

The single most common cause of poor LCP is a large, unoptimised image — usually the hero image at the top of the homepage — being served at full resolution to every visitor, regardless of their device or connection. A photograph taken on a modern smartphone camera can be 4-8MB in its original form. Served unoptimised to a mobile visitor on a 4G connection, that single image can take three to five seconds to load on its own — and it is usually the largest element on the page, meaning it is also the LCP element being measured.

🔧 THE FIX — Compress and serve modern image formats

Convert images to WebP or AVIF format, which achieve the same visual quality at 25-50% of the file size of JPEG or PNG. Resize images to the actual maximum display dimension needed (a hero image displayed at 1200px wide should never be served as a 4000px-wide file). Use responsive image techniques (the srcset attribute) so mobile devices receive a smaller file than desktop devices automatically. Tools: Squoosh.app for manual conversion, or automatic image optimisation built into modern frameworks like Next.js (next/image) which handles resizing, format conversion, and lazy loading automatically.

3.2 Cause: Render-Blocking CSS and JavaScript

Every CSS and JavaScript file linked in a page's head must be downloaded and processed before the browser can render the page content. A page that loads ten separate CSS files (common on page-builder platforms with plugins, each adding its own stylesheet) forces the browser to wait for all ten downloads before painting anything. This is the single largest structural difference between hand-coded sites and page-builder sites: a clean codebase loads one optimised CSS file; a typical WordPress page-builder site loads CSS and JavaScript from the theme, three to eight plugins, and the page builder itself — often six to twelve separate files.

🔧 THE FIX — Minimise, combine, and defer

Combine multiple CSS files into one. Minify CSS and JavaScript (remove whitespace and comments, which can reduce file size by 20-40% with zero functional change). Defer or async-load any JavaScript that is not required for the initial render (most tracking scripts, chat widgets, and non-critical interactive elements can be deferred). On WordPress, plugins like WP Rocket or Autoptimize handle this automatically — though the most effective fix is reducing the number of plugins in the first place, since each one is a potential source of additional blocking resources.

3.3 Cause: Slow Server Response Time

Before any content can render, the browser must receive the first byte of the HTML document from the server. If the server takes 800 milliseconds to respond — common on shared hosting plans serving hundreds of other websites from the same physical machine — that delay is added to every other delay in the loading process before the page has even started rendering.

🔧 THE FIX — Use a CDN and modern hosting infrastructure

A Content Delivery Network (Cloudflare, Vercel's Edge Network, or similar) caches your page at data centres around the world and serves it from the location physically closest to each visitor — turning a potential 800ms+ round trip to a single origin server into a 20-50ms response from a nearby edge node. For sites built on frameworks like Next.js, deployment to Vercel pre-renders pages as static HTML at build time, meaning there is often no server processing required at all for the visitor's request — the page is already built and waiting at the edge.

3.4 Cause: No Browser Caching Configured

Without caching headers configured, a returning visitor's browser re-downloads every image, stylesheet, and script on every visit — even though nothing has changed since their last visit five minutes ago. This unnecessarily slows down every repeat visit, which matters significantly for content-heavy sites where visitors browse multiple pages in one session.

🔧 THE FIX — Set long cache lifetimes for static assets

Configure cache-control headers so that images, CSS, and JavaScript files (which rarely change) are cached by the browser for periods of weeks or months, while the HTML document itself (which may change more frequently) is cached for a much shorter period or not at all. Cloudflare and Vercel handle this automatically with sensible defaults for most asset types.

3.5 Cause: Web Fonts Loading Slowly

Custom web fonts (Google Fonts, Adobe Fonts, or self-hosted brand fonts) require an additional download before text can render in the intended typeface. If this download is not optimised, the browser may either display invisible text while waiting for the font (a "flash of invisible text") or display a fallback font and then visually swap to the custom font once it loads — both of which delay or disrupt the perceived load experience.

🔧 THE FIX — Preload critical fonts and use font-display: swap

Add a preload hint for your primary font file so the browser starts downloading it immediately, in parallel with other resources, rather than discovering it needs the font partway through CSS parsing. Set font-display: swap in your CSS so the browser shows a fallback font immediately and swaps to the custom font once loaded, rather than showing nothing. Consider self-hosting Google Fonts rather than loading them from Google's CDN, which removes an additional DNS lookup and connection.

4. Fixing INP: Why Your Buttons Feel Sluggish

4.1 Cause: Heavy JavaScript Execution Blocking the Main Thread

Browsers process JavaScript on a single main thread — the same thread responsible for responding to user interactions. If a page runs a large, complex JavaScript task (rendering a large list, processing data, running an animation calculation) at the exact moment a visitor taps a button, the browser cannot respond to that tap until the JavaScript task finishes. This is the most common cause of poor INP, and it disproportionately affects page-builder sites and sites with multiple third-party scripts (chat widgets, analytics tools, advertising pixels, review widgets) all competing for the same processing thread.

🔧 THE FIX — Break up long tasks and reduce third-party scripts

Audit every third-party script on the page — chat widgets, heatmap tools, marketing pixels, review widgets — and remove any that are not delivering clear value. Each one adds JavaScript execution time and competes for the main thread. For scripts that must remain, load them asynchronously and, where possible, delay their execution until after the page has become interactive (a technique called "facade loading" — showing a static placeholder for a chat widget, for example, and only loading the full widget code when the visitor actually clicks it).

4.2 Cause: Unoptimised Event Handlers

On custom-built or complex sites, inefficient JavaScript event handlers (the code that runs when a visitor scrolls, clicks, or types) can cause the browser to perform unnecessary, repeated calculations. A poorly optimised scroll handler that recalculates the entire page layout on every pixel of scroll movement, for example, can make scrolling feel sluggish and delay the page's ability to respond to a subsequent tap.

🔧 THE FIX — Debounce and throttle expensive operations

Techniques called debouncing and throttling limit how often an expensive function can run in response to rapid, repeated events like scrolling or resizing — for example, only recalculating layout once every 100 milliseconds during a scroll, rather than on every single scroll event. This is a code-level fix that requires a developer's attention, but it is one of the highest-impact fixes for INP on content-rich, interactive sites.

5. Fixing CLS: Stopping the Page from Jumping Around

5.1 Cause: Images and Videos Without Defined Dimensions

When an image tag does not specify its width and height in advance, the browser does not know how much space to reserve for it while it loads. The browser renders the surrounding text first, then the image arrives and the browser has to push everything below it down the page to make room — exactly the disruptive jump that CLS measures.

🔧 THE FIX — Always specify width and height attributes

Every image and video element should include explicit width and height attributes (or be wrapped in a container with a defined aspect ratio via CSS). This allows the browser to reserve the correct amount of space before the image has even started downloading, eliminating the layout shift entirely. Modern frameworks like Next.js enforce this by requiring width and height (or a "fill" mode with a sized parent container) on every image component — which is one of several reasons hand-coded modern framework sites consistently outperform page-builder sites on this specific metric.

5.2 Cause: Ads, Embeds, or Widgets Injected Without Reserved Space

Third-party content — embedded social media posts, advertising units, cookie consent banners, review widgets — is frequently injected into the page after the initial render, without any space reserved for it in advance. This is one of the most common causes of severe CLS scores, because these elements are often inserted above existing content, pushing everything else down at an unpredictable moment.

🔧 THE FIX — Reserve space with placeholder containers

For any element that loads asynchronously — a cookie banner, a review widget, an embedded video — define a fixed-height container in the page's CSS before the element loads, so its eventual appearance does not require the browser to shift other content. For cookie consent banners specifically, position them as an overlay (fixed position) rather than inserted inline into the page flow, since an overlay does not push other content and therefore cannot cause layout shift.

5.3 Cause: Web Fonts Causing a Visible Text Reflow

When a custom font loads and replaces a fallback font (as described in Section 3.5), if the two fonts have significantly different character widths, the text reflows — words wrap differently, line counts change, and content below shifts position. This is a secondary CLS cause connected to the same font-loading issue that affects LCP.

🔧 THE FIX — Match fallback font metrics to the custom font

Choose a fallback font with similar character width and line height to your custom font, or use a font-loading technique (such as the font-display: optional setting, or modern tools like Next.js's built-in font optimisation) that calculates and applies metric overrides automatically, minimising the visual reflow when the custom font loads.

6. Platform-by-Platform: Where Your Site Stands and What to Do

The platform a website is built on substantially determines how hard each of the fixes above is to implement — and, in some cases, whether it is possible at all. The following covers the most common platforms.

⚠️ WARNING — Some platforms have a hard ceiling

It is important to be honest about this: no amount of optimisation effort on Wix or a heavily plugin-dependent WordPress page-builder site will reach the scores achievable on a hand-coded Next.js site, because the platform itself generates bloated output that the user has no ability to modify at the code level. For businesses serious about Core Web Vitals as a ranking factor, migrating to a custom-built site is, at some point, the more effective use of resources than continuing to optimise a platform with a structural ceiling.

7. The 30-Minute Quick Win Checklist

Before considering a full rebuild, the following checklist covers fixes that can be implemented in roughly thirty minutes on most platforms and typically produce a measurable score improvement.

1. Run your homepage through pagespeed.web.dev (mobile) and note your current score and metrics as a baseline.

2. Compress your three largest images using Squoosh.app or TinyPNG, converting to WebP where the platform supports it.

3. Check your plugin or app list (WordPress, Shopify) and deactivate anything not actively delivering value — each one is a potential source of blocking scripts.

4. Enable a caching plugin (WP Rocket, W3 Total Cache, or your platform's built-in caching) if not already active.

5. Add explicit width and height to any images missing them — check this through your CMS's image editor or, on custom code, in the HTML directly.

6. Move your cookie consent banner to an overlay/fixed position if it currently pushes content down.

7. Re-run the PageSpeed test and compare to your baseline.

💡 TIP — Test on a real budget phone, not just your own device

PageSpeed Insights tests against a simulated mid-tier mobile device and a throttled connection — deliberately, because that represents the experience of a meaningful share of real visitors. If your own testing is done exclusively on a recent flagship phone over WiFi, you will consistently underestimate how slow your site feels to a portion of your actual audience.

8. When to Stop Optimising and Start Rebuilding

There is a point of diminishing returns on optimisation efforts applied to a fundamentally bloated platform. If you have worked through the fixes in this guide and your mobile Performance score remains below 60, the structural ceiling of your current platform is likely the binding constraint — not any remaining individual fix.

The decision to rebuild rather than continue optimising should weigh: the cost of a rebuild against the ongoing cost of lost rankings and lost conversions from a slow site; the time already invested in optimisation efforts with diminishing returns; and the broader benefits a rebuild provides beyond speed alone — proper schema markup, a conversion-focused page structure, and ownership of the underlying code rather than a platform subscription. The full breakdown of what to look for in a rebuild and how to evaluate an agency is covered in our companion guide.

A WebWise website build starts from a clean Next.js codebase deployed to Vercel's edge network, with image optimisation, font handling, and caching configured by default — not as advanced techniques applied after the fact, but as the baseline starting point. This is why every WebWise build scores in the green zone (90+) on mobile Performance from the day it launches, without requiring the optimisation work this article has just walked through.

9. Why This Matters Beyond Google: The Conversion Connection

It is worth restating the business case, because Core Web Vitals can feel like a technical curiosity divorced from revenue. It is not. As established in our CRO guide, a load time increase from one to three seconds raises the probability of a visitor bouncing by 32%; at six seconds, that probability rises 90%. Every one of the fixes in this article — image compression, render-blocking script removal, layout shift prevention — translates directly into more visitors staying on the page long enough to read the offer, see the phone number, and take action.

The ranking benefit and the conversion benefit are not two separate reasons to fix Core Web Vitals — they are the same fix, producing two compounding returns. A faster site ranks higher, bringing more visitors. The same speed improvement also converts a higher percentage of those visitors into enquiries. This is why technical performance work consistently produces some of the highest returns of any single category of website investment.

10. The 15 Keywords This Article Targets

Conclusion: The Score Is a Symptom, Not the Disease

A red PageSpeed score is not the actual problem — it is the measurement of the actual problem, which is visitors leaving before your page has finished telling them what you do. Every fix in this guide, from image compression to layout shift prevention, exists to close the gap between the moment someone clicks your link and the moment they can act on what you offer.

Work through the thirty-minute checklist first. If the score moves meaningfully, keep optimising incrementally. If it does not — if you are fighting a platform ceiling that no amount of plugin tweaking will overcome — that is valuable information too. It tells you that the highest-return next step is not another hour of optimisation, but a conversation about what a properly built foundation looks like.

If you would like a second opinion on your current score, or want to know what a rebuild would look like, the starting point is a free 15-minute call. We will run your site through the same diagnostics covered in this article and tell you, honestly, whether optimisation or a rebuild is the better investment. Start at webwise.digital/contact.

Further reading: Your Website Has Visitors. Here's Why It Has No Customers — the companion conversion guide that explains what to do once your site is fast enough to keep visitors around.