Improving speed does not start with “let me install a plugin” or “let me change hosting”. It starts with correct measurement. If you don't know what exactly it is delaying and on which pages, it is very easy to make changes that do not bring results or (even worse) create new problems. In this guide we will look at the most useful website speed measurement tools, what each one shows you, and a practical workflow to move from diagnosis → fixes → re-checking.
1) What we are really measuring when we talk about “speed”
“Speed” isn't just a number. In practice, you measure 3 things:
- When is the main content displayed? (so that the user does not see a blank screen).
- When can it interact? (clicks, scrolling, forms, filters) without any delay.
- How stable is the page? (Do not move any items whilst it is loading).
Here you will often come across symbols such as:
- LCP (loading main content),
- INP (response to an interaction),
- CLS (layout stability),
and also terms such as TTFB (how quickly the server “responds”) or total “load time”.
You don’t need to memorise everything. The aim is to understand Where is the bottleneck?: server, files (images/JS/CSS/fonts) or third-party scripts.
2) Lab vs Field: why you might see different results
Before we even get to the tools, there’s one point that confuses a lot of people:
- Laboratory data: testing in a controlled environment (under the same conditions every time). Very useful for diagnosis and debugging.
- Field data: data from real users (different devices/networks). Very useful for getting a true picture of the user experience.
Ideally you want both:
- Lab to find what's the problem?,
- Field to confirm whether users actually benefited.
3) The basic tools for measuring website speed (and when to use them)
A) Google PageSpeed Insights (PSI)
The PSI is the “quick check” that gives you:
- summary overview,
- key findings,
- suggestions for improvement.
When do you use it: when you want an initial audit per page (ideally: home, category, product, checkout/form, landing page).
What to watch out for: Don't get bogged down just on the “score”. Look which problems keep recurring and if it is image-heavy, JS-heavy or server-heavy.
B) Lighthouse (via Chrome)
Lighthouse is essentially the “engine” behind many reports. It runs from:
Chrome → DevTools → Lighthouse.
When do you use it: when you want recurring lab tests and a more detailed breakdown.
What to watch out for: compare before/after changes under the same conditions (incognito, without extensions).
C) Chrome DevTools: Network & Performance
If you want to find exactly what’s the delay, this is the “operating theatre”.
Network tab:
- which files are being downloaded,
- which is massive,
- which ones are blocking the upload,
- those provided by third parties.
Performance tab:
- where time is spent in the browser (rendering, scripting),
- which scripts do the “heavy lifting”.
When do you use it: when you have a specific problem and you want to tie it to a cause (e.g., “it’s slow because it’s loading 5MB images” or “it freezes because a script is running for too long”).
D) GTmetrix (report + waterfall)
GTmetrix is very useful for more “readable” reports and waterfall.
When do you use it: when you want to see clearly:
- which asset is behind schedule,
- which requests are too many,
- if there is a “chain” of scripts.
Tip: Waterfall is gold. It’ll show you if, for example, a chat widget is generating 10 extra requests and slowing down the interaction.
E) WebPageTest (more advanced test)
It is one of the most powerful tools for a deep dive, especially if you want to try:
- different locations,
- different network speeds,
- multiple repetitions.
When do you use it: when you want “proof” under more realistic conditions, or when a website behaves differently depending on the country or network.
F) Google Search Console: Core Web Vitals report
Here you can see problems at the level URL groups and not just on a single page.
When do you use it: to identify patterns: e.g., “all product pages have an issue”, or “only articles with many embeds”.
What you gain: site-wide prioritisation, especially if you have many pages.
4) A practical 5-step workflow (so you don't get lost)
Step 1: Choose the “important” pages
Don’t just count at random. Make a short list:
- Home
- 1–2 categories (if you have an e-shop)
- 1–2 products or 1–2 core services
- Checkout or form
- 1 landing page from advertisement (if you are running one)
Step 2: Take a baseline with 2 tools
E.g. PageSpeed Insights + GTmetrix. Note:
- what is repeated,
- what is the greatest “burden”,
- if the problem is mainly mobile.
Step 3: Confirm “what is happening to users”
Have a look at Search Console (Core Web Vitals) where a signal is available.
Step 4: Find 2–3 key “culprits”
They are usually:
- images/videos,
- third-party scripts,
- heavy JS,
- slow TTFB (server),
- fonts/layout shifts.
Step 5: Make one change at a time and measure again
The most common mistake: making 10 changes at once and then saying, “I don’t know which one worked”.
Keep a record (even a simple Word document): change → result → next step.
5) Improvements by problem category (If you see this → do this)
If you see “disturbing images”
Symptoms: large file transfers, slow LCP, delayed image loading.
What do you do (in order):
- correct dimensions (not 4000px for a 900px display),
- modern formats (e.g. WebP),
- compression,
- lazy loading for content below the fold,
- pay attention to sliders/hero images (they are usually the “LCP element”).
If you see “many third-party scripts”
Symptoms: numerous requests to third-party domains, slow response times, “freezes”.
What are you doing?
- keep only what you really need,
- load the non-critical ones later (defer/delay),
- prioritise: analytics is fine, but 3 chat widgets are not.
If you come across “heavy JavaScript”
Symptoms: Long scripting time, low INP, lag when clicking or scrolling.
What are you doing?
- remove unnecessary components/animations,
- severely restricted plugins,
- Check for page builders that load lots of scripts everywhere.
If you notice a “slow server / high TTFB”
Symptoms: Loading is slow to start, even though the files are small.
What are you doing?
- page caching,
- object cache where necessary,
- hosting/resource check,
- database optimisation (especially in CMS),
- CDN for static files.
If you see “layout shifts” (CLS)
Symptoms: Buttons and text move as it loads.
What are you doing?
- defining dimensions in images/embeds,
- watch out for fonts (swap behaviour),
- avoiding banners “overlapping” existing content without space.
6) WordPress: the most common areas that can be improved
If the site is WordPress, the classic “themes” are:
- many plugins that load scripts on all pages,
- a heavy theme/page builder,
- incorrect/incomplete caching,
- images uploaded without optimisation,
- Too many third-party scripts (pop-ups, reviews, chat).
What is usually worth looking at first:
- caching (properly configured),
- images,
- reduction/restriction of third-party scripts,
- cleaning up plugins,
- hosting check/TTFB.
7) Mini checklist of priorities (a quick guide to “what to do first”)
- I’ve counted 5–6 key pages (mobile & desktop)
- I'm checking whether the problem is images, scripts or server
- Optimising hero/LCP images
- I limit third-party scripts (keeping only those that are essential)
- I’m setting up proper caching
- I check fonts and layout stability
- I repeat the measurements after every change
Conclusion
The correct ones website speed measurement tools They protect you from “blind” changes and guide you towards targeted improvements. Start with a baseline, review the findings calmly, identify 2–3 key culprits and work through them step by step, checking as you go. In this way, speed becomes a process that delivers results, rather than a constant source of stress.
👉 Return to the overview: The importance of speed on your website
👉 Regarding how it affects business/SEO: How fast loading affects sales and SEO
