Back to blog
How to improve LCP: the complete guide for optimal Largest Contentful Paint
Performance

How to improve LCP: the complete guide for optimal Largest Contentful Paint

Bastien AllainMarch 4, 202626 min read
lcpcore-web-vitalsperformancettfbnextjsimages

Loaded cached credentials.

Yet, despite its widely documented criticality, systematically optimizing LCP remains one of the most formidable technical challenges for engineering teams. Unlike more isolated or purely cosmetic performance metrics, LCP is the unforgiving final output of a profoundly complex and intertwined chain of dependencies. From the initial latency of DNS resolution and the server's initial response time, to the rigorous management of the browser's Critical Rendering Path, the byte weight of media assets, and the main-thread blocking caused by JavaScript execution—a failure or inefficiency at any single stage of this pipeline will inevitably cascade and degrade the final score. The consequences of poor lifecycle management are immediate: they aggressively penalize both the user experience and your visibility in organic search engine results.

This engineering guide deeply explores the underlying mechanics of the Largest Contentful Paint. Moving far beyond superficial recommendations, we will dissect architectural bottlenecks, advanced profiling methodologies, and modern optimization strategies. From re-architecting cloud infrastructures to the granular prioritization of critical assets, the objective is to equip you with the technical expertise required to guarantee an instantaneous, fluid, and highly resilient display of your core content, regardless of the end-user's network conditions or hardware constraints.

What is LCP and why is it crucial?

Definition and measurement mechanics

The Largest Contentful Paint (LCP) is a user-centric performance metric that precisely measures the time elapsed between the initiation of a navigation event and the complete rendering of the single largest visible content element within the user's viewport. On a technical level, the browser's PerformanceObserver API continuously analyzes the evolving Document Object Model (DOM) tree to identify potential candidate elements. These candidates primarily include <img> tags, <video> elements (specifically their poster images), background images loaded via the CSS url() function, and block-level elements containing significant text nodes (such as major headings or large introductory paragraphs).

The true complexity of measuring LCP lies in its highly dynamic nature. Throughout the loading and rendering sequence, the browser's layout engine continuously re-evaluates the candidate element. For instance, a block of descriptive text might render almost instantly, triggering an initial LCP dispatch event. However, if a massive visual banner—often referred to as a hero image—is downloaded and decoded several hundred milliseconds later, subsequently replacing the text as the element occupying the largest surface area in pixels on the screen, the API will overwrite the previous LCP value to reflect the load time of this new image. This continuous evaluation process persists until the page reaches a state of complete interactivity, or until the user initiates an interaction, such as scrolling or clicking. Grasping this mechanism of continuous re-evaluation is the foundational step in identifying the exact target asset you need to optimize.

Google's thresholds: Good, Needs Improvement, Poor

To standardize the evaluation of web experiences on a global scale, Google has established extremely precise performance thresholds for LCP. These benchmarks are not arbitrary; they are the direct result of rigorous statistical analysis of hundreds of millions of real-world user sessions, cross-referenced with behavioral studies on human wait-time tolerance. Today, these thresholds are hardcoded into the core of organic ranking algorithms:

  • Good: An LCP strictly less than or equal to 2.5 seconds. This is the absolute standard of engineering excellence and the mandatory target for any production application. Adhering to this threshold guarantees that the cognitive load of waiting remains imperceptible, ensuring the user perceives the application as inherently fast and responsive.
  • Needs Improvement: An LCP falling between 2.5 seconds and 4.0 seconds. Within this gray zone, the degradation of the user experience becomes consciously perceptible. This range is frequently symptomatic of unoptimized media assets, bloated rendering paths, or a backend server lacking rapid response capabilities. In this bracket, navigation abandonment rates begin to climb steadily, particularly on congested mobile networks.
  • Poor: An LCP strictly greater than 4.0 seconds. This critical threshold triggers severe user frustration. The risk of immediate bounce becomes exponential, engagement metrics collapse, and search engines apply a measurable, systemic penalty to the domain's organic authority.

