LCP (Largest Contentful Paint) is the Core Web Vitals metric that most sites fail. It measures how long it takes to render the largest visual element in the visible portion of the page: typically a hero image, a main text block or a background video. If that element takes more than 2.5 seconds to appear, Google considers it a problem.
What makes LCP frustrating is that the culprits are usually design decisions that seem harmless: a high-resolution hero image, a custom font loaded from an external CDN or a carousel that depends on JavaScript to render. Identifying the exact cause is the first step. Fixing it is usually simpler than it seems.
What LCP is and the threshold Google sets
LCP measures the render time of the largest visible content element in the viewport. Google sets three thresholds based on the 75th percentile of field data (real user data, not lab):
- Good: 2.5 seconds or less.
- Needs improvement: between 2.5 and 4 seconds.
- Poor: more than 4 seconds.
The 75th percentile means that 75% of page loads must meet the threshold for the page to be classified as “good”. It is not enough for the median to be fast; slow loads on mobile connections or older devices also count.
The LCP element varies by page. On a home with a hero image, the LCP is usually that image. On a blog post, it can be the first visible paragraph or the featured image. On a product page, it can be the main product photo. Knowing which element is your LCP on each type of page is the first step before optimising.
LCP is part of the Core Web Vitals set that Google uses as page experience signals for ranking.
Diagnosis: how to identify your page’s LCP element
Before optimizing, you need to know which element is determining your LCP. There are several ways to identify it:
PageSpeed Insights. Enter the URL and look for the “Diagnostics” section. PageSpeed explicitly shows which element is the LCP with a highlighted screenshot. It also separates lab data (simulated) and field data (real users from the Chrome UX Report).
Chrome DevTools: Performance tab. Record the page load and look for the “LCP” marker in the timeline. Clicking it highlights the exact element on the page and shows the render time.
Web Vitals Extension. Google’s official Chrome extension shows all three Core Web Vitals metrics in real time, including the LCP element and its time.
Search Console: Core Web Vitals report. Shows URLs grouped by LCP performance with aggregated field data. It does not identify the specific element, but it points to which pages or groups of pages have issues.
Once the element is identified, the causes of slow LCP come down to four main categories.
Cause 1: Unoptimized LCP images (WebP, preload, srcset)
Images are the cause of 70% of LCP problems. The typical pattern: a 2 MB hero image in uncompressed PNG or JPEG format, served without preload and without a next-generation format.
Solutions
WebP or AVIF format. These formats offer the same visual quality with 25-50% less weight than JPEG. An 800 KB JPEG hero can be reduced to 300-400 KB in WebP with no visible loss. WebP images improve both performance and SEO by reducing transfer times.
Preload the LCP image. Add a <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> tag in the HTML <head>. This tells the browser to download the image before processing CSS and JavaScript, reducing LCP by 200ms to 1 second.
fetchpriority=“high” attribute. Add it directly to the <img> of the LCP element. It tells the browser to prioritize this image over other resources in the download queue.
Srcset and sizes. Serve different image sizes based on the viewport. A mobile does not need to download a 1920px wide image. Define breakpoints with srcset and the browser will download the appropriate version.
Explicit dimensions. Always define width and height on images so the browser reserves space before downloading them. This does not affect LCP directly, but it prevents CLS that can delay the final render.
Cause 2: Slow server and high TTFB
TTFB (Time to First Byte) is the time the server takes to send the first byte of the HTTP response. If your TTFB is 800ms, your LCP cannot be below 800ms no matter how perfect everything else is.
Reference thresholds
- Excellent: less than 200ms.
- Acceptable: between 200ms and 600ms.
- Problem: more than 600ms.
Solutions
CDN (Content Delivery Network). Distributes static content from servers geographically close to the user. A CDN can reduce TTFB from 600ms to less than 100ms for users far from the origin server.
Server caching. Implement server-level caching (Varnish, Redis, Cloudflare cache) to avoid regenerating the same page on each request. Static pages should be served directly from cache without processing.
Database optimization. If your CMS runs slow queries on each page load, the TTFB will be high regardless of the infrastructure. Review queries, add indices and consider using static generation for pages that do not change frequently.
HTTP/2 or HTTP/3. These protocols allow multiplexing connections, reducing latency when downloading multiple resources simultaneously. Most CDNs and modern servers already support HTTP/2.
Cause 3: Render-blocking resources (CSS, fonts, JS)
Render-blocking resources prevent the browser from painting content until they are fully downloaded and processed.
Render-blocking CSS
Every CSS file linked with <link rel="stylesheet"> in the <head> blocks rendering by default. If you have 5 CSS files totalling 300 KB, the browser will not paint anything until it downloads and processes all five.
The fix is to inline critical CSS (the styles needed for above-the-fold content) directly in the <head> and load the rest asynchronously with media="print" onload="this.media='all'".
Web fonts
Custom fonts cause two problems: FOIT (Flash of Invisible Text, where text is invisible until the font loads) and FOUT (Flash of Unstyled Text, where text appears with a generic font and then switches). Both affect LCP if the LCP element is a text block.
Use font-display: swap to show text immediately with a system font and switch to the custom one when it loads. Preconnect to the font domain with <link rel="preconnect" href="https://fonts.googleapis.com">. Consider using system fonts as the first option, since the visual difference is minimal and the performance impact is significant.
Render-blocking JavaScript
Scripts in the <head> without defer or async attributes block HTML parsing. The browser stops everything to execute the script.
Use defer for scripts that need the complete DOM (they execute after parsing) or async for independent scripts (they execute as soon as they download). Remove unnecessary JavaScript from the <head>.
Cause 4: Incorrect lazy loading on the above-the-fold element
Applying loading="lazy" to the LCP element is one of the most common and easiest mistakes to make. When you mark the hero image as lazy, you tell the browser not to download it until it is close to the viewport. But the hero image is already in the viewport from the first moment, causing an unnecessary load delay.
Applying lazy loading to the LCP element can worsen the metric by between 500ms and more than 1 second. This mistake is especially common on sites that apply global lazy loading to all images without distinguishing those that are above the fold.
Never apply loading="lazy" to images that appear in the initial viewport. The LCP image should have loading="eager" (or simply not have the attribute, since eager is the default behaviour) and fetchpriority="high".
The article on web speed and SEO analyses the impact of speed on rankings beyond LCP, including the effects on conversion.
Frequently asked questions about LCP
What is a good LCP according to Google?
Google defines three ranges: good (2.5 seconds or less), needs improvement (between 2.5s and 4s) and poor (more than 4 seconds). The goal is to keep LCP below 2.5 seconds at the 75th percentile of field data, both on mobile and desktop.
How does LCP affect Google ranking?
LCP is one of the three Core Web Vitals metrics that Google uses as ranking signals. A slow LCP does not directly penalize you, but it puts you at a disadvantage compared to competitors with faster LCP when other factors are similar.
Is it possible to improve LCP without changing server?
Yes, in many cases. Optimising images (WebP format, compression, srcset), removing render-blocking CSS and JS, using preload for critical resources and correctly configuring load priority can measurably improve LCP without changing infrastructure.
If your LCP exceeds 2.5 seconds and you cannot identify the root cause, you need a technical diagnosis that analyses the complete load chain. Contact our team to measure your real performance with field data and apply the corrections that will have the greatest impact on your Core Web Vitals.
Share this article
If you found this content useful, share it with your colleagues.
Frequently Asked Questions
¿Con qué frecuencia publican contenido nuevo?
Publicamos artículos nuevos semanalmente, enfocados en las últimas tendencias de SEO técnico, casos de estudio reales y mejores prácticas. Suscríbete a nuestro newsletter para no perderte ninguna actualización.
¿Los consejos son aplicables a cualquier tipo de sitio web?
Nuestros consejos se adaptan a diferentes tipos de sitios: ecommerce, blogs, sitios corporativos y aplicaciones web. Siempre indicamos cuándo una técnica es específica para cierto tipo de sitio o requerimientos técnicos.
¿Puedo implementar estas técnicas yo mismo?
Muchas técnicas básicas puedes implementarlas tú mismo siguiendo nuestras guías paso a paso. Para optimizaciones avanzadas o auditorías completas, recomendamos consultar con especialistas en SEO técnico como nuestro equipo.
¿Ofrecen servicios de consultoría personalizada?
Sí, ofrecemos servicios de consultoría SEO técnica personalizada, auditorías completas y optimización integral. Contáctanos para discutir las necesidades específicas de tu proyecto y cómo podemos ayudarte.
