Why Your LCP (Largest Contentful Paint) Is Slow and How to Fix It Manually

If you’ve run a Lighthouse test and seen a poor LCP score, you’re not looking at a simple “speed” issue. You’re looking at a breakdown in your website’s critical rendering path, specifically in how your most important content is delivered. Largest Contentful Paint (LCP) measures how long it takes for the largest visible element usually a hero image, a banner, or a large block of text to render on the screen. A good LCP is under 2.5 seconds. Beyond that, you’re losing users and signaling to search engines that your page isn’t providing a good experience.

In WordPress, a slow LCP is rarely one problem. It’s a cascade of small failures: a server waiting too long to respond, a massive image being loaded without optimization, CSS and JavaScript blocking the browser from rendering anything, and a theme that prioritizes features over performance.

This guide is for those who want to move beyond plugin-based “optimizations” and understand the root causes. We’re going to dig into the manual, technical fixes that address LCP at its source.

Understanding LCP: What It Actually Measures

LCP marks the point in the page load timeline when the largest text block or image element within the viewport becomes visible. It’s a user-centric metric it measures when they see the main content.

The candidates for LCP are:

• <img> elements
• <image> elements inside an <svg>
• <video> elements (the poster image is used)
• An element with a background image loaded via the url() function (with some important caveats)
• Block-level elements containing text nodes

Crucially, LCP is about painting. The element must be rendered to the screen. This means the browser must have downloaded the asset, processed the HTML and CSS, calculated layouts, and finally painted the pixels. A bottleneck at any of these stages delays your LCP.

The Root Causes: A Diagnostic Framework

Before you change a line of code, you need to know what you’re fighting. Use this diagnostic sequence.

1. Identify Your LCP Element.
Open your page in Chrome DevTools.

• Go to the Performance panel.
• Click Record, then reload the page.
• In the trace, find the Timings section and click LCP.
• In the Summary pane below, it will show you the exact element (e.g., img.hero-banner).

This tells you what you need to optimize. If it’s an image, your job is mostly about resource loading. If it’s a text block, your fight is against web fonts and render-blocking CSS.

2. Measure Your Time to First Byte (TTFB).
This is the foundational metric. In the same Performance trace, check the TTFB timing. If TTFB is above 600ms on a decent connection, your server is the primary bottleneck. No amount of image optimization will fix an LCP that’s waiting 1.5 seconds just to start.

3. Analyze the Network Waterfall.
In DevTools, go to the Network tab, disable cache, and reload. Throttle to “Fast 3G.” Look at the waterfall chart for your LCP resource (the hero image file). Ask:

• When did its request start? Is it delayed by other scripts or styles?
• How long is its download time? A multi-second download for a single image is the problem.
• What is its priority? Is it marked as “High” or “Low”? Images in the viewport should be “High.”

Now, let’s fix the problems, starting from the server and moving up the stack.

Cause 1: Slow Server Response (TTFB)

Your LCP cannot be faster than your TTFB plus the time it takes to load the LCP resource. A slow TTFB means the browser is idle, wasting precious milliseconds before it can even request your hero image.

Why it happens in WordPress:
WordPress is dynamic. For every page request, it typically executes PHP code, makes database queries (for posts, menus, options), loads plugins, and assembles HTML. This process is computationally expensive if not cached.

The Manual Fixes:

A. Implement Robust Object Caching.
This is the single most effective server-side improvement. Object caching stores the results of database queries in memory. When the same query is needed again (e.g., “get the site’s menu items”), it’s served from RAM instead of hitting the database.

• Solution: Install and configure a persistent object caching extension like Redis or Memcached.
  1. Ensure your hosting supports it (many managed hosts do; for VPS, you’ll install it yourself).
  2. Install the corresponding PHP extension (php-redis or php-memcached).
  3. Use a WordPress plugin like Redis Object Cache or Memcached Redux to enable the connection.
  4. Verify it’s working in the plugin settings. A hit rate above 90% is excellent.
  This can reduce TTFB on uncached requests from >1500ms to <400ms.