The impact of LCP on SEO and conversions

The definitive integration of Core Web Vitals as a major ranking signal transformed LCP from a specialized technical monitoring metric into a primary lever for organic traffic acquisition. An optimal LCP signals to search engine crawlers that the underlying technical architecture is robust, healthy, and fundamentally respectful of the user's time. However, moving beyond the isolated benefits of Search Engine Optimization, the most tangible and financially significant impact of LCP optimization is measured directly on conversion rates.

The e-commerce and SaaS industries have spent years documenting a ruthless correlation between the milliseconds saved on the critical rendering path and the subsequent increase in generated revenue. Major industry players consistently demonstrate that a degradation of a mere 100 milliseconds in LCP can slash overall conversion rates by over 1%.

In a hyper-competitive market, a sluggish initial load instantly shatters psychological momentum. If the high-definition photography of a flagship product takes more than three seconds to emerge from a blank white screen, the user's inherent trust in the platform's reliability rapidly erodes. Optimizing LCP is not an exercise in engineering vanity; it is a direct, measurable, and highly profitable intervention on the efficiency of your sales funnel and global user retention.

How to measure your LCP

Lab tools: Lighthouse and DevTools

Modern web performance engineering mandates isolating the measurement process into two distinct, yet deeply complementary environments: the laboratory, which provides deterministic simulation, and the field, which captures the chaotic reality of actual usage. Lab tools offer a controlled sandbox, indispensable for developers during iterative debugging, precise identification of bottleneck elements, and the empirical validation of patches prior to production deployment.

The Lighthouse tool, integrated natively into all Chromium-based browsers, remains the undisputed industry standard for lab testing. By imposing rigorous network throttling—simulating a degraded cellular connection—and artificially underclocking the CPU, Lighthouse exposes structural weaknesses and main-thread congestions that would otherwise remain masked by the immense computational power of developer workstations.

Moving deeper into the investigation, the Performance tab of Chrome DevTools allows engineers to capture a highly detailed loading profile, generating a granular flame chart. Within this interface, developers can dissect the network waterfall request by request, analyze main-thread idle times, and pinpoint the exact millisecond of the LCP dispatch event. DevTools enables you to target the precise DOM node responsible, revealing whether the latency originates from an excessive image decoding phase, a slow TTFB, or a heavy JavaScript compilation task that is blocking the rendering pipeline.

Field data: CrUX and Search Console

While laboratory tests allow engineers to diagnose and repair, only Field Data accurately reflects the raw reality of the user experience. These metrics are harvested from millions of real individuals navigating your application under fundamentally chaotic conditions: varying cellular tower proximity, bandwidth saturation, and constrained memory on low-end mobile devices. Google's infrastructure aggregates this telemetry data anonymously within the Chrome User Experience Report (CrUX).

The Google Search Console operates as the primary dashboard for exposing this CrUX data via its dedicated "Core Web Vitals" report. This is the absolute ultimate judge: Google's algorithm relies exclusively on this trailing 28-day field data to adjust organic rankings.

Web Vitals Chrome Extension

To successfully integrate a culture of performance into the daily workflows of product managers, QA testers, and developers, the official Web Vitals extension proves to be an invaluable continuous diagnostic tool. Rather than requiring heavy, manual audits, the extension discreetly injects a lightweight overlay that displays and refreshes the values of LCP, Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) in real-time as you navigate.

The true power of this extension lies in its one-click visual debugging capabilities. During a routine QA sweep, clicking on the LCP metric within the extension overlay applies a bright green highlight directly onto the DOM element identified by the browser's API. This immediate visual feedback short-circuits hours of investigation. If the highlight reveals that the LCP component is not the highly optimized hero image as architected, but rather an obscure text carousel injected dynamically via a third-party tag manager ten seconds later, the architectural flaw becomes glaringly obvious and the path to correction is immediately clear.

Most common causes of poor LCP

