dotvitals

Real visitors stare at a blank page for too long

LowConfirmedperf.crux.fcp-slow

What this check looks for

For a quarter of real visits to ‹scope›, ‹value› passed before anything at all was drawn on the screen. Google's threshold for a good experience is 1.8 seconds.

Why it matters

A blank screen is the point at which visitors decide the site is broken and go back. Getting something — anything — painted early buys you the patience for the rest of the page to arrive.

When the check passes, your report says: “Real visitors see something drawn within Google's threshold”.

What it costs your score

When this check fails it removes 6 points from your Performance score, before the status, confidence and repeat multipliers are applied. Performance carries a weight of 8 in the overall score.

It shares the performance.field family ceiling of 35 points: however many findings that family produces, together they cannot remove more than that from Performance. One underlying problem showing up in several places is still one problem.

Severity
low
Default confidence
confirmed
Status when triggered
fail
Deduction
6 points
Family cap
performance.field · 35
Category
Performance
Module
Perf crux
Fix owned by
user
In the ruleset since
2026.09

How the whole score is calculated

How to fix it

Paint something within 1.8 seconds of a real visitor asking for the page.

A quarter of visits currently spend ‹value› on a blank screen, which is where visitors abandon.

  1. Fix the server response time first if it is a large share of this number — everything else is downstream of it.

  2. Inline the small amount of CSS needed for what is above the fold, and load the rest without blocking rendering.

  3. Move <script> tags out of the critical path with defer or type="module"; a synchronous script in <head> stops the parser dead.

  4. Preconnect to the origins the critical resources come from, so DNS, connection and TLS are not serialised after discovery.

  5. Self-host or preload web fonts, and set font-display: swap so text is painted in a fallback face rather than waiting.

How to confirm it worked

  • Re-run this scan after the change has been live for several weeks — field data uses a trailing 28-day window.

  • Confirm in the lab section of this report that no render-blocking resource remains on the critical path.

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Technical detail

First Contentful Paint at the 75th percentile: **‹value›** (‹band›).

This is **field data**: the experience of real Chrome users who visited ‹scope› over the trailing 28-day collection window, not a measurement we took ourselves. The number quoted is the **75th percentile** — Google's own choice of statistic, meaning three visits in four were at least this good. A site with a fast median can still fail here, and that is the point: the quarter of visits that are worst are real people on real networks and devices.

Field data also lags. A fix you deployed yesterday will not move this number until it has been in front of users for most of the window, so use the lab measurements alongside it to confirm the change landed.

Google's published thresholds: **good at or below 1,800 ms**, needs improvement up to 3,000 ms, **poor above 3,000 ms**. FCP is the moment the browser paints the first text or image — not the main content, which is LCP, but the first sign of life.

FCP is dominated by two things: the time to first byte, and whatever blocks rendering once the HTML arrives. If TTFB is already close to this number, fix the server first; the gap between the two is what the critical rendering path costs you. ‹detail›

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the perf crux checker

Other perf crux checks