B. Use a Full-Page Cache (Correctly).
Object caching helps dynamic requests. A full-page cache serves a completely static HTML file, bypassing PHP and MySQL entirely for logged-out users.

• For LiteSpeed Users: The LiteSpeed Cache plugin, coupled with the LiteSpeed Web Server, is unmatched. Enable page caching and set sensible purge rules.
• For NGINX/Apache: Use a plugin like WP Super Cache in “Expert” mode, which delivers static .html files via rewrite rules. Avoid “simple” mode as it still uses PHP.
• Critical Configuration: Ensure your cache is serving HTML with the correct headers. Cached pages should have a Cache-Control header. Exclude truly dynamic elements (e.g., shopping cart) via ESI (LiteSpeed) or AJAX.

C. Optimize Your Hosting Stack.

• PHP Version: Run PHP 8.0 or higher. Each major version brings significant performance gains.
• OPCode Cache: Ensure OPCache is enabled and configured in your php.ini. This caches compiled PHP scripts in memory.
  ini opcache.enable=1 opcache.memory_consumption=256 opcache.interned_strings_buffer=32 opcache.max_accelerated_files=10000 opcache.revalidate_freq=2
• Choose the Right Host: Shared hosting is often the root cause. If your site is business-critical, consider a managed WordPress host with built-in performance features or a well-configured VPS. The baseline cost of poor hosting far outweighs the monthly fee of a good one.

Cause 2: Unoptimized LCP Resource (Usually an Image)

Once the browser has the HTML and knows it needs a hero image, it requests it. If that image is 2 MB and served from a slow server, your LCP is doomed.

Why it happens:
WordPress themes often use full-size images for hero sections. Users upload multi-megabyte photos from their cameras. The theme or page builder calls the_post_thumbnail( 'full' ) or uses a background image with a huge size.

The Manual Fixes:

A. Serve Modern, Compressed Image Formats.

• WebP is Non-Negotiable. WebP typically provides 25-35% smaller file sizes than JPEG at similar quality. WordPress now generates WebP versions by default (since 6.5 with Performance Lab plugin), but you must ensure they are being served.
  • Check: Look at the Network tab. Is your hero image a .jpg or a .webp?
  • Fix: Use a plugin like Webp Converter or Imagify for bulk conversion and setup delivery rules. For a manual, code-based approach, you can use the picture element or modify theme templates to use wp_get_attachment_image_srcset() which supports WebP in modern WordPress.
• AVIF for the Cutting Edge: AVIF offers even better compression. Consider using a CDN like Cloudflare or Bunny.net that provides automatic AVIF conversion and delivery.

B. Resize the Image to Its Display Dimensions.
A 4000px wide image displayed in a 1200px container is wasteful. You must deliver a source image that is close to the rendered size.

• Manual Method: In your theme’s template file (e.g., front-page.php or header.php), do not use the_post_thumbnail( 'full' ).
  Instead, create a specific image size for your hero:
  php // In your theme's functions.php add_image_size( 'hero_large', 1200, 675, true ); // Cropped to 16:9 add_image_size( 'hero_large_2x', 2400, 1350, true ); // For retina
  Then, in your template:
  php echo wp_get_attachment_image( get_post_thumbnail_id(), 'hero_large', false, array( 'srcset' => wp_get_attachment_image_url( get_post_thumbnail_id(), 'hero_large' ) . ' 1x, ' . wp_get_attachment_image_url( get_post_thumbnail_id(), 'hero_large_2x' ) . ' 2x', 'loading' => 'eager', 'decoding' => 'async', 'class' => 'hero-image' ) );
• Use srcset Responsibly: The example above uses a manual srcset. The wp_get_attachment_image() function does this automatically, allowing the browser to choose the best file from multiple sizes. Ensure your theme supports it.

C. Prioritize Loading with fetchpriority="high" and loading="eager".
Tell the browser this image is the LCP candidate.