To drastically lower the Largest Contentful Paint time, an engineer must dissect the global loading timeline into precise sub-metrics: the Time to First Byte (TTFB), the resource discovery delay, the duration of the actual payload download, and finally, the render delay of the element on the screen. Each distinct phase harbors its own specific vulnerabilities and architectural bottlenecks.

Slow server response times (TTFB)

The Time to First Byte (TTFB) measures the fundamental latency of the network and the backend server: it is the precise duration elapsed between the initial DNS resolution and the client's receipt of the very first byte of the HTML response. If your backend infrastructure requires 1.5 full seconds to route the request, query an overloaded database, instantiate a server-side framework, and compile the final HTML document, it becomes mathematically and physically impossible to achieve an LCP of under 1.5 seconds.

This initial delay serves as the absolute bottleneck for the entire loading cascade. Absolutely no other critical resources on the page (CSS stylesheets, essential executable scripts, web fonts, or high-priority images) can be discovered—let alone downloaded—until the browser has received and begun to parse that initial HTML structure. A sluggish, under-provisioned backend or poorly indexed SQL queries will decimate your LCP metric before the frontend rendering engine even has the opportunity to initialize.

Render-blocking resources (CSS, JS)

Before it can paint a single colored pixel onto the browser canvas, the rendering engine must complete a colossal amount of preparatory computation: it must synchronously construct both the Document Object Model (DOM) from the HTML payload and the CSS Object Model (CSSOM) from the stylesheets. The HTML parsing process is strictly sequential. Whenever the parser encounters a synchronous <script> tag or a link to a massive stylesheet, the browser is forced to violently halt DOM construction.

<!-- Architectural failure: total blockage of the critical rendering path -->
<head>
  <!-- The screen remains entirely blank until this file is downloaded and parsed -->
  <link rel="stylesheet" href="/assets/monolithic-styles-400kb.css">
  
  <!-- Synchronous execution that monopolizes the main thread, freezing the UI -->
  <script src="/js/legacy-bundle-app.js"></script>
</head>

These assets are accurately classified as render-blocking resources. If the display and formatting of your LCP element depend on the prior resolution of a heavy, unoptimized CSS file, the browser will hold the page hostage on a completely white screen, or at best, display unstyled, malformed text. The cumulative delay caused by downloading, parsing, and executing these monolithic files blocks the pipeline entirely, pushing the rendering of critical content back by several seconds.

Unoptimized images

In the overwhelming majority of contemporary web interfaces—spanning e-commerce platforms, media outlets, and marketing landing pages—the element elected as the LCP is a multimedia asset. This is typically a hero banner, a dynamic carousel, or a high-resolution product photograph. The negligent handling of these specific visual resources ranks among the most severe causes of LCP penalties. This technical negligence generally manifests in three major forms:

  1. Excessive Kilobyte Weight: Continuing to serve uncompressed JPEG or PNG files weighing several megabytes, completely ignoring the radical efficiency and massive payload reductions offered by modern compression formats like WebP or AVIF.
  2. Lack of Responsive Adaptation: Serving a single, monolithic image file scaled to 4000 pixels wide (intended for 4K desktop monitors) to a smartphone confined to a 400-pixel viewport. This forces the mobile device to download megabytes of completely useless pixel data and brutally wastes its battery life during the hardware-intensive downscaling operation.
  3. Late Asynchronous Discovery: Injecting critical hero images asynchronously via client-side JavaScript frameworks (a historical anti-pattern prevalent in early Single Page Applications lacking Server-Side Rendering), or declaring hero images exclusively within CSS files via the background-image property. These practices completely hide the LCP assets from the browser's Preload Scanner, relegating their discovery and subsequent download to the very end of the network waterfall.

Late-loading web fonts

