Slow websites do not announce themselves. Nobody emails to say your page took six seconds to load; they simply leave, and the departure is recorded in your analytics as a visit that went nowhere. That makes speed one of the few problems that costs you money continuously while producing no visible symptom.
This guide covers what actually gets measured, what genuinely causes slow pages, and which fixes give the most improvement for the least work.
What Google Measures
Core Web Vitals are the metrics Google uses to describe page experience. There are three, and they measure different kinds of frustration.
Largest Contentful Paint (LCP)
How long until the largest visible element — usually a hero image, video or heading block — has rendered. This is the closest single measure to "how long until the page looks loaded". Google's stated threshold for a good score is 2.5 seconds or less.
Interaction to Next Paint (INP)
How quickly the page responds when someone taps or clicks. It captures the experience of a page that has appeared but does not yet react — a button pressed twice because nothing happened the first time. Google's good threshold is 200 milliseconds or less.
Cumulative Layout Shift (CLS)
How much content jumps around while loading. If you have ever gone to tap a link and hit an advert that appeared underneath your finger, that is layout shift. Good is 0.1 or less.
All three are measured on real visitors' devices and connections, not in a lab. That distinction matters: a site that feels instant on your office connection can score badly for customers on a phone with a weak signal.
What Actually Makes Pages Slow
In rough order of how often each one is the culprit:
1. Images
Comfortably the most common cause, and the easiest to fix. The usual pattern is a photograph exported straight from a camera or stock library at several thousand pixels wide and displayed in a space a fraction of that size.
What to do:
- Resize images to the largest size they will actually be displayed at
- Compress them — substantial file size reductions are usually possible with no visible difference
- Serve modern formats such as WebP or AVIF, with fallbacks
- Lazy-load anything below the fold, but never the main hero image
- Always set width and height attributes, which prevents layout shift
On many small business sites, images alone account for the majority of page weight.
2. Too much JavaScript
Every script has to be downloaded, parsed and executed, and that work happens on the visitor's device. A mid-range phone is considerably slower at it than a laptop.
The usual sources are page builders, sliders and carousels, chat widgets, analytics and marketing tags, social embeds, and animation libraries loaded for a single effect.
The question worth asking about each one: what does this earn? A carousel that nobody scrolls past the first slide of is pure cost.
3. Render-blocking resources
CSS and JavaScript in the page head stop rendering until they have loaded. Inline the small amount of CSS needed for what appears first, defer the rest, and load scripts with defer or async where they are not needed immediately.
4. Fonts
Custom fonts are a frequent and invisible cost. Each weight and style is a separate file, and text can stay invisible while they load.
Limit yourself to the weights you genuinely use, use font-display: swap so text renders immediately in a fallback, preload the critical font, and self-host where practical to avoid an extra connection.
5. Slow hosting
If the server takes a long time to respond before anything can even begin downloading, no front-end optimisation will rescue it. Budget shared hosting under load is a real constraint, not an excuse.
6. Third-party embeds
Maps, videos, review widgets, chat and tracking pixels all load code you do not control from servers you do not control. Embedding a video player when a linked thumbnail would do is a common and expensive habit.
What to Fix First
Ordered by return on effort:
| Priority | Action | Effort |
|---|---|---|
| 1 | Compress and correctly size every image | Low |
| 2 | Add width and height attributes to images | Low |
| 3 | Remove plugins, widgets and scripts you do not use | Low |
| 4 | Enable caching and compression on the server | Low |
| 5 | Reduce font weights and set font-display | Low |
| 6 | Defer non-critical JavaScript | Medium |
| 7 | Replace heavy embeds with lighter alternatives | Medium |
| 8 | Reserve space for anything that loads late | Medium |
| 9 | Move to better hosting or add a CDN | Medium |
| 10 | Rebuild a bloated theme or page-builder template | High |
The first five are achievable on most sites without a developer and frequently produce the largest single improvement.
How to Measure Properly
- PageSpeed Insights gives both a lab test and, where enough data exists, real visitor measurements. Prioritise the real-visitor section.
- Search Console's Core Web Vitals report shows which groups of pages are failing across your whole site.
- Your own phone, on mobile data, with the cache cleared. The least scientific test and often the most informative.
Test the same page several times. Single results fluctuate enough to mislead.
A Note on Chasing a Perfect Score
A score of 100 is a nice thing to have and a poor thing to obsess over. Beyond a certain point, further gains require restructuring a site in ways that cost more than they return, and the difference is not perceptible to visitors.
The target worth aiming for is passing Core Web Vitals on real visitor data and a page that feels immediate on a mid-range phone. That is achievable on most sites. Perfection in a lab test is not the same thing and is worth considerably less.
Does Speed Affect Rankings?
It is one signal among many, and it is not the strongest. A fast page with weak content will not outrank a slow page that answers the question better.
Where speed matters most is not ranking but behaviour: visitors who leave before the page renders never read the content, never see the pricing and never reach the form. That effect is direct and immediate, which is a better reason to fix it than any ranking argument.
Summary
Most slow sites are slow for boring, fixable reasons: oversized images, unnecessary scripts, too many fonts and third-party embeds nobody asked for. Start with images, remove what you do not use, measure on real devices, and stop when the page feels immediate rather than when a number reads 100.
If you would like your site's performance reviewed and the actual causes identified, get in touch.
Request a Speed Review Our Services
Frequently asked questions
What are Core Web Vitals?
Three measurements taken on real visitors' devices: Largest Contentful Paint, how long until the main content renders (good is 2.5s or less); Interaction to Next Paint, how quickly the page responds to a tap (200ms or less); and Cumulative Layout Shift, how much content jumps while loading (0.1 or less).
What makes websites slow most often?
Images, by a wide margin — usually photographs served at several times the size they are displayed at. After that: too much JavaScript, render-blocking CSS, too many font weights, slow hosting and third-party embeds.
Do I need a PageSpeed score of 100?
No. Beyond a point, further gains cost more than they return and are imperceptible to visitors. Aim to pass Core Web Vitals on real visitor data and to feel immediate on a mid-range phone.
