Site speed:
measuring takes thirty seconds. The number is the easy part.
Most of what is written about site speed is a list of measuring tools. Measuring is the easy half — this page is about the order you fix things in, and why most of the fixing is free.
Three numbers judge your site, and there is one order to fix them in.
Google's published "good" thresholds: LCP under 2.5 seconds (when the largest element appears), INP of 200 milliseconds or less (how fast the page responds to an interaction), and CLS of 0.1 or less (how much the layout shifts while loading).
And the detail most writing on this subject skips: these are assessed at the 75th percentile of your page's visits, segmented between mobile and desktop. So the judgement is not on your average visitor, and certainly not on your own experience at a desk with fast internet — it is on roughly your slowest quarter of visitors. Which is why "it feels fast to me" is not data.
The repair order: images, then caching, then the theme, then plugins, then fonts. The first two are free and resolve most cases — and none of them needs a developer.
The Core Web Vitals thresholds and the 75th-percentile basis are from the Core Web Vitals documentation on web.dev; INP became a stable Core Web Vital in 2024, replacing FID. Reviewed 12 August 2026. We publish no speed figure for our own site on this page: the measurement depends on your network and device, and the one that matters is yours.
What do these numbers actually measure?
| Metric | Measures | Good | Most common cause when poor |
|---|---|---|---|
| LCP | When the largest element appears | 2.5s | A large image near the top of the page |
| INP | Response to the first interaction | 200ms | Too much JS from plugins |
| CLS | How much the layout shifts | 0.1 | Images without dimensions, late-loading fonts |
The last column is the useful one: each metric has a single common cause, so you are not fixing "speed" in general — you are fixing a specific thing.
How to measure properly
- Open Google's PageSpeed Insights, which is free and reports all three metrics plus what is slowing the page.
- Read the mobile result first — most of your visitors are on a phone, and a phone is where slowness shows.
- Measure the pages that matter, not just the homepage — the product page, the article page, the contact page. The homepage is usually lighter than the rest.
- Measure again after each fix — one change at a time, or you will not know which one worked.
The causes, in order of impact
- Uncompressed images — the number one cause on most sites, by a wide margin. A single 3 MB image is enough to ruin LCP on its own.
- No caching — without it every request is rebuilt from scratch on every visit. A free plugin, and the difference is immediate.
- A heavy theme — one that loads components and animations you never use, on every page. Covered in our themes guide.
- Too many plugins — each one loads something on every visit, and they are the most common reason INP is poor.
- Arabic webfonts — this one is specific to us: Arabic font files are larger than Latin ones because an Arabic letter has more contextual forms. Load only the weights you actually use, and only the Arabic subset, rather than the whole family.
The general rule: slowness is usually in what the page loads, not in the server serving it.
What does not fix slowness
We say this because it is the most common thing sold to someone with a slow site:
- Upgrading to a VPS — it does not make your images smaller or your theme lighter. The test for whether you genuinely need one is in our VPS guide.
- A more expensive hosting plan — helps if you are genuinely starved of resources, and does nothing if your page loads 5 MB.
- A geographically closer server — lowers time to first byte, but not the weight of what you load. We covered this in detail in our Saudi hosting guide.
- A "speed optimisation" plugin — some genuinely help with caching, and some add weight in the name of optimisation. Measure before and after.
When is hosting genuinely the cause?
One metric points at it: time to first byte (TTFB). Test it on a light page — a contact page with no images and no plugins. If it is high there too, the problem is the server or the distance rather than your content.
And if TTFB is good while the page is still slow, the cause is the page itself — more expensive hosting will just pay for the same weight slightly faster. If hosting does turn out to be the cause, we worked out the four-year cost of 12 companies in the comparison.
A half-hour plan
- Measure two important pages on mobile, and write down the three numbers.
- Compress your images and re-upload the three largest on each page.
- Turn on caching with one plugin — not two.
- Delete every plugin you have not used this month.
- Measure again and compare against what you wrote down.
In most cases it ends here, at zero cost. If it does not, you now know your problem is the theme or the resources — and those are two entirely different purchases, each with its own guide here.
And if resources really are the constraint — a light page with a high response time after all of the above — the next step is more resources, not a different company: a cloud plan such as Hostinger Cloud Startup gives four CPU cores, 4 GB of memory and 100 GB of NVMe storage from $7.99/mo and stays managed, so you are not administering a server. It renews at $25.99/mo — a large jump, so do not buy it until measurement tells you resources are the limit. And if what you want is root access, that is a different question, answered in the VPS guide.
The cloud plan's specification, price and renewal price are from the cloud hosting page, reviewed 12 August 2026.
Some links on this page are affiliate links — they cost you nothing extra, and they do not affect how we rank recommendations. Full disclosure.
Speed questions.
What is site speed, exactly?
Not a single number. Google measures it with three metrics: LCP, the time until the largest element appears, INP, how quickly the page responds to an interaction, and CLS, how much the layout shifts while loading. The published "good" thresholds are 2.5 seconds, 200 milliseconds and 0.1 respectively.
How do I measure my site's speed?
Open Google's PageSpeed Insights and enter your page URL. It is free and reports all three metrics along with what is slowing the page down. One important point: measure the pages that matter rather than only the homepage, and read the mobile result before the desktop one, because most of your visitors are on a phone.
How do I speed up my site?
In this order, because it is the order of return: compress your images, turn on caching, review the theme, delete unused plugins, then reduce your fonts. The first two are free and resolve most cases, and neither needs a developer.
Is my hosting the cause?
Sometimes, but it is not the most common cause. The metric that points at it is time to first byte (TTFB): if that is high on a light page with no plugins, the problem is the server or the distance. But if TTFB is good and the page is still slow, the cause is what the page itself loads — and more expensive hosting will not fix that.
Does speed affect Google rankings?
Core Web Vitals are a published part of how page experience is assessed, so yes it has an effect — but it is not the first factor. What matters more is that speed affects who stays on your site and who buys from it, and that is worth more to you than the ranking. Fix it for the visitor and the search benefit follows.
Turned out to be the theme?
The theme is one of the two biggest influences on speed; the other is hosting. Plus how to verify a theme genuinely supports RTL in 30 seconds.