Almost every slow site is slow for the same five reasons. None of them are mysterious, and they are not equally expensive to fix — which is why the order matters more than the list.
First, measure the right thing
Lab tools run on a fixed machine and a synthetic connection. They are useful for comparing before and after, and useless as a verdict.
The number that decides both ranking treatment and how the site feels is field data: what real visitors experienced, at the 75th percentile. The thresholds worth holding to:
| Metric | Good | What it measures |
|---|---|---|
| LCP | ≤ 2.5s | How long until the main content is visible |
| INP | ≤ 200ms | How quickly the page responds when someone interacts |
| CLS | ≤ 0.1 | How much the layout jumps while loading |
Check them in Search Console's Core Web Vitals report before you change anything, so you can tell whether the work did what you hoped.
1. Images
A photograph straight off a phone is four thousand pixels wide and several megabytes. Displayed in a card six hundred pixels across, you have downloaded roughly forty times more image than you needed.
The fix is mechanical: correct dimensions for the space, modern formats, lazy loading below the fold, and explicit width and height so nothing jumps while they arrive. It is usually the single largest win available and the least likely to break anything.
2. Third-party scripts
Chat widgets, tracking pixels, heat maps, review embeds, ad tags, consent tools. Each is a request to a domain you do not control, running code you cannot audit, on the main thread that is trying to render your page.
Audit them annually. Most sites are still loading a script for a tool the business stopped using two years ago. Removing one is free, reversible and often worth more than a week of optimisation elsewhere.
What survives the audit should load after the page is interactive, not before it.
3. Fonts
Custom fonts are worth having. Custom fonts fetched from a third-party domain, on a render-blocking stylesheet, with no fallback behaviour, are not — the visitor stares at nothing while they download.
Self-host the files, subset them to the characters you actually use, load one variable file rather than six weights, and make sure text renders in a fallback face immediately rather than waiting.
4. JavaScript
This is where modern sites lose their advantage. Shipping a framework's worth of JavaScript to render text that never changes means the browser downloads, parses and executes code just to show what the server could have sent as HTML.
Two questions decide most of it: does this page need JavaScript to display its content, and does this component need to be interactive at all? Server-rendered HTML for the content, JavaScript only for the parts that genuinely respond to a user, is the difference between a fast site and a slow one with good intentions.
It is also what makes a page readable by crawlers and AI assistants that do not execute scripts — see getting cited in AI answers.
5. The platform
A page builder ships the CSS and JavaScript for every layout it could produce, not the one you used. That is how a five-page site ends up sending two megabytes to display a phone number and an opening-hours table.
This is last on the list because fixing it means rebuilding, and that is a different conversation with a different budget. When we took a representative page-builder site apart, most of the weight was code for features the site did not use.
What slow actually costs
Two costs, and the second is larger than most owners assume.
The direct one: page experience has been part of Google's ranking signals since 2021, and a slow or unstable server also limits how much of your site gets crawled — which is one of the reasons pages end up not indexed at all.
The indirect one: people leave. They do not email to say why, and the analytics show it as a bounce that looks like a content problem.
Where to start tomorrow
Export the Core Web Vitals report. Run one page through a lab test and look at what is actually large — usually two images and a chat widget. Fix those. Re-measure in a fortnight, once field data has caught up.
If you would rather not do the measuring yourself, send us the domain — the free audit runs these same checks and comes back in writing in three working days.
If the platform turns out to be the cost, that is what our web development work is for: hand-built, server-rendered, with performance as a budget rather than a cleanup task.
Frequently asked questions
- What counts as a fast website in 2026?
- Google's Core Web Vitals thresholds are the practical bar: Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint at or under 200 milliseconds, and Cumulative Layout Shift at or under 0.1 — measured at the 75th percentile of real visits, not on your own laptop.
- Why does my site score well in tests but feel slow?
- Lab tests run on a fixed machine and connection. Real users are on mid-range phones, on mobile networks, sometimes with a cold cache. Field data — the Core Web Vitals report in Search Console — is the one that matters.
- Is a rebuild always necessary?
- No, and usually not first. Images, third-party scripts and fonts account for most of the weight on a typical site and can be fixed in place. A rebuild is warranted when the platform itself is the cost.
- Does speed really affect ranking?
- It is one signal among many, and it has been part of Google's page experience signals since 2021. The larger effect is usually commercial: people abandon slow pages before they see what you sell.
- performance
- core web vitals
- web development