Modern typographic aesthetics, if not strictly governed by rigorous loading strategies, introduce severe delays into the critical rendering path. In highly frequent scenarios where the LCP element is purely textual (such as a monumental <h1> hero heading), the browser's behavior regarding web font downloads becomes the deciding factor. Rendering engines historically adopt highly problematic fallback behaviors: the FOUT (Flash of Unstyled Text), where text initially renders with a basic system font causing a jarring visual layout shift, or the FOIT (Flash of Invisible Text), where the text remains entirely invisible while the browser waits for the font file to traverse the network.

If your .woff2 files are hosted on distinct third-party domains (such as unoptimized cloud font services), each individual file will demand its own dedicated latency chain: DNS resolution, TCP connection establishment, and a secure TLS negotiation handshake. In the absence of early preloading directives, the final rendering of your primary typography will be suspended for hundreds of vital milliseconds, irreparably dragging the page's LCP score into unacceptable thresholds.

Optimizing server resources (TTFB)

The primary step, and arguably the most foundational phase, of any robust optimization strategy targeting a pristine LCP is to eradicate wait-latency at its absolute root: the hosting infrastructure. A blazing-fast, highly stable Time to First Byte is the non-negotiable prerequisite for any hope of dropping below the strict 2.5-second barrier mandated by Core Web Vitals.

Choosing the right hosting and CDN

The physical architecture and network topology governing your production environment dictate an overwhelming percentage of your base, incompressible latency. Maintaining a professional, revenue-generating application on under-provisioned shared hosting servers—where your application fights for CPU cycles with hundreds of other tenants—introduces a massive variance in processing latency that is entirely unacceptable by modern performance standards. It is critical to allocate engineering budgets toward highly available, containerized, or dedicated cloud infrastructures capable of elastically absorbing massive traffic spikes without yielding a single millisecond in database query response times.

However, the raw computational horsepower of the world's most advanced server cannot bypass the laws of physics and the speed of light. Network transfer latency is directly correlated to the physical geographic distance separating the client's device from the data center. This is precisely where the implementation of a premium Content Delivery Network (CDN) transitions from optional to mandatory. A CDN operates as a global distribution shield, massively replicating your static assets (HTML documents, compiled CSS, executable scripts, and media) across a mesh network of hundreds of Points of Presence (POPs) strategically distributed across the globe. Consequently, when a client browsing from Tokyo requests your platform initially hosted in Paris, the CDN intelligently routes that request to serve the payload from an edge node located within Tokyo itself. This physical intermediation slashes the inherent data transit latency from hundreds of milliseconds to a completely negligible fraction.

Server-side caching

Every single millisecond of CPU time consumed by your backend application to dynamically assemble an HTML document that is functionally identical to the one served to the previous request represents a total loss of performance. Server-Side Caching aims to entirely bypass this redundant computational labor. This technique involves aggressively memorizing the final output of complex calculations, object serialization, and expensive SQL queries, allowing the server to return the payload instantaneously from high-speed RAM during subsequent requests.

At the network layer, this is achieved through the expert manipulation of HTTP cache headers for all immutable assets, thereby aggressively offloading the request burden to client browsers and intermediate reverse proxies.

// Implementing an aggressive HTTP caching strategy using Node.js and Express
app.use('/static/assets', express.static(path.join(__dirname, 'public'), {
  maxAge: '1y',
  immutable: true, // Informs the browser engine that this specific file will never change
  setHeaders: (res, path) => {
    // Force a long-duration public cache to completely bypass future network requests
    res.setHeader('Cache-Control', 'public, max-age=31536000, immutable');
  }
}));

For highly structural content such as fully generated HTML pages, deploying a Full Page Caching strategy pushed all the way to the CDN edge guarantees an almost non-existent TTFB. Modern meta-frameworks drastically simplify these complex caching architectures through features like Incremental Static Regeneration (ISR). ISR intelligently combines instantaneous cache delivery with highly optimized asynchronous invalidation protocols (Stale-While-Revalidate), perfectly balancing the need for absolute speed with the requirement for data freshness.

Edge Computing and edge rendering

