Free · Fast · Privacy-first

Check Your LCP Score (Largest Contentful Paint)

Largest Contentful Paint (LCP) is the Core Web Vital that measures how quickly the main content of your page loads, specifically the moment at which the largest visible element such as a hero image or headline finishes rendering in the viewport.

⚡

LCP timing measurement

🔒

LCP element identification

✨

Mobile and desktop LCP

⚡

No sign-up required

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this Website Speed Test to your website

Drop the Website Speed Test into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Website Speed Test by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Website Speed Test by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

LCP Explained: What It Measures, What Causes It to Fail, and How to Fix It

Largest Contentful Paint (LCP) is a Core Web Vital that measures the time from when a page starts loading to when the largest visible content element finishes rendering. The LCP element is typically a hero image, above-fold banner, heading text block, or video thumbnail and is identified at runtime by the browser as the visually dominant element within the initial viewport. Google's thresholds are Good under 2.5 seconds, Needs Improvement between 2.5 and 4 seconds, and Poor above 4 seconds. LCP carries the highest weight in the Lighthouse performance score at 25 per cent of the composite total, reflecting Google's view that loading the most visible content quickly is the strongest predictor of perceived page speed. The LCP element can be identified precisely in Chrome DevTools through the Performance panel's LCP marker, or in PageSpeed Insights through the Opportunities section that lists element-specific recommendations.

Poor LCP has four primary root causes that map to four distinct fix strategies. The first is slow server response time, where a TTFB above 800ms delays every downstream metric including the LCP element. The fix is to enable page caching, upgrade hosting if the plan is underpowered, or add a CDN that terminates connections closer to users. The second is render-blocking resources in the document head, including CSS files and synchronous JavaScript that must be parsed before the browser can render the LCP element. The fix is to defer non-critical CSS, move scripts to just before the body close tag, or add async and defer attributes to script tags. The third is the resource load time of the LCP element itself: a 500KB hero image on a 3G connection adds 3 or more seconds to LCP regardless of any other optimisation. The fix is to compress and convert to WebP, reduce dimensions to match the display size, and preload the LCP image. The fourth is client-side rendering, where the LCP element is injected by JavaScript rather than present in the HTML and therefore can only load after scripts execute. The fix is to server-side render critical above-fold content.

The LCP preload optimisation is one of the highest-ROI single-line changes available across the entire performance toolkit. Adding a link rel="preload" as="image" hint for your hero image in the document head tells the browser to fetch the LCP image at the highest priority during initial HTML parsing rather than waiting until the browser encounters the img tag later in the document body. This single change can reduce LCP by 0.5 to 2 seconds on many pages because the browser starts the image fetch in parallel with parsing rather than serialising the work. For responsive images using srcset, use the imagesrcset and imagesizes attributes on the preload link to ensure the correct image size for the current viewport is preloaded rather than the desktop master that would be wasted on mobile devices.

Diagnosing LCP failures requires identifying which specific element is the LCP element for the page being measured, because the optimisation strategy depends entirely on what the element is. A hero image needs compression and preload; a large headline needs font loading optimisation; a video thumbnail needs poster image work; a background image needs CSS optimisation that exposes the image to the preloader. The same numeric LCP score can have completely different root causes across different pages, which is why a generic prescription rarely works. Open Chrome DevTools, run a Performance recording, and locate the LCP marker on the timeline. Click the marker to highlight the specific element and inspect its loading characteristics in the Network panel. Only after this identification step should the actual fix strategy be selected, because applying the wrong fix to the wrong element type produces no improvement at all.

web.dev: Optimize Largest Contentful Paint web.dev: LCP Metric Definition and Scoring

How to use this tool

💡

Enter your URL to measure LCP and identify the specific element causing your Largest Contentful Paint.

How It Works

Step-by-step guide to check your lcp score (largest contentful paint):

1
Enter your page URL
Paste the URL of the page you want to check LCP for, picking a page that represents typical content rather than an unusual outlier. Test the highest-traffic landing page first, then move to product or article templates that drive significant traffic. The LCP element often varies across page types within the same site, so testing only one page gives an incomplete picture of where the real optimisation opportunities lie across the broader template structure.
2
Review the LCP score
Check the LCP time against the standard thresholds. Good is under 2.5 seconds, Needs Improvement falls between 2.5 and 4 seconds, and Poor is over 4 seconds. Note how close your score sits to the next threshold boundary, because a score of 2.4 seconds is one network hiccup away from slipping into the Needs Improvement bucket while a comfortable 1.8 seconds offers genuine headroom against everyday measurement variance and future content additions.
3
Identify the LCP element
The tool identifies which specific element on your page is triggering the LCP measurement, which is usually a hero image, a background image referenced from CSS, or a large text block such as a headline or above-fold paragraph. Note the element carefully, because the entire optimisation strategy that follows depends on what the element is. The same LCP score can have completely different root causes across different element types, and the wrong fix applied to the wrong element produces no improvement at all.
4
Optimise the LCP element
Apply the specific fix for that element type. Compress images and convert them to WebP if the LCP element is an image. Preload the resource using a link rel="preload" hint in the document head regardless of element type. Remove any JavaScript or CSS that delays rendering of the LCP element by appearing earlier in the critical path. Re-test after each individual change so you know which intervention produced which improvement, rather than batching multiple changes and losing the per-change attribution.

