What Was Causing the Slow LCP
The LCP element was the hero image — a 2400×1600 JPEG served at original resolution for all screen sizes. On mobile, the browser was downloading a 3.2MB image to display it at 400px wide. The image was also not preloaded, so it started downloading only after the HTML and CSS were parsed.
The second issue: the image was in an img tag with no width/height attributes. The browser didn't know the image's dimensions until it downloaded the file, so it couldn't reserve layout space — causing both the slow LCP and a CLS hit when the image finally loaded.
The Twenty-Minute Fix
Converted the hero to use Next.js Image component with explicit width, height, and priority props. Next.js Image automatically serves WebP to browsers that support it, generates srcset for responsive sizes, and with priority set, adds a preload link tag in the document head.
Added explicit width and height attributes to reserve layout space, eliminating the CLS. The image went from 3.2MB to 180KB on mobile (WebP, sized to viewport). LCP dropped from 4.2s to 1.4s. No redesign, no architecture change — just using the right component.
Key takeaways
- The LCP image should always have the 'priority' prop in Next.js — this adds a preload hint so the browser fetches it immediately instead of after parsing the full HTML
- Specify explicit width and height on all images to prevent CLS — the browser reserves the exact space before the image loads
- Next.js Image automatically generates WebP variants and responsive srcset — a 3MB JPEG often becomes a 150KB WebP without any manual conversion
Conclusion
Most LCP fixes are not sophisticated. They're applying the tools that already exist in the framework — correctly. Twenty minutes of implementation for a 3x improvement in page load speed is one of the best ROI fixes in web performance.
Enjoyed this article?
Vivek Kumar Singh
Technical Expert · Full Stack Cloud Engineer · Tokyo, Japan
