Guide Measurement and improvement
Why a website is slow and how to find out why
By Studio Swing
A website is usually slow for a small number of findable reasons: a large image at the top of the page, scripts that run before the visitor can do anything, a server that takes too long to answer, or content that shifts around while loading. The platform you built on can contribute, but it is rarely the whole story, and you cannot tell from the outside which reason applies to you. You find out by measuring real visitors first, then running a lab test on the pages that fail, then matching each failing measurement to its usual cause.
On this page
- 01What "slow" actually means for a visitor
- 02What are the Core Web Vitals targets
- 03How do you find out which metric is failing
- 04What usually makes the main content load slowly
- 05What usually makes a page ignore taps
- 06What usually makes a page jump
- 07Is the platform to blame
- 08Does speed affect search rankings
- 09What a speed fix will not do
- 10A checklist you can use without us
- 11Where to go from here
- 12Sources
What "slow" actually means for a visitor
This guide explains the three measurements Google publishes targets for, how to read them, what each failing score usually points to, and how to decide whether the platform or something else is responsible.
Say you own a kitchen showroom with an online enquiry form. Your site feels slow on a phone. Your developer says the platform is the problem. A friend says the hosting is cheap. A speed tool gives the home page 41 out of 100 and a red warning.
None of those is a diagnosis yet. "Slow" can mean three different experiences, and each has a different cause:
- The page takes a long time to show its main content. The visitor stares at a blank or half-built screen.
- The page shows, but ignores taps. A visitor presses "Enquire" and nothing happens for a moment.
- The page jumps. A button moves just as the visitor reaches for it.
Google's Core Web Vitals name these three experiences and give each a target. They are measured on real visitors' devices, not on a score out of 100.
What are the Core Web Vitals targets?
These are the good thresholds as web.dev states them: Largest Contentful Paint (LCP) within 2.5 seconds, Interaction to Next Paint (INP) within 200 milliseconds, and Cumulative Layout Shift (CLS) of 0.1 or less. A page "passes" when it meets all three at the 75th percentile of page loads, segmented across mobile and desktop.
The 75th percentile matters. It means that for the page to count as good, three out of four visits must meet the target, so a fast experience on your own office wifi proves little.
A fourth number sometimes appears in reports: Time to First Byte (TTFB), the time until the server starts to answer. web.dev says most sites should aim for 0.8 seconds or less, but it also says plainly that "TTFB isn't a Core Web Vitals metric". Treat it as a clue to a cause, not a target in its own right.
How do you find out which metric is failing?
Start with real visitors, then use a lab test to look for causes.
Step 1: look at field data. Field data is what real visitors experienced. Google's PageSpeed Insights shows it from the Chrome User Experience Report, using "the previous 28-day collection period". If the page has too few visits, PageSpeed Insights falls back to data for the whole site (the "origin"), and if that is also thin, it shows no field data at all. Search Console's Core Web Vitals report uses the same source, groups URLs that have similar user experience, and gives each group the status of its slowest metric. Both tools tell you whether there is a problem and where it is: which metric, on mobile or desktop, on which kind of page.
Step 2: run a lab test on a failing page. Lab data is a simulated load on one device with fixed network conditions, produced by Lighthouse (it is inside PageSpeed Insights, and in Chrome DevTools). It is the tool for finding causes, because it lists what the page loaded, in what order and what blocked it. web.dev's guidance is to prioritize field data because it reflects real users, and to use lab data to look for opportunities.
Step 3: expect the two to disagree. web.dev lists reasons: personalized content and A/B tests vary what loads, cached files load faster for returning visitors, a lab test cannot predict when a real visitor taps, and field data includes layout shifts across the whole visit, while a lab test mostly catches those near the top of the page. A good lab score with poor field data often means real devices, networks or behavior differ from the simulation. It does not mean the real data is wrong.
Step 4: look at more than the home page. Test your most important pages: the home page, a main service or product page, and the page with the form. Slowness is often in one template, not the whole site.
What usually makes the main content load slowly?
Largest Contentful Paint is the metric most people mean by "the page loads slowly". web.dev breaks it into four parts with an ideal share of the 2.5-second budget:
| Part | Ideal share | What it is |
|---|---|---|
| Time to first byte | About 40% | The server answering |
| Resource load delay | Under 10% | The gap before the browser starts fetching the main element |
| Resource load duration | About 40% | Downloading the main element, often a large image |
| Element render delay | Under 10% | The gap between download and showing it, often caused by blocking styles or scripts |
This turns a vague complaint into specific questions:
- Is the main element a big image? When the largest element is a hero photo, its file size drives the download time. Reducing the file's size, using modern formats and serving a size suited to the device all shorten the download. Our guide to website images that help customers understand your offer covers the preparation steps.
- Is that image discoverable early? If the browser only learns about the image late, for example because a script adds it, it starts the download late. web.dev advises making the main image visible in the page's initial HTML. It also warns against lazy-loading images at the top of the page: "Don't lazy-load images that are likely to be in-viewport when the page loads, especially LCP images," and shows a test where adding a fetch priority hint to a hero image cut LCP from 2.6 seconds to 1.9 seconds on one site.
- Is the server slow to answer? A high first-byte time points at hosting, caching, redirects or heavy page building on the server. Redirect chains add to it.
- Do styles or scripts block the display? Render-blocking files delay showing content even after the image has arrived.
What usually makes a page ignore taps?
Interaction to Next Paint replaced the older First Input Delay metric. web.dev describes it as measuring the time from the start of an interaction until the next frame is fully presented, across all interactions on a page, not just the first.
The usual cause is JavaScript. web.dev calls any task that takes longer than 50 milliseconds a "long task", and explains that when a visitor interacts with a page full of long tasks, the interface "will feel unresponsive, and possibly even broken". It names the JavaScript you write, meaning the scripts that run on your page, as perhaps the largest source of these tasks. A shop with a chat widget, a review plugin, a tracking tag and an animation library may be running four sets of scripts before the visitor can use a menu.
What usually makes a page jump?
Cumulative Layout Shift measures unexpected movement. web.dev lists the common causes: images or videos with no declared size, web fonts that render larger or smaller than the fallback font, and third-party adverts or widgets that resize themselves after loading. The fixes are equally concrete: declare width and height on images, reserve space for embeds with a minimum height or aspect ratio, and manage font loading so text does not reflow.
Is the platform to blame?
Sometimes, but you should measure before assigning blame, because the answer differs by site.
What a platform controls: how fast the server answers, what scripts and styles come bundled with the theme, and how images are delivered. Those set a floor. What you or your agency control, usually the larger share: how many apps, plugins and tracking tags you have added, how large your images are, which fonts you load, and how the pages are built on top of the platform.
web.dev recommends a direct test for third-party scripts. In Chrome DevTools, measure the page's load with throttling on, block a suspected third-party address, reload, and measure again, taking the median of several runs. If the page speeds up noticeably, the script is part of the cause, and the question becomes whether it earns its place. Lighthouse also flags the heaviest third-party providers and warns when a page's total download is above 5,000 KiB.
Be careful with claims in either direction. A developer who says "it's the platform" has not yet shown which part of the platform. A platform vendor who says "it's your apps" has not measured your pages. Ask for the failing metric, the page it fails on, and the specific resource causing it.
Does speed affect search rankings?
Core Web Vitals are used by Google's ranking systems, and Google highly recommends good scores for success with Search and for a good experience. Google also says "there is no single signal", that "there's more to great page experience than Core Web Vitals scores alone," and that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." A fast site is not promised a better position, and a score out of 100 from a lab tool is not a ranking. Where several pages are equally relevant, page experience can contribute. The firmer reason to fix speed is the visitor: a page that loads late, ignores taps or shifts under a thumb loses people before they read a word of it. That connects to the question in why a website is not bringing enquiries.
What a speed fix will not do
- Make a weak offer convincing. A fast page with an unclear message still fails to convert.
- Produce a guaranteed score. Real-world data varies by visitor, device and day.
- Fix every metric at once. Each metric has its own cause, and a change that improves LCP can worsen layout shift if images lose their declared sizes.
- Replace measurement after changes. Field data covers a trailing 28 days, so it takes weeks to show whether a fix worked. Check the lab result at once and the field result later.
A checklist you can use without us
- Open PageSpeed Insights for your home page, a main service or product page and your form page, on mobile.
- Note whether each has field data, and whether LCP, INP and CLS are good, need improvement or poor.
- Check Search Console's Core Web Vitals report for groups of pages with the same problem, on mobile and desktop.
- For a failing LCP: identify the largest element, its size, whether it loads early, and the server's first-byte time.
- For a failing INP: list the scripts that run on the page and ask what each is for.
- For a failing CLS: check that every image and embed has a reserved space, and how fonts load.
- Block one suspected third-party script in DevTools and re-measure, using the median of several runs.
- Ask your developer for the cause of each failing metric in one sentence, and the planned fix.
- Re-check field data after four weeks, not after four days.
Where to go from here
When we build a site, speed is planned before the build, not repaired after it. The page brief sets which image or element leads each page, the build is tested against Google's Core Web Vitals targets, and performance is one of the nine lenses a site is reviewed through before launch.
If you would like a site where that is decided up front, see our website design and development work. If you want to know what else to measure beyond speed, read our guide to what to measure on a website. If you would like to talk through your own site's slowness, you can discuss your project with us.
Sources
web.dev, "Web Vitals" (the three metrics, thresholds, 75th percentile): https:/
web.dev, "Largest Contentful Paint (LCP)": https:/
web.dev, "Interaction to Next Paint (INP)": https:/
web.dev, "Cumulative Layout Shift (CLS)": https:/
web.dev, "Time to First Byte (TTFB)": https:/
web.dev, "Optimize Largest Contentful Paint": https:/
web.dev, "Optimize Cumulative Layout Shift": https:/
web.dev, "Optimize long tasks": https:/
web.dev, "Why lab and field data can be different": https:/
web.dev, "Identify slow third-party JavaScript": https:/
web.dev, "Browser-level image lazy loading": https:/
web.dev, "Fetch Priority API": https:/
Google PageSpeed Insights documentation, "About PageSpeed Insights": https:/
Search Console Help, "Core Web Vitals report": https:/
Google Search Central, "Understanding page experience in Google Search results": https:/
Google Search Central, "Core Web Vitals and Google Search results": https:/