• fetchpriority="high": Instructs the browser to prioritize this image’s download over other resources.
• loading="eager": Tells the browser to load this image immediately, not lazily.
  You can add these attributes via the wp_get_attachment_image() function’s fourth parameter (the $attr array), as shown in the code above. Some optimization plugins can do this automatically for the detected LCP element.

D. For Background Images, Use Critical Inline Styles.
If your LCP is a CSS background image (e.g., background-image: url(hero.jpg)), the browser won’t discover it until it downloads and parses the CSS file, which is often render-blocking. This is a suboptimal pattern for LCP.

• Better Pattern: Use an HTML <img> tag with object-fit: cover for styling. This allows you to use all the optimization attributes above.
• If You Must Use Background Images: Inline the critical background image rule directly in the HTML <style> tag in the <head> for the element that is above the fold. This ensures the browser knows about it immediately.
  html ¨K10K
  Note: This inlines a potentially large URL. For this reason alone, the <img> tag approach is superior.

Cause 3: Render-Blocking Resources

Before the browser can paint your LCP text or image, it needs to construct the Render Tree. To do that, it needs the CSSOM (CSS Object Model). Any CSS that is linked in the <head> with a standard <link rel="stylesheet"> is render-blocking. The browser must stop, fetch it, and parse it before it can render anything. Similarly, JavaScript with async or defer can block rendering if placed incorrectly.

Why it happens:
WordPress themes and plugins enqueue dozens of CSS and JS files. A typical theme loads 3-4 stylesheets (theme style, block editor style, WooCommerce style, etc.), plus plugins add their own. They all load in the <head> by default.

The Manual Fixes:

A. Generate and Inline Critical CSS.
This is the most powerful technique for text-based LCP and for pages where the LCP image is defined in CSS. “Critical CSS” is the minimal set of CSS rules needed to style the content that is visible in the viewport on page load.

• Manual Generation Process:
  1. Use a tool like Critical (from Addy Osmani) or Lighthouse.
  2. Run it against your live homepage URL. It will generate a file containing only the CSS needed for above-the-fold elements.
  3. Inline this CSS directly into the <head> of your WordPress theme.
     php // In your theme's header.php, inside the <head> section ¨K11K
  4. Load the full stylesheet asynchronously using preload and onload.
     html <link rel="preload" href="<?php echo get_stylesheet_uri(); ?>" as="style" onload="this.onload=null;this.rel='stylesheet'"> ¨K12K
• Automated Approach (Plugin): Plugins like LiteSpeed Cache (with its CSS Critical setting), Autoptimize, or WP Rocket can automate this process. However, manual generation often yields a more accurate, smaller critical CSS file.

B. Defer Non-Critical JavaScript Aggressively.
JavaScript execution can block the main thread, delaying paint.

• Manual Deferral in WordPress: When enqueuing scripts in your theme’s functions.php, set the right flags.
  php // For NON-CRITICAL scripts (e.g., analytics, chat widgets) wp_enqueue_script( 'my-non-critical-script', $src, array(), null, true ); wp_script_add_data( 'my-non-critical-script', 'strategy', 'defer' ); // WordPress 6.3+ // Or the classic method: Manually add `defer` in the script tag via `script_loader_tag` filter.
• Identify Critical vs. Non-Critical: Use the Coverage tab in Chrome DevTools to see which scripts execute before your LCP. Any script not directly involved in rendering the LCP element should be deferred. jQuery and other foundational libraries often block rendering; consider loading them from the footer (in_footer => true).

C. Optimize Web Font Loading.
If your LCP is a text block, the text won’t paint until the web font is loaded, causing a Flash of Invisible Text (FOIT).

• Use font-display: swap: In your @font-face declaration, this tells the browser to immediately show text in a fallback font, then swap when the custom font loads.
  css @font-face { font-family: 'Custom Font'; src: url('font.woff2') format('woff2'); font-display: swap; }
• Preload Key Fonts: Preload the font file used for your main heading/LCP text.
  php // In your theme's header.php or via wp_enqueue_style hook echo '<link rel="preload" href="' . get_theme_file_uri( '/fonts/custom-bold.woff2' ) . '" as="font" type="font/woff2" crossorigin>';
