Skip to content

How to Fix Slow Largest Contentful Paint on a WordPress Site

Illustration of a speedometer gauge with a lightning bolt moving from slow to fast

Largest Contentful Paint (LCP) measures how long it takes the biggest visible element — usually a hero image, a heading, or a banner — to render. Google treats it as a Core Web Vital, and it’s the one WordPress sites fail most often, because plugins accumulate over time and each one adds a little more weight to the critical rendering path.

Find the actual LCP element first

Before changing anything, run the page through PageSpeed Insights or Chrome DevTools and identify exactly which element is being measured as the LCP element. Optimising the wrong thing — a below-the-fold image, say, when the real culprit is a webfont — wastes time and won’t move the score.

Unoptimised hero images are the most common cause

A hero image served at its original upload resolution, in JPEG or PNG rather than a modern format like WebP or AVIF, is the single most common LCP problem on WordPress. Resize images to the actual display size, convert to WebP, and make sure the LCP image specifically is not lazy-loaded — lazy-loading the one image the page is racing to paint first works against you.

Render-blocking CSS and JavaScript

Every plugin that adds its own stylesheet or script to the page head can block rendering until it downloads and parses. Audit what’s actually loading in the <head> and defer or remove anything that isn’t needed for the initial render — chat widgets, marketing pixels, and slider libraries are frequent offenders.

Slow server response time (TTFB)

If the server itself takes a long time to respond, nothing downstream can start rendering sooner than that. Shared hosting, an oversized PHP stack from too many active plugins, or a missing object cache on a WordPress site with a large database are common causes. A caching plugin plus a proper page cache is often the single highest-leverage fix available.

Webfonts blocking text render

A custom Google Font loaded without font-display: swap can leave text invisible until the font file arrives. Self-hosting fonts and preloading the specific weights you use, rather than fetching a whole font family from a third-party origin, removes both the extra DNS lookup and the blocking behaviour.

Third-party embeds above the fold

A YouTube embed, a review widget, or a font-loading analytics script placed above the fold can each individually push LCP past the 2.5 second threshold Google considers "good." Where possible, replace heavy embeds with a lightweight placeholder that loads the real thing on interaction.

What a fix usually looks like in practice

On most WordPress sites we see, the winning combination is: compress and correctly size the hero image, add a page cache, remove or defer two or three unused plugin scripts, and self-host the primary webfont. That combination alone typically moves LCP from the 4–6 second range down under 2.5 seconds without a full rebuild.

Our free audit measures your actual Core Web Vitals and tells you exactly which of these six causes applies to your homepage.

Check your Core Web Vitals for free

LCP is one piece of technical SEO. For the full priority list, see technical SEO for WordPress: what actually moves rankings.

← Back to all articles