Edge Computing undeniably represents the most powerful architectural paradigm shift of the decade regarding extreme TTFB optimization, and by direct cascade, the collapse of LCP metrics. Rather than routing all traffic back to execute complex application logic within a monolithic central server cluster, Edge architecture distributes and deploys ultra-lightweight serverless functions directly onto the CDN's global network, executing logic at the physical periphery closest to the end-user's connection.

By leveraging modern peripheral execution environments (such as Cloudflare Workers, Vercel Edge infrastructure, or Fastly Compute), the application can intercept the initial request, query globally replicated databases, and crucially, begin to stream the HTML response in chunks back to the client's browser. This HTML streaming technique ensures the client receives the initial <head> tags instantaneously. Consequently, the browser's Preload Scanner can begin parsing the document and parallelizing download requests for critical CSS files and the LCP image many milliseconds before the edge server has even finished assembling and flushing the footer of the page. This elite level of network parallelization and preemptive execution is the true engineering key to shattering physical latency limits and consistently achieving sub-second LCP scores on a global scale.

Optimizing images and media

Visual content frequently constitutes the primary element evaluated by the Largest Contentful Paint metric. Whether your architecture relies on a massive hero image, an autoplaying background video, or a dynamic product carousel, the total byte weight and the specific delivery mechanics of these resources directly dictate your final performance scores. Delivering an unoptimized media asset is undeniably the number one root cause of a failing LCP.

Modern formats: WebP, AVIF

The era of relying exclusively on legacy formats like JPEG and PNG is definitively over. In 2026, the deployment of next-generation compression formats is no longer an optional enhancement; it is a strict engineering standard.

The AVIF (AV1 Image File Format) currently dominates the landscape by offering the most aggressive compression ratios available, routinely outperforming WebP by approximately 20% to 30% at an identical visual quality threshold, and completely eclipsing traditional JPEGs by over 50%. While WebP enjoys near-universal browser support, AVIF has also achieved massive, widespread adoption across modern rendering engines.

To guarantee maximum cross-browser compatibility while simultaneously serving the most hyper-optimized payloads to capable devices, it is strongly recommended to utilize the HTML <picture> element. This structure allows the browser's internal engine to autonomously select and decode the most optimal format it natively supports.

<picture>
  <!-- Browsers supporting AV1 will prioritize and download this highly compressed asset -->
  <source srcset="hero-image.avif" type="image/avif">
  
  <!-- Excellent fallback for older browsers lacking AVIF support -->
  <source srcset="hero-image.webp" type="image/webp">
  
  <!-- Ultimate fallback ensuring complete backwards compatibility -->
  <img src="hero-image.jpg" alt="Main hero illustration defining the page content" width="1200" height="800">
</picture>

Sizing and responsive images (srcset)

Delivering a monolithic, 4000-pixel-wide image payload to a user navigating on a smartphone via a 4G connection is a catastrophic engineering failure for LCP. The mobile browser is forced to download a massive, entirely useless file, consuming valuable bandwidth, only to waste further CPU cycles locally downscaling the image to fit the constrained viewport.

Implementing the srcset attribute, tightly coupled with the sizes attribute, empowers you to provide the browser with a comprehensive catalog of available dimensions. The browser's engine will mathematically calculate and select the most perfectly adapted image file based on the current viewport width and the hardware's specific Device Pixel Ratio.

<img 
  src="hero-800w.jpg"
  srcset="hero-400w.jpg 400w, 
          hero-800w.jpg 800w, 
          hero-1600w.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 
         (max-width: 1200px) 50vw, 
         33vw"
  alt="Highly responsive hero illustration"
  width="1600"
  height="900"
>

Furthermore, it is an absolute imperative to always explicitly declare the width and height attributes within the <img> tag. This critical practice allows the rendering engine to preemptively reserve the exact spatial dimensions required within the layout before the image bytes are even downloaded, entirely eliminating the risk of Cumulative Layout Shift (CLS)—another highly scrutinized Core Web Vital.

Lazy loading vs eager loading for LCP

