At a glance
First Contentful Paint p75 over time, daily time-series of mobile FCP from CrUX. Pairs with crux_fcp_p75 snapshot. The earliest paint signal trend, useful for distinguishing TTFB-driven regressions (FCP and TTFB rise together) from render-blocking-driven regressions (FCP rises alone) from LCP-element-driven regressions (LCP rises but FCP doesn’t). FCP is no longer a CWV (replaced by LCP in March 2020) but remains useful as a precursor metric.
| What it counts | Time-series of first_contentful_paint p75 across the rolling 28-day CrUX window. Each daily data point reflects the trailing 28 days of real-user FCP measurements. |
| Sample type | Field data sourced from CrUX. |
| Why FCP trend matters as a diagnostic layer | The trio of TTFB + FCP + LCP trends, read together, isolates where regressions originate. TTFB up + FCP up + LCP up = server / infrastructure regression. TTFB stable + FCP up + LCP up = render-blocking regression. TTFB stable + FCP stable + LCP up = LCP-element-specific regression (image upload, hero swap). Reading these three trends together is the fastest diagnostic. |
| Common FCP drift patterns | Same as LCP causes upstream of the LCP element: server response, render-blocking resources, font loading. Drift is usually slower than CLS regressions but faster than LCP drift because FCP excludes the slow-loading-image issues that dominate LCP. |
| Sample size threshold | CrUX requires sufficient real-user volume (~1,000+ sessions per 28 days). |
| Currency | n/a, time-series of milliseconds. |
| Time window | 28D rolling × T |
| Alert trigger | current value > 1,800ms OR 7-day rolling delta > +400ms (regression). |
| Sentiment key | psi_fcp |
| Roles | owner, marketing, operations |
Calculation
Calculated automatically from your Website Performance (PageSpeed + CrUX) data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK-based BigCommerce fashion store, mobile FCP + TTFB + LCP trio over 6 months ending Wednesday 15 May 26.| Month | FCP p75 | TTFB p75 | LCP p75 | Diagnostic read |
|---|---|---|---|---|
| Nov 25 | 1,640ms | 720ms | 2,380ms | All healthy |
| Jan 26 | 1,920ms | 740ms | 2,720ms | FCP up, TTFB stable → render-blocking added |
| Feb 26 | 2,180ms | 760ms | 3,180ms | More render-blocking + LCP-element heavier |
| Mar 26 | 2,440ms | 1,020ms | 3,840ms | TTFB up too → server / cache regression |
| Apr 26 | 2,500ms | 1,140ms | 4,420ms | TTFB still rising, hero images heavier |
| May 26 | 2,540ms | 1,180ms | 4,820ms | All three poor |
-
The trio of TTFB + FCP + LCP shows the regression staging clearly. Different metrics rose at different times, identifying different cause types:
- Jan 26 FCP rise without TTFB rise = render-blocking resources added (Klaviyo popup CSS as external stylesheet)
- Feb 26 FCP + LCP rise = render-blocking persisted + new heavy hero (the carousel deploy)
- Mar 26 TTFB rise = server / cache regression (CDN cache hit rate dropped from 70% to 45%)
- Apr-May 26 LCP-only rise = hero campaign images uploaded without optimisation
- Reading the trio diagnoses regression type without manual investigation. This is the value of the FCP trend, it’s the differential between TTFB and LCP, surfacing render-blocking issues that otherwise look like generic “everything got slower.”
-
The recovery sequence follows the same logic, in reverse:
- Address TTFB first (lift cache hit rate back to 80%+), pulls FCP and LCP down by ~400ms each just from TTFB improvement.
- Address render-blocking next (defer Klaviyo popup CSS), pulls FCP and LCP down further.
- Address LCP-element-specific issues (image format conversion, preload), pulls only LCP down.
- The trio also catches the inverse pattern: when only LCP rises and FCP stays stable, the regression is image-element-specific. No need to investigate render-blocking or TTFB; the diagnosis is unambiguous.
-
Alert configuration recommendation: alert on FCP regressions specifically because they signal render-blocking issues that LCP alone wouldn’t isolate. A
+400ms FCP delta over 7 daysalert catches render-blocking regressions early.
- Check FCP trend alongside TTFB and LCP trends.
- Pattern-match the trio: which metrics rose, in what order? The pattern identifies the regression class.
- Apply the right fix per identified class.
| Time horizon | Action |
|---|---|
| First 1 hour | Read the trio; identify regression class. |
| First 24 hours | Apply class-specific fix. |
| Day 28 | Field metric reflects fix. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
crux_fcp_p75 | Static FCP snapshot. |
crux_lcp_trend | LCP trend; pair for diagnostic trio. |
crux_ttfb_trend | TTFB trend; the third leg of the trio. |
crux_inp_trend | INP trend. |
crux_pass_rate_trend | All-three pass rate trend. |
psi_render_blocking | Render-blocking resources directly affect FCP. |
psi_score_trend | Lab score trend. |
Reconciling against the vendor’s own dashboard
Where to look:- CrUX BigQuery, historical FCP data.
- PageSpeed Insights, current FCP shown in field section.
- Web Vitals Chrome extension, live FCP measurement.
| Reason | Direction | What to do |
|---|---|---|
| Window timing. | Vortex IQ lags 1-2 days | Wait for refresh. |
| Smoothing. Each daily point is 28-day rolling. | Smoothed | Step regressions appear gradual. |
crux_fcp_p75, crux_lcp_trend, crux_ttfb_trend).
Quick rule for support tickets: if a merchant says “my FCP regressed but TTFB is fine”, render-blocking resources were added. Check theme version, third-party CSS additions, font-loading configuration changes.
Known limitations / merchant FAQs
Should I monitor FCP trend as a separate alert from LCP? Yes. FCP-only regressions (FCP up while LCP stable) catch render-blocking issues that LCP alone might miss because LCP is dominated by image-element timing. A+400ms FCP delta alert catches this class of regression early.
Why is FCP no longer a CWV but still tracked?
Google replaced FCP with LCP as the official CWV in March 2020 because FCP fires too easily (any tiny element render triggers it) without reflecting user perception. FCP remains useful diagnostically as a precursor to LCP and as a render-blocking detector.
My TTFB and FCP trended up together. What does that suggest?
Server / cache regression. TTFB is upstream of FCP; if both rise together, the issue is server-side (slow origin, cache miss rate increase, network configuration change). Investigate CDN cache hit rate first.
Can I have FCP improve while LCP regresses?
Yes, when render-blocking is reduced (FCP improves) but the LCP element is replaced with a heavier image (LCP regresses). The trio diagnostic catches this; the snapshot view alone wouldn’t.