LCP Under 2.5 Seconds: A Technical Guide for Marketing Sites

Largest Contentful Paint (LCP) measures how quickly the biggest visible element on your page loads for real users. Google's threshold for a "Good" LCP score is 2.5 seconds. Sites below that threshold pass the Core Web Vitals assessment. Sites above it fail — and that failure is a confirmed ranking signal.

For most marketing sites, hitting 2.5 seconds is achievable. For many WordPress sites running common themes and plugin stacks, it is genuinely difficult without meaningful architectural changes. The difference matters: Google's LCP guidance defines a page as having a "Poor" LCP if the score exceeds 4 seconds, and field data from the Chrome User Experience Report consistently shows WordPress sites clustering in the Needs Improvement (2.5–4s) and Poor (4s+) ranges when they carry a typical plugin and theme load.

The path to sub-2.5s LCP is not a single fix. LCP is composed of four sequential phases, each of which can be optimized independently. This guide walks through each phase, explains how to identify where your time is actually being lost, covers WordPress-specific fixes for each bottleneck, and explains why Next.js clears most of these hurdles at the architectural level.

Quick Checklist

Identify the LCP element on your top 10 pages (PageSpeed Insights, field data)
If LCP is an image: preload it, serve WebP/AVIF, use correct srcset sizes
If LCP is text: eliminate render-blocking CSS, inline critical styles
Reduce TTFB below 800ms (upgrade hosting or add CDN layer)
Remove render-blocking third-party scripts from above-the-fold
Set fetchpriority="high" on the LCP image element
Avoid lazy-loading the LCP image (this delays it, not helps it)
Test with throttled mobile (Slow 3G) to simulate real-world conditions

