NO_LCP Error in Lighthouse and PageSpeed Insights: How to Fix It

What the NO_LCP error means

Lighthouse is the testing engine behind PageSpeed Insights and the Lighthouse panel in Chrome DevTools. It loads your page in a controlled browser and listens for the browser's own performance events. One of those is the largest-contentful-paint event, which the browser fires each time a larger image or block of text appears in the viewport. If the load finishes and that event never fired, Lighthouse reports an error instead of a score. The message reads along these lines:

The page did not display content that qualifies as a Largest Contentful Paint (LCP).
Ensure the page has a valid LCP element and then try again. (NO_LCP)

Because LCP carries a large share of the performance score, Lighthouse cannot produce that score without it. The other categories, such as accessibility and SEO, usually still run, which is why you can see those numbers next to an empty performance gauge.

A close relative is NO_FCP, which means the page did not paint any content at all, not even a first contentful paint. NO_FCP usually points to a blank page, a page that never finished loading or a browser tab that was in the background during a local test. NO_LCP means something may have painted, but nothing that qualified as the largest contentful element. The causes overlap, so the checks below cover both.

Remember that a lab error is not the same as a field failure. The Core Web Vitals assessment in PageSpeed Insights comes from real Chrome users. If real visitors have LCP data and only the lab test fails, the page is working for people and the problem is the test conditions. The LCP guide explains how the metric is measured in full.

Why Lighthouse finds no LCP element

Almost every NO_LCP case falls into one of three groups: the test saw the wrong page, your content was not counted as painted, or the content arrived too late. This table lists the common causes and how to spot each one.

Note what does not count as an LCP candidate. Elements with zero opacity, elements outside the viewport, and images that cover the whole viewport and look like a background can be ignored by Chrome, and very low-detail placeholder images are also excluded. A page whose first screen is only a solid block, a gradient or a decorative full-screen image can therefore end up with no candidate at all.

How to see what Lighthouse actually saw

The fastest clue is in the report itself. In PageSpeed Insights, scroll to the filmstrip of screenshots under the lab section and look at the final screenshot. In the DevTools Lighthouse panel the same filmstrip appears near the top of the performance results. Ask one question: is that your real page?

• A challenge, captcha or access denied screen means bot protection stopped the test. See fixing 403 Forbidden errors if the server itself is refusing the request.
• A white or empty frame throughout means nothing painted. Look at hidden content, loaders and JavaScript rendering.
• Only a cookie banner or popup means the overlay covered the content. Consent tools that dim and block the whole screen are a common cause.
• Your real page means the content painted but was not counted. Hidden-on-load styles are the usual reason.

Check the server logs for the test request

PageSpeed Insights sends requests with a user agent containing Chrome-Lighthouse. Search your access log for it at the time of the run and read the status code. On a Plesk server the logs sit under the domain's system folder:

sudo grep "Chrome-Lighthouse" /var/www/vhosts/system/example.com/logs/access_ssl_log | tail -n 20

A 200 for the page means the server answered normally. A 403, 429 or 503, or no line at all, means something in front of or on the server is blocking the test. No line at all usually means a CDN or firewall answered before the request reached you.

Watch the paint events yourself

Open the page in Chrome, open DevTools, go to the Console and paste this before reloading:

