Largest Contentful Paint Still Slow? Fix the Real Bottlenecks
Largest Contentful Paint is a top ranking signal. Learn exactly what slows LCP down and the specific fixes that actually move the number.
Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element on a page — usually a hero image, banner, or heading block — to render on screen. Google uses it as one of three Core Web Vitals, and it's the one most sites struggle with. A score under 2.5 seconds is "good," 2.5–4 seconds is "needs improvement," and anything above 4 seconds is flagged as "poor" — both in Search Console and directly in ranking signals.
Most advice on this topic stops at "compress your images." That's true but incomplete. LCP is actually the sum of four separate delays, and you need to know which one is hurting you before you can fix anything.
The Four Phases That Make Up Your LCP Score
Every LCP measurement breaks down into these stages. Diagnosing the wrong one wastes time.
- Time to First Byte (TTFB) — how long the server takes to respond to the initial request
- Resource load delay — the gap between the HTML arriving and the browser starting to fetch the LCP resource
- Resource load time — how long the actual image/font/video takes to download
- Render delay — time between the resource being ready and the browser actually painting it
Open Chrome DevTools → Performance panel → record a page load → look at the LCP entry in the timeline. It will show you the breakdown by phase, not just the total number. Fix whichever phase eats the most time first.
Step 1: Identify What Your LCP Element Actually Is
You can't optimize what you haven't identified. Common LCP culprits:
- A full-width hero image on a landing page
- A large heading (h1) rendered with a custom web font
- A background image applied via CSS instead of an img tag
- A video poster frame
- The first product image in an e-commerce grid
In DevTools, the Performance panel labels the element directly. In PageSpeed Insights, it's listed under "Largest Contentful Paint element." Once identified, every fix below should target that specific element — optimizing images elsewhere on the page won't move the score.
Fixing Server Response Time (TTFB)
If TTFB is over 600ms, nothing else you do will get LCP under 2.5s reliably, because the clock hasn't even started rendering yet.
- Check whether you're on shared hosting with resource contention — move to a VPS or managed host if response times are consistently slow
- Enable server-side caching (Redis, object cache, or a full-page cache) so dynamic pages don't rebuild on every request
- Use a CDN with edge caching so the response comes from a location near the visitor, not your origin server
- Audit redirect chains — every redirect hop adds a full round trip before the browser even sees your HTML
Redirect chains are an underrated LCP killer. A page that bounces through 2-3 redirects before landing on the final URL adds hundreds of milliseconds before anything can load. Run your key landing pages through AXOX Hub's Redirect Checker to see the full chain and confirm you're not losing time to unnecessary hops.
Also Check Your Response Headers
Missing cache-control headers, no compression (gzip/brotli), or absent keep-alive settings all slow down delivery. AXOX Hub's HTTP Header Checker lets you inspect exactly what your server is sending back — useful for confirming caching and compression are actually active rather than assumed.
Fixing Resource Load Delay
This is the gap between the browser getting your HTML and actually starting to download the LCP image. It's almost always caused by the resource being discovered too late.
- Preload the LCP image — add
<link rel="preload" as="image" href="hero.jpg">in the head so the browser fetches it immediately instead of waiting to parse the CSS/JS first - Avoid lazy-loading the LCP element —
loading="lazy"on the hero image is one of the most common mistakes; it tells the browser to deliberately delay loading, which directly hurts LCP - Remove render-blocking CSS/JS above the fold — defer non-critical scripts and inline critical CSS so the browser doesn't wait on external files before it can start laying out the page
- Avoid loading the LCP image via JavaScript (e.g., background images set via JS, or lazy-load libraries) since the browser can't discover it until the script executes
Fixing Resource Load Time
Once the browser starts fetching the LCP resource, how long does the download itself take?
- Serve images in modern formats (WebP or AVIF) instead of JPEG/PNG — typically 30-50% smaller at equivalent quality
- Resize images to their actual display dimensions — don't serve a 2400px-wide image into a 600px container
- Use
srcsetandsizesso mobile devices download appropriately sized versions, not the desktop image - Serve the image from a CDN with HTTP/2 or HTTP/3 support for faster parallel delivery
- Compress with a quality setting around 75-80% — usually visually indistinguishable from 100% but significantly smaller
Web Fonts Count Too
If your LCP element is a text block using a custom font, the font file itself becomes part of the load chain. Use font-display: swap so text renders with a fallback font immediately rather than staying invisible until the custom font downloads, and preload the font file itself if it's critical.
Fixing Render Delay
Sometimes the resource is ready but something is blocking the paint itself.
- Long JavaScript tasks on the main thread can delay rendering even after resources are loaded — check the "Long Tasks" section of DevTools Performance
- Third-party scripts (analytics, chat widgets, ad tags) loaded synchronously in the head can block rendering — move them to load after the main content, using
asyncordefer - CSS animations or transitions applied to the LCP element on load can add unnecessary paint delay — avoid animating opacity/transform on the hero element itself
A Quick Priority Checklist
- Confirm TTFB is under 600ms — fix hosting/caching first if not
- Identify the actual LCP element via DevTools or PageSpeed Insights
- Preload it, never lazy-load it
- Compress and resize it correctly, serve in WebP/AVIF
- Remove render-blocking resources above the fold
- Defer third-party scripts that don't need to run immediately
- Re-test and check the phase breakdown again — repeat on whichever phase is now the largest
Before chasing image compression settings, rule out server and network-level issues first — a slow TTFB or an unnecessary redirect chain will cap your LCP score no matter how well-optimized your images are. Run your site through AXOX Hub's free Redirect Checker and HTTP Header Checker to catch these issues at axoxhub.com before touching a single image file.
Try the free tool
Open Tool