Largest Contentful Paint measures how long a visitor waits before the biggest visible thing on the page appears, and on a small business website that thing is almost always the hero image. If your LCP is poor, you probably do not have a broad performance problem. You have one image, loaded in the wrong order, at the wrong size.
Key takeaways
- Find the LCP element first. Fixing performance before you know what is slow wastes the effort.
- The hero image is the culprit roughly nine times out of ten on local service sites.
- Four fixes cover most of the gain: right-size the file, use a modern format, preload it, and never lazy load it.
- 2.5 seconds is the threshold Google uses for a good rating, measured on real visitors, not your laptop.
- Field data beats lab data. A green Lighthouse score with red Search Console data means the lab test is wrong about your audience.
What is Largest Contentful Paint, in plain terms?
LCP is the moment the largest element in the visible area finishes rendering. That is usually a hero image, sometimes a large block of heading text, occasionally a video poster frame.
It matters because it is the closest single number to "how long until this page looked ready." Total load time counts things the visitor never notices. LCP counts the wait they actually feel. Google publishes the thresholds and measurement details in its Core Web Vitals documentation: 2.5 seconds or under is good, 2.5 to 4 seconds needs improvement, over 4 seconds is poor.
The stakes for a local business are straightforward. Roughly 53% of mobile visits are abandoned when a page takes longer than three seconds, and mobile is where most local service searches happen.
How do I find out what my LCP element actually is?
Do this before changing anything. Open the page in Chrome, press F12, go to the Lighthouse tab, and run a mobile audit. In the results, expand the Largest Contentful Paint entry and it names the exact element.
Two things surprise people at this step:
- The LCP element is often not what the designer considers the hero. A background image behind the heading frequently wins.
- On pages without a big image, the LCP element is a heading, and the fix is a font problem rather than an image problem.
Run the audit on the pages that matter, which for a service business means the home page and the top two or three service pages. Do not audit the whole site. The pages nobody lands on do not need the attention.
Fix one: is the image far bigger than it is displayed?
This is the single most common cause and the easiest to fix. A photo taken on a phone is around 4,000 pixels wide. Displayed in a hero at 1,600 pixels, it is carrying four times the data it needs.
The rule: the file should be roughly the widest size it will ever be displayed at, multiplied by two for high-density screens, and no more. For a full-width hero, that usually means 1,600 to 2,000 pixels wide, not 4,000.
| Typical hero source | File size | After right-sizing and WebP |
|---|---|---|
| Phone photo, 4032px, JPEG | 3 to 6 MB | 120 to 250 KB |
| Stock download, 2400px, JPEG | 800 KB to 1.5 MB | 90 to 180 KB |
| Screenshot, 1920px, PNG | 1 to 3 MB | 60 to 150 KB |
Those ranges are what right-sizing plus format conversion typically achieves on real sites. Your numbers will vary with the photo, but the order of magnitude holds: most hero images can lose 80% of their weight without a visible difference.
Fix two: are you serving a modern image format?
WebP and AVIF compress substantially better than JPEG and PNG at the same visual quality. Browser support for WebP is universal in anything current, and AVIF is close.
If your site is on a modern framework, this is usually automatic and worth verifying rather than assuming. If you are on an older platform, a plugin or a one-time batch conversion gets you most of the way. Convert the hero images first and stop there if time is short, because the hero is the one being measured.
PNG deserves a specific warning. It is the right format for logos and screenshots with sharp edges, and the wrong format for photographs. A photographic hero saved as PNG is often ten times larger than it needs to be.
Fix three: is the browser finding the image late?
The browser cannot start downloading the hero until it discovers it. If the image is referenced in CSS as a background, or injected by JavaScript, discovery happens late and the download starts late.
Two mechanical fixes:
- Reference the hero as a real image element in the HTML, not as a CSS background, so the browser's preload scanner finds it in the first pass.
- Add a preload hint for the hero image so it is requested at the highest priority, ahead of scripts and fonts.
This one is invisible to the eye and often worth half a second on its own. It also costs nothing in design terms, which is rare in performance work.
Fix four: are you lazy loading the hero?
If you are, stop. This is the most common self-inflicted LCP problem.
Lazy loading tells the browser not to fetch an image until it is nearly in view. Applied to below-the-fold images, it is genuinely useful. Applied to the hero, it delays the exact element being measured, and it usually happens because someone enabled "lazy load all images" as a blanket setting.
Check the hero for a loading="lazy" attribute and remove it. Keep it on everything below the fold.
What about fonts, scripts, and hosting?
Once the image is handled, these are the remaining contributors, roughly in order of how often they matter:
- Web fonts blocking the heading from rendering. Limit yourself to two families and only the weights you use, and let text display in a fallback font while the real one loads rather than sitting invisible.
- Third-party scripts. Chat widgets, review carousels, tag managers, and heat-map tools all compete for bandwidth with the hero. Audit what is loading and remove what nobody looks at.
- Server response time. Worth checking, rarely the main problem on a small site. If your host takes over 600ms to send the first byte, it is worth addressing, but migrating hosts to fix an image problem is an expensive detour.
- Render-blocking CSS. A real issue on older theme-based sites carrying stylesheets for features the page does not use.
The pattern across all four is the same: a small business site is usually slow because it accumulated things, not because it was built badly. This is why we treat bloat and unused plugins as the villain rather than any particular platform, and why how we build starts with what a page actually needs to load.
Why does Search Console disagree with my Lighthouse score?
Because they measure different things and only one of them reflects your customers.
Lighthouse is a lab test: one run, simulated network, your machine. Search Console reports the Chrome User Experience Report, which is field data from real Chrome visitors on real devices over a rolling 28-day window. When the two disagree, the field data is describing your actual audience, often on older phones and worse connections than yours.
Practical consequence: use Lighthouse to confirm a fix worked immediately, and Search Console to confirm it worked for real people a few weeks later. Do not conclude a fix failed because Search Console has not moved after a week; the window has not rolled over yet.
What is not worth chasing?
Audit tools produce long lists, and most items on them will not change what a visitor feels. Deprioritise:
- Shaving kilobytes off already-small assets
- Perfect scores on metrics your page does not have a problem with
- Micro-optimising pages that get no traffic
- Rebuilding on a new platform because a report showed red
Fix the hero image, the loading order, the fonts, and the third-party scripts. That is the bulk of the available gain on almost every local service site. If the site is genuinely too heavy to rescue, that is a different conversation, and the signs are usually structural rather than a slow score.
What to do next
Run a mobile Lighthouse audit on your home page and your best service page, note the named LCP element, and check it against the four fixes above in order. Most sites gain a second or more from the image alone.
If you want the whole thing handled rather than diagnosed, tell us what you are working with and we will tell you whether it is a tune-up or a rebuild.
