Performance

Is your caching plugin delaying your mobile LCP?

Lazy-loading a hero background image can push Largest Contentful Paint past 15 seconds on mobile. How to spot it in Lighthouse and fix it in WordPress.

By , Northline Search · · 6 min read

A smartphone on a dark desk with a thin gold loading line on the screen and a warm lamp behind it

On a recent audit, a WordPress homepage scored 96 for desktop performance and 33 on mobile. Mobile Largest Contentful Paint (LCP) was 15.1 seconds. Google's "good" threshold is 2.5 seconds.

The server was not the problem: HTML arrived from the CDN in 30 to 50 milliseconds. The problem was that the biggest thing on the screen, the hero image, was deliberately loaded last.

How lazy-loading backfires

Lazy-loading defers images until they are about to scroll into view. That is great for images further down the page. Applied to the hero, it means the browser has to download and run JavaScript, work out the layout, notice the hero is visible, and only then start downloading the largest image on the page.

Caching and optimization plugins often lazy-load CSS background images too. Page builders commonly place the hero image as a section background, so it gets caught by that setting.

How to confirm it in Lighthouse

  1. Run Lighthouse in Chrome DevTools with mobile emulation, or use PageSpeed Insights.
  2. Open the Largest Contentful Paint element diagnostic. If it is your hero section, note whether it is an <img> or a background.
  3. Look for "Largest Contentful Paint image was lazily loaded" and the LCP request discovery insight. Either one points to this problem.
  4. In the network waterfall, check when the hero image request starts. If it starts after most scripts, it was discovered late.

The fix

  • Exclude the hero from lazy-loading. Most plugins have an exclusion field for CSS background lazy-loading; add the hero section's class or the image file name.
  • Preload it. Add <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> in the head, ideally with responsive imagesrcset.
  • Better still, use a real image. An <img> with fetchpriority="high", width and height, and a modern format is discovered by the browser's preload scanner immediately.
  • Right-size it. Serve a mobile-sized WebP or AVIF, not the desktop original.

Then cut the scripts in front of it

On the same site, Google Tag Manager plus separate GA4 and Ads tag libraries added about 530 KB of JavaScript, and reCAPTCHA added 356 KB on every page, including pages without forms. Firing analytics through one tag manager container and loading form scripts only on form pages frees the main thread for the content users came for.

Measure again with field data

Lab tests show the cause; field data shows the result. After shipping the fix, watch the Core Web Vitals report in Search Console. Changes take about 28 days to fully appear, because the data is a rolling window.

Want this checked on your site? Every Northline audit includes a full crawl, mobile speed tests and AI crawler access.
Request an audit