Disclosure: Some links on this page are affiliate links. We may earn a commission at no extra cost to you.
30 mobile landing pages with LCP > 3.5s before and after fetchpriority="high" and WebP srcset implementation
Average mobile LCP improved from 3.8s down to 1.6s without server hardware upgrades
Largest Contentful Paint (LCP) measures when the largest visual element in the viewport finishes rendering. While desktop sites frequently pass LCP with ease, mobile devices on 4G cellular networks struggle with constrained CPU power and cellular bandwidth. Here are the 7 patterns that sabotage mobile LCP scores.
Pattern 1: Applying loading="lazy" to the Above-the-Fold Hero Image
The most destructive performance anti-pattern on modern websites is lazy-loading the hero image. Visual page builders and WordPress performance plugins frequently include "Enable Lazy Loading" toggles that blindly apply loading="lazy" to every <img> element on the page, including the topmost visual.
When loading="lazy" is set on a hero asset, the browser parser deliberately defers downloading the image until layout calculation completes and the browser confirms the element is inside the viewport. On mobile devices with CPU throttling, this delay adds between 600ms and 1.2s directly to your LCP score.
Pattern 2: Missing fetchpriority="high" on Viewport Assets
By default, modern browsers schedule image downloads with "Low" or "Medium" priority until after stylesheets and synchronous JavaScript files have finished loading.
By explicitly declaring fetchpriority="high" on your primary hero image, you instruct the browser network scheduler to allocate maximum available bandwidth to that asset immediately upon discovering the URL in HTML markup.
<!-- Document Head Preload -->
<link
rel="preload"
as="image"
href="/assets/hero-mobile.webp"
type="image/webp"
fetchpriority="high"
/>
<!-- Viewport Image Markup -->
<img
src="/assets/hero-mobile.webp"
srcset="/assets/hero-mobile.webp 600w, /assets/hero-desktop.webp 1200w"
sizes="(max-width: 640px) 100vw, 1200px"
alt="Forensic Website Audit Inspector"
loading="eager"
fetchpriority="high"
decoding="async"
width="1200"
height="675"
/>Pattern 3: Serving Desktop Banners to Mobile Viewports
A 1920x1080px hero visual compressed to 280KB is manageable over fiber broadband, but on a 4G mobile connection with 50ms round-trip latency, downloading that file delays the paint thread by over two seconds.
Mobile screens (such as the iPhone 15 at 393x852px) do not require 1920px image widths. Serving a properly sized 600px or 750px mobile asset compressed via WebP or AVIF drops cellular payload to under 45KB, cutting image transfer time by up to 80%.
| Asset Resolution | Format | File Size | 4G Transfer Time | Observed Mobile LCP |
|---|---|---|---|---|
| 1920x1080 (Desktop) | JPEG | 480 KB | 1,450 ms | 3.8s (POOR) |
| 1920x1080 (Desktop) | WebP | 220 KB | 780 ms | 2.9s (NEEDS WORK) |
| 750x422 (Mobile 2x) | WebP | 52 KB | 180 ms | 1.6s (GOOD) |
| 750x422 (Mobile 2x) | AVIF | 38 KB | 140 ms | 1.4s (GOOD) |
Pattern 4: Render-Blocking Web Fonts Delaying Text-Based LCP
When an H1 heading or lead paragraph is the designated LCP element, render-blocking Google Fonts or Adobe Typekit stylesheets can delay text rendering until custom font files finish downloading.
If your CSS uses font-display: block, the browser renders an invisible text block (FOIT: Flash of Invisible Text) while waiting for the font. Replacing this with font-display: swap and utilizing size-adjust font fallbacks ensures text renders immediately with zero layout shift.
- Verify your primary hero image does NOT have loading="lazy"
- Add fetchpriority="high" to the hero img tag and link preload
- Enforce responsive srcset with 600w, 900w, and 1200w breakpoints
- Serve modern WebP or AVIF formats under 75KB mobile budget
- Eliminate client-side slider libraries on above-the-fold hero banners
- Self-host critical Google Fonts and use font-display: swap
Inspect Your Mobile LCP Element Now
Run our free in-browser diagnostic tool to locate your exact Largest Contentful Paint node and calculate asset payload weights.
Run Free LCP InspectionFrequently Asked Questions
Q1:Why does adding fetchpriority="high" to the LCP image sometimes fail to improve LCP if the image is still discovered late by the preload scanner?
The fetchpriority attribute only reorders requests within the browser's existing priority queue, it does not change when the resource is discovered in the document. If the LCP image is injected via JavaScript, hidden inside a CSS background-image, or nested inside a lazy-loading component that requires hydration before the src attribute resolves, the preload scanner never sees it during the initial HTML parse and fetchpriority has nothing to act on until the main thread is already busy. The fix requires the image to exist as a plain img tag with a real src or srcset in the raw HTML response, combined with an explicit link rel=preload as=image tag in the head for cases where the image is behind a client-side framework. Without this structural fix, fetchpriority is essentially a no-op because the resource was never eligible for early discovery in the first place.
Q2:We implemented WebP with srcset but mobile LCP barely moved. What server-side or CDN misconfiguration typically causes this?
The most common cause is a CDN or origin server that is not correctly parsing the Accept header for content negotiation, so it serves the full-resolution WebP asset to every device regardless of the sizes attribute in srcset, effectively downloading a 400KB image when a 60KB variant should have been selected. This happens frequently with misconfigured Cloudflare Polish or improperly tuned Nginx image_filter modules where the srcset breakpoints exist in markup but the actual byte-served file ignores viewport width. Another frequent culprit is missing or incorrect Content-DPR and Vary: Accept response headers, which causes intermediary caches to store and re-serve the wrong variant to subsequent mobile requests. Diagnosing this requires inspecting the actual transferred file size in DevTools Network panel per breakpoint, not just confirming that srcset markup exists, since markup correctness and server delivery correctness are two independent failure points.
Q3:What is the mechanism by which a render-blocking third-party script in the head delays LCP even when it has nothing to do with the hero image?
A synchronous script tag in the head halts the main thread's parsing of the HTML document until the script downloads, compiles, and executes, which means the browser cannot continue discovering downstream resources like the hero image or its preload hints during that window. This is compounded when the third-party script itself makes additional network calls, such as tag managers loading consent frameworks or A/B testing libraries, because each round trip adds serial latency before the DOM continues building. On mobile specifically, the combination of higher network RTT and slower CPU parsing multiplies this delay compared to desktop, often adding 800ms to 1.5s of pure blocking time before the LCP candidate is even requested. The remediation is moving non-critical third-party scripts to async or defer, or relocating them below the fold markup entirely, and validating the change using a Long Tasks trace in Chrome DevTools Performance panel rather than just re-running a single Lighthouse score.
Q4:Our LCP element is a headline text block, not an image, so why did fetchpriority and WebP optimizations still matter for our audit cohort?
When the LCP candidate is text, the bottleneck is almost never the text rendering itself but the web font file blocking the text from painting, since browsers default to a font-display: block behavior of roughly 3 seconds during which invisible text sits in a Flash of Invisible Text state. Font files enter the network queue at the same contention point as hero images, so unoptimized image requests earlier in the waterfall can push the critical font file back in priority, delaying text paint even though the font itself was never the direct problem. Applying fetchpriority="high" to the font preload link and correctly setting font-display: optional or swap resolves this by ensuring the font either paints immediately with a fallback or times out fast rather than blocking. This is why holistic waterfall analysis matters, our 7-pattern findings on image prioritization indirectly freed up contention that also benefited text-based LCP elements in the same cohort.
Q5:After fixing image priority, our lab LCP score improved but real-user CWV data in Search Console did not reflect the same gain. What explains this discrepancy?
Lab tools like Lighthouse or PageSpeed Insights test under fixed, often idealized network and CPU throttling profiles on a single run, while Search Console's Core Web Vitals report aggregates real-user field data from Chrome UX Report across a 28-day rolling window with wide variance in device tiers, network conditions, and cache states. A common hidden factor is that lab tests frequently hit a warm cache or CDN edge that has already cached the optimized WebP variant, while a meaningful percentage of real mobile users on 4G or throttled connections in the field dataset are still being served stale cached HTML or intermediary CDN nodes that have not fully propagated the fetchpriority and srcset changes. Additionally, real users on low-end Android devices experience main thread contention from ad scripts, extensions, or background processes that lab environments do not replicate, meaning the underlying fix is correct but the field percentile shift takes longer to surface and requires purging CDN caches at every edge node plus waiting out the full CrUX reporting window before drawing conclusions.
Architectural Verdict & Summary
Passing mobile Largest Contentful Paint does not require expensive edge servers or complex code refactoring. In over 80% of cases, simply removing lazy-loading from the hero image, setting fetchpriority="high", and providing a compressed mobile srcset brings mobile LCP securely into the green sub-2.5s threshold.