> ## 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 Visible, Website Performance (PageSpeed + CrUX) > First Content Visible for Website Performance (PageSpeed + CrUX) stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to... **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 at the 75th percentile.** The time at which the first piece of content (text, image, or non-blank canvas) appears on screen, measured from `navigationStart`. **The earliest "the page is loading" signal** users perceive, earlier than LCP. FCP is no longer a Core Web Vital (replaced by LCP for ranking purposes) but remains a useful precursor metric: a slow FCP guarantees a slow LCP since LCP can't render before the page paints anything at all. Healthy FCP is under 1.8 seconds at p75; over 3 seconds is "poor". | | | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | The 75th-percentile of `first_contentful_paint` measurements across all real-user page-loads in the 28-day CrUX window. The metric measures from navigation start to the moment any content (DOM text, images, non-blank canvas, SVGs) renders. | | **Sample type** | **Field data** sourced from CrUX. Lab equivalent doesn't have a direct named card but appears in Lighthouse audits as the "First Contentful Paint" sub-metric of the Performance Score (10 percent weight). | | **Google thresholds** | **Good: ≤ 1,800ms**. **Needs improvement: 1,800-3,000ms**. **Poor: > 3,000ms**. FCP is no longer a CWV signal but the thresholds are still part of Lighthouse's Performance Score calculation. | | **What drives slow FCP** | (1) **Slow TTFB**: FCP cannot fire before the HTML response arrives. A 1,200ms TTFB sets a 1,200ms floor on FCP. (2) **Render-blocking resources**: synchronous CSS or JS in `` delays the first paint. (3) **Slow CSS-Object-Model construction**: very large stylesheets take time to parse. (4) **Slow DOM construction**: very large HTML (10,000+ DOM nodes) takes time to parse before render can begin. | | **FCP vs LCP** | FCP fires when *any* content paints; LCP fires when the *largest* content paints. **For most ecommerce pages**, FCP arrives 200-1,000ms before LCP. **The gap matters**: if FCP and LCP fire close together (small gap), the LCP element rendered with the first paint, suggesting render-blocking is the dominant issue. If the gap is large (over 2 seconds), the LCP element is loading separately, suggesting image-optimisation or preload work is needed. | | **Why FCP is no longer a CWV** | Google replaced FCP with LCP in March 2020. **Reason**: FCP can fire when any tiny element renders (a logo, a single character, a navigation pixel), it doesn't reflect the user's perception of "the page is ready". LCP focuses on the largest element which more closely matches user perception of meaningful content. **FCP remains useful as a precursor metric** because it's a leading indicator: improving FCP usually improves LCP too. | | **Sample size threshold** | CrUX p75 calculation requires sufficient real-user volume (\~1,000+ page-loads per 28-day window per device). | | **Currency** | n/a, this is a duration in milliseconds. | | **Time window** | `28D` (CrUX-fixed). | | **Alert trigger** | `> 1,800ms` (Google's good threshold). Sub-thresholds: amber 1,800-3,000ms, red > 3,000ms. | | **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 field-data measurement Wednesday 15 May 26. | Page template | Mobile FCP p75 | Mobile LCP p75 | LCP-FCP gap | Diagnosis | | ------------------- | -------------: | -------------: | ----------: | --------------------------------------- | | Homepage | 2,640ms | 4,820ms | 2,180ms | Wide gap: hero image loads separately | | Product detail page | 2,180ms | 3,640ms | 1,460ms | Moderate gap: product hero image | | Collection page | 2,820ms | 4,210ms | 1,390ms | Moderate gap: 12-image grid first image | | Cart | 1,680ms | 2,180ms | 500ms | Tight gap: page light, no media drag | | Checkout | 1,320ms | 1,940ms | 620ms | Tight gap: lightest pages | | **Origin p75** | **2,540ms** | **4,820ms** | **2,280ms** | **FCP needs improvement; LCP poor** | What the per-template view is telling us: 1. **Origin FCP at 2,540ms is in the "needs improvement" band.** Real users see the first painted content roughly 2.5 seconds after navigation, with 25 percent of users experiencing 3+ seconds. **Improving FCP also improves LCP** because LCP can't fire before FCP, but they're not 1:1. 2. **The TTFB-FCP relationship**: with TTFB at \~1,180ms (per [`psi_server_response`](/nerve-centre/kpi-cards/website-performance/server-response-time)), FCP fires roughly 1,360ms after the HTML arrives. This 1,360ms is "render preparation time", CSS download + parse + layout + first paint. **Render-blocking CSS is the likely culprit** for the FCP-after-TTFB gap; reducing render-blocking resources should drop FCP toward 1,500ms. 3. **The LCP-FCP gap of 2,280ms on the homepage** is wide, telling us the LCP element loads separately from the initial paint. The hero image arrives 2.2 seconds after the page first paints. **Two-stage fix**: (a) fix FCP via render-blocking CSS reduction; (b) preload the LCP element so it arrives near FCP rather than 2 seconds later. **Combined, expect the homepage's mobile p75 LCP to drop from 4,820ms to roughly 2,400ms**. 4. **PDP and collection pages have moderate gaps** (1,400ms range). Same fix-pattern: address render-blocking + preload the largest above-the-fold image. 5. **Cart and checkout have tight gaps and healthy absolute values.** No optimisation needed; they're already fast. The gap is small because these pages have no large above-the-fold media. 6. **The optimisation sequencing**: address FCP first because it's upstream of LCP. **Fix render-blocking CSS** (covered in [`psi_render_blocking`](/nerve-centre/kpi-cards/website-performance/render-blocking-resources)) → FCP drops 200-500ms → LCP drops by similar amount as a side effect. Then **address LCP-specific issues** (image preload, format conversion) for the remaining gap. 7. **Implications for engineering**: don't optimise LCP before FCP. The two-stage fix sequence is more efficient than parallel work because FCP improvements automatically lift LCP, and FCP work (render-blocking) is mostly different from LCP work (image preload + format). The diagnostic flow when this card flags amber/red: 1. **Cross-reference with [`crux_ttfb_p75`](/nerve-centre/kpi-cards/website-performance/server-response-time).** Slow TTFB sets the FCP floor; fix TTFB first if it's amber/red. 2. **Check render-blocking resources.** [`psi_render_blocking`](/nerve-centre/kpi-cards/website-performance/render-blocking-resources) surfaces CSS/JS in `` blocking first paint. 3. **Compare to LCP.** Wide LCP-FCP gap = LCP-element loading issue. Tight gap = render-blocking is the dominant issue. 4. **For low-traffic sites with null FCP**, fall back to lab measurements via [`psi_perf_score_summary`](/nerve-centre/kpi-cards/website-performance/performance-score-summary). Rapid-response playbook: | Time horizon | Action | | -------------- | ------------------------------------------------------ | | First 1 hour | Cross-reference TTFB and render-blocking diagnostics. | | First 24 hours | Apply render-blocking fix (defer non-critical CSS/JS). | | First 7 days | Field FCP partial movement. | | Day 28 | Field FCP fully reflects fix. Re-evaluate LCP. | ## Sibling cards merchants should reference together | Card | Why merchants reach for it | | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | [`crux_lcp_p75`](/nerve-centre/kpi-cards/website-performance/page-load-speed) | LCP cannot fire before FCP; FCP improvement lifts LCP. | | [`crux_ttfb_p75`](/nerve-centre/kpi-cards/website-performance/server-response-time) | TTFB is upstream of FCP; slow TTFB sets the FCP floor. | | [`crux_fcp_trend`](/nerve-centre/kpi-cards/website-performance/first-content-over-time) | FCP over time; drift detection. | | [`psi_render_blocking`](/nerve-centre/kpi-cards/website-performance/render-blocking-resources) | Render-blocking resources delay FCP directly. | | [`psi_speed_index`](/nerve-centre/kpi-cards/website-performance/speed-index) | Speed Index integrates the visual completeness curve including FCP. | | [`psi_perf_score_summary`](/nerve-centre/kpi-cards/website-performance/performance-score-summary) | Composite score; FCP is 10 percent of weight. | | [`crux_cls_p75`](/nerve-centre/kpi-cards/website-performance/layout-stability) | Sister CWV. | | [`crux_inp_p75`](/nerve-centre/kpi-cards/website-performance/click-responsiveness) | Sister CWV. | | [`psi_cwv_pass_rate`](/nerve-centre/kpi-cards/website-performance/speed-test-pass-rate) | All-three CWV gate (excludes FCP since FCP is no longer a CWV). | ## Reconciling against the vendor's own dashboard **Where to look:** * **[PageSpeed Insights](https://pagespeed.web.dev)**, field section shows origin-level p75 FCP. * **[CrUX URL-level dataset](https://github.com/GoogleChrome/CrUX#crux-on-bigquery)**, per-URL FCP for high-traffic URLs. * **Web Vitals Chrome extension**, measures FCP live as you navigate. **Why the Vortex IQ FCP may differ from PSI:** | Reason | Direction | What to do | | ------------------------------------------------------------------- | ------------------ | --------------------------------------- | | **Window timing.** Vortex IQ refreshes daily; CrUX has 1-2 day lag. | Vortex IQ **lags** | Wait for next refresh. | | **Origin vs URL.** Different aggregation. | Different scope | Use per-URL view for direct comparison. | | **Form factor.** Mobile vs desktop. | n/a if both mobile | Confirm form factor. | **Cross-connector reconciliation:** primarily internal (with [`crux_lcp_p75`](/nerve-centre/kpi-cards/website-performance/page-load-speed), [`crux_ttfb_p75`](/nerve-centre/kpi-cards/website-performance/server-response-time)). **Quick rule for support tickets:** if a merchant says *"my FCP improved but my LCP didn't"*, the LCP element is loading separately from the initial paint. Investigate image preload, format optimisation, or render-blocking on the LCP element specifically. ## Known limitations / merchant FAQs **Why was FCP replaced by LCP as a CWV?** FCP fires too easily, a logo, a single character, or a navigation pixel can trigger it without reflecting "the page is ready". LCP focuses on the largest content element which more closely matches user perception of meaningful content. **Google made this change in March 2020** to better align CWV with perceived performance. **Should I still optimise FCP?** Yes, indirectly. FCP improvements automatically lift LCP because LCP can't fire before FCP. **Optimise FCP first** (render-blocking resources, TTFB) and LCP improves as a side effect. Then tackle LCP-specific issues (image preload, format conversion) for the remaining gap. **My FCP is healthy but LCP is poor. What's going on?** The LCP element is loading separately from the initial paint. Common cause: large hero image that arrives 1-3 seconds after the page paints text + small images. **The fix**: preload the LCP image so it downloads in parallel with the critical render path; convert format for smaller bytes; serve responsive variants for mobile. **Why is my FCP slow if my TTFB is fast?** Render-blocking resources. The HTML arrived quickly (fast TTFB) but external CSS or synchronous JS in `` is blocking the first paint. The browser has to download + parse those resources before painting anything. **Fix render-blocking** ([`psi_render_blocking`](/nerve-centre/kpi-cards/website-performance/render-blocking-resources)) to drop FCP toward TTFB + 200-400ms. **Can I make FCP under 1 second?** Possible but rarely needed. Sub-1s FCP requires aggressive edge caching (TTFB under 200ms) plus inlined critical CSS plus minimal blocking resources. **For typical ecommerce, 1.2-1.6s FCP is excellent**; pushing below that has diminishing returns. **Why isn't FCP a Core Web Vital anymore?** It's still a Lighthouse Performance Score component (10 percent weight) but not a ranking signal in Google's CWV. The transition was March 2020. **For ranking**, only LCP, INP, CLS matter; FCP is for engineering iteration. **Can Vortex IQ improve FCP automatically?** Read-only. Vortex IQ identifies the issue; engineering implements. *** ### Tracked live in Vortex IQ Nerve Centre *First Content Visible* 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.