LCP for Brand Sites: The 2026 Hero Image and Type Loading Checklist
LCP on brand sites is almost always a hero image or a heading rendered in a web font. This checklist covers both, with specific thresholds and fixes for 2026.
What Triggers LCP on Brand Sites
Largest Contentful Paint identifies the biggest visible element in the viewport when the page first renders. On brand and studio sites, that element is almost always one of two things: a hero image or a large heading set in a web font.
This sounds simple. But the loading mechanics behind each are different, and fixing one without understanding the other leads to incomplete optimizations. A hero image that loads in 1.8 seconds still produces a slow LCP if it cannot paint until a render-blocking font stylesheet finishes loading.
The 2026 threshold is still 2.5 seconds. Field data from CrUX shows that most brand sites cluster between 2.0 and 3.5 seconds on mobile. The ones that pass comfortably tend to have solved both problems: image delivery and font loading. The ones that fail usually have a slow image, a blocking font, or both.
The Hero Image Checklist
Hero images on brand sites typically run 1400 to 1800 pixels wide and 600 to 900 pixels tall. At JPEG quality levels that preserve visual fidelity for photography, that is 150 to 300KB. At AVIF quality levels, 40 to 100KB. The format choice alone can be the difference between passing and failing LCP.
Format selection
For photographic hero images, the priority order in 2026 is:
- AVIF for browsers that support it (roughly 92% of global traffic). Best compression-to-quality ratio for photographic content.
- WebP as a fallback. Broader support than AVIF, better compression than JPEG.
- JPEG as the final fallback for the remaining few percent.
Use the
Preloading
The hero image should have a corresponding in the document head. Without this, the browser discovers the image only after it has parsed the HTML, constructed the DOM, parsed the CSS, and built the render tree. That discovery delay can be 500 milliseconds or more on slower connections.
If you are using the imagesrcset and imagesizes attribute to match. This is slightly awkward but well-supported in 2026.
Responsive sizing
Do not serve a 1600-pixel-wide image to a 375-pixel-wide mobile viewport. Use srcset and sizes to deliver appropriately sized images. A mobile visitor on a 2x display needs roughly an 800-pixel-wide source. Serving them the full desktop image wastes bandwidth and delays LCP.
Decoding
Add decoding="async" to allow the browser to decode the image off the main thread. This prevents image decoding from blocking other rendering work. The visual difference is imperceptible, but the performance benefit is measurable on slower devices.
Avoid lazy loading the hero
As we noted in the Core Web Vitals playbook, applying loading="lazy" to the hero image is a common mistake. Lazy loading defers the fetch until the image is near the viewport, which is counterproductive for an above-the-fold element.
The Font Loading Checklist
When the LCP element is a heading, its paint time depends on when the web font becomes available. If the font is render-blocking, the heading cannot paint until the font file downloads and the browser parses it.
Use font-display: swap
This allows the browser to paint the heading immediately using a fallback system font, then swap in the web font when it arrives. The heading appears quickly (good for LCP) and the font swap happens later (acceptable for visual refinement).
The risk with swap is a visible flash of unstyled text (FOUT). On brand sites where typographic precision matters, this flash can feel jarring. The mitigation is metric overrides.
Match fallback font metrics
CSS now provides size-adjust, ascent-override, descent-override, and line-gap-override properties for @font-face declarations. By setting these on a local fallback font (like Arial or system-ui), you can match its metrics to the web font closely enough that the swap is barely perceptible.
This eliminates the layout shift that normally accompanies font swapping and reduces the visual disruption of FOUT. It is the single best improvement you can make for brand sites that care about both LCP and typographic quality.
Self-host fonts
Using Google Fonts via the default tag introduces two network round trips: one to fonts.googleapis.com for the CSS, and another to fonts.gstatic.com for the font files. Self-hosting the font files on your own domain eliminates the cross-origin connection overhead.
Download the font files, add @font-face declarations in your own CSS, and serve them with appropriate cache headers. As discussed in our article on type systems, this also gives you more control over which font weights and character subsets you ship.
Subset aggressively
Most brand sites use Latin characters only. A full Google Fonts file for a variable font can be 100KB or more. A Latin-only subset of the same font might be 20-30KB. Use tools like glyphhanger or pyftsubset to strip the character ranges you do not need.
Preload the primary font file
If the heading font is critical to LCP, preload it:
```
```
This tells the browser to fetch the font file during HTML parsing, before the CSS is fully processed. The crossorigin attribute is required even for same-origin fonts due to how browsers handle font requests.
The Interaction Between Images and Fonts
Here is where it gets subtle. On many brand sites, the LCP element changes depending on how fast each resource loads.
If the hero image loads before the heading font, the image is the LCP element. If the heading font loads first and the heading is larger than the image in the viewport, the heading becomes the LCP element.
This means your LCP optimization needs to account for both resources, not just the one you think is largest. Profile your page with DevTools, look at the LCP element identified in the Performance panel, and optimize whichever resource is actually the bottleneck.
On mobile, the hero image is usually cropped or hidden, and the heading becomes the LCP element. On desktop, the full-width hero image is typically larger. This means the optimal loading strategy may differ between breakpoints.
Server and Hosting Considerations
All the resource-level optimizations above are limited by how fast the server responds.
Time to First Byte (TTFB) is the time from the browser's request to the first byte of the HTML response. On static sites deployed to edge CDNs (Cloudflare Pages, Vercel, Netlify), TTFB is typically 20-100ms globally. On traditional hosting without a CDN, TTFB can be 500ms or more for visitors far from the origin.
HTTP/2 multiplexing allows the browser to request the HTML, CSS, font, and hero image over a single connection without waiting for each to complete. Make sure your hosting supports HTTP/2 or HTTP/3.
Cache headers on fonts and images should be set to long durations (at least one year) with immutable hints. These resources rarely change, and caching them aggressively eliminates the network cost on repeat visits.
The Measurement Trap
Lighthouse scores the LCP of a single simulated page load. Real users experience variance: different network conditions, different devices, different cache states. A page that scores 1.8 seconds in Lighthouse might report 3.2 seconds at the 75th percentile in CrUX.
Always validate LCP improvements with field data. Deploy the change, wait for CrUX to update (28-day rolling window), and check whether the field metric actually improved. Lab improvements that do not show up in the field are not real improvements.
FAQ
Should I use fetchpriority="high" on the hero image?
Yes. The fetchpriority attribute tells the browser to prioritize this image over other same-priority resources. It is well-supported in 2026 and provides a small but consistent LCP improvement for hero images.
Does using a background-image in CSS hurt LCP?
Yes. CSS background images are discovered later in the rendering pipeline than
What about lazy-loading images below the fold?
Absolutely do this. loading="lazy" on images below the initial viewport reduces bandwidth competition with the hero image, indirectly helping LCP. Just keep it off the hero itself.
Next Steps
If your brand site is failing LCP, start with the hero image format and preloading. These two changes alone solve the problem for the majority of sites. If LCP is still marginal after that, move to font loading optimizations: self-hosting, metric overrides, and subsetting. The combined effect is usually enough to pass comfortably on both mobile and desktop.