Which element on your page is the LCP element
LCP doesn't measure your whole page. It measures one element: the largest thing visible inside the viewport when the page paints. Everything below the fold is irrelevant to the score, which surprises people who've spent a week compressing footer images.
Chrome picks it from a short list: an <img>, an SVG <image>, a video poster frame, a block of text, or anything carrying a CSS background-image. On a D2C homepage that's the hero banner. On a blog post it's the H1 or the featured image.
- PageSpeed Insights names the element outright under the LCP diagnostic.
- Chrome DevTools → Performance — record a load; the LCP marker points straight at the node in the DOM.
- Search Console → Core Web Vitals groups failing URLs, so you learn it's every product page, not the one you tested.
LCP is four numbers wearing one coat
This is the part most people skip, and it's why so much speed work fails. A 4.8-second LCP tells you nothing about what to fix. Break it into its four parts — Google's own breakdown — and the culprit usually announces itself in ten minutes.
- Google's guidance: TTFB should eat no more than roughly 40% of your LCP budget, and load delay should be near zero. If TTFB alone is 1.8 seconds you have 0.7 left for everything else, and compression won't get you there.
| Sub-part | What's happening | The usual fix |
|---|---|---|
| Time to First Byte | Your server thinking, plus the round trip to wherever it physically lives. | Full-page caching, a CDN with Indian edge nodes, a better host. |
| Resource load delay | The gap between the HTML arriving and the browser deciding to fetch the hero image. | Preload it, add fetchpriority="high", stop lazy-loading it. |
| Resource load duration | The image actually downloading over the visitor's connection. | AVIF or WebP, correct dimensions, honest compression. |
| Element render delay | The image has arrived and nothing is painted yet. | Cut render-blocking CSS and JS. Fix font loading. |
The hero banner tax
Here's the failure we find most often in Indian audits: a hero exported at 2,400px wide, saved as a 1.4MB JPEG at quality 95, and served identically to a ₹9,000 Android phone on 4G in Indore. The design review went beautifully. The metric is on fire.
- Serve the right size.
srcsetandsizes, so a 390px phone downloads a 390px image instead of scaling the desktop original. - Use a modern format. AVIF and WebP are meaningfully smaller than JPEG at the same perceived quality. How much depends on the image, so test rather than assume.
- Never lazy-load the LCP image.
loading="lazy"on a hero tells the browser to deprioritise the exact thing being measured. - Add `fetchpriority="high"` to the hero
<img>, and preload it if it's discovered late — CSS background images and slider scripts both do that. - Kill the carousel. A rotating hero downloads four full-size images to show one, and it's usually your biggest layout shift source as well.
TTFB, hosting and where your server actually sits
The speed of light isn't negotiable. If your site runs on a shared host in Arizona and your buyers are in Ahmedabad, every request pays a round trip across the planet before your server has thought about anything.
Two fixes, in order. Cache aggressively so most requests never reach the origin, then put a CDN in front so cached responses come from an edge node in Mumbai or Chennai. Managed platforms like Vercel do this by default; a ₹300-a-month cPanel plan does not.
Treat 800ms as your TTFB ceiling — that's Google's own "good" threshold — and anything past 1.5 seconds as a hosting decision rather than an SEO task. Pages that hit a database on every request skip most caching by design, and those need real cache rules or server rendering, not a fourth speed plugin. That's Core Web Vitals work, not content work.