Largest Contentful Paint (LCP) measures how long it takes for the largest visible content element in the initial viewport to finish rendering. On many business websites, that element is the hero image, a large headline block, or a prominent banner.
If LCP is slow, the page can feel slow even when smaller elements appear quickly. The fix is usually not one trick. You need to find which part of the loading path is delaying the main content.
What LCP Actually Measures
LCP is one of Google's Core Web Vitals.
It tracks the render time of the largest image, text block, or other eligible content element visible within the viewport. The metric can change during loading as larger elements appear, and the final qualifying element becomes the LCP element.
Google's current LCP guidance recommends aiming for an LCP of 2.5 seconds or less at the 75th percentile of page loads. Between 2.5 and 4 seconds needs improvement, while more than 4 seconds is considered poor.
LCP is not simply “image load time.” It includes the full path required before the main content can appear.
The Four Parts of LCP Delay
A slow LCP can usually be broken into four stages:
- Time to First Byte;
- resource load delay;
- resource load duration;
- element render delay.
Each stage needs a different fix. If the server is slow, compressing the hero image will not solve the whole problem. If the image is discovered late, faster hosting may not help.
1. Start With Server Response Time
The browser cannot render the main content until the initial HTML starts arriving, so a slow Time to First Byte puts LCP behind immediately.
Check:
- redirect chains;
- server region;
- page caching;
- database work;
- backend APIs;
- hosting resource limits.
Veil Vertex's guide to Time to First Byte explains how to separate server delay from frontend problems.
TTFB is not the whole LCP problem, but fix obvious backend delays before optimising everything after them.
2. Make the LCP Resource Easy to Discover
A common LCP mistake is hiding the hero image behind CSS, JavaScript, sliders, or delayed component rendering. The browser should discover the main above-the-fold image as early as possible.
For an important hero image, prefer a normal image element in the initial HTML where practical. Avoid forcing the browser to wait for JavaScript before it learns that the resource exists.
web.dev's current LCP optimisation guidance recommends improving resource discovery and priority when the LCP element is an image.
If the browser discovers the image late, even a compressed file can still produce a poor LCP.
3. Do Not Lazy-Load the Hero Image
Lazy loading is useful for content below the fold.
It is usually a bad idea for the image that becomes the LCP element.
If the hero image is marked for lazy loading, the browser may intentionally delay fetching the most important visual on the page.
Use lazy loading for lower-page images, galleries, embeds, and other content that does not need to appear immediately.
The main above-the-fold image should normally load eagerly.
4. Give the LCP Image the Right Priority
Browsers make decisions about which resources deserve bandwidth first.
If the hero image competes with non-critical scripts, fonts, tracking tools, sliders, and other media, it can start too late.
For a known LCP image, developers can use appropriate resource-priority techniques such as fetchpriority="high" where supported and suitable.
Do not mark everything as high priority; if every resource is “important,” priority becomes meaningless.
5. Serve the Correct Image Size and Format
A 3000-pixel-wide hero image displayed at 1200 pixels wastes bandwidth.
Resize images close to their real display dimensions and use responsive image techniques when different devices need different sizes.
Modern formats such as WebP and AVIF can often reduce file size. Avoid compressing so aggressively that the most important image looks visibly damaged.
6. Reduce Render-Blocking CSS and JavaScript
Sometimes the LCP resource finishes downloading but still cannot render.
Large stylesheets, synchronous JavaScript, heavy frameworks, or scripts running on the main thread can delay when the browser is able to paint the element.
Review:
- unused CSS;
- large script bundles;
- third-party widgets;
- tag managers;
- animation libraries;
- sliders;
- consent tools;
- chat widgets;
- client-side rendering.
The goal is not to remove every script, but to stop non-critical code from blocking the first meaningful view.
7. Be Careful With Web Fonts
A large text block can itself become the LCP element.
If that text waits on a slow custom font, LCP may be delayed even when there is no large hero image.
Use sensible font loading, reduce unnecessary font files and weights, and make sure the page can render readable text without an avoidable long wait.
Custom typography should strengthen the brand without making the headline wait unnecessarily.
Use the PAINT Framework
Veil Vertex uses a simple framework for diagnosing LCP:
P — Prompt server: Is the initial HTML arriving quickly enough?
A — Above-the-fold discovery: Does the browser find the LCP resource immediately?
I — Image and asset efficiency: Is the resource correctly sized, compressed, and prioritised?
N — Non-critical blocking: Are scripts, styles, fonts, or widgets delaying rendering?
T — Test real users: Does the improvement show up in field data, not just one fast lab run?
This order helps avoid random optimisation.
How to Test LCP Properly
Use both lab and field data.
Lab tools such as PageSpeed Insights or Lighthouse are useful for reproducing issues and testing fixes.
Field data reflects real visitors with different devices, networks, locations, and cached states.
Test more than the homepage. Service pages, landing pages, blog templates, and pages built with different components can have different LCP elements and bottlenecks.
If only one template is slow, investigate that template before redesigning the site.
LCP Checklist for a Business Website
Before changing platforms or rebuilding the page, check:
- Is LCP above 2.5 seconds for real users?
- What exact element becomes the LCP element?
- Is TTFB already slow?
- Is the LCP image discoverable in the initial HTML?
- Is the hero image being lazy-loaded?
- Is the image larger than its display size?
- Could WebP or AVIF reduce transfer size?
- Is the resource competing with unnecessary high-priority files?
- Are CSS, JavaScript, fonts, or widgets blocking rendering?
- Does the fix improve field performance as well as lab results?
The goal is to make the page's main content appear quickly for actual visitors, not merely achieve a green score.
Fix the LCP Path, Not Just the Image
A slow LCP often looks like an image problem, but the true bottleneck may be the server, late discovery, scripts, fonts, or render-blocking CSS.
Identify the actual LCP element, break the delay into stages, and optimise the slowest stage first.
If your website feels visually slow but it is unclear which part of the loading path is responsible, Veil Vertex can identify the biggest performance bottlenecks through a free tailored website audit.