← Back to glossary

Core Web Vitals & Page Performance

Q: What is a common misconception about Core Web Vitals & Page Performance?

A fast server response time guarantees good web performance. Server response time (TTFB) is one factor — render-blocking scripts, large unoptimised images, layout shifts, and JavaScript execution time all affect user-perceived performance independently of server speed.

Q: Why does Core Web Vitals & Page Performance matter?

Web performance directly impacts user experience and revenue — a 1-second delay in mobile page load reduces conversions by 20%, and Google uses Core Web Vitals as a ranking signal.

Frontend Intermediate

debt(d5/e5/b5/t7)

d5 Detectability Operational debt — how invisible misuse is to your safety net

Closest to 'specialist tool catches it' (d5). The detection_hints list Lighthouse, PageSpeed Insights, WebPageTest, and CrUX — all specialist tools that must be explicitly run. Issues like render-blocking scripts or missing image dimensions are not caught by a compiler or default linter, and many problems (especially CLS and INP) only surface under real-world conditions. Not quite d7 because automated tooling (Lighthouse CI) can catch most issues in CI pipelines.

e5 Effort Remediation debt — work required to fix once spotted

Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix describes a multi-step audit covering LCP, CLS, INP, and JS payload via code splitting. Individual fixes (adding async/defer, lazy loading, image dimensions) are one-liners, but the full remediation — preloading hero images, reducing JS payload with code splitting, eliminating layout shifts across templates — spans multiple files and components. Not e7 because it doesn't require cross-cutting architectural changes.

b5 Burden Structural debt — long-term weight of choosing wrong

Closest to 'persistent productivity tax' (b5). applies_to is the general web context, meaning every page and every release needs to be evaluated against performance budgets. Large images, render-blocking scripts, and layout shifts are recurring risks that affect many work streams (images pipeline, JS bundling, CSS loading strategy, third-party scripts). Not b7 because the codebase isn't architecturally shaped by this concern — it's more of a recurring maintenance tax.

t7 Trap Cognitive debt — how counter-intuitive correct behaviour is

Closest to 'serious trap' (t7). The misconception field directly states the canonical wrong belief: developers assume fast server response (TTFB) guarantees good web performance, when in fact render-blocking scripts, large images, layout shifts, and JS execution time all independently affect user-perceived performance. This contradicts intuition from backend-focused developers and is a well-documented but widely-held misconception, justifying t7.

About DEBT scoring → scored by claude-sonnet-4-6 · 2026-05-11 · reviewed by human

Also Known As

Core Web Vitals page performance LCP FID CLS

TL;DR

Google's Core Web Vitals — LCP, INP, CLS — measure real user experience and directly influence search ranking.

Explanation

Core Web Vitals (2024 set): LCP (Largest Contentful Paint, <2.5s good) — time until the largest image or text block renders; INP (Interaction to Next Paint, <200ms good, replaces FID) — responsiveness to user interactions; CLS (Cumulative Layout Shift, <0.1 good) — visual stability, unexpected layout movements. Optimising LCP: serve images in WebP/AVIF, use rel='preload' for hero images, server-side render critical content, use a CDN. Optimising INP: break up long tasks with scheduler.yield(), use web workers for heavy JS. Optimising CLS: always specify width/height on images and iframes, avoid inserting content above existing content. Measure with Lighthouse, PageSpeed Insights, or field data from Chrome UX Report. For PHP applications, server response time (TTFB) directly affects LCP.

Common Misconception

✗ A fast server response time guarantees good web performance. Server response time (TTFB) is one factor — render-blocking scripts, large unoptimised images, layout shifts, and JavaScript execution time all affect user-perceived performance independently of server speed.

Why It Matters

Web performance directly impacts user experience and revenue — a 1-second delay in mobile page load reduces conversions by 20%, and Google uses Core Web Vitals as a ranking signal.

Common Mistakes

Render-blocking JavaScript in <head> without async or defer attributes.
Large unoptimised images — the single biggest contributor to page weight.
No lazy loading for below-the-fold images — loading=lazy is a one-attribute fix.
Not measuring with real users (RUM) — synthetic tests miss real-world network and device conditions.

Code Examples

✗ Vulnerable

<!-- Render-blocking resources in <head>: -->
<head>
  <script src="large-bundle.js"></script>  <!-- Blocks rendering -->
  <link rel="stylesheet" href="all-styles.css">  <!-- Blocks rendering -->
</head>

<!-- Non-blocking: -->
<script src="large-bundle.js" defer></script>
<link rel="preload" href="critical.css" as="style">

✓ Fixed

<!-- Preload critical resources -->
<link rel="preload" as="image" href="hero.webp" fetchpriority="high">
<link rel="preload" as="font" href="/fonts/sora.woff2" crossorigin>

<!-- Lazy-load below-fold images -->
<img src="product.webp" loading="lazy" decoding="async"
     width="800" height="600" alt="Product photo">

<!-- Avoid layout shift — always specify dimensions -->
<img width="1200" height="630" src="banner.webp" alt="">

<!-- Defer non-critical JS -->
<script src="analytics.js" defer></script>
<script src="chatwidget.js" async></script>

<!-- Reduce INP: break up long tasks -->
// In JS:
await scheduler.yield(); // hand control back to browser between chunks

References

https://web.dev/vitals/