Slow-loading pages and a poor Largest Contentful Paint

Largest Contentful Paint (LCP) is the time until the biggest image or block of text in view has rendered; web.dev calls 2.5 seconds or less good. To shorten it, make the server answer quickly with caching or a CDN, load the main image early instead of lazy-loading it, keep that image small, and stop scripts and stylesheets in the page's head from holding up the first paint.

Last updated 29 October 2026, when every step was checked against the vendor's documentation.

Why it matters

Largest Contentful Paint is the time from the start of loading until the largest image, text block or video in view has rendered. web.dev calls 2.5 seconds or less good and more than 4 seconds poor, judged at the 75th percentile of page loads, on phones and desktops separately.

LCP is one of the three Core Web Vitals. Google says "Core Web Vitals are used by our ranking systems", and in the same answer that good scores do not guarantee a top position. It also says there is no single page experience signal, that its core ranking systems look at a variety of signals, and that it shows the most relevant content even when the page experience is poor. A faster page is better for the people who visit it; it does not make up for a page that does not answer the search.

web.dev splits LCP into four parts that add up to the whole: the time to the first byte of the HTML, the delay before the main image starts to download, the download itself, and the delay before it is drawn. Our findings sit on those parts: a slow server response on the first, a lazy-loaded first image on the second, large images on the third (the large images guide covers those) and render-blocking files on the fourth. web.dev warns that speeding up one part can simply move the wait to another, so look at all four.

Time to first byte is not a Core Web Vital, but web.dev says a high one can make a 2.5-second LCP hard or impossible, and gives 0.8 seconds or less as a rough guide. SERPCompass flags a page when the server takes more than 1.5 seconds to start answering our crawler. That threshold is ours, not Google's.

loading="lazy" tells the browser to wait until an image is near the screen before fetching it, and web.dev's advice is to never lazy-load the LCP image, because that always delays it. A script in the <head> without async or defer, and the stylesheets linked there, must arrive before the browser paints anything, so each one adds to the wait.

The audit findings this guide fixes: Poor Largest Contentful Paint (over 4 s, lab); Slow server response (over 1.5 s); First content image is lazy-loaded (likely above the fold); Many render-blocking resources.

Find every page with this problem

Run the free scan on your domain. It opens a sample of your pages in our own headless Chromium: the start page, then one page of each template, then the most-linked pages, up to 10 in the free scan (25 or 50 in larger workspace audits). Each page loads once, with an empty cache, under simulated mobile conditions modelled on Lighthouse's mobile test: a 412 by 823 pixel screen, a slow 4G connection (150 ms round trip, 1.6 Mbps down) and a processor slowed four times. A page whose LCP is over 4 seconds is flagged; a page still loading after 45 seconds is reported with the LCP seen so far, as a lower bound. These are lab measurements from our browser, not field data from your visitors: Search Console's Core Web Vitals report shows field data, from the Chrome UX Report. On every page it crawls, the scan also records how long your server took to start answering our crawler, from sending the request (connection included) to the response headers, and flags more than 1.5 seconds; whether the first image of the main content (outside the header, navigation, sidebars and footer) carries loading="lazy", which is a guess from the HTML, since it does not know which element was measured as the LCP; and how many render-blocking files the <head> holds: scripts with a src and neither async nor defer (module scripts and JSON blocks aside), plus stylesheets other than print or disabled ones. More than four is flagged. The scan shows your most urgent findings with the number of pages each affects; the Gap Report and a SERPCompass workspace list the pages, with the LCP measured on each.

Scan my site free

How to fix it on your platform

Interaction to Next Paint and long JavaScript tasks, which our Total Blocking Time finding measures, are not covered here.

WordPress

Keep WordPress up to date. Since version 6.3 it leaves loading="lazy" off the first images it renders, three by default (in classic themes, images before the main content count too), and adds fetchpriority="high" to the first large image, the one most likely to be the LCP element.
If the audit still names a lazy-loaded first image, find out what put the attribute there: images earlier in the page using up WordPress's three, a lazy-loading or optimization plugin's settings, or your theme. WordPress asks themes to print a custom header image with get_header_image_tag(), so that WordPress counts it.
To cut server response time, WordPress's optimization guide suggests a caching plugin, which serves posts and pages as static files, deactivating and deleting plugins you do not need, a CDN, and more capable hosting when the server is the limit.
If you build the theme or a plugin, load scripts the first paint does not need with wp_enqueue_script() and 'strategy' => 'defer' in its $args array (WordPress 6.3 and later) rather than as a blocking script in the head. WordPress may still print it blocking when a dependency or an inline script added after it needs that.

Sources: Image performance enhancements in WordPress 6.3 (Make WordPress Core); Optimization (WordPress advanced administration handbook); wp_enqueue_script() (WordPress developer reference); Registering scripts with async and defer attributes in WordPress 6.3 (Make WordPress Core).

Shopify

Review your installed apps and remove those that are not essential. Uninstalling an app does not always remove its code from your theme: ask the app's developer how to remove it fully.
Audit your tag manager and remove unused or low-value tags.
Use an up-to-date theme that is optimized for performance, and limit the number of sections on page templates.
In theme code, load the images visible in the first screen eagerly and give the LCP image fetchpriority="high". Use an <img>, not a CSS background image, for the hero, so the browser finds it early.
With the image_tag filter, Shopify sets loading="lazy" on images in sections further down the page unless you pass preload: true. Use preload sparingly, for images above the fold.
Add defer to scripts that are not critical, and remove or defer app scripts that block the page before any content is shown.

Sources: Improving your online store performance (Shopify Help Center); Performance best practices for Shopify themes (Shopify.dev); image_tag (Shopify Liquid reference).

Wix

