Website speed usually means several different metrics at once: how fast the server responds, how many seconds pass before the first content appears, and how long it takes for the page to become fully interactive. Before speeding anything up, it helps to measure where time is actually lost — otherwise it is easy to optimize something that was already fast. Without a "before" and "after" measurement there is no way to prove, even to yourself, that a change had a real effect rather than just coinciding with a lucky day.
What "website speed" means and why measure it
The single word "speed" hides a set of different metrics, and speeding up one does not always speed up another.
- Server response time (TTFB) — how long it takes until the first byte of the server's response.
- Largest Contentful Paint (LCP) — the moment the largest visible content block appears on screen.
- Full page load time — when all resources are loaded: scripts, styles, images.
- Number of requests to the server — how many separate files the browser must download to render the page.
How to measure server response time
Server response time can be measured right from the command line without opening a browser.
curl -o /dev/null -s -w "time_total: %{time_total}\n" https://example.comIf this time grows on repeated runs, the problem is usually not the network but the server itself: a slow database query, heavy page generation, or a lack of resources. It helps to repeat the measurement several times in a row and compare the spread of values rather than relying on a single result.
How to measure full page load speed
For the full picture you need a browser tool that builds a timeline of loading all the page resources, not just the server response. Such a timeline shows which file is actually slowing down rendering: a large image, a third-party analytics script, or a font that blocks rendering. Part of this load can be removed without changing the site's code by turning on caching and compression at the CDN level — details are in the article speeding up a site with Cloudflare.
Common causes of slow loading
In practice, slow loading is usually caused by one of a few typical reasons: unoptimized images without compression, no page caching, too many third-party scripts, heavy CMS plugins, or a poorly tuned web server configuration. For sites on WordPress, the main points to speed up are covered in the article how to speed up WordPress, and for a server running on a VPS — in the article nginx optimization on a VPS. These causes usually add up together rather than acting alone, so speeding up a site is rarely a single fix.
Comparing key speed metrics
| Metric | What it means | What it affects |
|---|---|---|
| TTFB | Time to the first byte of the server response | Backend and database speed |
| LCP | The moment the largest content block appears | Perceived loading speed |
| CLS | How much elements shift while loading | Visual stability of the page |
| INP | The response delay to user actions | Interface responsiveness |
In practice it is enough to keep TTFB and LCP in view all the time and come back to the other metrics only when visitors complain about jumpy layout or slow button response.
What to do, in order
- Measure the current TTFB and LCP values before changing any settings.
- Compress images and convert them to a modern format without losing readable quality.
- Turn on caching of static files and, where possible, caching at the CDN level.
- Disable or defer scripts that are not needed for the first screen.
- Re-measure and compare the results with the original ones to confirm the change actually helped.
This order guards against the most common mistake: changing several settings at once and then not knowing which one actually affected the result.
Frequently asked questions
Why does the site load fast for me but slowly for others?
The difference is usually explained by the geographic distance to the server, the visitor's internet connection speed, and whether the site's static files are already cached from a previous visit.
Should mobile speed be measured separately?
Yes, mobile devices usually process scripts more slowly and run on a less stable connection, so mobile numbers are almost always worse than desktop ones.
How many metrics are enough to track regularly?
For most sites it is enough to regularly track TTFB and LCP — they show both server condition and the visitor's perceived speed, while other metrics are checked only when a specific problem comes up.