Largest Contentful Paint checker
Free for 3 URLs.
Largest Contentful Paint is the moment the biggest piece of content in the viewport finishes rendering. For most pages that is a hero image, a product photo or a large block of text. This checker shows your LCP from real users and from a lab test, names the element responsible, and shows where the time goes.
The target
Google's threshold for a good LCP is 2.5 seconds or less at the 75th percentile of page loads. Between 2.5 and 4 seconds needs improvement. Over 4 seconds is poor.
The four parts of LCP
LCP time can be split into four phases. The checker shows each one from the lab test.
- Time to First Byte. How long until the server starts sending the HTML. Slow hosting, uncached pages and redirects all add here.
- Resource load delay. The gap between the first byte and the browser starting to download the LCP resource. If the browser only discovers your hero image after running JavaScript or reading CSS, this grows.
- Resource load duration. How long the image or font takes to download. Large files and slow servers make this longer.
- Element render delay. Time between the resource arriving and the element appearing on screen. Render-blocking scripts and styles, or client-side rendering, add to this.
Fixing LCP means finding the largest phase and attacking that one first.
Common causes and fixes
The LCP image is discovered late
If the image is set as a CSS background or inserted by JavaScript, the browser cannot start downloading it early. Use a normal img element in the HTML, or add a preload hint for it. Give it a high fetch priority.
The LCP image is lazy-loaded
Lazy loading is great for images further down the page and harmful for the main image. Remove the lazy attribute from images that appear in the first screen.
The image is too large
A 3000 pixel wide photo shown at 800 pixels wastes bandwidth. Serve responsive sizes with srcset and use a modern format like WebP or AVIF.
Slow server response
If TTFB is over about 800 ms, look at caching, a CDN for HTML, database query time and redirects before the final URL.
Render-blocking resources
Large CSS files and synchronous scripts in the head delay first render. Inline the critical CSS, defer the rest, and add defer or async to scripts that are not needed up front.
Client-side rendering
If the page content is built by JavaScript after load, LCP waits for the framework to start. Server-side rendering or static generation for key pages makes a large difference.
Text as the LCP element
When a heading or paragraph is the LCP element, the usual culprit is web fonts. Text cannot paint until the font loads unless you allow a fallback. Use font-display swap or optional, preload the main font file, and keep the number of font files small.
Mobile versus desktop
Mobile LCP is usually slower: smaller CPUs, slower networks, and sometimes a different, larger hero image. Check both. Google uses mobile data for mobile search results.
Watching LCP over time
LCP regressions often come from content rather than code. Someone uploads a new banner at full resolution, and LCP jumps by a second. Vitals Clock checks LCP every day, compares it with the seven-day median and alerts you when it moves, with page weight and request count so you can spot a heavy new image quickly.
Questions
Why is the LCP element different in field and lab data?
Real users have different screen sizes, so the largest element can change. The lab test uses one fixed viewport.
Can a cookie banner be the LCP element?
Yes, if it is the largest thing on screen at load. Keep banners small, or make sure the main content renders first.