sfw/fix
NO_FCP high

Lighthouse returned error: NO_FCP

PageSpeed's test aborted because Chrome never detected a first contentful paint inside its 15-second load budget.

What you see

Lighthouse returned error: NO_FCP. The page did not paint any content. Please ensure you keep the browser window in the foreground during the load and try again. (NO_FCP)

What’s actually happening

You run PageSpeed Insights and get no score at all, just a red error box. Lighthouse measures First Contentful Paint by watching for the first text or image Chrome rasterizes to the screen; if 15 seconds pass with the viewport still blank, the whole run fails instead of scoring. The page itself usually loads fine in your own browser, which makes this confusing. The difference is that your browser will happily wait 30 seconds for a slow preloader while Lighthouse will not.

Common causes

  • A full-page loading screen or splash animation that covers content until JS finishes — Lighthouse sees only the overlay, never the content behind it
  • CSS that ships the body at opacity:0 or visibility:hidden and fades it in via a script that runs late or fails
  • Render-blocking JavaScript or a slow third-party call (chat widget, A/B tool, font host) that pushes the first paint past 15 seconds
  • Server response time so high that the HTML itself arrives after the timeout — common on oversold shared hosting or a cold serverless function
  • A client-side-rendered SPA whose first meaningful paint depends entirely on a bundle that is slow to parse and execute

How to fix it

  1. Reproduce the blank window locallyRun `npx lighthouse https://yoursite.com --view --throttling-method=devtools` and watch the filmstrip. If every thumbnail is white until the very end, you have confirmed there is no early paint and can stop guessing.
  2. Kill or defer the preloaderIf a full-page loader or opacity:0 body is hiding content, make the real HTML paint first. Render server-side markup that is visible by default, then layer the animation on top — never gate the first paint on a script completing.
  3. Remove render-blocking work from the critical pathMove non-essential `<script>` tags to `defer`/`async`, lazy-load chat and analytics widgets after load, and inline only the critical CSS. The goal is any text or image painting within a few seconds, not a perfect score.
  4. Fix slow server responseCheck Time To First Byte with `curl -w "%{time_starttransfer}\n" -o /dev/null -s https://yoursite.com`. If TTFB is multiple seconds, the HTML is arriving too late for anything to paint — add caching, a CDN, or move off oversold hosting before touching front-end code.
  5. Disable plugins one at a time on WordPressDeactivate all plugins, confirm the error clears, then re-enable in groups, re-testing as you go. Page builders and 'optimization' plugins that defer everything are frequent culprits here.

Stop it recurring

Always render visible content in the initial HTML response and treat any opacity:0-until-JS pattern as a paint risk.

Related errors