What you should measure in 2026

Use current Core Web Vitals – LCP, INP, and CLS at the 75th percentile – and treat older timings as diagnostic clues, not the scoreboard.

Verified: July 2026 – metric definitions and thresholds: web.dev Web Vitals.

LCP ≤ 2.5s – main content visible.
INP ≤ 200ms – responsiveness across interactions (FID is historical).
CLS ≤ 0.1 – visual stability.

Still useful for debugging, but not CWV: TTFB, FCP, Speed Index, Total Blocking Time, DOM size, transfer size, and request count.

Tools: what each one is good for

One screenshot never describes real users – pick tools by the question you need answered.

PageSpeed Insights + CrUX – field Core Web Vitals for the URL/origin when enough Chrome data exists, plus a lab Lighthouse run.
Lighthouse (Chrome DevTools / CI) – repeatable lab audits, opportunities, and traces. Does not prove real INP by itself.
GTmetrix – waterfall and filmstrip with configurable locations/devices; good for comparing before/after deploys.
WebPageTest – deep waterfalls, multi-step scripts, advanced locations, and filmstrips for LCP resource hunting.
Your own RUM – web-vitals library or analytics RUM for logged-in flows, carts, and markets CrUX undersamples.

Use PSI/CrUX to decide whether you have a field problem; use WPT/Lighthouse to decide what to change; use RUM to confirm production after release.

Audit methodology that survives arguments

Standardize conditions or you will optimize noise.

Mobile and desktop – Google primarily stresses mobile; still check desktop templates that differ (mega-menus, heavy dashboards).
Repeat runs – 3-5 lab runs; discard outliers; record medians.
Locations – test near your audience and near origin to separate CDN wins from origin TTFB.
Cold vs warm cache – first view vs repeat view; page-cache hit vs miss.
Logged-out vs logged-in – caches often bypass for accounts, carts, and memberships.
Template coverage – home, category/archive, single post, product, cart, checkout, and any landing page with heavy tags.

Document theme/plugin versions, PHP version, and whether a performance plugin was enabled. Otherwise next month’s “regression” is unexplainable.

How to read the waterfall

Map each Core Web Vital to concrete resources and main-thread work.

TTFB high – hosting, PHP bootstrap, DB, missing page/object cache, slow origin routing.
LCP resource – identify the LCP element; check discovery delay, download time, and render delay. Oversized heroes and late CSS are common.
Long tasks – JS > 50ms blocks input; split, defer, or remove. Tag managers love creating these.
Third-party – chat, A/B, pixels, embeds. Measure with them blocked once to see the ceiling.
Fonts – multiple weights, missing font-display, or late stylesheets causing invisible text then CLS.
CLS sources – images/ads without dimensions, late banners, web fonts, injected carousels.

Screenshots of tools go stale quickly – prefer saving shareable WebPageTest/PSI links and filmstrips in your change ticket rather than embedding outdated UI chrome.

From audit to action

Ship the smallest change that moves field metrics on the worst template.

Pick one failing URL class from CrUX/Search Console.
Reproduce in lab with the methodology above.
Change one layer (cache, image, script, font).
Re-test lab immediately; wait for field data to refresh before calling it done.
Encode winners into a performance budget for future releases.

Implementation ideas live in Optimizing WordPress for page speed. For media weight, see the image optimization guide. For edge delivery, use the CDN connection snippet. For a full-site diagnosis, book a technical audit.

Key takeaways

Score against LCP / INP / CLS at p75; keep FID and older timings in the diagnostic drawer.
CrUX/PSI field ≠ Lighthouse lab ≠ WebPageTest deep dive – use each correctly.
Standardize mobile/desktop, repeats, locations, cache state, auth state, and templates.
Interpret TTFB, LCP resource, long tasks, third parties, fonts, and CLS sources explicitly.

Related on WP-Dude

Measuring and Auditing WordPress Page Speed: Tips and Tools