Largest Contentful Paint (LCP) is one of the Core Web Vitals metrics that measures when the most meaningful piece of content on a page becomes visible. On modern sites, that “largest” element is usually an image or other media asset, which is why LCP often gets reduced to one familiar directive: compress images.
But as Amrik Malhans explains in his recent Web Performance Calendar contribution, optimizing LCP isn’t just shrinking file sizes. LCP is the outcome of multiple phases in the loading and rendering pipeline. If you don’t know which phase is dominating your timeline, you can spend weeks shipping “performance improvements” that don’t move real-user LCP.
The key idea is simple: LCP isn’t a single number. It can be broken down into sub-parts that tell you exactly where time is being spent. Once you identify the dominant sub-part, the next step becomes clearer, and you can stop guessing.
Amrik focuses specifically on image-based LCP candidates, and he grounds the discussion in real-world context: most LCP elements are images, especially on mobile.
He breaks LCP into four sub-parts:
- Time to First Byte (TTFB): how long it takes to receive the first byte of HTML
- Resource Load Delay: how long it takes before the browser even starts requesting the LCP resource
- Resource Load Duration: how long the LCP resource takes to download once requested
- Element Render Delay: how long it takes to paint the LCP element after the bytes arrive
The practical value is in what each dominant sub-part usually means and what tends to help first. For example:
- If TTFB dominates, the bottleneck is often origin, CDN, or server processing time. Image tweaks won’t save you.
- If Resource Load Delay dominates, the browser is discovering the LCP asset too late. This is where early discovery signals (like preload and priority hints) and avoiding “hidden” LCP patterns (CSS background images, JavaScript initiation, lazy loading the hero) matter.
- If Resource Load Duration dominates, you’re in bytes and throughput land. Modern formats, correct responsive delivery, and CDN image optimization become the levers that move the needle.
- If Element Render Delay dominates, rendering is blocked after the download completes. Blocking JS/CSS, hidden-page patterns from testing or personalization, and late DOM insertion can erase all the wins you made earlier.
Amrik also lays out a helpful mental model of the browser’s critical rendering path and then connects the theory to practice with how to identify these sub-parts in Chrome DevTools and in real user monitoring (RUM), where the sub-parts are derived by correlating multiple timing entries.
If you want a clearer way to diagnose slow LCP on real sites, this is the ideal deep dive: specific, actionable, and structured around how browsers actually load pages.
Read “The Anatomy of LCP: A Deep Dive into Sub-Parts” on Web Performance Calendar to learn more.
