Fix Slow LCP Image Issues on Mobile
LCP is usually a hero image. Format, dimensions, preload and fetchpriority, in the order that actually moves the number.
Fix a slow Largest Contentful Paint (LCP) image in 4 steps: resize it to its display size, convert it to WebP or AVIF, preload it, and set fetchpriority to high. The first 2 steps deliver most of the improvement and require no change to your page markup.
On most pages the largest contentful paint element is a single hero image, which means LCP is really a question about one file rather than about your whole site. Fixing that one file usually moves the measurement more than any other optimisation available.
What LCP measures
LCP records how long the largest visible element takes to render, measured from when the page starts loading. Google treats 2.5 seconds or less as good, 2.5 to 4 seconds as needing improvement, and over 4 seconds as poor.
The measured element is usually an image, occasionally a block of heading text, and it is always something visible without scrolling. The element can change between devices, since a hero image that dominates a desktop layout may sit below the fold on a phone.
Finding the element responsible
Run Lighthouse and read the Largest Contentful Paint element entry, which names the exact element being measured. Guessing wastes time, because the element is frequently not the one people assume.
Check on mobile as well as desktop, since the layouts differ and so does the answer. Field data from real visitors is more reliable than a single laboratory run, because network conditions vary far more in the wild than in a test. Where the 2 disagree, trust the field data and use the laboratory run for diagnosis.
Fix the image in order of impact
To improve LCP on an image, work through these 6 steps in order.
- Resize the image to the largest size it will ever display, doubled for high density screens.
- Convert it to WebP, or to AVIF if the image is large and photographic.
- Compress to a target under 200 KB for a hero image, which is achievable at full width on most designs.
- Add width and height attributes so the browser reserves space and no layout shift occurs.
- Preload the image in the page head so the browser starts fetching it immediately.
- Set fetchpriority to high on the image element, which tells the browser this file matters most.
Steps 1 and 2 usually deliver the bulk of the improvement, and they are the 2 that do not require touching the page markup at all.
Why resizing beats compressing
Dimensions control most of a file size, so resizing removes more weight than any quality setting. A 4000 pixel photograph displayed at 1200 pixels carries 11 times more pixel data than the page can show.
| Hero image | Dimensions | Format | File size | Typical LCP |
|---|---|---|---|---|
| Straight from camera | 4032 x 3024 | JPEG quality 90 | 4.2 MB | Over 6 seconds |
| Compressed only | 4032 x 3024 | JPEG quality 70 | 1.4 MB | About 3 seconds |
| Resized only | 1920 x 1440 | JPEG quality 90 | 620 KB | About 2 seconds |
| Resized and converted | 1920 x 1440 | WebP quality 80 | 190 KB | Under 1.5 seconds |
The third row shows why resizing comes first. Resizing alone beat compressing alone, and the combination beat both. The figures vary by image and connection, while the ordering holds consistently.
Preload and fetchpriority
Preloading tells the browser to fetch the hero image before it has finished parsing the page, which typically saves 200 to 500 milliseconds. The setting matters because browsers discover images late in the parsing process.
Preload one image only. Preloading several removes the benefit, since the browser then divides its attention exactly as it would have anyway. Setting fetchpriority to high achieves a similar result with less markup and is frequently enough on its own for an image already present in the initial HTML.
Mistakes that make LCP worse
- Lazy loading the hero image. Lazy loading delays the very file you want first. Apply it below the fold only.
- Loading the hero through JavaScript. A script inserted image cannot start downloading until the script runs.
- Using a CSS background image. Background images are discovered later than img elements and cannot be prioritised as easily.
- Preloading several images. Competing priorities remove the advantage entirely.
- Omitting width and height. Layout shift damages a separate measurement while this one improves.
When the LCP element is text
A text based LCP is usually delayed by web fonts rather than by the text itself. The browser has the words immediately and waits for a font file before painting them.
Set font-display to swap so text renders in a fallback font and switches when the web font arrives. Preload the single most important font file, and subset the font to the characters your pages actually use, which frequently reduces a font from 200 KB to under 30 KB. Serving fonts from your own domain removes an additional connection to a third party.
Server response time sets the floor
LCP cannot be faster than the time your server takes to return the first byte, so a slow server caps every other improvement. Aim for under 600 milliseconds to the first byte.
Check that figure before optimising images, because a 2 second server response makes a 2.5 second LCP target impossible whatever you do to the files. Caching, a faster host or a content delivery network address that layer. Image work then improves what remains rather than fighting a limit set elsewhere.
Third party scripts delay the image too
Analytics, consent banners, chat widgets and advertising scripts compete with your hero image for bandwidth and processing time. A perfectly optimised image still renders late when 12 scripts load ahead of it.
Consent banners are the most damaging, because many block rendering until the visitor chooses. Load third party scripts with the defer or async attribute so they do not hold up the page, and audit how many are genuinely needed. Removing 3 unused tracking scripts frequently improves LCP more than a further round of image compression.
Testing the change properly
Test in a private window with extensions disabled, and run the measurement 3 times rather than trusting a single result. Scores vary between runs by a noticeable margin.
Verify the browser actually received the smaller file. Open developer tools, switch to the Network tab, filter by images and reload. The transferred size and the format appear in the list. A page still serving the old file usually means a caching layer is holding the previous version rather than that the optimisation failed.
Keeping LCP fast after the fix
Set a rule for hero images rather than fixing them one at a time, because new pages reintroduce the problem. A site fixed once will regress within months if editors upload straight from a camera.
Agree a maximum width and a maximum file size for hero images, write it down, and apply it to every new page. A rule such as 1920 pixels wide and under 200 KB is easy to check and covers almost every design. Where several people publish, the written rule matters more than the technique, since the measurement reflects the worst page rather than the best one.
Preparing hero images in one pass
Process every hero image on the site together, since they share one specification and one target size. Most sites have between 10 and 100 of them across landing pages, category pages and articles.
Set the width and the KB target once, drop the images in, and every file comes back matched. Up to 500 images run per batch, entirely inside your browser on your own processor. Nothing is uploaded, so staging assets, unpublished campaign pages and client work stay on your machine while the whole library is prepared.