Deferred loading, universally known as lazy loading, is a spectacular architectural practice designed to drastically conserve network bandwidth by strictly delaying the download of media assets until they physically intersect with the user's viewport. However, applying lazy loading mechanics to the specific element functioning as your LCP candidate is a catastrophic performance error.

If the LCP image is constrained by lazy loading, the browser will wait until it has completely constructed the DOM, calculated all CSSOM styles, finalized the entire layout geometry, and finally determined that the image actually resides within the viewport before it even initiates the network request. This deeply serializes the rendering path and artificially delays the most critical visual display.

The Golden Rule: The element identified as your LCP candidate must always strictly utilize immediate, priority execution, known as eager loading.

<!-- Severe Anti-Pattern: Will drastically penalize your LCP score -->
<img src="hero.jpg" loading="lazy" alt="Main hero banner">
 
<!-- Engineered Best Practice: Ensures immediate discovery and priority downloading -->
<img src="hero.jpg" loading="eager" fetchpriority="high" alt="Main hero banner">

Injecting the fetchpriority="high" attribute provides an explicit, undeniable directive to the browser's internal network stack, forcing it to immediately elevate this specific resource to the absolute top of its download queue, preempting even lower-priority executable scripts or non-critical stylesheets.

Loaded cached credentials.

When a browser constructs a web page, it parses the HTML document from top to bottom. If it encounters a synchronous script or an external stylesheet, it must abruptly halt HTML parsing, fetch the resource over the network, and execute or apply it before it can continue. These elements are known as render-blocking resources, and they represent one of the most common and severe bottlenecks preventing a fast Largest Contentful Paint.

To ensure the browser can discover and render the LCP element as quickly as possible, you must aggressively manage how and when CSS and JavaScript are delivered to the client.

Optimizing CSS delivery and avoiding import chains

CSS is inherently a render-blocking resource. The browser is designed to prevent a Flash of Unstyled Content (FOUC), meaning it will not render the page until it has fully constructed the CSS Object Model (CSSOM). If your primary stylesheet is massively bloated with unused rules, the browser will sit idle, delaying the rendering of your LCP element.

To mitigate this, you should separate your CSS into critical and non-critical segments. Critical CSS should be prioritized, while non-critical CSS—such as styles for footers, complex interactive states, or off-canvas menus—should be deferred.

A common, highly effective pattern for deferring non-critical CSS utilizes a clever manipulation of the media attribute:

<!-- The browser downloads this asynchronously because it assumes it is only for printing -->
<link rel="stylesheet" href="/css/non-critical.css" media="print" onload="this.media='all'">
 
<!-- Fallback for users with JavaScript disabled -->
<noscript>
  <link rel="stylesheet" href="/css/non-critical.css">
</noscript>

In this pattern, setting media="print" tells the browser that this stylesheet is not required for the initial screen rendering, allowing it to load the file asynchronously without blocking the main thread. Once the file finishes loading, the onload event handler seamlessly switches the media type to all, applying the styles to the document safely.

Managing JavaScript execution and code splitting

JavaScript can block HTML parsing, delaying the discovery of your LCP element entirely—especially if the LCP element is an image defined later in the document.

You must systematically audit your <head> and <body> tags for synchronous <script> elements. For any script that does not fundamentally need to execute immediately before the page renders, you should use either the defer or async attribute.

<!-- Blocks parsing until downloaded and executed. Avoid this in the <head>. -->
<script src="/js/heavy-analytics.js"></script>
 
<!-- Downloads in the background, executes after HTML parsing is complete. Maintains execution order. -->
<script src="/js/ui-components.js" defer></script>
 
<!-- Downloads in the background, executes as soon as it is ready. Does not guarantee order. -->
<script src="/js/third-party-widget.js" async></script>

Beyond attributes, you should employ code splitting. Modern bundlers like Webpack, Vite, or Rollup allow you to split massive JavaScript bundles into smaller, logical chunks. Instead of forcing the user to download the entire application logic upfront, you only load the JavaScript necessary for the initial route. Components required for modal windows or subsequent pages are loaded dynamically later, freeing up the main thread during the critical initial load sequence.

