A 4.8-Second Hero Image Was Quietly Costing a SaaS Company Six Figures
A B2B software client came to us with a familiar complaint: their highest-traffic landing page felt fast on the office WiFi, but paid traffic was converting well below benchmark and rankings had slipped after a competitor refresh. Their analytics told the real story. The page’s Largest Contentful Paint (LCP) was landing at 4.8 seconds on mobile at the 75th percentile, well into the “poor” range. The culprit was not one big problem. It was a 1.1 MB hero image loaded by JavaScript, three render-blocking stylesheets, and a server that took most of a second to send the first byte. Each issue stole a few hundred milliseconds, and together they pushed real users past the point where many of them simply left.
This is the pattern we see most often. Slow landing pages are rarely killed by a single bottleneck. They die by a thousand cuts, and LCP is the metric that exposes them. Below is the diagnostic playbook our team uses to find and fix those cuts, and why getting it right pays off in both conversions and rankings.
What LCP Actually Measures (And Why 2.5 Seconds Is the Line)
Largest Contentful Paint records the moment the largest visible element finishes rendering in the viewport. According to Google’s web.dev documentation, that element is usually an image, a video poster, a CSS background image, or a large block of text. In practice it is the thing a visitor is waiting to see: the hero shot, the headline, the product photo.
Google grades LCP in three bands. A score of 2.5 seconds or less is “good,” between 2.5 and 4.0 seconds is “needs improvement,” and anything above 4.0 seconds is “poor.” The number that matters is not your fastest load or your average. Google measures the 75th percentile of page loads, segmented across mobile and desktop, so you have to be fast for roughly three out of four visitors, not just the ones on fast connections.
LCP is one of the three Core Web Vitals that feed into Google’s page experience signals, alongside Interaction to Next Paint and Cumulative Layout Shift. It is also the hardest of the three to pass for most sites, because it depends on your entire delivery stack working in concert. That is exactly why a structured diagnosis beats guesswork.
The Four Phases of LCP: Where Your Seconds Disappear
The single most useful idea in LCP optimization is that the metric breaks into four sequential phases. Google’s guide to optimizing LCP defines them and gives rough budgets for a well-tuned page:
- Time to First Byte (TTFB): from the click until the browser receives the first byte of HTML. Should be roughly 40 percent of your total LCP.
- Resource load delay: the gap between TTFB and when the browser actually starts downloading the LCP element. Should be under 10 percent.
- Resource load duration: the time to download the LCP resource itself. Should be roughly 40 percent.
- Element render delay: the gap between the download finishing and the element appearing on screen. Should be under 10 percent.
A healthy page spends the vast majority of its LCP time actually loading the resource. If a large share of your time sits in the two “delay” phases instead, you have a discovery or rendering problem, not a bandwidth problem, and the fix is completely different. Before touching any code, pull a field-data waterfall in PageSpeed Insights or a real-user monitoring tool and figure out which phase owns most of your seconds. That single diagnostic step prevents teams from spending weeks compressing images when the real issue is a slow server or a blocked main thread.
Phase One: Fix Server Response Time First
TTFB is the foundation, because every other phase waits behind it. If your server needs 900 milliseconds to think before it sends a byte, you have already burned more than a third of your entire budget before the browser has done anything. Google’s guidance is to keep TTFB low so the rest of the load has room to breathe, and a common working target is under 800 milliseconds, with the best sites well below that.
In our audits, the usual TTFB offenders are:
- Uncached pages that rebuild from the database on every request.
- Origin servers physically far from the visitor, with no edge caching.
- Bloated server-side logic or outdated runtime versions.
- Redirect chains that add a full round trip before the real page even starts.
The highest-leverage fixes are caching and a content delivery network. Serving cached HTML from an edge location near the user can cut hundreds of milliseconds off TTFB instantly, and it improves every downstream metric at the same time. This is foundational technical SEO work: it is invisible to visitors but moves the needle on both performance and crawl efficiency. When the architecture itself is the bottleneck, the fix often belongs in site design and development rather than a plugin or a config tweak.
Phase Two and Four: Clear Render-Blocking Resources and Main-Thread Blocks
The two “delay” phases are where most quick wins hide. After the HTML arrives, the browser has to parse it before it can paint, and render-blocking CSS and synchronous JavaScript stop that parsing cold. If the browser is busy downloading and executing a stack of stylesheets and scripts, your LCP element waits in line even though it is ready to render.
The practical moves here are well established:
- Inline critical CSS for above-the-fold content so the browser can paint without waiting for an external stylesheet.
- Defer or async non-critical JavaScript with the
deferandasyncattributes so scripts stop blocking the parser. - Eliminate request chains. A common killer is an LCP image that only loads after JavaScript runs and a stylesheet downloads. Per Mozilla’s MDN guidance, loading the LCP image via JavaScript instead of a plain HTML tag delays its discovery and stretches the load chain.
- Break up long main-thread tasks so the browser is not stuck executing a 400-millisecond script when it should be rendering.
There is real money in this phase. MDN notes that when an LCP image is competing for bandwidth with other resources, removing that contention let one image download in less than half the time. Pruning what loads, and when, frees the browser to prioritize the one element your visitor is actually waiting for. Because these changes touch how the page is built and ordered, they overlap heavily with UX and UI optimization, where perceived speed and visual stability are evaluated together.
Phase Three: Make the LCP Image Itself Small and Discoverable
When the LCP element is an image, and it usually is, the resource load duration is where you spend or save the most. Three tactics do almost all the work.
Serve Modern Image Formats
WebP and AVIF compress dramatically better than JPEG or PNG at the same visual quality. MDN’s worked example converted a 1 MB image to AVIF at 80 percent quality and landed at 46 KB, a 95 percent reduction. A heavy hero image is often the single biggest LCP win available, and a <picture> element with AVIF and WebP sources and a JPEG fallback ships the smallest file every browser can read.
Send Responsive Sizes, Not One Giant File
A phone does not need a 2,000-pixel-wide image. Using srcset and sizes lets the browser pull a version that fits the viewport, which matters enormously given how much traffic is now mobile. Average mobile load times still run far higher than desktop, so shaving payload on small screens is where the gains compound.
Help the Browser Find It Early
Discovery delay is a silent killer. Two attributes fix it. Add fetchpriority="high" to the LCP image so the browser prioritizes it over less important downloads, and use <link rel="preload"> for a background image the browser would otherwise discover late. Just as important: never put loading="lazy" on the LCP image. Lazy loading is for below-the-fold content. Applied to the hero, it actively delays the one thing you most need to render fast.
Why This Pays Off: Conversions and Rankings
Speed work can feel like an engineering luxury until you connect it to revenue. The connection is direct. Google and Deloitte’s Milliseconds Make Millions study, built on more than 30 million mobile sessions across dozens of brands, found that a 0.1-second improvement in mobile load speed lifted retail conversions by 8.4 percent and travel conversions by 10.1 percent, and improved lead-generation page bounce rates by 8.3 percent. That is a tenth of a second translating into measurable revenue, and most slow landing pages have several whole seconds to recover.
On the ranking side, LCP is a confirmed input to Google’s page experience signals. It is rarely the deciding factor between two pages, but it is a tiebreaker and a baseline. When two pages are otherwise comparable on relevance and authority, the faster one wins the experience comparison, and a “poor” LCP at the 75th percentile is a self-inflicted handicap. Faster pages also get crawled more efficiently and keep users on the page long enough for your content and offers to do their job.
The Order of Operations We Recommend
If you take one thing from this playbook, make it the sequence. Diagnose before you optimize, and fix in this order:
- Measure the four phases in field data and identify which one owns most of your LCP time.
- Fix TTFB first with caching and a CDN, because every other gain stacks on top of it.
- Clear render-blocking CSS and JavaScript and break up long main-thread tasks.
- Optimize the LCP image with modern formats, responsive sizes,
fetchpriority, and preload, and remove lazy loading from the hero. - Re-measure at the 75th percentile to confirm you have crossed under 2.5 seconds for the majority of real visitors.
Done in this order, the work compounds. The SaaS client we opened with went from 4.8 seconds to 2.1 seconds at the 75th percentile by fixing TTFB with edge caching, deferring two third-party scripts, and replacing a JavaScript-loaded JPEG hero with a preloaded AVIF. None of those changes was exotic. They were the right fixes applied in the right sequence, which is exactly what a disciplined LCP diagnosis delivers.
Sources
See where you are cited today
A free snapshot audit of your rankings and AI citations before we ever talk.