Ever been to a restaurant where you technically got your food… but the whole experience still felt bad?
That’s web performance.
A page can “load” and still feel slow because users don’t experience one moment. They experience a few key moments—and if any of them is painful, the site feels sluggish (or janky) even if the total load time looks fine.
Here’s the ELI5 version, with a practical way to diagnose what’s actually broken.
Your website is a restaurant
Imagine your page is dinner:
1) TTFB = “Does the waiter even acknowledge you?”
TTFB (Time To First Byte) is how long it takes before the server starts responding.
- If you sit there for 5 minutes before anyone says hello, the restaurant feels slow.
- Same with websites: a slow first response usually means backend, caching, database, or network/CDN issues.
2) LCP = “When does the main dish arrive?”
LCP (Largest Contentful Paint) is when the main thing people came to see appears (hero image, product image, headline block, etc.).
- If your drink arrives quickly but the main dish takes forever, the experience feels slow.
- Same with a page where the shell renders but the hero/product image shows up late.
3) INP = “When you ask for something, how fast do they respond?”
INP (Interaction to Next Paint) is about responsiveness: when a user taps/clicks/types, how quickly does the UI react.
- If the waiter ignores you when you try to order, you feel stuck.
- On the web, this is usually “main thread is busy” — heavy JavaScript, long tasks, hydration, third-party scripts.
4) CLS = “Is the table wobbling and your plate sliding around?”
CLS (Cumulative Layout Shift) is visual stability: does stuff jump around while you’re trying to read/click?
- If your plate keeps moving, you’re annoyed—even if the food is technically there.
- On pages: late-loading images/ads, fonts swapping, banners pushing content down.
That’s the core: performance isn’t one number. It’s four user-experience moments.
The cheat sheet: what to check first
If TTFB is the problem (slow “waiter”)
Likely bucket: server / caching / DB / edge
Fast checks:
- Compare logged-in vs logged-out (logged-in often bypasses cache).
- Compare home vs cart/checkout (cart/checkout often uncached and DB-heavy).
- Verify your caching is actually working (headers, HIT/MISS, CDN behavior).
- On WordPress/Woo: use Query Monitor to spot slow queries/hooks.
Typical fixes:
- Full-page cache (where safe), object cache (Redis), DB query cleanup, PHP opcache tuning, reduce uncached dynamic work.
If LCP is the problem (late “main dish”)
Likely bucket: hero image / render-blocking / priority / fonts / heavy JS
Fast checks:
- In Lighthouse/DevTools, identify the LCP element (what exactly is it?).
- Look at LCP phases: is it waiting on TTFB, resource load, or render delay?
- Check if the LCP element is an image that’s too big, lazy-loaded incorrectly, or discovered late.
Typical fixes:
- Correct image sizing + compression,
preloadthe hero image, avoid sliders for the hero, inline critical CSS, reduce render-blocking CSS/JS, tame font loading.
If INP is the problem (slow “response to your order”)
Likely bucket: main-thread JS / long tasks / hydration / third-party scripts
Fast checks:
- Open DevTools Performance and look for long tasks around interactions.
- Check third-party tags (chat widgets, A/B testing, analytics) and how early they load.
- Confirm whether a framework app is doing heavy hydration on every page.
Typical fixes:
- Split bundles, defer non-critical JS, reduce hydration scope, move expensive work off the main thread, audit event handlers, delay third-party scripts until after interaction-critical UI is ready.
If CLS is the problem (wobbly table)
Likely bucket: missing dimensions / late inserts / fonts
Fast checks:
- Are images/iframes/ads missing fixed dimensions?
- Are banners/cookie bars inserting above content after render?
- Are fonts swapping late and shifting layout?
Typical fixes:
- Reserve space (width/height or aspect-ratio), avoid injecting UI above content, use font loading strategies that minimize shift, ensure placeholders match final size.
The “lab vs field” confusion (ELI5)
This trips teams up constantly.
- Lighthouse / PageSpeed = the test kitchen. Controlled, repeatable, great for debugging.
- CrUX / Google Search Console CWV = real customers eating dinner. Messy, but it’s the truth.
Rule of thumb:
- Use lab to find why.
- Use field to confirm impact.
If Lighthouse says “bad” but CrUX says “good,” you might have a lab-only issue or your real users aren’t hitting the same scenario.
If CrUX says “bad” but Lighthouse looks fine, you might have a segment problem (certain devices, geos, templates, or third-parties).
A simple 3-step diagnostic flow
If you only do one thing, do this.
Step 1: Name the “bad moment”
Is it TTFB, LCP, INP, or CLS?
Step 2: Identify the page template
Performance regressions usually cluster by template:
- home
- category/listing
- product detail (PDP)
- cart
- checkout
“Site is slow” is too vague. “Checkout INP got worse” is actionable.
Step 3: Ask “what changed?”
Most regressions come from:
- plugin/theme updates
- new tags (marketing pixels are frequent offenders)
- new fonts/hero media
- backend changes (cache config, server resources, DB)
Even one new third-party script can turn a fast site into a laggy one.
Common traps I see a lot
“We improved Lighthouse once, so we’re done.”
Regressions happen weekly. Performance is a process, not a launch task.“It loads fast on my machine.”
Field data often fails on mid-range Android + real network + 3rd-party tags.“We’ll fix it later.”
Every new feature becomes a permanent maintenance cost. Keep a small performance budget.
If you want help debugging, reply with 3 things
1) Which metric is failing (TTFB / LCP / INP / CLS)
2) Which page type (home/category/PDP/cart/checkout)
3) Your rough TTFB and what changed recently (plugin/tag/release)
I’ll suggest the next 1–2 checks that usually narrow it down quickly.
(Side note: we are building an internal monitor called Watcher to track these per template over time, because the hardest part isn’t fixing performance once—it’s catching regressions before clients do. But the diagnostic logic above is the same no matter what tools you use.)
Top comments (0)