7. Optimizing the Critical Rendering Path

The Critical Rendering Path (CRP) is the intricate sequence of steps the browser executes to convert raw HTML, CSS, and JavaScript bytes into painted pixels on the user's screen. Optimizing this path is about ruthlessly prioritizing the resources required to render the initial viewport, thereby aggressively accelerating your LCP.

Inlining Critical CSS

While deferring non-critical CSS is an excellent step, you still need to load the styles required for the above-the-fold content. If you rely on an external stylesheet for these critical styles, the browser must still initiate a network request, wait for the response, and parse the CSS before any painting can occur.

A highly advanced optimization technique is to extract the critical CSS—the absolute minimum styles required to structurally render the top portion of your page—and inline it directly within a <style> block in the <head> of your HTML document.

<head>
  <style>
    /* Critical CSS: Minimal styles required for the header and hero section */
    body { margin: 0; font-family: system-ui, sans-serif; background: #fff; }
    .header { display: flex; padding: 1rem; border-bottom: 1px solid #eaeaea; }
    .hero-container { min-height: 50vh; display: grid; place-items: center; }
    .hero-title { font-size: clamp(2rem, 5vw, 4rem); color: #111; }
  </style>
  
  <!-- Deferred non-critical CSS loads in the background -->
  <link rel="stylesheet" href="/css/main.css" media="print" onload="this.media='all'">
</head>

By inlining this CSS, you successfully eliminate an entire network round-trip from the critical rendering path. The browser can immediately construct both the DOM and the CSSOM simultaneously from the initial HTML payload, allowing it to paint the text and structure of the LCP element almost instantaneously.

Controlling Web Font Loading

Typography frequently dictates the LCP element, particularly on articles or text-heavy landing pages. However, custom web fonts can introduce severe performance penalties, resulting in either a Flash of Invisible Text (FOIT) or a Flash of Unstyled Text (FOUT). If the browser hides the text while waiting for a slow font file to download, your LCP timing will pause until the font finally renders.

To optimize typography for LCP, you must instruct the browser to display fallback text immediately using the font-display: swap property in your CSS.

@font-face {
  font-family: 'BrandFont';
  src: url('/fonts/brand-font-regular.woff2') format('woff2');
  font-display: swap; /* Crucial for fast text LCP */
}

Additionally, if your LCP element relies heavily on a specific font, you should explicitly preload that font file high up in the document head:

<link rel="preload" href="/fonts/brand-font-regular.woff2" as="font" type="font/woff2" crossorigin>

Preloading and the Fetch Priority API

Sometimes your LCP element is a heavy image asset that the browser discovers too late in the parsing process. For instance, if your LCP element is injected via client-side JavaScript or exists as a background image defined in an external CSS file, the browser remains entirely unaware of it until those blocking resources are executed or parsed.

To resolve this, you can utilize the <link rel="preload"> directive. This strictly commands the browser to initiate a high-priority fetch for a specific resource immediately, regardless of where it is positioned in the DOM.

However, modern browsers have introduced an even more precise mechanism: the Fetch Priority API. By adding the fetchpriority="high" attribute to your primary LCP image, you explicitly instruct the browser's internal network stack to prioritize its download over other concurrent requests, such as lower-priority images or tracking scripts.

<head>
  <!-- Preload syntax for background images -->
  <link rel="preload" as="image" href="/images/hero-banner.jpg" fetchpriority="high">
</head>
<body>
  <!-- Standard inline image syntax -->
  <img 
    src="/images/hero-banner.jpg" 
    alt="Main promotional banner" 
    fetchpriority="high" 
    decoding="sync"
  >
</body>

Resource Hints: Preconnect and DNS-Prefetch

If your LCP element relies on assets hosted on a third-party domain (such as an external Content Delivery Network or an analytics-driven image

Related posts