• Consider System Fonts for Body Text: For ultimate LCP performance, using a system-ui font stack for body text eliminates the web font loading delay entirely.

Cause 4: Client-Side Rendering Delays and Heavy JavaScript

When your LCP element is dependent on JavaScript to render, you’ve created a fundamental bottleneck. The browser must download, parse, compile, and execute JavaScript before it can even begin to paint your main content.

Why it happens in WordPress:
This is increasingly common with:

• Modern “React-like” themes that rely on client-side rendering for dynamic components.
• Page builders (Elementor, Divi, WPBakery) that may wrap sections in JavaScript-controlled containers or use JavaScript to calculate and apply styles.
• Slider/hero plugins that use JavaScript to initialize and display the main image.
• Heavy analytics/tracking scripts that execute early and block the main thread.

The Manual Fixes:

A. Identify JavaScript-Driven LCP Elements.
In Chrome DevTools, go to Settings > Experiments and enable “Timeline: event-initiated LCP”. Run a performance recording. If your LCP is triggered by a JavaScript event (like DOMContentLoaded or even later), you have a client-side rendering problem.

B. Server-Side Render Critical Components.
If your hero section is built with a complex JavaScript component, you must ensure its initial HTML is present in the server response.

• For Custom Themes/Components: If you’re building with React or Vue within WordPress, implement Server-Side Rendering (SSR) or at least Static Site Generation (SSG) for the critical above-the-fold component. Tools like Next.js (for headless WordPress) or even WordPress’s own REST API with server-side rendering can achieve this. The key is that the initial HTML contains the visible LCP element.
• For Page Builders: Some builders, like Elementor, have optimization settings. In Elementor, go to Settings > Experiments and activate “Improved Asset Loading” and “Inline Font Icons.” These can help, but understand that many builders will always have some render-blocking JS. For the absolute best LCP, consider if a critical hero section could be hard-coded in your theme template and only use the builder for less critical content below the fold.

C. Defer or Asynchronously Load Non-Essential JavaScript with Precision.
We touched on this, but for LCP, it’s about surgical precision.

• Use the wp_script_add_data Function (WordPress 6.3+): This is the cleanest way to add defer or async to enqueued scripts.
  php // Defer a specific script wp_enqueue_script( 'my-plugin-script', $url ); wp_script_add_data( 'my-plugin-script', 'strategy', 'defer' );
