When I first launched this site, the PageSpeed score was embarrassing. The biggest culprit was the hero image — a PNG I'd grabbed from a design tool without thinking about size. Fixing it taught me more about Core Web Vitals than any tutorial I'd read. Here's what actually matters.
Largest Contentful Paint measures how long it takes for the biggest visible element on the page to fully load. In most cases, that's a hero image, a large banner, or the main article image. Google considers it "good" if it happens within 2.5 seconds.
The reason Google chose this metric is that it correlates with how users perceive page speed better than raw load time does. A page can technically "load" in 1 second if all it does is show a spinner, but users experience it as slow because nothing meaningful appeared. LCP tries to measure when the page actually looks like something.
Where most sites fail: the biggest element is an image, and that image is large, unoptimized, or not prioritized correctly. The browser discovers it late, fetches it slowly, and LCP suffers.
The hero section had a PNG exported directly from Figma. It was 1.4MB. On a fast connection it loaded in about 3 seconds. On a mobile connection it was taking 6–7 seconds. PageSpeed Insights was showing LCP of 5.2 seconds and flagging it as "Poor."
I converted it to WebP at 82% quality. The file dropped to 180KB. LCP on mobile went to 1.8 seconds. Same visual quality — I couldn't tell the difference looking at them side by side.
Text renders from HTML, which loads early and fast. CSS loads early. JavaScript can be deferred. Images, especially large ones, are often discovered late in the loading process — the browser has to parse the HTML, find the image reference, then start a separate fetch request for the image file. If that file is large, it arrives late, and LCP is high.
There's also a prioritization issue. By default, browsers treat most images as lower priority than HTML, CSS, and scripts. Your hero image — the one that determines your LCP score — might be sitting in a queue behind resources that matter less. One of the most useful things I learned was the fetchpriority attribute, which I'll come back to.
File size and load time are directly connected. A smaller file arrives faster. That's the whole argument for modern image formats — not that they look better, but that they're smaller, so they arrive sooner, so LCP is lower.
Here's a rough sense of the file size differences between formats for the same image:
| Format | Relative file size | Notes |
|---|---|---|
| PNG (photo) | Largest — often 3–5× JPG | Lossless, every pixel stored. Not for photos on web. |
| JPG | Baseline | Fine for photos, but larger than WebP/AVIF. |
| WebP | ~65–75% of JPG | Better compression, nearly universal browser support. |
| AVIF | ~50–60% of JPG | Best compression, slightly lower support, slow to encode. |
The practical implication: if your LCP element is a 1MB PNG, converting it to WebP could take it to 150–200KB. That difference in download time, especially on mobile connections, directly translates to LCP improvement.
Cumulative Layout Shift (CLS) is a separate Core Web Vitals metric, but it's often caused by the same images. When a browser loads an image without knowing its dimensions in advance, it initially renders the page without reserving space for the image. When the image loads, everything shifts down to make room. That's a layout shift, and it feels jarring to users.
The fix is simple and often missed: always specify width and height on your image elements.
<!-- Bad: browser doesn't know how tall this will be --> <img src="hero.webp" alt="Hero image"> <!-- Good: browser reserves the right space immediately --> <img src="hero.webp" alt="Hero image" width="1200" height="600">
You can use CSS to make the image responsive — max-width: 100%; height: auto — while still providing the dimensions so the browser knows the aspect ratio. This is one of those fixes that takes 5 minutes and has an immediate impact on CLS.
Start by running your URL through PageSpeed Insights. Look specifically at the LCP element — it tells you what element caused the LCP score and how long it took. If it's an image and it's either large or slow, that's your target.
For the LCP image specifically, two things matter most:
Convert it to WebP. If it's currently a PNG or JPG hero image, converting to WebP is the fastest meaningful improvement. Use the PNG to WebP tool or JPG to WebP tool here — your file stays local, nothing is uploaded.
Add fetchpriority="high". This tells the browser to treat this image as high priority and fetch it early. Add it only to the LCP image — adding it to everything defeats the purpose.
<picture>
<source srcset="hero.webp" type="image/webp">
<img
src="hero.jpg"
alt="Hero image"
width="1200"
height="600"
fetchpriority="high"
>
</picture> For everything else on the page — images below the fold, article images, thumbnails — add loading="lazy". This defers their loading until the user scrolls near them, which frees up bandwidth for the LCP image to load faster.
Not directly. Google doesn't care about format by name. It cares about LCP, which is driven by file size and loading order. JPG and PNG tend to produce larger files, which leads to slower LCP, which affects rankings. The format is the cause, not the direct issue.
No — this is a common mistake. Lazy loading tells the browser to delay fetching the image, which will hurt your LCP score. Use fetchpriority="high" on the LCP image. Use loading="lazy" on everything else.
Often yes. If old posts have large unoptimized images, converting them to WebP can improve their PageSpeed scores, which can contribute to ranking improvements on those specific pages. It's not glamorous work but it's effective.
If your LCP is under 2.5 seconds and PageSpeed isn't flagging images as a problem, the impact of converting to WebP will be marginal. Focus your time elsewhere. Run the test first, optimize what it tells you to optimize.
If you ran PageSpeed Insights and have a specific LCP element that's causing problems, I'm happy to look at it with you. The contact page comes directly to me — include the URL and what PageSpeed is reporting and I'll take a look.