What Counts as the LCP Element (It's Not Always What You Think)

Before optimizing, you need to know what you are optimizing. The LCP element is the largest element visible in the viewport when the page first loads. "Largest" means largest by rendered area, not by file size. And "visible in the viewport" means above the fold — elements below the fold are not candidates for LCP.

The browser considers four types of elements when determining LCP: images (including <img> tags and images set via CSS background-image), <video> poster frames, block-level text elements (<p>, <h1>, <div> containing text), and SVG images.

For marketing sites, the LCP element is most commonly:

The hero image at the top of the homepage or landing page
The hero section's background image (if set via CSS)
An <h1> or large headline when no image is present above the fold
A video poster frame if video is used in the hero

The LCP element changes per page and per device. On desktop, a wide hero image might be the LCP. On mobile, the same hero might be cropped out of view and an <h1> becomes the LCP. Use PageSpeed Insights or Chrome DevTools to check the LCP element for each specific page you are optimizing, at the viewport size you care about.

Do not guess. The wrong diagnosis leads to the wrong fixes. If you optimize image delivery for a page where the LCP element is actually a text block, you will spend time and get minimal improvement.

The Four Phases of LCP and Where Time Is Lost

Google defines LCP as the sum of four sequential phases. Every millisecond in your LCP score is accounted for by one of these four phases. Knowing which phase is eating your time tells you exactly what to fix.

Server Response Time (TTFB)

Time to First Byte (TTFB) is the time between the browser making a request for the page and receiving the first byte of the HTML response from the server. It is the foundation of LCP. If TTFB is slow, everything downstream is delayed.

Google's threshold for a Good TTFB is under 800ms. TTFB is typically slow because of one or more of the following: a server that is physically far from the user (no CDN), a server that is too slow or underpowered for the traffic it receives, or a server-side rendering process (PHP execution, database queries) that takes too long before it can start sending bytes.

For WordPress, TTFB is often the hardest bottleneck to fix without changing infrastructure. A WordPress page request executes PHP, queries the database, loads the active theme, and initializes every active plugin before it can send a byte. On shared hosting with no page caching, this can take 1–3 seconds on its own — and that is before any resource loading begins.

Resource Load Delay (Render-Blocking CSS/JS)

After the browser receives the HTML, it discovers the LCP element. If the LCP element is an image, the browser needs to start loading it. Resource load delay is the gap between the browser receiving the HTML and actually being able to start loading the LCP resource.

This gap is caused by render-blocking resources — CSS stylesheets and JavaScript files that the browser must download and process before it can render anything on the page. A WordPress site with three to five CSS files and multiple JavaScript bundles loading in the <head> will have substantial resource load delay. The browser sees the LCP image's <img> tag in the HTML, but it cannot start fetching the image until it has finished processing all the blocking resources in front of it.

Resource Load Time (Image Download)

This is the time it takes to actually download the LCP resource once the browser has started fetching it. For image LCP elements, this is determined by the image file size and the network speed.

On a fast desktop connection, even a large image may download quickly. On a throttled mobile connection (Slow 3G or Fast 3G, which are used by Google's field data methodology), a large unoptimized hero image can add 2–4 seconds to LCP by itself. Image format, compression level, and dimensions all directly affect this phase.

Element Render Delay (Layout and Paint)

This is the time between the LCP resource finishing its download and the browser actually painting it to the screen. On most well-structured pages, this phase is under 50ms and not the primary bottleneck. However, it can become significant if heavy JavaScript is running on the main thread and blocking the browser's rendering process.

Layout shifts (CLS), large JavaScript bundles executing before paint, and complex CSS animations can all contribute to element render delay. If your other three phases look healthy but LCP is still slow, investigate what is happening on the main thread just before the LCP paint event.

How to Identify Your LCP Element (DevTools Walkthrough)

Open Chrome DevTools and navigate to the Performance panel. Record a page load with CPU throttling set to 4x slowdown and network throttling set to Slow 3G (to simulate the conditions Google uses for field data collection). After the recording completes, look for the "LCP" marker on the timeline.

Click on the LCP marker and the DevTools panel will highlight the LCP element in the page and show you its details: the element, its size, and its timing breakdown across the four phases described above.

Alternatively, use PageSpeed Insights. Run your URL through PageSpeed Insights at mobile settings. The report will identify the LCP element by screenshot and show you its timing. For field data rather than lab data, the Chrome User Experience Report (CrUX) data shown in PageSpeed Insights reflects real-user measurements from Chrome users visiting your site — this is the data Google uses for ranking purposes.

The critical distinction: lab data (your own Lighthouse run) and field data (CrUX) can differ significantly. A page that scores well in Lighthouse may still have a Poor field data LCP if real users are on slower devices or networks than your test simulates. Always check field data before concluding that LCP is fixed.

WordPress-Specific LCP Fixes

WordPress presents specific LCP challenges because of how themes and plugins load resources. Here are the fixes in priority order, from highest to lowest typical impact.

Fix TTFB first. If you are on shared hosting and your TTFB is above 800ms, no amount of image optimization will get you to 2.5s LCP. Options: switch to a managed WordPress host with server-level caching (Kinsta, WP Engine, Rocket.net), add a page caching plugin (WP Super Cache, W3 Total Cache, WP Rocket), or add a CDN with edge caching (Cloudflare, Fastly). Page caching eliminates the PHP execution and database query overhead for most page requests by serving a pre-rendered static HTML file.

Identify and eliminate render-blocking resources. Install a plugin like WP Rocket or Asset CleanUp to defer non-critical JavaScript and remove unused CSS. The goal is to reduce the number of resources that block rendering before the LCP element starts loading. Use DevTools' Coverage panel to identify CSS rules that are not used on the page — unused CSS loaded in the critical path is pure waste.

Preload the LCP image. Add a <link rel="preload"> tag for the LCP image in the <head> of the page. This instructs the browser to start fetching the image immediately, before the browser would normally discover it by parsing the page content. In WordPress, this can be done with the wp_head action or by using a performance plugin that supports LCP preloading. Include fetchpriority="high" on the <img> tag itself.

Serve images in WebP or AVIF format. WebP typically reduces image file size by 25–35% compared to JPEG at equivalent visual quality. AVIF achieves even better compression but has slightly less universal browser support. Plugins like Imagify, ShortPixel, or WebP Converter for Media can convert your existing image library automatically.

Do not lazy-load the LCP image. This is a common mistake. WordPress 5.5 and later adds loading="lazy" to images by default. If the LCP image gets this attribute, the browser deliberately delays loading it — the opposite of what you want. Remove loading="lazy" from the LCP image and replace it with fetchpriority="high".

Size images correctly. Serving a 3000px-wide hero image to a 390px-wide mobile screen means the browser downloads 10–15x more data than it needs. Use the srcset attribute to serve appropriately sized images at each viewport width. WordPress generates multiple image sizes automatically — make sure your theme is using them correctly via the <picture> element or srcset/sizes attributes.

For the full context of Core Web Vitals on WordPress versus Next.js, see our Core Web Vitals guide.

How Next.js Achieves Sub-2.5s LCP by Architecture

Next.js does not magically produce fast LCP — but its architecture removes several of the constraints that make fast LCP hard on WordPress.

TTFB with static generation or ISR. Next.js with Static Site Generation (SSG) or Incremental Static Regeneration (ISR) serves pre-rendered HTML files from a CDN edge node. There is no PHP execution, no database query, and no plugin initialization on each request. TTFB for a statically generated Next.js page served from a CDN edge can be under 100ms for users geographically near an edge node. This alone eliminates the most common LCP bottleneck.

No render-blocking plugin overhead. WordPress plugins add CSS and JavaScript to every page regardless of whether that page uses the plugin's features. A WordPress site with 15 active plugins might load 8–12 additional CSS files and 6–10 JavaScript files on every page request. Next.js bundles only the code that is actually needed for each page, using automatic code splitting. The result is a dramatically smaller critical resource load.

Native image optimization with next/image. The <Image> component from next/image handles format selection (WebP/AVIF), responsive srcset generation, lazy loading for below-fold images, and — critically — priority prop for the LCP image. Adding priority to the LCP <Image> component automatically adds a preload tag to the <head>, removes lazy loading, and sets fetchpriority="high". This is one prop that replaces several separate optimizations that require manual configuration in WordPress.

CSS-in-JS and scoped styles. Next.js applications commonly use CSS Modules, Tailwind CSS, or styled-components — all of which scope styles to the components that use them. The CSS shipped to the browser contains only styles relevant to the current page. This reduces the CSS payload and eliminates the render-blocking overhead of loading a large global stylesheet.

The tradeoff is that achieving these benefits requires migrating from WordPress — which is an investment. But for sites where LCP is a persistent problem despite WordPress optimizations, the architectural difference is often the reason the benchmark is hard to hit. See our SEO-safe WordPress → Next.js migration page for how we approach this transition without sacrificing rankings.

For other Core Web Vitals issues, including Interaction to Next Paint (INP) optimization, see our INP optimization guide.

Testing LCP After Making Changes

Performance optimization without measurement is guesswork. After implementing any LCP fix, verify the impact before moving to the next change. This helps you understand which fixes are moving the needle and which are not.

For immediate feedback, use Chrome DevTools Performance panel with throttled CPU and network to simulate mobile conditions. Record a load, find the LCP marker, and compare the timing breakdown to your pre-fix baseline.

For a more realistic simulation, use WebPageTest (webpagetest.org). Run tests on a real mobile device profile (Motorola G Power on Slow 3G is a commonly used reference) from a location close to your server. WebPageTest provides a detailed waterfall that shows exactly which resources are blocking which, and it reports LCP with a breakdown of contributing phases.

For field data, wait. CrUX data is collected over a 28-day rolling window. Changes you make today will not be reflected in PageSpeed Insights' field data section for up to four weeks. Do not judge the success of your optimizations on field data during this window — use lab data to validate the fix, then wait for field data to confirm real-world improvement.

Once field data shows a sustained Good LCP (under 2.5s) for at least one full 28-day window, the improvement is stable. Google's Core Web Vitals assessment in Search Console updates monthly based on the field data, so expect the ranking benefit to appear over the following one to two months.

FAQ

What's the most common LCP element on marketing sites?

For most marketing sites with a hero section at the top of the page, the LCP element is the hero image. This is the largest element visible in the initial viewport on both desktop and mobile. The second most common LCP element is a large <h1> heading on pages that do not have a hero image, or on mobile viewports where the hero image is displayed differently. Use PageSpeed Insights on your actual pages to confirm — do not assume.

How do I check my LCP score in the real world (field data)?

The most accessible source for field data is PageSpeed Insights (pagespeed.web.dev). Enter your URL, run an analysis, and look at the "Discover what your real users are experiencing" section at the top, which shows CrUX field data. If Google has enough data for your URL (it requires a minimum number of Chrome user visits in the past 28 days), you will see field LCP, FID/INP, and CLS broken down by mobile and desktop. You can also access CrUX data programmatically via the CrUX API or through Google Search Console's Core Web Vitals report, which aggregates field data across similar pages on your site.

Does image format (WebP vs JPEG) significantly affect LCP?

Yes, meaningfully so — but the impact depends on the starting image and your current format. WebP typically achieves 25–35% smaller file sizes than JPEG at equivalent visual quality, according to the WebP specification and Google's own benchmarks. For a hero image that is 400KB as a JPEG, a WebP version might be 260–300KB. On a Slow 3G connection at 1.6 Mbps, that difference translates to roughly 0.7–0.8 seconds of download time savings. For image LCP elements, switching to WebP (or AVIF, which typically compresses even better) is one of the most reliable improvements available.

Can I hit 2.5s LCP on WordPress, or do I need Next.js?

Yes, you can hit 2.5s LCP on WordPress — but it requires a combination of good hosting (managed WordPress with server-level caching), a CDN, careful plugin management, a well-optimized theme, and consistent attention to image optimization. Many sites achieve this. The challenge is that WordPress's plugin ecosystem makes it easy for new plugins or theme updates to regress LCP without warning. Next.js removes several of the structural constraints that require constant maintenance to keep LCP fast. Whether WordPress optimizations are sufficient depends on your specific starting point — our performance audit assesses exactly this question.

What's the difference between LCP and TTFB?

TTFB (Time to First Byte) measures how quickly the server begins responding to a page request. LCP measures how quickly the largest visible element on the page is fully rendered for the user. TTFB is the first phase within LCP — a slow TTFB always means a slow LCP, because LCP cannot begin until the server responds. But a fast TTFB does not guarantee a fast LCP. The remaining three LCP phases (resource load delay, resource load time, element render delay) can still add seconds even with a sub-200ms TTFB. TTFB is necessary but not sufficient for good LCP.

Next Steps

LCP is the Core Web Vital with the most direct connection to how fast a site feels for real users. It is also the one with the most levers to pull. Start by identifying your LCP element and measuring your four-phase breakdown. Then apply fixes in order of impact, starting with TTFB and working through resource loading.

Related posts:

Services: