> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # First Content Over Time, Website Performance (PageSpeed + CrUX) > First Content Over Time for Website Performance (PageSpeed + CrUX) stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how ... **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Website Performance](/nerve-centre/connectors#connectors-by-type) ## At a glance > **First Contentful Paint p75 over time**, daily time-series of mobile FCP from CrUX. Pairs with [`crux_fcp_p75`](/nerve-centre/kpi-cards/website-performance/first-content-visible) 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** | What the three-trend trio is telling us: 1. **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 2. **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." 3. **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. 4. **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. 5. **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 days` alert** catches render-blocking regressions early. The diagnostic flow: 1. **Check FCP trend alongside TTFB and LCP trends.** 2. **Pattern-match the trio**: which metrics rose, in what order? The pattern identifies the regression class. 3. **Apply the right fix per identified class**. Rapid-response playbook: | 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`](/nerve-centre/kpi-cards/website-performance/first-content-visible) | Static FCP snapshot. | | [`crux_lcp_trend`](/nerve-centre/kpi-cards/website-performance/load-speed-over-time) | LCP trend; pair for diagnostic trio. | | [`crux_ttfb_trend`](/nerve-centre/kpi-cards/website-performance/server-speed-over-time) | TTFB trend; the third leg of the trio. | | [`crux_inp_trend`](/nerve-centre/kpi-cards/website-performance/responsiveness-over-time) | INP trend. | | [`crux_pass_rate_trend`](/nerve-centre/kpi-cards/website-performance/speed-test-pass-rate-over-time) | All-three pass rate trend. | | [`psi_render_blocking`](/nerve-centre/kpi-cards/website-performance/render-blocking-resources) | Render-blocking resources directly affect FCP. | | [`psi_score_trend`](/nerve-centre/kpi-cards/website-performance/performance-score-over-time) | 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. **Why the Vortex IQ FCP trend may differ from external views:** | 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. | **Cross-connector reconciliation:** primarily internal (with [`crux_fcp_p75`](/nerve-centre/kpi-cards/website-performance/first-content-visible), [`crux_lcp_trend`](/nerve-centre/kpi-cards/website-performance/load-speed-over-time), [`crux_ttfb_trend`](/nerve-centre/kpi-cards/website-performance/server-speed-over-time)). **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. *** ### Tracked live in Vortex IQ Nerve Centre *First Content Over Time* is one of hundreds of KPI pulses Vortex IQ tracks across Website Performance (PageSpeed + CrUX) and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.