At a glance
Lab-measured Largest Contentful Paint from Lighthouse’s synthetic page-load. Reflects what LCP would be in standardised conditions (slow 4G, mid-tier mobile CPU emulation). The deterministic engineering metric that pairs with the field-datacrux_lcp_p75(real users): lab gives you a number you can run repeatedly during development to confirm fixes; field gives you the ranking-impact truth source. Lab LCP is what feeds 25 percent of the lab Performance Score (psi_perf_score_summary).
| What it counts | The Largest Contentful Paint timestamp from a single Lighthouse audit run, in milliseconds from navigationStart. The LCP element is auto-detected as the largest above-the-fold render-area element (image, video poster, or text block). |
| Sample type | Lab data (synthetic Lighthouse run). Field equivalent: crux_lcp_p75. |
| Why lab and field can differ | Lab measures one synthetic load on emulated mid-tier mobile + slow 4G; field measures the real-user distribution. Common gaps: (a) lab cold-cache vs warm-cache real-user mix; (b) lab uses Google’s PSI infrastructure (high CPU + good network); (c) real-user devices range from flagship phones (faster than lab) to entry-level Android (slower). The psi_field_vs_lab card surfaces the gap directly. |
| Lighthouse scoring | Lab LCP feeds the Performance Score with these scoring breakpoints: ≤ 2,000ms = 100 score, 2,000-4,000ms = scaled, > 4,000ms = 0 score. The 2,000ms target is stricter than the field 2,500ms “good” threshold because lab conditions are deterministic and Lighthouse expects sites to ship with margin. |
| Device profile | Mobile by default (Slow 4G + mid-tier CPU emulation). Desktop profile available via psi_mobile_desktop_lcp. |
| Run-to-run variance | Lab LCP fluctuates ±10-20 percent between runs due to timing variations in JS execution and network response. A single audit’s LCP is directional, not precise. Use 7-day rolling for trend reads; compare deltas larger than 200ms as meaningful. |
| Why this card matters | Engineering teams iterating on performance work need a deterministic measurement they can run repeatedly during development. Lab LCP fills that role: deploy a fix, run Lighthouse, see the impact within minutes. The field equivalent has a 28-day rolling lag that makes iteration impossible. |
| Currency | n/a, this is a duration in milliseconds. |
| Time window | T/7D (current measurement plus 7-day rolling average). |
| Alert trigger | > 2500ms (matches field threshold for consistency). Sub-thresholds: amber 2,000-2,500ms, red > 2,500ms (lab band stricter than field by design). |
| Sentiment key | psi_lcp |
| Roles | owner, 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 homepage, lab measurement Wednesday 15 May 26.| Audit run | Lab LCP (mobile) | Lab LCP (desktop) | Field LCP (mobile p75) | Notes |
|---|---|---|---|---|
| Run 1 (current) | 4,420ms | 1,920ms | 4,820ms | Hero PNG carousel still unoptimised |
| Run 2 (24h ago) | 4,580ms | 1,840ms | (28D rolling) | Within run-to-run variance |
| Run 3 (48h ago) | 4,680ms | 2,020ms | Within variance | |
| Run 4 (7 days ago, baseline) | 4,520ms | 1,960ms | Within variance | |
| 7-day rolling average | 4,550ms | 1,935ms | 4,820ms | Lab and field agree directionally |
- Lab LCP at 4,550ms (7-day rolling) sits in the “poor” band (above 4,000ms), and the field measurement at 4,820ms confirms real users experience similar slowness. Lab and field agree directionally, the gap of ~270ms between them is normal and reflects: cold-cache lab vs warm-cache real-user mix, lab’s mid-tier emulation vs real-user device distribution, and lab’s deterministic conditions vs real-user network variance.
- Run-to-run variance is visible in the daily measurements (4,420 → 4,580 → 4,680 → 4,520ms over 4 runs). The ±150ms range is typical Lighthouse variance; don’t react to single-run movements under 200ms. The 7-day rolling smooths to a stable 4,550ms baseline.
- Desktop at 1,935ms is in the “good” band (under 2,000ms target). Desktop runs faster because: (a) no network throttling (vs mobile slow 4G), (b) no CPU throttling (vs mid-tier mobile emulation), (c) typically larger viewport selecting different LCP elements. Desktop performance is not the priority; mobile is what Google ranks on.
- The gap between lab desktop (1,935ms) and lab mobile (4,550ms) is structural. Same site, same code, same audit infrastructure, only the throttling profile differs. A 2.5x mobile penalty is typical for unoptimised hero images: the slow 4G connection takes 2.5x longer to download the 2.8MB hero PNG, and that download time directly drives LCP.
-
The fix priority: lift mobile lab LCP from 4,550ms to under 2,500ms via image optimisation (covered in
psi_image_optimisation). Expected post-fix lab LCP: 1,800-2,200ms mobile, 1,200-1,400ms desktop. Field LCP follows over the 28-day rolling window. - Engineering iteration cadence: deploy a fix, run Lighthouse manually (gets a fresh lab measurement in 60 seconds), confirm the lab LCP dropped as expected. Repeat for next fix. Lab is the right tool for this loop; waiting 7+ days for field-data confirmation makes iteration impossible.
- Confirm with field data.
crux_lcp_p75and lab should agree directionally; large persistent gaps suggest real-user-condition-specific issues. - Decompose the LCP timeline. Lighthouse’s audit JSON breaks LCP into TTFB + Resource load delay + Resource load duration + Element render delay. The dominant portion suggests the fix.
- Identify the LCP element. Lighthouse names the element (hero image, hero video, h1 text); the fix-pattern follows.
- Apply the fix; re-run lab Lighthouse to confirm. Iterate until lab LCP is under target.
- Wait 28 days for field validation. Field LCP starts shifting at 7-day rolling, fully reflects at 28 days.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify LCP element + dominant timeline portion. |
| First 4 hours | Apply image format / preload / render-blocking fix. |
| First 24 hours | Re-run Lighthouse; confirm lab LCP improvement. |
| Day 7-28 | Field LCP rolling window absorbs. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
crux_lcp_p75 | Field LCP; the ranking-impact truth source. |
psi_field_vs_lab | Direct lab vs field gap analysis. |
psi_lab_tbt | Lab Total Blocking Time; pairs with lab LCP for the lab snapshot. |
psi_lab_cls | Lab CLS. |
psi_speed_index | Speed Index; alternative lab measure of perceived load speed. |
psi_performance_score | Lab Performance Score; LCP is 25 percent of the weight. |
psi_perf_score_summary | Composite executive view. |
psi_image_optimisation | Most common LCP fix lever. |
psi_render_blocking | Render-blocking resources delay LCP indirectly. |
psi_slowest_lcp_urls | Per-URL LCP ranking. |
Reconciling against the vendor’s own dashboard
Where to look:- PageSpeed Insights, “Performance” panel shows lab LCP for the audited URL.
- Chrome DevTools → Lighthouse panel, runs the same audit locally; lab LCP value matches PSI within run-to-run variance.
- Lighthouse CI, runs in your build pipeline; lab LCP is the metric that fails builds when set as a budget.
| Reason | Direction | What to do |
|---|---|---|
| Run-to-run variance. ±10-20 percent typical. | Either direction | Use 7-day rolling for trend reads. |
| Audit timing. PSI runs on-demand at the moment of request; Vortex IQ runs scheduled. | Different snapshot times | Re-run PSI immediately after a Vortex IQ audit for direct comparison. |
| Local Lighthouse vs PSI. Local DevTools Lighthouse runs on your CPU/network; PSI uses Google’s infrastructure. Local often runs faster (better connection). | Local lower | Use the PSI web UI for direct comparison; local DevTools is for development iteration. |
crux_lcp_p75, psi_field_vs_lab, psi_perf_score_summary).
Quick rule for support tickets: if a merchant says “my local Lighthouse says LCP is 2.1s but your card shows 4.5s”, the most common cause is the merchant running Lighthouse on a fast connection without proper throttling. Confirm the local Lighthouse is set to “Mobile” device with “Slow 4G” throttling for direct comparison.