How to Diagnose a Slow Website in 30 Minutes: Tools for 2026
In short
A high PageSpeed score does not make a website fast. This is the diagnostic order that finds the real bottleneck, from field data through the server to JavaScript.
- First name the problem and the goal.
- Then outline a simple step-by-step plan.
- Each step needs an owner and a deadline.
- Track results — without numbers it stays opinion.
The classic trap: a lab report scores 95 out of 100 while customers keep complaining that the site crawls. A lab test measures one run on a fast connection with an empty cache. Your visitors open the page on a three year old phone, on a weak mobile network, with a full browser cache. Here is the diagnostic order that identifies the real bottleneck within half an hour.
Step 1: field data before laboratory numbers 📊
Start with the user experience section in PageSpeed Insights and the Core Web Vitals report in Search Console. These numbers come from real sessions collected over the last 28 days and show the distribution: how many visits had a good LCP, INP and CLS.
When field data is healthy and lab data is poor, you are optimising something users never notice. When the opposite is true, a specific group of devices or regions is struggling - something a lab test will never reveal.
Step 2: read each metric separately 🎯
- LCP above 2.5 seconds: usually the hero image, missing priority hints, an oversized file or a slow server.
- INP above 200 milliseconds: JavaScript blocking the main thread, too many event listeners, third-party widgets.
- CLS above 0.1: elements shift because images have no reserved dimensions and banners or fonts load after the first paint.
- TTFB above 800 milliseconds: stop touching the front end. Fix the server first: opcode cache, object cache, database queries, edge caching.
⛔ MYTH: "A perfect PageSpeed score means a fast website" 🚫
REALITY: The lab score is a weighted average of dozens of rules, including several that do not affect perceived speed. A page can score 100 and still feel delayed on click when JavaScript produces long tasks. What counts is field data: LCP, INP and CLS in real sessions.
💡 Pro tip
Change one thing at a time and record the result. Serving responsive AVIF images typically improves LCP more than three hours of JavaScript refactoring, and it takes fifteen minutes to deploy. The most common mistake is shipping five optimisations at once and never learning which one worked.
Is your website too slow? ⚡
I run a full diagnosis covering field data, server response, images and JavaScript, then hand you a fix list ordered by business impact.
Request a performance auditSee the related service: fast website development or contact us for a free quote.
FAQ
Why does my page score 95 in PageSpeed but still feel slow?
PageSpeed runs a single lab test on a fast connection with an empty cache. Real visitors use older phones, weaker networks and a full browser cache. Always start with field data - the user experience section in PageSpeed Insights plus the Core Web Vitals report in Search Console - because that is what your customers actually feel.
What is a good TTFB value?
Time to first byte should stay under 200 milliseconds and is acceptable up to about 500 milliseconds. Anything above 800 milliseconds almost always points to the server: missing opcode cache, slow database queries, an overloaded shared host or a missing cache layer.
Should I optimise images or JavaScript first?
Follow the field data. When LCP is the failing metric, start with the hero image, priority loading and server response. When INP fails, the problem is long JavaScript tasks, excessive event listeners and third-party scripts.
How I can implement this for you
Have questions?
Questions about an article, or need a solution for your business? Just ask.
Contact Me