Improve LCP: a complete guide to speeding up your site

TTFB, resource loading, rendering: the four levers that decide LCP, with concrete actions to apply on WordPress to drop below the 2.5-second mark.

You just delivered a WordPress site to a client. The design is polished, the content is in place, the features run smoothly. Then you run a PageSpeed Insights test and the verdict lands: LCP at 4.2 seconds on mobile. The client sees an orange score, asks questions, and your credibility takes a hit before production even starts.

This scenario is familiar to every freelancer and web agency. Improving LCP (Largest Contentful Paint) has become a must for any professional who wants to deliver a site that performs well, ranks well and impresses clients. This guide gives you the keys to diagnose, understand and fix a slow LCP, step by step, with concrete actions you can apply on your next audit.

What LCP is and why the metric matters

LCP within the Core Web Vitals

Largest Contentful Paint measures the time needed to display the largest content element visible in the browser viewport. That element is typically a hero image, a video or a main text block above the fold. Google considers a good LCP to sit under 2.5 seconds at the 75th percentile of visits. Between 2.5 and 4 seconds, the page is rated "needs improvement". Beyond 4 seconds, it is deemed "poor".

LCP is one of the three Core Web Vitals, alongside CLS (Cumulative Layout Shift) and INP (Interaction to Next Paint, which replaced FID in March 2024). These three metrics have been an official ranking signal in Google's algorithm since May 2021, and their weight in organic search has grown with every update.

The concrete business impact on your clients

A slow LCP is not just a bad score in a test tool. According to data published by Google, Vodafone saw an 8% lift in online sales after improving their LCP by 31%. Per the Web Almanac 2025 (HTTP Archive), only 62% of mobile pages achieve a good LCP score, which means nearly four pages out of ten still fail on this metric.

For an agency or a freelancer, these numbers are a powerful commercial argument. An audit that flags a degraded LCP opens the door to an optimization engagement, or even a recurring maintenance contract. LCP turns a technical diagnosis into a business opportunity.

The four sub-parts of LCP

Understanding Google's decomposition

Google recommends breaking LCP into four sequential phases to pinpoint exactly where the bottleneck sits. These four sub-parts, documented on web.dev, cover the full path from the initial request to the display of the main element.

The first phase is TTFB (Time to First Byte), measuring the time between the user's navigation and the arrival of the first byte of the HTML response. The second is LCP resource load delay, the time between TTFB and the moment the browser starts downloading the required image or font. The third is the resource load duration itself. The fourth is the element render delay, the time between download completion and the actual on-screen display.

The 80/20 rule

On a well-optimized page, roughly 80% of LCP time should be spent on network requests (TTFB + resource load) and only 20% on intermediate delays. If your load or render delays exceed that ratio, it signals an architectural issue or blocking resources that needlessly delay display.

In audits run with Orilyt, we regularly observe that LCP resource load delay is the most underestimated phase. The browser cannot download an image it does not yet know exists, and that is exactly what happens when the hero image is injected by JavaScript or referenced only inside a CSS stylesheet.

Optimize TTFB to lay the foundations

Why TTFB conditions everything else

TTFB is the foundation of LCP. If your server takes 2 seconds to respond, reaching an LCP under 2.5 seconds becomes mathematically impossible. Google recommends a TTFB under 800 milliseconds. Every millisecond saved on TTFB feeds directly into LCP and every other loading metric.

The most common causes of a slow TTFB are an overloaded shared host, the absence of server cache, unoptimized SQL queries and the geographic distance between the server and the visitors. To dive deeper, our dedicated guide helps you understand and optimize your TTFB with thresholds, causes and solutions.

Priority actions on the server side

Setting up page cache is the highest-leverage change. On WordPress, a plugin like WP Super Cache or WP Rocket can cut TTFB by 60 to 80% by serving pre-generated HTML pages instead of running PHP and database queries on every visit. For sites with an international audience, a CDN (Cloudflare for example) serves content from a server geographically close to each visitor.

Reducing redirects is another often-overlooked lever. Every redirect adds a full network round-trip. A shortened link that redirects to an intermediate URL and then to the final page can add several hundred milliseconds to TTFB without the visitor noticing.

Reduce the LCP resource load delay

Make the resource discoverable as early as possible

Resource load delay is the time wasted between the HTML arriving and the moment the browser actually starts downloading the LCP element. On a well-built page, this delay should be close to zero. In practice, it explodes when the hero image is loaded via JavaScript, referenced inside an external CSS file, or hidden behind a chain of dependent requests.

The most effective fix is to place the LCP image directly in the page's source HTML, via an img tag, rather than loading it dynamically. The browser discovers images present in HTML as soon as initial parsing starts, before even downloading the stylesheets.

Use preload and fetchpriority

For cases where the LCP image cannot be placed directly in the HTML (a CSS background image, for example), the link rel="preload" tag tells the browser to start downloading immediately. Combined with the fetchpriority="high" attribute, it sends an even stronger priority signal.

Beware of overusing preload. Preloading too many resources dilutes the priority effect and can even slow overall load. Reserve preload for the LCP image and, optionally, the main font. Every extra preloaded resource consumes bandwidth that could have gone to loading the critical element faster.