• Manual Filter for Granular Control: add_filter( 'script_loader_tag', function( $tag, $handle, $src ) { // Defer a list of scripts except those critical for LCP $defer_scripts = [ 'contact-form-7', 'analytics-script', 'cookie-plugin' ]; $async_scripts = [ 'social-share' ];if ( in_array( $handle, $defer_scripts ) ) { return str_replace( ' src', ' defer src', $tag ); } if ( in_array( $handle, $async_scripts ) ) { return str_replace( ' src', ' async src', $tag ); } return $tag;}, 10, 3 );
• Critical Exclusion: Never defer scripts that directly affect the rendering of your LCP element. This includes:
  • The theme’s main JavaScript file if it handles hero sliders or animations.
  • jQuery, if your LCP component depends on it (though moving jQuery to the footer with in_footer => true is often safe and recommended).

D. Minimize Main Thread Work.
JavaScript execution blocks the main thread, delaying style calculation, layout, and paint. Use the Performance panel in DevTools to identify long tasks (blocks of JavaScript execution over 50ms).

• Code Splitting: Break your JavaScript bundles into smaller chunks. If using a modern build process (like Webpack), implement dynamic imports for non-critical functionality.
• Web Workers: For heavy computations that aren’t related to the DOM (like sorting large datasets), consider moving them to a Web Worker.

Cause 5: Poor Hosting and Network Issues

All the optimizations in the world can’t fix a fundamentally slow server or a long network distance between your server and your user.

Why it happens:

• Shared Hosting Overselling: Your server’s resources (CPU, RAM) are shared with hundreds of other sites, leading to contention and slow response times.
• Geographic Distance: A user in London accessing a server in Mumbai will have higher latency.
• Unoptimized Database: Over time, WordPress databases accumulate overhead from post revisions, transient options, and unindexed tables.

The Manual Fixes:

A. Choose the Right Hosting Tier.

• Avoid Budget Shared Hosting for Business-Critical Sites: The cost savings are false economy when it impacts conversions and SEO. For a site where performance matters, look at:
  • Managed WordPress Hosting: Providers like Kinsta, WP Engine, or Rocket.net have optimized stacks, built-in caching, and CDNs. They handle server-level optimizations.
  • VPS with LiteSpeed: A Virtual Private Server (like from DigitalOcean or Linode) with LiteSpeed Web Server and the LSCache plugin gives you tremendous control and performance, but requires more sysadmin knowledge.
  • Specialized Performance Hosts: Cloudways (VPS managed platform) or RunCloud for a control panel.

B. Implement a True CDN for Static Assets.
A CDN isn’t just for images. It should deliver all static assets: CSS, JS, fonts, and images.

• Configuration: A proper CDN setup involves creating a pull zone and changing your site’s URL for static assets. Many managed hosts do this automatically.
  php // Sometimes needed in wp-config.php to force asset URLs to CDN define('WP_CONTENT_URL', 'https://cdn.yoursite.com/wp-content');
• Modern CDN Features: Use a CDN that offers:
  • Image Optimization On-the-Fly: (Cloudflare Polish, Bunny Optimizer) Automatically serves WebP/AVIF, resizes images.
  • HTTP/3 (QUIC): Reduces connection latency.
  • Early Hints: Sends hints to the browser about what resources will be needed, improving perceived load time.

C. Database Optimization – Beyond Plugins.
Plugins like WP-Optimize can clean things up, but understand what’s happening:

• Clean Post Revisions: DELETE FROM wp_posts WHERE post_type = 'revision'; (Always backup first)
• Optimize Tables: OPTIMIZE TABLE wp_posts, wp_options, wp_postmeta;
• Autoloaded Options: Reduce the size of the wp_options table by identifying and disabling unnecessary autoloaded data. The Query Monitor plugin’s “Autoloaded Options” section is invaluable for this.

Cause 6: The WordPress Theme Itself

Your theme is the framework for every page. A poorly coded theme is an LCP anchor.

Why it happens:
Themes can be bloated with:

• Dozens of inline styles and scripts in the <head>.
• Unnecessary dynamic PHP calculations on every page load.
• Multiple render-blocking webfonts.
• Complex, nested DOM structures that slow down layout calculations.

The Manual Fixes:

A. Audit with a Default Theme.
This is the most revealing test. Switch temporarily to a default theme like Twenty Twenty-Four. Run an LCP test. If your score improves dramatically (e.g., from 4s to 1.5s), your theme is the primary problem. No amount of plugin optimization will fully fix a fundamentally slow theme.

B. Build or Choose a Theme for Performance.
If you’re building a custom theme or choosing a new one:

• Minimal PHP Processing: The theme’s template files should be lean. Move complex logic to cached functions or background processes.
• Smart Asset Loading: The theme should only load CSS/JS for the features being used on that page. Use wp_enqueue_style/script with conditionals.
• Avoid Massive Frameworks: Many “multipurpose” themes include code for hundreds of features you’ll never use, all loaded on every page. A lean, custom WordPress development approach or a focused “block theme” is often superior for LCP.

C. Manual Theme Surgery.
For an existing theme you’re stuck with:

• Strip Unnecessary <head> Content: Use the wp_head and wp_footer hooks to remove unnecessary meta tags, styles, and scripts added by the theme.
  php remove_action('wp_head', 'theme_custom_font_inline_style'); // Example
• Simplify the Above-the-Fold DOM: Use your browser’s inspector to look at the HTML of your hero section. Is it a nest of 15 <div> tags? If possible, edit the theme template (using a child theme) to flatten the structure. A simpler DOM calculates layout faster.

The Comprehensive LCP Optimization Checklist: A Step-by-Step Workflow

Follow this sequence. Each step builds on the previous one.

Phase 1: Measurement & Baseline (Do Nothing Else First)

1. Run Lighthouse in an incognito window, throttled to “Slow 4G.”
2. Note the LCP score and the identified LCP element.
3. Use Chrome DevTools Performance panel to record a load. Find the LCP timestamp and the associated network request.
4. Check TTFB in the Performance panel or using WebPageTest.org.

Phase 2: Server & Foundation (Aim for TTFB < 400ms)

5. Implement object caching (Redis/Memcached).
6. Ensure full-page caching is active and working (check HTTP headers for x-cache:hit).
7. Upgrade to PHP 8.x and verify OPCache settings.
8. If on shared hosting with poor scores, initiate a migration to a better host. This is often the single biggest fix.

Phase 3: Optimize the LCP Resource

9. If it’s an image: Convert to WebP/AVIF, ensure it’s the correct display size, add fetchpriority="high" and loading="eager". Consider preload if it’s discovered late.
10. If it’s text: Inline Critical CSS for that text and its container. Preload the critical webfont with font-display: swap.

Phase 4: Unblock the Render

11. Generate and inline Critical CSS for the entire above-the-fold area.
12. Defer all non-critical CSS.
13. Identify and defer/non-block load all JavaScript not needed for the LCP. Use defer or async.

Phase 5: Advanced Delivery

14. Set up a CDN for all static assets (wp-content, wp-includes).
15. Implement resource hints (preconnect, dns-prefetch) for your CDN and key third parties.
16. Enable HTTP/2 or HTTP/3 on your server.

Phase 6: Validation & Monitoring

17. Re-test with the same throttled conditions. Compare before/after in the Performance panel waterfall view.
18. Submit URL to Google Search Console for re-crawling.
19. Set up monitoring with Google Search Console Core Web Vitals or a tool like SpeedCurve to track field LCP over time.

The Business Impact: Why Manual LCP Optimization Matters

This isn’t academic. A slow LCP has direct, measurable consequences:

• Bounce Rate Increase: Users leave if the main content doesn’t load quickly. A 1-second delay can increase bounce rate by 30%.
• Lower Conversion Rates: Every millisecond of delay impacts your bottom line. For e-commerce, a 100ms delay can reduce conversion by 1%. For a WooCommerce store, this is revenue lost.
• Search Ranking Penalty: LCP is a Core Web Vitals. Sites with poor LCP are less likely to rank highly in competitive searches.
• Poor User Perception: Your site feels slow and unprofessional, damaging brand trust.

Manual optimization is the difference between a site that’s “fast enough” and a site that’s engineered for speed. Plugins can help, but they work within the constraints of your theme and hosting. Manual fixes address those constraints themselves.

This level of optimization is what I consider essential WordPress maintenance. It’s not a one-time task. As you add new plugins, content, or features, LCP can regress. Regular audits and the disciplined application of these principles are what keep a site performing at its peak, supporting your business goals instead of hindering them.

Final Thought: The Philosophy of Performance

Fixing LCP manually teaches you a deeper truth about WordPress performance: it’s a holistic system. You cannot plugin-your-way out of a server bottleneck. You cannot CDN-your-way out of a 4MB hero image. You cannot cache-your-way out of render-blocking JavaScript from a bloated theme.

True performance comes from understanding how each layer server, cache, CDN, theme, plugin, asset interacts and creating a streamlined pipeline from the server to the user’s screen. It’s engineering, not just optimization. When you approach it this way, a fast LCP isn’t a lucky outcome; it’s the predictable result of a well-architected website.

💡 Developer Pro-Tip: Optimizing for LCP often involves loading resources asynchronously, which can inadvertently lead to layout shifts. Make sure you are balancing speed with stability by following my companion guide: How to Fix CLS in WordPress.