Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) is a Core Web Vital that measures how long it takes for the largest visible content element to render on a page. The target is under 2.5 seconds on the 75th percentile of page loads; anything over 4 seconds is ‘poor’ and hurts rankings. LCP is the most commonly-flagged Core Web Vital because most pages have a large hero image or headline whose loading is a critical user-experience moment.
What counts as the ‘largest contentful element’
LCP tracks the rendering of the largest element in the initial viewport. Usually one of:
Hero images. The first large image on a page. Common LCP element on content-heavy and e-commerce sites.
Headline text blocks. Large H1 or hero copy. Common on marketing pages without large imagery.
Video poster frames. The thumbnail for an embedded video.
Background images (if loaded as images). CSS background images count if they’re the largest visible element.
What slows down LCP
Five common causes:
Unoptimised images. Large file sizes, wrong format (PNG where WebP would do), no responsive images.
Slow server response (TTFB). The browser can’t render what it hasn’t received. Server-side delays propagate to LCP.
Render-blocking resources. CSS and synchronous JavaScript in the head block rendering until they’re loaded.
Client-side rendering for above-the-fold content. SPAs that render hero content via JavaScript delay LCP until after the JS executes.
CDN misses or slow CDN. Hero images not served from CDN, or CDN with high latency, extend LCP.
How to improve LCP
Seven standard optimisations:
Image optimisation. Convert to WebP/AVIF, size appropriately, serve responsive variants via srcset.
Preload the LCP element. <link rel="preload"> for hero images. Tells the browser to start loading before standard discovery.
CDN for static assets. Hero images, CSS, fonts served from geographically-close CDN nodes.
Server-side rendering (SSR) or static generation. Don’t wait for client-side JavaScript to render above-the-fold content.
Critical CSS inlined. Styles needed for above-the-fold content inlined in the head; rest loaded async.
HTTP/2 or HTTP/3. Multiplexed connections reduce round-trip delays.
Minimise render-blocking JavaScript. Move non-essential scripts to defer or async.
Measuring LCP
Three measurement sources:
Chrome DevTools Performance panel. Detailed waterfall of what loads when. LCP element highlighted.
PageSpeed Insights. Both lab and field LCP scores, plus specific recommendations.
Real User Monitoring (RUM). LCP from actual users at scale. What Google uses for ranking.
LCP on content pages versus commerce pages
Three patterns:
Content pages. Usually text-heavy with one hero image. LCP often the hero image. Typical target: 1.5โ2.0s.
Commerce category pages. Multiple products above the fold. LCP can be a category hero or a product-tile image. Harder to optimise due to image density.
Commerce product pages. Product image dominates LCP. Optimise the primary product image heavily; other images can lazy-load.
LCP and Penfriend-produced content
Penfriend-produced articles use minimal imagery by default (text-heavy structure), which means LCP tends to be dominated by the headline or opening paragraph rather than by a large image. On well-hosted sites, Penfriend pages have LCPs under 1.5s consistently. The contribution isn’t an LCP optimisation per se; it’s that the content doesn’t introduce LCP problems the way heavier page types do.
Related terms
- Core Web Vitals - the parent framework
- Cumulative Layout Shift (CLS) - a sibling metric
- Interaction to Next Paint (INP) - a sibling metric
- Time to First Byte (TTFB) - a precursor metric that affects LCP
- Page Speed - the broader performance category