Real-world examples

Common situations where this approach makes a real difference:

Hero image optimisation

A photographer's portfolio site has an LCP of 7.2 seconds caused by a 4.8MB hero image served at full master resolution to every device regardless of viewport size. The developer converts the image to WebP at quality 80, resizes the served version to 1200 pixels wide for desktop with appropriate srcset variants for tablet and mobile, and adds a preload hint in the document head. LCP drops to 1.8 seconds within a single deployment, moving the score from Poor to Good and pushing the homepage through the Core Web Vitals threshold for the first time since the site launched two years ago.

E-commerce product image

An online shop discovers through a FixTools audit that the LCP element on product detail pages is the main product image, currently loading at 3.8 seconds on mobile due to a combination of large file size and no priority hint. The team adds fetchpriority="high" to the main product image tag, switches the served format to WebP with a JPEG fallback for older browsers, and ensures the displayed dimensions match the rendered viewport size rather than serving the high-resolution variant used in the zoom feature. LCP drops to 1.9 seconds, conversion rate on product pages improves measurably over the next month.

News article headline

A news site's LCP element is identified as the large above-fold headline rather than any image, which surprises the team because they had assumed image weight was the cause. The headline renders slowly because the custom serif font it uses takes 1.8 seconds to download and the headline is invisible until then. Adding font-display: swap so a fallback font renders immediately while the custom font loads, then preloading the font file in the document head, reduces the effective LCP text render from 3.1 seconds to 0.8 seconds with no other changes required to the article template.

When to use this guide

Use this when you need to specifically diagnose and improve your LCP score, especially if your overall performance score is poor and you want to understand the leading cause.

Pro tips

Get better results with these expert suggestions:

Preload your LCP image in the document head

Add a link rel="preload" as="image" hint pointing at your hero image into the document head as one of the first elements after the meta tags. This single change tells the browser to fetch the LCP image at the highest priority during initial HTML parsing, rather than discovering it later when the img tag is encountered partway through the document. The optimisation can reduce LCP by 0.5 to 2 seconds with a single line of code and no functional change to the page, which makes it among the highest-ROI changes in the entire performance toolkit.

Identify your LCP element before optimising

Different page types have different LCP elements and the right optimisation depends on which element you are actually fixing. On a blog post the LCP might be the featured image, on a homepage it might be a text heading using a custom font, and on a product page it might be the first product image. Open Chrome DevTools, run a Performance profile, and identify the exact LCP element before deciding which optimisation to apply. Optimising the wrong element produces no improvement at all and wastes engineering time that could have moved the metric.

Reduce your TTFB to improve LCP

LCP cannot begin until the browser receives the initial HTML response, which is the TTFB measurement. Every millisecond of TTFB delay adds directly to LCP in a strict one-for-one relationship that no front-end optimisation can break. If your TTFB is above 600ms, enabling server-side caching will reduce both TTFB and LCP simultaneously, which often makes it the single highest-impact LCP improvement available. Fix TTFB before pursuing image optimisations or preload hints, because those front-end fixes hit a ceiling determined by your server-side performance.

Avoid lazy loading your LCP image

The loading="lazy" attribute defers images until they approach the viewport, but the LCP image is by definition already in the viewport from the moment the page starts to render. Applying lazy loading to your LCP element delays its discovery by the browser and significantly increases LCP. Only apply lazy loading to below-fold images that the user has to scroll to reach. Explicitly set loading="eager" on your LCP image if your site template applies lazy loading by default to all images through a build tool or CMS feature, because the default behaviour silently sabotages your LCP score.

Identify the LCP element first

LCP is caused by a specific element on the page, usually a hero image, a large text block, or a background image. The checker identifies which element is the LCP element so you can focus optimisation efforts on exactly that resource.

Preload your LCP image

Add <link rel="preload" as="image" href="your-hero-image.jpg"> in your HTML head to tell the browser to start loading your LCP image as early as possible, before it has parsed the CSS or JS that would normally trigger the load.

Ensure the LCP resource is not blocked by JavaScript

If your LCP element is rendered by JavaScript (e.g., a carousel or lazy-loaded image), the browser cannot paint it until the JS executes. Server-side rendering or eager loading of the LCP element can dramatically reduce LCP time.

