Why page speed matters more than you think
Page speed is not a vanity metric. It is a ranking factor, a conversion factor, and a user experience factor — all at once.
Google confirmed page speed as a mobile ranking factor in 2018 and elevated Core Web Vitals to a ranking signal in 2021. But the business impact goes beyond rankings. Research from Google and Deloitte consistently shows that every 100 milliseconds of added load time reduces conversion rates by up to 7%. Amazon found that a one-second delay cost them 1% of revenue — which, at their scale, was $1.6 billion annually.
For small and mid-sized businesses, the numbers are proportionally similar. A slow site does not just rank worse; it loses visitors who never convert.
Understanding Core Web Vitals
Largest Contentful Paint (LCP)
LCP measures how long it takes for the largest visible element to render — typically a hero image, heading, or video. Google considers under 2.5 seconds "good." Most LCP problems come from slow server response times, unoptimised images, or render-blocking resources that delay the browser from painting content.
Interaction to Next Paint (INP)
INP replaced First Input Delay in March 2024. It measures the worst-case responsiveness across all interactions during a page visit — not just the first click. A page with heavy JavaScript that freezes the browser during scroll, click, or keyboard input will score poorly. Under 200 milliseconds is the target.
Cumulative Layout Shift (CLS)
CLS measures how much the page layout shifts unexpectedly during load. Ads that push content down, images without defined dimensions, and dynamically injected elements are the usual culprits. A score under 0.1 is considered good. Layout shifts are particularly damaging on mobile, where a shift can cause a user to tap the wrong element.
The usual suspects
In our experience auditing hundreds of websites, the same handful of issues cause the majority of speed problems:
Unoptimised images account for the largest performance gap on most sites. A single 3MB hero image served without compression, resizing, or modern format (WebP/AVIF) can add seconds to load time. Image optimisation alone often moves a site from "poor" to "needs improvement."
Render-blocking resources — CSS and JavaScript files that the browser must download and parse before it can show any content — are the second most common issue. Deferring non-critical scripts and inlining critical CSS can dramatically improve perceived load time.
Third-party scripts from analytics, chat widgets, A/B testing tools, and ad platforms add up quickly. Each script is a network request, and many execute JavaScript that blocks the main thread. Audit which third-party scripts you actually use and remove the rest.
Server response time (TTFB) is the foundation. If your server takes 800 milliseconds to respond, nothing else can load until that time has passed. Slow TTFB is usually caused by unoptimised database queries, lack of caching, or geographic distance between the server and the user.
What a speed test cannot tell you
A synthetic speed test — including ours — simulates a single page load in controlled conditions. It is excellent for identifying specific technical issues and tracking improvements over time. But it does not capture the full picture of real-world performance.
Real users visit on varied devices, network conditions, and geographic locations. They interact with your site in ways a synthetic test cannot replicate. For a complete performance picture, combine synthetic testing with real-user monitoring (RUM) tools like Google's Chrome User Experience Report (CrUX), which powers the Core Web Vitals data in Search Console.
From metrics to action
The purpose of a speed test is not to chase a perfect score. It is to identify the specific issues that are costing you visitors and conversions, and fix them in order of impact.
Start with the top three issues in your report. Fix them, re-test, and see the score move. If the remaining issues require server configuration, CDN setup, or build pipeline changes, our engineering team can handle the implementation.
Our process
What you get
Frequently asked questions
What are Core Web Vitals?
Core Web Vitals are three metrics Google uses to measure real-world user experience: Largest Contentful Paint (LCP) measures loading speed — how quickly the main content appears. Interaction to Next Paint (INP) measures responsiveness — how quickly the page reacts when you click or tap. Cumulative Layout Shift (CLS) measures visual stability — whether elements jump around during load.
What is a good page speed score?
Google considers a performance score of 90 or above as good. Scores between 50 and 89 need improvement, and below 50 is poor. For Core Web Vitals specifically, good thresholds are: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1.
Why is my mobile score lower than desktop?
Mobile testing simulates a mid-range device on a 4G connection, which is significantly slower than a typical desktop setup. Most websites score 20 to 40 points lower on mobile. This is normal, but since Google uses mobile-first indexing, the mobile score is the one that matters most for rankings.
How do I improve my page speed?
The most impactful fixes are usually: compress and properly size images (often the single biggest win), remove or defer render-blocking CSS and JavaScript, reduce server response time, eliminate unnecessary third-party scripts, and enable text compression (gzip or Brotli). Start with the largest opportunities in your report.
How often should I test page speed?
Test after any deployment, CMS update, or content change. New images, plugins, or tracking scripts are the most common causes of speed regressions. Monthly testing as a baseline catches gradual degradation.