New format
How to check site speed: measurements, CWV, and tools
A slow page loses people and search signals. Speed checks aren’t a race to a hundred in PageSpeed — they’re figuring out what blocks (server, images, JS) and on which URLs it hurts.
Below: lab vs field, which metrics matter, a lean tool set, and how to read recommendations. We don’t reprint a ten-tool price list from 2018 — some aged out, some changed products. Speeding up WordPress is a separate article.
Why measure speed
Users rarely wait forever: bounces rise and conversion falls. For SEO, page-experience signals matter — and bots and people should get content without pain.
Don’t treat the myth “top sites load in 0.38 s” from old posts as a KPI. Measure your templates on mobile networks and compare competitors on substance, not someone else’s magic number.
Lab and field: two layers of truth
Lab (PageSpeed Insights / Lighthouse, WebPageTest): reproducible conditions, waterfall, “what to remove” tips. Handy for regressions after a release.
Field (Chrome UX Report, Search Console reports): how it really loads for your audience. Sometimes lab is green and field is red — different geography, devices, cache.
What to treat as the base
| Layer | When |
|---|---|
| Lab | Debugging, before/after fix comparison |
| Field | Real UX and SEO-signal assessment |
| Both | Releases and “we’re already fast” debates |
Which metrics to watch
Core Web Vitals: LCP (largest content), INP (responsiveness), CLS (layout stability). Nearby — TTFB as a server/backend signal.
Don’t fix everything at once. First LCP on mobile for a key URL, then INP/CLS, then score cosmetics.
Common culprits:
- heavy hero without dimensions
- blocking JS/CSS
- slow TTFB / hosting
- third-party widgets and tags
- fonts without font-display
A lean tool set
PageSpeed Insights — quick lab start plus a field summary where available. WebPageTest — deep waterfall and region comparison. Google Search Console — page experience across the site.
Also: DevTools Performance/Network locally, uptime monitoring (Pingdom and peers — as alerting, not as the only SEO meter). Extra “sitespeed” checkers as a second look, not as truth.
Reading the report — then acting
Lock the URL, device (mobile), date, and a screenshot or export. List the top three recommendations with effort estimates. Ship → remeasure in a day (field catches up slower).
High TTFB — hosting, cache, backend. LCP — images, SSR/critical CSS, load priority. CLS — media and ad-slot dimensions.
Monthly mini-ritual:
- PSI on 3–5 key URLs
- GSC: URLs with poor experience
- compare with last month
- 1–2 fixes into the sprint
What to remember
Speed is measured with perception and server metrics — not a pile of ten bookmarks. Lab for debugging, field for user truth.
After measuring — find the bottleneck and fix it. Racing to 100 points without better UX isn’t the job.
FAQ
Do I need 100 in PageSpeed?
No. What matters more is LCP / INP / CLS in the green zone on mobile for key URLs — and real UX.
Are lab and field the same?
No. Lab (Lighthouse) is a controlled run. Field (CrUX) is real-user data. Watch both.
Is Webmaster enough?
Helpful for availability and some diagnostics — it doesn’t replace PSI / CWV for how load feels.
Does speed equal rankings?
Indirectly, via UX and crawl. Core positions take planned months of work — not “ran PSI, hit page one.”
Which URL should I start with?
Home, top landings from ads or organic, product or service page, checkout.
Chasing PageSpeed 100 while mobile LCP on key URLs is still red?
We’ll measure lab and field, pick the real brake (TTFB or CWV), and ship fixes that move UX — not vanity scores.
Discuss the task
