Skip to main content
ModPageSpeed 2.0 and mod_pagespeed 1.1 — Now available

WordPress LCP: the server-layer fix

By Otto van der Schaaf

core-web-vitals lcp wordpress

WordPress LCP regressions almost always trace back to one of three things: an unsized featured image, a theme stylesheet blocking paint, or a page builder whose hero element is injected by JS. We’ll diagnose which one, then fix it server-side with ModPageSpeed (an nginx or Apache module) so the change applies to every URL at once — no theme rewrite, no per-image audit.

What LCP measures

LCP — Largest Contentful Paint — is the render time of the largest above-the-fold element on a page. On most WordPress sites that is the post’s featured image, a hero block from the page builder, or the H1. Google considers anything under 2.5 s “good”; anything over 4 s is “poor”. The field measurement comes from Chrome’s CrUX dataset (real users over the last 28 days); the lab measurement comes from Lighthouse and PageSpeed Insights. The two often disagree because real users are slower than your developer machine. See web.dev/articles/lcp for the canonical definition.

The most common LCP failures on WordPress

On WordPress, three things blow LCP:

  1. The hero image isn’t preloaded. Themes (Twenty Twenty-Five, Astra free, Kadence) render the LCP element through the_post_thumbnail(). WordPress 6.4+ ships wp_get_loading_optimization_attributes(), which is supposed to set fetchpriority="high" on the first large image. In practice it misfires on pages where the LCP is set by a page-builder hero block (Elementor, Bricks, GenerateBlocks). The image then waits behind the CSS chain and LCP slips past 4 s on mobile.

  2. Render-blocking plugins inject CSS and JS from wp_head. Yoast SEO, WooCommerce (even on non-shop pages), Contact Form 7, and Elementor all enqueue stylesheets unconditionally. A typical un-tuned WordPress install ships 8–14 <link rel="stylesheet"> tags in <head>, every one of them render-blocking. LCP cannot fire until the last one resolves.

  3. Editor-pasted images have no width or height. Classic-editor content and many shortcode-generated galleries omit the dimension attributes. The browser can’t reserve a layout box early, which delays LCP candidacy until the image decodes. This also costs CLS, but the LCP impact is direct: the image is not counted as a paint until it has a known size.

Spot the responsible image

Before changing anything, get the baseline number and the attribution. The attribution — which element is the LCP — decides what you fix.

  • Run PageSpeed Insights on the affected URL: https://pagespeed.web.dev/analysis?url=<URL>. Read the Largest Contentful Paint element box in the Diagnostics section. It names the element selector and shows the timing breakdown (TTFB, resource load delay, resource load duration, element render delay).
  • Open Chrome DevTools → Performance panel → record a trace on the same URL with mobile throttling (Slow 4G + 4× CPU slowdown). Stop the recording, find the LCP marker on the Timings track, click it, and read the Related Node in the summary panel. Confirm it matches the element you think the hero is.
  • For repeatable measurement in CI or before/after comparison: npx lighthouse <URL> --only-categories=performance --form-factor=mobile.
  • WordPress Site Health (Tools → Site Health → Status) flags some upstream causes — outdated plugins, missing PHP modules — but does not measure LCP. Pair it with PSI for the actual number.

Output you’re hunting for: a baseline LCP value and a named element. If the named element is an <img>, the fix is image + preload + CSS. If it’s a text block (H1), the fix is the CSS chain and font loading.

Step 2: Inline above-the-fold CSS with prioritize_critical_css

ModPageSpeed runs as an nginx module (or Apache module, or — for ASP.NET Core — a NuGet middleware) in front of WordPress. It rewrites HTML on the way out and serves optimized image variants from a shared cache. The filters that move LCP on WordPress:

  • prioritize_critical_css — inlines the above-the-fold CSS rules into the document <head> and defers the rest. This kills the multi-stylesheet <head> chain that failure mode #2 creates. The extractor is heuristic, not headless-browser-based, so it runs in single-digit milliseconds per page; see Critical CSS without a headless browser for the algorithm.
  • recompress_images + convert_jpeg_to_webp — shrinks the hero JPEG by 30–60% with zero theme changes, then transcodes to WebP for browsers that advertise support. The variant is served from the cache on subsequent requests at HIT speed.
  • inline_preview_images — for phone-camera-grade JPEGs that still cost time even after recompression, this filter ships a sub-1 KB low-quality image placeholder inline in the HTML. The user sees something in under 100 ms while the full image continues loading.

The case for fixing this at the server layer is operational. Fighting the plugin and theme ecosystem one update at a time is a rolling cost; a rewriter in front of the HTML applies the fix uniformly to every page — including the ones the marketing team publishes tomorrow.

Minimal nginx config to address the WordPress failure modes above:

pagespeed on;
pagespeed FileCachePath /var/cache/ngx_pagespeed;
pagespeed RewriteLevel CoreFilters;
pagespeed EnableFilters prioritize_critical_css;
pagespeed EnableFilters convert_jpeg_to_webp;
pagespeed EnableFilters inline_preview_images;
pagespeed EnableFilters hint_preload_subresources;

After enabling, re-run PSI. The LCP attribution should change — the element render delay drops as critical CSS inlines, and the resource load duration drops as the WebP variant is served. If attribution stays on the same image, see the “When this doesn’t work” section.

WordPress-side adjustments

What you can do inside WordPress to stack additional wins without ModPageSpeed:

  • In functions.php, dequeue WooCommerce styles on non-shop pages: if ( ! is_woocommerce() ) wp_dequeue_style( 'woocommerce-general' );. Same pattern for Yoast SEO assets on non-content templates.
  • Add an explicit <link rel="preload" as="image" fetchpriority="high" href="<hero-url>"> in the theme’s header.php for known hero URLs. Page builders usually expose a hook for the hero image URL.
  • Set loading="eager" on the LCP image and loading="lazy" on everything else. WordPress’s auto-detection gets this wrong on roughly 20% of templates — fix it in the theme.
  • On Elementor: test with “Improved Asset Loading” toggled both ways. Counter-intuitively it sometimes bundles CSS in a way that defers above-the-fold rules; the right setting depends on your template.
  • Use a blocks-based theme (Twenty Twenty-Five) where you can. Page-builder wrapper divs add layout passes that block paint compared to native block markup.

Bullets are imperatives — apply them, then re-measure.

Confirming the LCP moved

A four-point checklist confirms the fix landed:

  1. Re-run PSI on the same URL. The LCP element timing breakdown should show smaller element render delay and resource load duration.
  2. DevTools → Performance panel → record again under the same throttling profile. The previously attributed element either has a smaller LCP marker or a different element has become the LCP. Either is progress.
  3. Open the page with ?PageSpeedFilters=+debug (or ?ModPagespeedFilters=+debug on Apache) — the response includes HTML comments showing which filters ran and which images were rewritten. Confirm the hero image is in the rewritten set.
  4. After 28 days, check Search Console → Core Web Vitals report. The URL group should move from “Needs improvement” to “Good”. Watch the field number, not just lab — lab improvements that don’t show up in CrUX after 28 days are usually attribution mismatches, not real regressions.

Configuration cheat sheet

# nginx — minimal config to address LCP on WordPress
pagespeed on;
pagespeed FileCachePath /var/cache/ngx_pagespeed;
pagespeed RewriteLevel CoreFilters;
pagespeed EnableFilters prioritize_critical_css;
pagespeed EnableFilters recompress_images;
pagespeed EnableFilters convert_jpeg_to_webp;
pagespeed EnableFilters inline_preview_images;
pagespeed EnableFilters hint_preload_subresources;
# Tuning: recompression quality for photographic content
pagespeed ImageRecompressionQuality 82;

For Apache:

ModPagespeed on
ModPagespeedFileCachePath /var/cache/mod_pagespeed
ModPagespeedRewriteLevel CoreFilters
ModPagespeedEnableFilters prioritize_critical_css
ModPagespeedEnableFilters recompress_images
ModPagespeedEnableFilters convert_jpeg_to_webp
ModPagespeedEnableFilters inline_preview_images
ModPagespeedEnableFilters hint_preload_subresources
ModPagespeedImageRecompressionQuality 82

The full directive reference lives in the filter reference.

When this doesn’t work

Cases where ModPageSpeed alone isn’t enough on WordPress:

  • The hero is rendered by JavaScript after page load. Some page builders (especially React-based heroes in Bricks or Breakdance) inject the LCP image via JS after the initial HTML response. ModPageSpeed rewrites the static HTML; it cannot rewrite content that doesn’t exist until the browser executes JS. Fix: move the hero into the server-rendered template, or hard-code a <link rel="preload"> for the hero URL.
  • TTFB is the long pole. If PSI shows time-to-first-byte over 1 s, no amount of HTML rewriting will get LCP under 2.5 s — the browser is already 1 s in when the first byte arrives. Fix: page cache (LiteSpeed, WP Super Cache, or Varnish in front of nginx), database query tuning, or upgrade the hosting plan.
  • The LCP is a third-party embed. Lazy-loaded YouTube embeds and CMP-injected video posters often become the LCP element on landing pages. ModPageSpeed cannot rewrite a third-party iframe’s contents. Fix: use a <facade> pattern (a static thumbnail that replaces itself with the iframe on click) so the LCP is your own image, not a third-party load.

ModPageSpeed runs as an nginx or Apache module; a 14-day trial starts from /pagespeed_global_admin (card-at-start via FastSpring). See license terms.

Read next