Go to Site Speed in your site's dashboard.
Read the Real visitor experience section: it shows your Core Web Vitals, LCP included, from your actual visitors, once the site has had 10 or more sessions in the last 7 days. The Google PageSpeed simulation section shows Lighthouse scores measured in a lab, like ours.
Work through the tips the dashboard gives for each Core Web Vital.

Sources: Understanding your Site Speed dashboard (Wix Help Center); Improving your site speed (Wix Help Center).

Plain HTML

Remove loading="lazy" from the image people see first and add fetchpriority="high" to it. Keep loading="lazy" for images further down the page, and give fetchpriority="high" to one image, not many.
Put the main image in the HTML as an <img>, not only in a stylesheet or a script, so the browser finds it at once. If it has to stay a CSS background, preload it with <link rel="preload" as="image" fetchpriority="high"> in the head.
Add defer to the scripts in the <head> that the first paint does not need; deferred scripts run in order once the page is parsed. Use async only for independent scripts, such as analytics, because async scripts run in no fixed order. Delete scripts and stylesheets no page uses.
Keep the stylesheets in the head few and small. Inlining the CSS the first screen needs and loading the rest later also works, but Chrome's documentation calls it an advanced technique most sites can do without.
Speed up the server's first response: cache pages on the server or at a CDN's edge servers close to your visitors, avoid redirects on the way to the page, above all those within your own site, and make sure your hosting can handle your traffic.

Sources: Optimize Largest Contentful Paint (web.dev); Browser-level image lazy loading for the web (web.dev); Optimize resource loading with the Fetch Priority API (web.dev); The Image Embed element (MDN); The script element (MDN); Render-blocking requests (Chrome for Developers); Eliminate render-blocking resources (Chrome for Developers); Optimize Time to First Byte (web.dev).

Examples

Bad
```
<img src="/images/hero.jpg" loading="lazy" alt="Fresh bread on the counter">
```
The first image on the page, lazy-loaded: the browser waits until it knows the image is on screen before fetching it.

Good

<img src="/images/hero-1200.webp" width="1200" height="675"
     fetchpriority="high" alt="Fresh bread on the counter">

Fetched straight away and at high priority. Images further down keep loading="lazy".

Bad

<head>
  <link rel="stylesheet" href="/css/theme.css">
  <link rel="stylesheet" href="/css/slider.css">
  <script src="/js/jquery.js"></script>
  <script src="/js/slider.js"></script>
  <script src="/js/chat-widget.js"></script>
</head>

Five render-blocking files before anything is painted; the audit flags more than four.

Good

<head>
  <link rel="stylesheet" href="/css/theme.css">
  <link rel="stylesheet" href="/css/slider.css">
  <script src="/js/jquery.js" defer></script>
  <script src="/js/slider.js" defer></script>
  <script src="/js/chat-widget.js" async></script>
</head>

Two blocking stylesheets left. defer runs the scripts in order after parsing, so slider.js still finds jQuery; async suits the chat widget, which nothing depends on.

Common mistakes

Turning on lazy loading for every image in a theme or plugin setting, the hero image included.
Giving fetchpriority="high" to many images. web.dev says it stops helping once more than one or two images have it.
Making a script async when other scripts depend on it: async scripts run as soon as they arrive, in no fixed order. Likewise, an inline script that calls a deferred library runs before the library has loaded.
Shrinking the hero image while a render-blocking script still holds the first paint. web.dev's example of a fix that moves the wait instead of removing it.
Testing only on your own computer and connection. Our lab and Lighthouse's mobile test slow down the network and the processor, and Google's data looks at phones and desktops separately.
Expecting Search Console to show the fix the next day. Its Core Web Vitals report uses real visits collected over time, and its validation of a fix runs for 28 days.

Questions and answers

What is a good Largest Contentful Paint?

web.dev calls 2.5 seconds or less good, up to 4 seconds needs improvement, and more than 4 seconds poor, measured at the 75th percentile of page loads on phones and desktops separately. Search Console uses the same bands. SERPCompass flags pages over 4 seconds in its lab test, so a page we do not flag can still need work to reach good.

Why do SERPCompass, PageSpeed Insights and Search Console show different LCP?

They measure different visits. SERPCompass and the lab part of PageSpeed Insights load the page once in a test browser under simulated mobile conditions. Search Console and the field part of PageSpeed Insights report real Chrome users over time, through the Chrome UX Report. Devices, networks, caches and locations differ, so the numbers differ. Use a lab test to check a fix quickly and the field data to judge it.

Will a better LCP improve my rankings?

Google says Core Web Vitals are used by its ranking systems, but that there is no single page experience signal, that its core ranking systems look at a variety of signals, and that it shows the most relevant content even when the page experience is poor. Good scores do not guarantee a top position. We make no promise of a ranking change; a faster page is better for the people who visit it.

Will a CDN fix a slow server response?

It often helps. web.dev says a CDN serves content from servers closer to your visitors and can cache pages on those edge servers. A cache only hides a slow server while the cached copy is used, so a page that cannot be cached still waits for your server. If the server itself is slow, page caching, fewer plugins or more capable hosting deal with the cause.

Should I stop lazy-loading images?

Only for the images people see as the page opens. web.dev advises loading the images in the first screen eagerly and using lazy loading for images outside it, so they are fetched only when a visitor scrolls near them. Never lazy-load the image most likely to be the Largest Contentful Paint.

Images that are too large or in an older format
Files sent uncompressed, without a cache lifetime or unminified
Layout shift: content that jumps while the page loads
All guides
Free tools: checks for robots.txt and llms.txt that need no account.

Sources

Every step above was checked against these documents on 29 October 2026. Vendors change their menus; if a step no longer matches, the vendor's page is the authority.

Start with a free scan of your site.

Two to five minutes, no account. You get your three most urgent findings, and the exact count of everything else.