Skip to main content

Supporting Metrics

Supporting metrics—such as Time to First Byte (TTFB), First Contentful Paint (FCP), and Total Blocking Time (TBT)—help explain why your Core Web Vitals are failing. While Google doesn't use these secondary metrics directly as Core Web Vitals signals, they are the fastest way to pinpoint whether the bottleneck is server response, render-blocking work, or main-thread JavaScript.

Quick Summary

If LCP or INP is failing, use supporting metrics to locate the constraint. High TTFB points to server/network delay. Elevated TBT points to main-thread JavaScript blocking. Delayed FCP often indicates render-blocking CSS/fonts.

Key Diagnostic Metrics​

MetricWhat It MeasuresDiagnostic Relationship to CWVPass Threshold
TTFBTime until the first byte of HTML arrivesHigh TTFB often makes good LCP hard to achieve≤ 200ms
FCPTime until the first content paintsSlow FCP often correlates with delayed LCP≤ 1.8s
TBTTotal time long tasks block the main thread (lab)Useful lab proxy for responsiveness issues≤ 200ms
Speed IndexVisual pacing of the DOM populationRepresents the human perception of "loading speed"≤ 3.4s
Waterfall TimingsChronological request-by-request breakdownExposes the specific render-blocking file dependenciesAnalytical

Understanding the Dependency Chain​

metric-cascade-logic.txt
Server baseline:    TTFB is slow ───► FCP is delayed     ───► LCP is delayed
JavaScript weight:  TBT is high  ───► Main thread blocked ───► INP gets worse
Typography/media:   Late fonts/ads ─► Layout changes      ───► CLS increases

Step-by-Step Diagnostic Examples​

Utilize Waterfall charts for LCP Diagnosis​

  1. Run an isolated URL analysis on WebPageTest.org.
  2. Expand the Waterfall chronological chart.
  3. Locate row #1 (TTFB). If it exceeds 1,000ms, your server is the problem.
  4. Locate the specific LCP element's row (e.g., hero-banner.jpg). Verify if it is waiting for a 200kb .css file to finish downloading before the browser even requests the image.

Utilize TBT to predict INP Failures​

  1. Run a standard PageSpeed Insights examination.
  2. Observe Total Blocking Time (TBT) in the Lab Data section.
  3. If TBT surpasses 400ms+, expect a high rate of real-world INP failures.
  4. Dive into the DevTools Performance trace to identify the exact functions consuming that 400ms block.

Measure Raw TTFB Execution​

ttfb-health-check.sh
# Execute a raw header evaluation bypassing the browser entirely
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}\n" https://yourdomain.com

If the CLI registers a TTFB > 600ms, prioritize server and caching fixes before chasing front-end micro-optimizations.

Practical Diagnosis Scenarios​

High LCP Despite Compressed Imagery​

Problem: A mobile LCP reading of 3.5s contradicts the fact that the primary hero image is a tiny 75KB WebP graphic. Diagnosis: TTFB is 1.8s. The server/origin path is the bottleneck. Fix: Add page caching and reduce backend work (example: Redis object caching). TTFB drops and LCP follows.

Passing Lab Data, Failing Field Data​

Problem: PageSpeed Insights yields a perfect 95/100, but Search Console throws severe "Poor URL" warnings. Diagnosis: Lab tests run in controlled conditions; your real users may be on slower networks and devices. Fix: Implement aggressive Cloudflare CDN Edge HTML caching to push the physical server closer to resolving global latency penalties.

Explosive INP on WooCommerce Checkouts​

Problem: INP is ~520ms during checkout interactions. Diagnosis: TBT shows long tasks from a payment gateway script plus additional analytics tags. Fix: Force the analytics scripts to delay execution until user scrolling occurs, protecting the payment processing thread cleanly.

Common Mistakes & Troubleshooting​

MistakeExplanationSolution
Ignoring TTFBA slow origin response can dominate everything else.Measure TTFB first, then decide whether to focus on server/caching or front-end work.
Obsessing over the "PSI Grade"A composite 88/100 score easily obscures a hidden INP failure that destroys metrics.Assess LCP, CLS, INP, and TTFB directly in isolation.
Confusing lab and field dataLab conditions are synthetic; field metrics reflect real users.Use lab data to diagnose, and field data to validate.
Bypassing Waterfall mechanicsWaterfalls visually expose the exact chronological reason an asset was blocked.Run WebPageTest.org to see the exact sequence of loading constraints.

Target Quick Reference​

Supporting Metrics Baseline Cheat Sheet

Diagnostic Connections:

  • TTFB ≤ 200ms → Validates healthy server architecture; prerequisites for LCP.
  • FCP ≤ 1.8s → Proves the critical CSS rendering path is unblocked.
  • TBT ≤ 200ms → Powerful lab-controlled proxy protecting the INP score.

Primary Workflow Method:

  1. Check TTFB via curl. If > 500ms, stop and optimize the server.
  2. Run WebPageTest to expose the Waterfall sequence.
  3. Compare Lab (PSI) vs Field (CrUX).

What's Next​