Page speed
Making a website faster, in the order that actually works.
Speed work goes wrong when it starts with a tool score instead of a measurement, and with a plugin instead of a diagnosis. This is the order that finds the real problem first.
How do I make my website load faster?
Start by measuring the right thing: Google's Core Web Vitals are Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less and Cumulative Layout Shift at 0.1 or less, measured at the 75th percentile of real page loads and reported separately for mobile and desktop.
Then fix in order of impact: identify which element on screen is the largest one people are waiting for, remove whatever delays it, compress and correctly size images, defer or delete third party scripts, and reserve space for anything that arrives late.
A single lab test is a diagnostic tool rather than the result, because the number that counts comes from real visits on real devices and networks.
Measure the right thing before you change anything
There is no secret speed score. Google publishes the three metrics, the thresholds and the percentile they are judged at, which makes this one of the few parts of web work with a public pass mark.
Largest Contentful Paint is how long until the biggest thing on screen appears, usually a hero image or a headline. Interaction to Next Paint is how long the page takes to visibly respond when someone taps. Cumulative Layout Shift is how much the page jumps while it loads, which is what makes people tap the wrong button.
The 75th percentile matters more than the thresholds do. It means three quarters of real visits have to be good, so an average dragged upward by desktop users on fast connections does not count as a pass. Results are also segmented by mobile and desktop, and mobile is almost always the harder of the two.
Interaction to Next Paint replaced First Input Delay as a Core Web Vital. If a report or an agency is still quoting First Input Delay at you, it is measuring something Google no longer treats as current.
What a tenth of a second was worth
Google commissioned Deloitte and 55 to measure this across 37 brand sites and more than 30 million user sessions. The study was published in 2020 and remains the largest public attempt to connect mobile load time to commercial outcomes.
SourceGoogle, Deloitte and 55, Milliseconds Make Millions, 2020 (37 sites, 30m+ sessions)
Those are correlations measured in 2020 on other people's websites, not a forecast for yours. What they establish is direction and rough magnitude: tenths of a second carry commercial weight, which is why speed belongs inside a build rather than in a later phase nobody budgets for.
Where the gain actually shows up
Speed rarely changes who finds you. It changes how many of the people who already arrived are still there when the page becomes useful.
This is why the honest promise about speed work is a conversion promise and not a ranking promise. The people you lose to a slow page had already chosen to click.
It also tells you where to measure the effect. Watch form starts, form completions and calls from the pages you sped up, not just the score from the tool you used to speed them up.
The diagnosis and fix order
Every step after the first is cheaper once you know which element people are actually waiting for. Working out of order is how sites end up with four caching plugins and the same load time.
Get field data before you touch a line of code
Field data is what real visitors experienced. Look at it segmented by mobile and desktop and read the 75th percentile figure, not the average. This tells you whether you have a problem and on which device class. Lab tools tell you why, but they cannot tell you whether.
- Check mobile and desktop separately, because they usually disagree
- Check the pages that receive search traffic, not only the home page
- Record the starting numbers somewhere, so there is a before to compare against
Identify the Largest Contentful Paint element on the slow page
It is one specific element: a hero image, a background image, a heading, or a video poster frame. You cannot optimise it until you know which one it is, and teams routinely spend a week compressing images that are not the element anyone is waiting for.
Break the wait into its four parts
Google's guidance splits Largest Contentful Paint into time to first byte, resource load delay, resource load duration and element render delay. Finding which of the four is largest decides everything you do next, because the fix for a slow server has nothing in common with the fix for an image that is discovered late.
- A long time to first byte points at hosting, redirects or an uncached database query
- A long load delay usually means the browser found out about the image too late
- A long load duration means the file itself is too big for the connection
- A long render delay means something else is blocking the page from painting
See the remaining steps: The diagnosis and fix orderHide the remaining steps: The diagnosis and fix order
Make the main image discoverable, and make it smaller
Serve it in a modern format, at the dimensions it is actually displayed at, with width and height declared. Do not lazy load the element that appears first: lazy loading it delays the exact thing the metric measures. Tell the browser it is high priority so it is fetched early rather than in queue order.
Take blocking work out of the head of the document
Styles and fonts that block rendering keep the page blank while they download. Load only the styles that page needs, allow text to display while a custom font is still arriving, and move anything that is not needed for the first screen out of the critical path.
Audit every third party tag and remove what you cannot justify
Chat widgets, heatmaps, review carousels, booking embeds, pixel tags and two analytics tools doing one job. Each one is code from someone else's server running before your content. Keep the ones that earn their place, defer the rest until after the page is usable, and delete the ones nobody has looked at in a year.
Reserve space for anything that arrives late
Cumulative Layout Shift is almost always caused by content with no space held for it: images without dimensions, banners injected at the top, embeds that resize themselves, and fonts that swap to a different size. Reserving the space costs nothing and removes the most irritating failure on the list.
Fix responsiveness separately from paint
Interaction to Next Paint is about what happens after a tap, so image work does not touch it. Look for long running scripts, heavy event handlers and work done on every keystroke. Breaking up long tasks so the browser can respond between them is usually the fix.
Re-measure in the field and keep watching
Lab scores move the moment you deploy. Field data moves gradually, as new visits accumulate, so improvements show up over the following weeks rather than the same afternoon. Keep watching after that: a single unreviewed plugin or one heavy new image can undo a month of work.
If you only do three of these, do the first, the second and the sixth. Knowing your starting numbers, knowing which element is the bottleneck, and deleting tags nobody needs will cover most of the available gain on a typical business site.
Lab scores and field data are not the same claim
This is the single most common source of confusion in speed conversations, and it is worth settling before anyone argues about a score.
| What you are looking at | A lab test | Field data from real visits |
|---|---|---|
| What it measures | One simulated load on a fixed device and connection | Actual loads by actual people on their own devices and networks |
| What it is good for | Diagnosis: which file, which script, which image | Judgement: whether the page is genuinely good enough |
| How fast it reacts to a change | Immediately, on the next run | Gradually, as new visits accumulate |
| Interaction to Next Paint | Estimated, because nobody is really tapping anything | Measured from real taps and clicks |
| How to use it | To decide what to fix next | To decide whether the fix worked |
Both are real and neither replaces the other. Only one of them decides whether your visitors had a good time, and it is not the one with the colourful score dial.
The usual culprits
Roughly in the order they turn up on small business sites. Most sites have four or five of these at once.
- A hero image exported straight from the camera at full resolution and scaled down by the browser.
- Images stored in an old format when a modern one would be a fraction of the weight at the same visible quality.
- A slider or carousel at the top of the page, which is nearly always the slowest element on the site and rarely the most persuasive one.
- Web fonts that block text from appearing, so the page sits blank while a font file downloads.
- A page builder or theme that ships the styles and scripts for every feature it supports on every page, including the features you never enabled.
See the full checklist: The usual culpritsHide the full checklist: The usual culprits
- Third party tags that arrived for a campaign years ago and were never removed.
- Images published without width and height, so the layout reflows as each one lands.
- Shared hosting that is slow to answer the very first request, which delays everything that follows it.
- Video embedded from a platform that loads a full player on every page view, whether or not anyone presses play.
Is speed a ranking factor?
This question gets oversold in both directions, so here is what is actually documented.
Google describes page experience, including Core Web Vitals, as something it considers when ranking. It is not a switch that lifts a slow page above a more relevant one, and no amount of speed work makes a page answer a question it does not answer.
Treat speed as a tie breaker and a conversion lever rather than a ranking strategy. If two pages serve the same intent equally well, the one that loads properly on a phone has an advantage. If your page does not serve the intent at all, it will stay where it is at any speed.
What not to do
Do not chase a perfect lab score. Past a certain point the remaining fixes cost more than they return, and the score is not what your visitors experienced anyway.
Do not install a caching plugin and consider the job finished. Caching helps repeat requests to the same page. It does not make a four megabyte hero image smaller, and it often hides the real problem behind a fast second load while first time visitors still wait.
Read the full breakdown: What not to doHide the full breakdown: What not to do
Do not strip out measurement to improve the number. A page that loads instantly and cannot tell you where its enquiries came from has traded something valuable for something cosmetic.
Do not test only the home page. The pages that receive search traffic and hold your forms are the ones that decide whether anyone contacts you, and they are usually heavier than the home page precisely because nobody looks at them.
Do not accept a speed report with no before and after. If nobody recorded the starting field numbers, there is no way to tell whether the work did anything.
Read next
Where speed work sits in the wider picture.
Mobile-first design explained
Why the mobile version is the one Google indexes, and what that changes about your build.
Mobile-first design explainedWhat a website costs
Why a performance budget changes the price of a build, and what else does.
What a website costsWhat bounce rate really means
The metric people reach for when a page feels slow, and what it actually reports.
What bounce rate really meansWhat technical SEO covers
The rest of the engineering layer: crawling, indexing, structure and duplication.
What technical SEO coversThe web design guide
How the whole build works, from page planning through to what happens after launch.
The web design guideFind out what your real visitors are experiencing
A free audit includes your field Core Web Vitals by device and which element is holding the slow pages back.
Straight answers.
How fast should my website load?
Google's published target is Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less and Cumulative Layout Shift at 0.1 or less.
All three are judged at the 75th percentile of real page loads and reported separately for mobile and desktop, so the goal is that three quarters of real visits are good, not that one test run looks good.
Why does a speed test give me a different score every time I run it?
Lab tests simulate one load on one connection, and small differences in network conditions, server load and which scripts respond first move the number.
That variability is exactly why the pass mark is defined against field data from many real visits rather than against a single test result.
Does site speed affect my Google rankings?
Google says page experience, which includes Core Web Vitals, is among the things it considers. It is not a lever that outranks relevance.
The dependable return from speed work is that more of the people who already clicked stay long enough to contact you.
Will a caching plugin fix my slow site?
It will usually help repeat visits and reduce server work, which is worth having. It does not shrink oversized images, remove blocking scripts or stop the layout jumping.
If a caching plugin is the entire speed plan, the underlying problem is still there and first time visitors still meet it.
Why is my site fast on my laptop but slow on my phone?
Phones have less processing power and often worse connections, so the same page does more work with fewer resources. Scripts that a laptop absorbs invisibly can take seconds on a mid range handset.
This is also why Core Web Vitals are reported separately by device. Passing on desktop and failing on mobile is an extremely common pattern.
How long until speed improvements show up?
Lab measurements change as soon as the fix is deployed. Field data moves gradually as new visits accumulate, so expect the real numbers to shift over the following weeks.
Resist the urge to keep changing things during that window, or you will not know which change did what.
Where this comes from.
Primary documentation and published research behind the guidance on this page.
- Google web.dev: Web Vitals (opens in a new tab)The current thresholds for LCP, INP and CLS, and the 75th percentile rule.
- Google web.dev: Optimize Largest Contentful Paint (opens in a new tab)
- Google web.dev: Interaction to Next Paint (INP) (opens in a new tab)
- Google web.dev: Cumulative Layout Shift (CLS) (opens in a new tab)
- Google Search Central: Understanding page experience in Google Search results (opens in a new tab)
Talk to the team
A short call, a look at how the business currently shows up, and a straight answer on what we would do first.