FAQ

Frequently asked questions

LCP measures the time from when a page starts loading to when the largest visible content element finishes rendering in the viewport, marking the point at which the user can see the dominant piece of content the page exists to deliver. Typically the LCP element is a hero image, a large heading, a banner, or a video thumbnail, and the browser identifies it at runtime based on which element occupies the most visible area within the initial viewport. Google's thresholds are Good under 2.5 seconds, Needs Improvement between 2.5 and 4 seconds, and Poor above 4 seconds. LCP is one of Google's three Core Web Vitals and serves as a direct ranking signal in the Page Experience update that has been live since 2021.

The four main causes work in a layered order and need to be addressed in that order to avoid wasted effort. Slow server response with a TTFB above 800ms delays every downstream metric including LCP, so it must be fixed first regardless of what else is wrong. Render-blocking resources in the document head delay the moment the browser can begin painting any content. The LCP element itself may be a large, unoptimised image that takes too long to download even when the surrounding infrastructure is fast. Client-side rendered content where the LCP element is injected by JavaScript after scripts execute prevents the browser from discovering and rendering the element in time.

The five highest-leverage LCP fixes resolve most production issues. Preload the LCP image with a link rel="preload" as="image" hint in the document head so the browser fetches it at top priority during initial parsing. Enable server-side caching to reduce TTFB, which improves LCP one-for-one. Compress and convert the LCP image to WebP format for roughly 30 per cent smaller file size at equivalent visual quality. Remove render-blocking scripts from the head or add async and defer attributes to prevent them from delaying the first paint. Use a CDN to serve the LCP image from a server geographically close to the user, reducing network latency on every visit.

Google defines Good LCP as under 2.5 seconds measured at the 75th percentile of real user visits, which means three quarters of your visitors should experience LCP under 2.5 seconds for the page to qualify as Good in Search Console. Needs Improvement falls between 2.5 and 4 seconds, and Poor is above 4 seconds. The top decile of websites globally achieve LCP under 1 second, which is a reasonable aspirational target for high-performance pages. As practical targets, aim for under 2.5 seconds on mobile and under 1.5 seconds on desktop, with stretch targets a second below each of those for pages where speed is a competitive differentiator.

LCP is measured in two complementary ways that serve different purposes. Lab data is a single measurement captured by Lighthouse or PageSpeed Insights under simulated network and CPU conditions, which makes it reproducible but not necessarily representative of real user experience. Field data is aggregated from real Chrome users visiting your site over a 28-day rolling window, collected via the CrUX dataset. Google uses field data at the 75th percentile as the ranking signal, not the lab score. If you have sufficient traffic, check your Google Search Console Core Web Vitals report for field data LCP because that is what Google itself sees and uses for ranking decisions.

The LCP element must fall into one of several specific categories that the LCP algorithm recognises. The eligible types are an img tag, an image element inside an SVG, a video element with a poster image, a background image loaded via CSS url(), or a large block-level text element such as a heading or paragraph that occupies significant viewport space. The largest visible element among these eligible types is identified by the browser at the time it fully renders. In Chrome DevTools' Performance panel you can see exactly which element was selected as the LCP for a specific page load along with the timing breakdown that produced the measurement.

Yes, significantly, because network latency between the user and the server adds directly to TTFB, which delays LCP one-for-one. A server in London serving users in Sydney adds approximately 250 to 300 milliseconds of round-trip latency compared with a server hosted in Sydney itself, and that latency cannot be reduced through application optimisation alone. A CDN that serves your page HTML and assets from a geographically local edge server can eliminate most of this latency penalty and is often the most impactful LCP fix available for geographically distributed audiences. For sites serving multiple regions, CDN coverage is essentially mandatory rather than optional.

Lab tests run under controlled conditions that often produce more favourable results than real-world conditions, which is the most common reason for the gap. Real users browse from slower devices, congested networks, and locations far from your origin server, all of which can degrade LCP relative to the lab simulation. Third-party scripts that load conditionally based on consent state, geographic location, or A-B test cohort may not execute during the lab test but do execute for real users, adding measurable time. Check the Search Console Core Web Vitals report for the specific URL groups failing and investigate what differs between the lab setup and the real production environment those users encounter.

Image compression is often the highest-impact LCP fix but it is far from the only lever. Preloading the LCP image via a link hint can reduce LCP by 0.5 to 2 seconds without changing the image at all. Reducing TTFB through server-side caching improves LCP one-for-one. Adding fetchpriority="high" to the LCP image tag tells the browser to prioritise it over other resources during the initial fetch. Removing render-blocking JavaScript and CSS from the document head shortens the time until the browser can begin rendering. These changes apply to pages where the existing image is already reasonably sized, or where image swap-out is too disruptive to attempt as a first move.