Your Core Web Vitals crater on mobile. Here's what actually fixes LCP.
LCP is the metric that tanks your phone score. Load your hero first and the red turns green.
Your vitals crater on mobile because Largest Contentful Paint is blowing past 2.5 seconds, and LCP is the one that drags the whole score down. Fix how fast your biggest above-the-fold element loads and the red turns green. That's the job.
Why does it tank on the phone and not your desk?
Because you built and tested on a fast laptop, on office wifi, cache warm. Your customer is on a mid-range Android, one bar of LTE, cold cache. Same page, different planet.
Google grades you on the second one. Per Google Search Central, Core Web Vitals measures “real-world user experience.” The score itself comes from real Chrome users. web.dev is specific about where the bar sits: the 75th percentile of page loads, split across mobile and desktop. So one slow visitor in four is enough to fail you. Your DevTools “looks fine” doesn't count.
What's a “good” LCP, and why should you care?
Good is 2.5 seconds or less. Between 2.5 and 4 needs work. Over 4 is poor. Those are web.dev's numbers, measured at the 75th percentile, mobile and desktop counted separately.
LCP is the render time of the largest thing in the viewport. Usually a hero image, a headline block, or a video poster. When that hero takes five seconds to show up, LCP is five seconds, and you fail.
Why care? Two reasons. Google says good Core Web Vitals “aligns with what our core ranking systems seek to reward.” That's rankings. And it's money. A study commissioned by Google and run by Deloitte and 55, covering 37 brands and over 30 million sessions, found that a 0.1 second improvement in mobile speed lifted retail conversions 8.4% and travel conversions 10.1%, with retail shoppers spending 9.2% more. One tenth of one second. Now picture your site sitting two seconds slow and do the math on what that costs.
Why is LCP the one that craters?
Four usual suspects. Frank sniffs them out every time.
- A monster hero image. A 3MB PNG shot for desktop, shipped full-size to a 400px phone screen.
- Render-blocking CSS and JavaScript. The browser hits a fat stylesheet or a synchronous script in the head and stops cold. Nothing paints until it finishes.
- A slow server. Time To First Byte is the clock running before your HTML even shows up. web.dev is blunt about it: “A high TTFB can make achieving a 2.5 second LCP challenging, or even impossible.”
- Client-side rendering with no cache. The page ships an empty shell, then JavaScript builds the content in the browser. A big gap between first byte and first paint is, in web.dev's words, “a classic sign of a site that relies heavily on client-side rendering.” On a cheap phone, that's a death sentence.
What actually fixes it, in order?
Priority matters. Do these top to bottom, not whatever's easiest.
1. Make the LCP image load first, not last. The browser can't show what it hasn't found. Put the real src or srcset in the HTML so the browser's preload scanner spots it early. If the hero is a CSS background or a web font, preload it with <link rel="preload">. Set fetchpriority="high" on it. And never lazy-load your LCP image. That's not our opinion, it's web.dev's flat rule: “Never lazy-load your LCP image.” Slapping loading="lazy" on the one thing you want first is a self-inflicted wound.
2. Kill the render-blocking junk. Trim what sits in the <head>. Remove unused CSS, defer the non-critical stuff, inline only what's genuinely tiny. Synchronous scripts in the head are, per web.dev, “almost never necessary” and almost always hurt. Add async or defer, or get them out of the way.
3. Right-size the image and change the format. Serve the size the device needs, not your 4K master. Switch to WebP or AVIF and compress hard, both formats web.dev names directly. A well-sized WebP hero can be a tenth of the PNG. Then cache it with a long cache policy so the second visit pulls it off disk instead of the network.
4. Fix TTFB with the edge and a CDN. Get your servers close to your users. A CDN cuts the distance the bytes travel and shrinks the file on the way. Cache your HTML at the edge so requests don't run all the way back to origin. And kill redirect chains. web.dev flags them as a common cause of slow TTFB, and every hop stacks straight onto the clock.
5. Stop rendering in the browser. Render ahead of time. Server-side rendering puts your content and your image right in the HTML source, so nothing waits on a JavaScript round trip. Better still, static generation. Build the pages at deploy, serve flat HTML off the edge. web.dev's take on prerendering: “it's generally a better choice for performance.”
This is where speed stops being a slogan. Static pages off a CDN are why a J450N build loads in half a second and paints before a bloated theme finishes phoning home for its plugins. No leash. All teeth.
What does this mean if you run the business?
It means a slow mobile site bleeds you twice. Google drops you a few spots for weak vitals, so fewer people find you at all. Then the ones who do find you sit there waiting, get bored, and bounce before your hero even loads. Lost ranking and lost conversion, same root cause. Two seconds of LCP.
The fix isn't a plugin you bolt on Friday afternoon and forget. It's how the site gets built. Right-sized images, a lean head, edge caching, static HTML. Get that right and 2.5 seconds is easy money. Get it wrong and no amount of “SEO” saves you.
Frank doesn't chase the score. He fixes what's slow, and the score follows.
Your hero image is the first thing your customer sees. Make it the first thing that loads.
We build sites that pass Core Web Vitals because they're fast by design, not fast by patch. Start the brief.