See the Orilyt documentation to understand how our performance tests automatically detect mis-prioritized critical resources.

Accelerate the LCP image load

Choose the right image format

When the LCP element is an image (which is 76% of mobile cases according to Web Almanac 2025), file size directly impacts load duration. Modern formats like WebP and AVIF deliver significantly better compression than traditional JPEG or PNG, with no perceivable quality loss.

AVIF in particular delivers weight reductions of 30 to 50% compared to WebP on photographs, and its browser compatibility now reaches 94% worldwide. On WordPress, plugins like ShortPixel or Imagify automate conversion and serve the optimal format based on the visitor's browser.

Size images correctly

A common mistake is serving a 2400-pixel-wide image for an 800-pixel mobile display. The browser downloads useless data, which lengthens load time without visual benefit. The HTML srcset attribute lets you serve images adapted to each screen size, and WordPress has supported it natively since version 4.4.

At Orilyt, we analyze the resources loaded by each audited page. When an image is oversized relative to its display zone, the report flags it with a precise recommendation, showing the potential savings in kilobytes.

Never lazy-load the LCP image

Lazy loading intentionally delays loading an image until it nears the visible area. That is excellent for images below the fold, but catastrophic for the LCP element. Per Web Almanac 2025, 16% of mobile sites lazy-load their LCP image by mistake, which practically doubles the load time of that element.

If your hero image carries loading="lazy", remove it immediately and add fetchpriority="high" instead. It is one of the simplest and most impactful fixes you can apply on a WordPress site.

Eliminate unnecessary render delays

Identify the resources that block display

Once the LCP resource is downloaded, the browser still has to display it. That render delay should be minimal, but it can explode when large CSS stylesheets or JavaScript files block the main thread. Until critical CSS is downloaded and parsed, the browser cannot display anything, even if the image is already in memory.

Removing unused CSS is a major lever. On a typical WordPress site using a page builder like Elementor or Divi, it is common for 80% of the loaded CSS to never be used on the current page. Cutting that CSS speeds up parsing and frees the main thread for rendering.

Defer non-critical scripts

JavaScript loaded in head without a defer or async attribute blocks HTML parsing and delays display of every element that follows. Our article on blocking scripts and deferred loading explains in detail why a simple defer attribute can transform a page's load behavior.

Third-party scripts (analytics, chat widgets, ad pixels) are often the first culprits. Every unchecked third-party script consumes CPU time and bandwidth at the most critical moment of load. Best practice is to defer anything not strictly required for the initial display.

Reduce the weight of the HTML itself

An often-ignored point: the HTML document size also impacts render delay. WordPress page builders sometimes generate DOMs of more than 3000 nodes, with layers of nested div elements that add no semantic value. Lighter HTML parses faster, and the LCP element displays sooner.

Some developers gain 25% on LCP simply by reducing the amount of inline code (CSS and JavaScript embedded directly in the HTML). Externalizing those resources into separate files lets the browser cache them and avoid re-downloading on every visit.

Measure and track LCP continuously

Diagnostic tools

PageSpeed Insights remains the reference tool for a point-in-time measurement. It combines lab data (Lighthouse) and field data (Chrome UX Report) for a complete view. The "Diagnostics" section shows the identified LCP element along with a breakdown of the four sub-parts, letting you target the exact phase to optimize.

Google Search Console offers a site-wide overview. The Core Web Vitals report classes every page as "Good", "Needs improvement" or "Poor", based on real Chrome visitor data. It is the ideal tool to identify problematic page templates (every product page, every category page, and so on).

Bake monitoring into your maintenance offer

For a freelancer or an agency, tracking LCP over time is a retention argument. A score that degrades after a new plugin is installed or a homepage slider is added gets caught immediately when monitoring is in place. Orilyt monitors multiple pages continuously and generates periodic white-label reports, usable directly in a client meeting.

Check the Orilyt pricing to include performance monitoring in your maintenance offer.

Set realistic targets

If your current LCP is at 5 seconds, aiming for 2.5 seconds immediately may be unrealistic depending on the infrastructure in place. A progressive approach works better: first get under 4 seconds (out of the "poor" zone), then target 2.5 seconds in a second phase. Prioritize the pages that drive traffic or conversions, where the ROI of optimization is highest.

Document every intervention and measure the before/after impact. A comparison table showing an LCP dropping from 4.1 to 2.2 seconds is infinitely more convincing than a technical pitch when justifying your work to a non-technical client.

Frequently asked questions

Sources and references

• Google web.dev, Optimize Largest Contentful Paint — official LCP optimization guide by Google
• Google web.dev, Largest Contentful Paint (LCP) — official definition and thresholds of the LCP metric
• Google web.dev, Common misconceptions about how to optimize LCP — LCP sub-parts analysis based on CrUX data
• HTTP Archive, Web Almanac 2025, Performance — web performance statistics and LCP compliance rates
• MDN Web Docs, Fix your website's LCP by optimizing image loading — best practices for LCP image optimization