"The site is slow" is something everyone feels, but fixing it precisely requires measuring it in numbers first. Tools like PageSpeed Insights and GTmetrix give detailed data, but if you can’t read it you may chase the wrong fix and waste time. This article shows how to measure and interpret results so you know which numbers matter and what to fix first.
In short: don’t obsess over a single "score". What really matters to users and Google is Core Web Vitals (LCP, CLS, INP) and TTFB — the overall score is just a summary, not the goal itself.
The main speed-testing tools
- PageSpeed Insights — by Google, gives both lab data (simulated) and field data (CrUX from real users). Best because it uses the same criteria Google ranks by.
- GTmetrix — shows a detailed waterfall of when each resource loads, helping find the files that slow things down, with selectable test locations.
- WebPageTest — the deepest; choose device, connection speed and location for technical analysis.
Start with PageSpeed Insights for the overview and Core Web Vitals, then use GTmetrix’s waterfall to find which files are slow.
The values you must understand
| Metric | Meaning | Target |
|---|---|---|
| LCP (Largest Contentful Paint) | When the largest element finishes rendering | < 2.5 s |
| CLS (Cumulative Layout Shift) | Layout stability while loading | < 0.1 |
| INP (Interaction to Next Paint) | Responsiveness when the user clicks | < 200 ms |
| TTFB (Time to First Byte) | Time until the first byte from the server | < 800 ms |
The first three (LCP, CLS, INP) are the Core Web Vitals Google uses as part of ranking, while TTFB directly reflects the speed of your server and hosting.
Lab data vs field data
A common confusion is a great lab score while the real site still feels slow — because these two differ:
- Lab data — measured in a controlled simulation (standard device and network). Good for debugging because it’s repeatable.
- Field data — collected from real users via Chrome (CrUX), reflecting real experience including older phones and slow networks — this is what Google actually evaluates.
If lab is good but field is poor, it’s usually because real users have lower-spec phones or slower networks than the simulation. Trust field data when you have enough of it.
Reading the GTmetrix waterfall
The waterfall charts the order and timing of each resource. What to watch:
- Long first bar (high TTFB) — the server responds slowly, possibly from slow PHP/database or hosting far from the user.
- Unusually large files — uncompressed images or big JS/CSS bundles that drag the load.
- Too many requests — calling too many files; combine them or remove plugins that load excessive scripts.
- Render-blocking — CSS/JS that block rendering should be deferred or loaded async.
Is it the hosting or the site?
The key question is where the root cause lies — the numbers tell you:
- Consistently high TTFB even on a simple page → points to the server/hosting: few resources, noisy neighbours on shared hosting, or a server far from visitors.
- Good TTFB but poor LCP → a front-end problem: large images, slow fonts or render-blocking JS.
- High CLS → a layout problem like images without dimensions or ads pushing content — nothing to do with hosting.
For Thai sites with Thai visitors, hosting on SSD with servers in Thailand cuts TTFB directly thanks to short distance and fast disks.
Misconceptions about speed scores
The most common misconception is chasing a perfect 100 and assuming the site is then as fast as possible. In reality the overall score just condenses many factors into one number. A site scoring 85 that passes all Core Web Vitals may deliver a better experience than one scoring 95 whose real mobile LCP is still poor. Focus on the values users actually feel, not the summary number.
Another misconception is treating a single measurement as the final answer. Site speed varies with time of day, traffic and test location. Measure several times at different times and look at the trend rather than one result — especially on shared hosting, where performance can swing with the neighbours on the same machine.
Finally, remember each tool uses different criteria and test locations, so GTmetrix and PageSpeed Insights scores naturally won't match. Pick one main tool as your before-and-after benchmark and use the others as supporting data; that gives clearer decisions than flipping between them in confusion.
Recommended fix order
- Cut TTFB first — enable OPcache, use object cache, choose SSD hosting near your visitors.
- Optimise images — convert to WebP, set dimensions, use lazy load — usually the biggest LCP win.
- Handle CSS/JS — defer unnecessary scripts, remove plugins loading excess assets.
- Add cache and CDN — page cache + browser cache + CDN for static files.
- Re-measure after each step — compare before and after to confirm the fix worked.
Summary: always measure before fixing, focus on Core Web Vitals and TTFB, and fix from the root cause the numbers point to — not chasing a perfect 100 score, which is sometimes not worth the time.
Frequently Asked Questions
What PageSpeed score is good enough?
There's no fixed number you must hit at 100. What matters more is passing the Core Web Vitals thresholds — LCP < 2.5 s, CLS < 0.1 and INP < 200 ms — which reflect real user experience better than the overall score.
How do lab and field data differ?
Lab data is measured in a controlled simulation, good for debugging; field data is collected from real Chrome users, reflecting real experience including old phones and slow networks. Google primarily evaluates field data.
Where do I fix a high TTFB?
High TTFB usually comes from the server side — slow PHP/database, few resources or a server far from visitors. Fix it by enabling OPcache, using an object cache and choosing SSD hosting with servers near your audience.
Is my site slow because of hosting or the site?
Read the numbers: consistently high TTFB even on a simple page points to hosting/server, while good TTFB with poor LCP or high CLS points to front-end issues like large images or unstable layout.
Slow site because of hosting? Move to SSD with servers in Thailand
AsiaGB Hosting runs on SSD with servers in Thailand to cut TTFB for Thai visitors — from 500 THB/year with a Thai support team to help tune speed.
See hosting plans