new PerformanceObserver((list) => {
  for (const e of list.getEntries()) {
    console.log('LCP candidate', Math.round(e.startTime), 'ms', e.element);
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

If nothing is logged after the page has fully loaded, your browser also found no candidate, and the cause is in the page rather than the test. If candidates are logged locally but PageSpeed Insights still fails, the cause is the test conditions or something that treats Google's servers differently.

Content hidden on load and JavaScript-only pages

The most common in-page cause is a fade-in. Many themes and animation libraries set the hero section to invisible in CSS and then reveal it with a script once the page is ready. It looks polished, but it means the content is not visible on its first paint.

/* Problem: the hero starts invisible and waits for a script */
.hero { opacity: 0; transform: translateY(20px); }
.hero.is-visible { opacity: 1; transform: none; transition: all .6s; }

/* Fix: visible from the first paint, optional motion only */
.hero { opacity: 1; }
@media (prefers-reduced-motion: no-preference) {
  .hero h1 { animation: rise .4s ease-out both; }
}
@keyframes rise { from { transform: translateY(8px); } to { transform: none; } }

The fixed version keeps the element fully opaque the whole time and only moves it slightly, so the browser counts the paint immediately. The same applies to visibility: hidden, display: none on the main wrapper, and libraries that add a class such as aos-init or wow to above-the-fold content. Keep scroll animations for content further down the page.

Full-page loaders

A preloader that covers the screen with a spinner until the window load event fires hides everything behind it. Under mobile throttling the load event can take many seconds. Turn the preloader off in the theme or page builder settings; there is rarely a reason to keep one.

Pages drawn only by JavaScript

If view source shows little more than <div id="root"></div> and a script tag, nothing can paint until that script has downloaded, parsed and run. On the slow device Lighthouse simulates, that can take long enough to fail. Server-side rendering or static generation fixes this properly. If that is not possible yet, send at least the main heading and first image in the HTML. Our guide on JavaScript rendering for crawlers covers the same problem from the search engine side.

Bot protection, consent walls and slow loads

Security services are built to stop automated traffic, and Lighthouse is automated traffic. Cloudflare Bot Fight Mode, managed challenges, country blocks, rate limits and security plugins such as Wordfence can all show the test a challenge instead of your page. PageSpeed Insights runs from Google's servers in a few regions, so a rule that blocks traffic from certain countries can catch it even when your local test passes.

Your options, from simplest to most targeted:

1. Look in the firewall's event log for blocked or challenged requests at the exact time of your test and note which rule fired.
2. Relax that rule, or add a skip rule for the test. In Cloudflare, a custom rule matching http.user_agent contains "Chrome-Lighthouse" with the Skip action can bypass specific security features.
3. Keep the skip rule narrow, for example to the paths you test, because user agents are easy to fake.

Consent banners

A cookie banner that fills the whole viewport, or dims the page and blocks it behind a modal, can become the only visible content or hide everything else. Use a banner that sits at the bottom of the screen and leaves the page content visible. This also reduces layout problems covered in the banner layout shift guide.

When the page is simply too slow

Lighthouse waits a limited time for the page to load before giving up. If your page takes more than ten seconds to show anything under mobile throttling, NO_LCP can be the symptom of a page that is far too slow. Measure the server response first with the high TTFB guide, then work through render-blocking resources.

A worked example

A small agency launches a landing page for a client. Every PageSpeed Insights run on mobile fails with NO_LCP, while desktop sometimes scores in the 70s. The final screenshot on mobile shows the real page, so the test was not blocked.

Running the console observer locally with 4x CPU slowdown and Slow 4G throttling in DevTools logs no LCP candidate until several seconds in, and sometimes none. The theme CSS contains .hero { opacity: 0 }, and an animation library adds a class to fade the hero in once its script has loaded. That library loads from a third-party host after two other scripts.

The fix is two lines of CSS: remove the starting opacity from the hero and turn off the fade on the heading and hero image. The library still animates sections lower down. The next five mobile runs all return a score, with a measured LCP of 2.9 seconds, which gives the team a real number to improve rather than an error.

The fix, step by step

Edge cases worth knowing

• Intermittent errors. One NO_LCP among several normal runs usually means an occasional block, a rate limit or a slow third party, not the page design. Run the test five times and look at the pattern.
• Background tabs. When you run Lighthouse in DevTools, keep the tab in the foreground. Chrome slows down painting in hidden tabs, which can produce NO_FCP or NO_LCP on a page that is fine.
• Browser extensions. Ad blockers and other extensions can change the page in a local test. Use a guest profile or an incognito window with extensions turned off.
• Text in images or canvas. Content drawn in a canvas element is not an LCP candidate. A hero made entirely of canvas or WebGL can leave nothing to measure; put the main heading in HTML text.
• Videos without a poster. Add a poster image to a hero video so there is an image the browser can count while the video loads.
• Interstitial redirects. If the test URL redirects to a login, region selector or age gate, Lighthouse measures that page instead.

Keeping it fixed

Make a short rule for anyone who edits the site: the main heading and hero image must be visible from the first paint, with no fade-in, preloader or full-screen overlay. Most NO_LCP errors come back when a new theme, page builder template or animation setting quietly brings one of those back.

After any change to your firewall, CDN or security plugin, run PageSpeed Insights on your key templates and check the filmstrip. Keep the skip rule for the test documented so it is not removed by accident. Check the Core Web Vitals report in Google Search Console every month as well; field data there tells you whether real visitors are affected, which the lab test alone cannot. For wider monitoring of your templates, see fixing a failed Core Web Vitals assessment.