The Ultimate Core Web Vitals Checklist (2026)

Table of Contents!

• The Ultimate Core Web Vitals Checklist
• Core Web Vitals Optimization Checklist
  • Optimize Images
  • Optimize Web Fonts
  • Optimize Scripts
  • Optimize Styles
  • Optimize Resource Hints
  • Optimize Icons
  • Optimize Server Response Times
  • Optimize Interactivity
  • Core Web Vitals Monitoring
  • Optimize Critical Rendering Path
  • Optimize Cookie Consent
  • Optimize Single Page Applications
  • Avoid Excessive DOM Size
  • Optimize API Requests
  • Optimize Chat Widgets
  • Optimize Service Worker Performance
  • Optimize Video Content

Optimize Images

Large images in the visible viewport will, most of the time, become the Largest Contentful Paint element. Optimizing images is one of the highest impact actions you can take for LCP. Use these core web vitals checklist items to improve image speed. For a deep dive, read our guide on how to optimize the LCP image.

• Resize images to match the largest on-screen dimensions: This ensures that bytes are never wasted on downloading images larger than their maximum on-screen size. Combine this practice with responsive images for smaller screen sizes. Serving correctly sized images can reduce image file sizes by 50% or more without any visible quality loss.
• Use lazy loading for below-the-fold images: Lazy loading delays the loading of images outside the viewport until they are scrolled into view, improving First Contentful Paint (FCP) and overall page load speed. Never lazy load the LCP image, as this will significantly delay it.
• Preload visually important images like the LCP element: Preloading instructs the browser to fetch critical images before the rest of the content, prioritizing LCP. Use <link rel="preload" as="image"> combined with fetchpriority="high" for the best results. This is especially important when the LCP image is referenced from CSS or loaded via JavaScript.
• Set width and height: Defining image dimensions upfront prevents layout shifts caused by the browser waiting for images to load. This improves CLS. Modern browsers use width and height attributes to calculate the aspect ratio before the image has loaded, reserving the correct amount of space.
• Use modern image formats like WebP or AVIF: These formats offer smaller file sizes compared to JPEG or PNG while maintaining similar quality, leading to faster loading times. WebP typically achieves 25-34% smaller files than JPEG, while AVIF can reduce file size by up to 50%. Use the <picture> element with format fallbacks for maximum browser compatibility.
• Use native lazy loading and disable JavaScript based lazy loading: Lazy loading delays the loading of images outside the viewport until they are scrolled into view. Native lazy loading offered by browsers via the loading="lazy" attribute is generally more efficient than relying on JavaScript for this task, as it does not require extra script parsing or execution.
• Use responsive images with srcset: This attribute specifies different image versions for various screen sizes, ensuring the browser delivers the optimal image for the user's device, reducing unnecessary large downloads. Combine srcset with the sizes attribute for precise control.
• Add decoding="async": The decoding="async" attribute prevents the browser from blocking other content while decoding an image. This allows the rendering engine to continue painting other elements while image decoding happens in parallel.
• Strip image metadata: Metadata like EXIF data embedded in images can add unnecessary bytes. Stripping this information can reduce file size without affecting image quality. Tools like ImageOptim, Squoosh, or Sharp can automate metadata removal as part of your build process.
• Avoid CSS background images for LCP elements: Background images referenced in CSS are discovered later by the browser than <img> elements in HTML. If you must use a background image as the LCP element, preload it with a <link rel="preload"> tag to ensure early discovery. Learn more about LCP resource load delay.

Optimize Web Fonts

Web fonts can delay the First Contentful Paint, cause layout shifts, and compete for early bandwidth resources. Use this checklist to ensure a smooth web font experience. For font hosting best practices, see our guide on self-hosting Google Fonts.

• Use font-display: swap for faster first paint: Set the font-display property to swap in your @font-face declarations. This ensures that the browser displays a fallback font immediately while loading the web font in the background. Once the font is ready, it swaps it out seamlessly. Read more about ensuring text remains visible during webfont load.
• Use font-display: optional combined with preloading to eliminate layout shift caused by fonts: Combining font-display: optional with preloading offers a balance between speed and potential layout shifts. The optional value hides text briefly (around 100ms) before using a fallback font. Preloading instructs the browser to fetch the web font early, minimizing the time spent on fallback fonts and reducing layout shifts.
• Use font-face descriptors to make the fallback font match the web font's dimensions: This ensures minimal CLS when the web font swaps in. By specifying similar metrics using size-adjust, ascent-override, descent-override, and line-gap-override for the fallback font, you can prevent content from jumping around as the font loads.
• Subset fonts to include only necessary characters: Reduce font file size by subsetting fonts to include only the characters needed for your content. Tools like Font Squirrel, pyftsubset, or glyphhanger can help generate subsets. A full Latin character set font can often be reduced from 100KB+ to under 20KB with proper subsetting.
• Limit the number of font weights and styles: Avoid loading excessive font variations. Stick to a maximum of 2 critical fonts (usually preloaded) and 2 late loading fonts (loaded after initial rendering). Each additional font weight adds 15 to 50KB of download size.

Optimize Scripts

Scripts can cause Interaction to Next Paint issues, trigger Cumulative Layout Shifts, or delay the Largest Contentful Paint. Even optimized and relatively harmless early scripts can compete for resources and delay paint metrics (LCP and FCP). For a full guide, see 14 methods to defer JavaScript.

• Remove unnecessary JavaScript: Identify and eliminate unused JavaScript code to minimize the amount of code that needs to be downloaded and executed. Use Chrome DevTools Coverage tab to find unused code. Removing dead code reduces both download time and main thread processing.
• Prioritize scripts based on their function and importance: Scripts that make large changes to the visible viewport should be render blocking. Important scripts should be deferred or loaded async. Nice to have scripts should load at browser idle. See our resource prioritization guide for a detailed strategy.
• Code splitting and lazy loading: Break down large JavaScript bundles into smaller chunks and load them only when needed. This reduces initial load time. Modern bundlers like webpack, Rollup, and esbuild support automatic code splitting based on dynamic imports.
• Minify and recompile JavaScript files: Always minify and recompile your JavaScript files with a minification tool like SWC, Terser, or esbuild. Minification typically reduces JavaScript file size by 30 to 50%.
• Limit third-party scripts: Third-party scripts can introduce significant performance overhead. Evaluate their necessity and explore alternatives if possible. Each third-party script adds DNS lookups, connection overhead, and main thread processing time. Audit third-party scripts regularly using the Chrome DevTools Network panel.
• Load third-party scripts asynchronously: Because of the unpredictable nature of third-party scripts, never allow rendering to be blocked by a third party. Use the async or defer attribute on all third-party script tags.
• Monitor third-party script performance: Use the Long Animation Frames (LoAF) API or CoreDash to track the real world impact of third-party scripts on INP and LCP. Set performance budgets for third-party JavaScript and review them regularly.

Optimize Styles

Styles are render blocking by default. Optimizing styles will result in optimized paint metrics. Follow the checklist to improve style performance of your webpage. Render blocking CSS directly impacts both First Contentful Paint and LCP element render delay. For tips on cleaning up unused styles, see how to remove unused CSS.

• Minify CSS files: Remove unnecessary characters like whitespace, comments, and formatting from CSS files. Minified files are smaller in size, leading to faster loading times. Tools like cssnano, PostCSS, or your CSS preprocessor's built in compression can automate this.
• Remove unused CSS: Identify and eliminate CSS code that is not used on your web pages. This reduces the amount of data the browser needs to download and parse, improving performance. Tools like PurgeCSS or the Chrome DevTools Coverage tab help identify unused CSS.
• Inline critical CSS: Serve styles essential for rendering the initial page content directly in the HTML to improve the paint metrics. Consider serving critical CSS only to new visitors and using cached external stylesheets for repeat visitors. This technique can reduce the FCP by eliminating the round trip needed to fetch an external stylesheet.
• Equally distribute CSS file sizes: While it might seem efficient to combine all CSS into one file, excessively large files can slow down download times. Consider splitting CSS into smaller files with a more even size distribution (10 to 15KB each) to optimize loading and allow the browser to process styles incrementally.
• Async load offscreen styles: For styles that apply to elements outside the initial viewport, consider using async loading via the media="print" onload="this.media='all'" pattern. This allows the browser to fetch these styles in parallel with other resources without blocking the initial rendering of the page.

Optimize Resource Hints

Resource hints help prioritize downloads for critical resources. Preloaded resources are usually enqueued for download and available to the browser much earlier than they would have been without preloading. Effective use of resource hints can significantly reduce LCP resource load delay. For advanced implementation, read about 103 Early Hints.

• Remove non-critical resource hints: Remove preload hints for resources that are not essential for the initial page load. This prevents unnecessary downloads or network connections that compete for those early, bandwidth-limited resources. Each unnecessary preload consumes bandwidth that could be used for genuinely critical resources.
• Preconnect to critical domains: Establish connections with important domains (like content delivery networks or font providers) early on. This speeds up the download of critical resources from those domains by completing DNS, TCP, and TLS handshakes in advance. Use <link rel="preconnect" href="https://example.com"> for critical third-party origins.
• Consider DNS prefetch as a preconnect alternative: Similar to preconnect, DNS prefetch hints the browser about potential connections. However, preconnect prioritizes establishing the full connection, while DNS prefetch just tells the browser to resolve the domain name in advance. Use <link rel="dns-prefetch"> when the full connection overhead of preconnect is not warranted.
• Preload the LCP element: LCP measures how long it takes for the main content to load. Preloading the LCP element instructs the browser to prioritize downloading this critical resource, speeding up the time it takes for users to see the main content. This is especially important for images referenced in CSS or loaded via JavaScript.
• Preload critical fonts: Preloading critical fonts ensures the browser fetches them early, preventing delays in displaying text and improving cumulative layout shifts caused by font swapping. Use <link rel="preload" as="font" type="font/woff2" crossorigin> for your most important typefaces.
• Prefer 103 Early Hints for resource hints: The 103 Early Hints HTTP status code allows the server to send resource hints before the full response is ready. If your server does not support 103, use Link response headers instead. If headers are not available, add <link> elements to the <head> of the page as a fallback. Earlier delivery of hints means faster resource discovery.
• Preload fonts before CSS files discover them: Fonts referenced in CSS are only discovered after the CSS file has been downloaded and parsed. By preloading fonts directly in the HTML <head>, you eliminate the dependency on CSS parsing and allow fonts to load in parallel, reducing both FCP and layout shift risk.

Optimize Icons

Icons can add significant weight to your page if not optimized. Large inline SVG icons bloat your HTML, while icon fonts often include thousands of unused glyphs. Optimizing icons impacts both LCP (reduced HTML/CSS weight) and CLS (proper dimension reservation).

• Avoid inline SVG icons in HTML: Inlining large SVG icons can increase the size of your HTML code and slow down page load. Consider alternative methods like serving them as separate files or using icon fonts (with caution) to minimize the HTML size and allow browser caching of the icons. An external SVG sprite sheet is often the best balance between performance and flexibility.
• Avoid large icon fonts: Never use large icon sets like Font Awesome in their entirety. Use subsetting to create optimized icon fonts or individual SVGs to reduce the overall size of the web page and improve loading speed. A full Font Awesome set can exceed 100KB, while a subset with 20 icons can be under 5KB.
• Reserve width and height for icons: Similar to images, specifying width and height for icons helps the browser reserve space and prevents layout shifts as they load. Use the width and height attributes on SVG elements or set explicit dimensions in CSS.
• De-prioritize non-critical icon sets: If icons are not critical for the initial rendering of your page, consider loading them with lower priority. This ensures essential content loads first and minimizes the impact on Core Web Vitals metrics. Use lazy loading or load icon stylesheets asynchronously after the initial paint.

Optimize Server Response Times

Server response times, measured by Time to First Byte (TTFB), have a direct relationship with all the paint metrics. A slow server response delays everything that follows. For detailed optimization strategies, explore our guides on diagnosing TTFB issues and configuring Cloudflare for performance.

• Use a fast and reliable hosting provider: A fast hosting provider with strong infrastructure can significantly improve server response times and overall website performance. Benchmark hosting providers using real world TTFB measurements, not synthetic marketing claims.
• Optimize server-side code and database queries: Frequently log code execution and database query time to find bottlenecks and improve overall speed. Use query profiling and application performance monitoring (APM) tools to identify slow endpoints.
• Implement caching strategies: Utilize browser caching and server-side caching to store frequently accessed data, reducing the need for repeated data retrieval and improving load times. Full-page caching can reduce TTFB from seconds to under 100ms. Learn more about cache duration optimization.
• Client-side or edge rendering for personalization: Consider client-side or edge rendering of small personalizations like cart count, login status, or minor menu changes to keep full page cache functionality. This avoids cache busting the entire page for minor dynamic elements.
• Optimize server configurations: Review and tune your web server settings for performance. This includes connection keep-alive settings, worker process counts, memory allocation, and timeout values. Misconfigured servers can waste resources and increase response times.
• Use a Content Delivery Network (CDN): A CDN distributes your website's static content across multiple edge nodes (servers). This reduces the physical distance users need to access your content, leading to faster loading times for global audiences. Moreover, CDNs are usually better configured than your own server. See our guide on configuring Cloudflare for a practical setup walkthrough.
• Reduce server-side processing: Minimize the amount of work your server does per request. Pre-compute expensive operations, use efficient algorithms, and move non-essential processing to background jobs. Analyze your application's request lifecycle to find and eliminate unnecessary processing steps.
• Use HTTP/3: HTTP/3 is the latest version of the Hypertext Transfer Protocol. HTTP/3 is faster and more efficient than HTTP/2 and significantly faster than HTTP/1.1. Upgrading to HTTP/3 can improve overall page load times and potentially all three Core Web Vitals metrics (LCP, INP, CLS). Learn more about connection duration optimization.
• Set up Server-Timing headers: These headers provide detailed information about how long different parts of your page take to process on the server. With this data, you can pinpoint bottlenecks and areas for improvement, specifically focusing on improving Largest Contentful Paint (LCP). Server-Timing headers are visible in the Chrome DevTools Network panel and can be captured by RUM tools like CoreDash.
• Log slow database queries and optimize them regularly: Enable slow query logging in your database (MySQL, PostgreSQL, MongoDB) and review the logs weekly. Index optimization, query restructuring, and adding caching layers for frequent queries can dramatically reduce TTFB.
• Use GZIP or Brotli compression: GZIP, or the newer Brotli, offers on the fly compression of text-based resources (HTML, CSS, JavaScript) before transmission, resulting in about 70% smaller file sizes. Brotli typically achieves 15 to 20% better compression than GZIP. Smaller file sizes translate to faster loading times.

Optimize Interactivity

Interaction to Next Paint (INP) measures how quickly your site responds to user interactions. Poor interactivity is often caused by long-running JavaScript tasks that block the main thread. For a complete breakdown of the three INP phases, see our guides on input delay, processing time, and presentation delay.

• Implement an idle-until-urgent pattern for expensive scripts: This approach involves prioritizing critical tasks and deferring non-essential JavaScript execution until the main browser thread is idle. This ensures critical tasks like rendering and user interactions are not blocked by long-running scripts. Use requestIdleCallback to schedule non-urgent work. Learn more about optimizing processing time.
• Break up long tasks by yielding to the main thread: Complex JavaScript tasks can block the main thread, delaying responsiveness. Splitting these tasks into smaller chunks and yielding control back to the main thread between chunks allows the browser to handle user interactions and maintain a smooth user experience. Use scheduler.yield() (where supported) or setTimeout(0) to break up long tasks. See our guide on improving INP by ditching JavaScript scrolling.
• Provide immediate feedback after input: Users expect immediate responsiveness after interacting with your website. Provide visual cues or acknowledge user input promptly, even while long-running tasks are processing in the background. Use CSS transitions and the :active pseudo-class for instant visual feedback. This helps maintain a sense of interactivity and prevents users from feeling like the website is frozen.
• Use passive event listeners for scroll and touch: Add { passive: true } to scroll and touch event listeners. Passive listeners tell the browser that the handler will never call preventDefault(), allowing it to start scrolling immediately without waiting for JavaScript. This is especially impactful on mobile devices and directly improves INP for scroll-adjacent interactions.

Core Web Vitals Monitoring

Monitoring your Core Web Vitals continuously is essential to catch regressions early and validate that optimizations have the expected impact. Use a combination of lab tools, field data, and real user monitoring for a complete picture.

• Check Lighthouse regularly: Lighthouse is a free, open-source auditing tool from Google that helps you identify performance issues on your web pages. While Lighthouse does not measure the Core Web Vitals directly in a real user context, it is a great tool for periodically testing and comparing your website under regulated and standardized conditions. Run Lighthouse in CI/CD pipelines to catch regressions before deployment.
• Check the CrUX historical data regularly: CrUX (Chrome User Experience Report) is a public dataset from Google that provides real-world performance data. CrUX is the data source used by Google to determine whether or not you pass the Core Web Vitals. Use the historical data to quickly spot regressions. You can access CrUX data through PageSpeed Insights, the CrUX Dashboard, or the CrUX API.
• Set up RUM tracking: RUM (Real User Monitoring) involves tracking real user experiences on your website. RUM tools collect data on how long it actually takes for pages to load for your visitors in different locations and on various devices. This provides valuable insights into real-world performance, complementing the simulated data from Lighthouse and CrUX. We recommend CoreDash as your RUM tracking tool for detailed Core Web Vitals attribution data.
• Set performance budgets: Performance budgets set specific performance targets (for example, LCP under 2.5 seconds, INP under 200ms, CLS under 0.1) for different metrics. These act as benchmarks to guide your optimization efforts. Regularly checking your performance against these budgets helps you identify areas that need immediate attention and prioritize optimizations.
• Use segmentation: Use segmentation to track your most valuable visitor types and different page types. Larger amounts of traffic might otherwise mask performance issues specifically impacting these vital groups. Segment by device type, connection speed, geography, and page template to uncover hidden problems.

Optimize Critical Rendering Path

The critical rendering path is the sequence of steps the browser takes to convert HTML, CSS, and JavaScript into visible pixels. Optimizing this path directly improves First Contentful Paint and LCP element render delay. See also how to avoid excessive DOM size.

• Minimize the number of critical resources: Every render-blocking resource (CSS and synchronous JavaScript) must be downloaded and processed before the browser can paint. Reduce the number of critical resources by deferring non-essential scripts and async loading non-critical stylesheets.
• Optimize the order of resource loading: Ensure that critical CSS and fonts load first, followed by above-the-fold images, then deferred scripts. Use the fetchpriority attribute and resource prioritization hints to communicate importance to the browser.
• Reduce the depth of the DOM tree: Deeply nested DOM trees increase style calculation time and layout work. Aim for a maximum depth of 32 levels and fewer than 1,500 total DOM elements where possible. A flatter DOM structure improves both paint performance and INP presentation delay.
• Favor classes and IDs over element tags and attributes: Instead of p.important, use .important. This reduces the browser's need to search through all elements of that type for style matching, resulting in faster style recalculation.
• Avoid nesting selectors deeply: The deeper you nest CSS selectors, the more calculations the browser needs to perform. Try restructuring your HTML to reduce nesting or use more specific classes closer to the element. Limit selector depth to 3 levels maximum.
• Minimize descendant selectors: Selectors like .container > .content force the browser to check every element within the container. If possible, use a more direct class on the content element for faster selector matching.
• Consolidate selectors with the same styles: If multiple elements share the same styles, group them into a single class or use a BEM (Block Element Modifier) naming convention for better maintainability and smaller CSS output.

Optimize Cookie Consent

Cookie consent banners are required by GDPR and similar regulations, but they can significantly impact Core Web Vitals if not implemented carefully. A poorly loaded consent banner can delay LCP, cause CLS, and increase INP. For more details, read about optimizing third-party widgets for Core Web Vitals.

• Consider server-side cookie consent for dynamic pages: For dynamically server-side rendered pages, implementing a server-side solution that renders the consent banner in the initial HTML response is often faster than loading a separate JavaScript-based solution. This eliminates the extra network request and script evaluation overhead.
• Async load cookie consent scripts on cached pages: For cached pages, async load your cookie consent script and consider adding fetchpriority="high" to the script to ensure it loads early enough to display before user interaction.
• Keep consent text short to avoid LCP interference: Long cookie notice texts can take over the LCP element because the browser considers the largest visible text block as a potential LCP candidate. Consider writing shorter texts or breaking up texts into multiple paragraphs with smaller visible area.
• Self-host cookie notification scripts: Cache and self-host cookie notification scripts and stylesheets whenever possible. This eliminates DNS lookups and connection overhead to third-party consent management platforms and gives you full control over loading behavior.

Optimize Single Page Applications

Single Page Applications (SPAs) built with React, Vue, Angular, or similar frameworks face unique Core Web Vitals challenges. Client-side rendering can delay both FCP and LCP, while hydration can block INP.

• Always use server-side rendering or prerendering: SPAs that rely solely on client-side rendering force the browser to download, parse, and execute JavaScript before any content is visible. Use SSR (Next.js, Nuxt, SvelteKit) or static prerendering to serve initial HTML that the browser can paint immediately.
• Prefer static prerenders over dynamic generation: Static prerenders (generated at build time) are much faster than dynamically generated prerenders because they can be served directly from a CDN without any server-side processing. Use static generation for pages that do not require per-request data.
• Load third-party scripts after hydration: During hydration, the framework is already consuming significant main thread time to make the page interactive. Loading third-party scripts simultaneously compounds the problem and worsens input delay. Defer all non-essential scripts until after the hydration process completes.

Avoid Excessive DOM Size

A large DOM (more than 1,500 elements or a depth exceeding 32 levels) increases memory usage, slows style calculations, and causes costly layout reflows. This directly impacts both INP presentation delay and paint metrics. See how to fix excessive DOM size.

• Reduce unnecessary DOM elements: Audit your HTML for wrapper elements that serve no styling or structural purpose. Replace deeply nested <div> structures with semantic HTML elements. Consider virtualizing long lists with libraries like react-window or virtual-scroller to keep the active DOM small.
• Use efficient JavaScript and CSS selectors: Complex CSS selectors and JavaScript DOM queries (such as querySelectorAll with broad patterns) become exponentially slower as DOM size grows. Use specific class selectors and limit the scope of DOM queries to subtrees whenever possible.
• Use content-visibility: auto for off-screen content: The CSS content-visibility: auto property tells the browser to skip rendering of off-screen elements until they are scrolled into view. This can dramatically reduce initial rendering work for pages with long content sections.

Optimize API Requests

API requests that block rendering or delay content can negatively impact LCP and TTFB. Client-side data fetching is a common source of slow LCP in single page applications.

• Minimize the number of API requests: Each API request adds to the overall page load time. Evaluate your website's functionality and identify opportunities to reduce the number of API requests needed to render the initial content. Techniques like data batching (combining multiple requests into one) and GraphQL can reduce round trips.
• Use efficient and optimized APIs: The design and implementation of the APIs themselves can impact performance. Ensure you are using well-designed APIs that are optimized for speed and efficiency. Implement caching mechanisms on the API side to reduce response times for frequently requested data.
• Preload critical API requests: Similar to preloading critical resources like images, preloading essential API requests can significantly improve perceived performance. Use <link rel="preload" as="fetch"> to instruct the browser to fetch critical APIs early, minimizing delays when they are needed for rendering the initial content. See our resource prioritization guide for more techniques.

Optimize Chat Widgets

Chat widgets are a common cause for layout shifts and might even cause issues with the LCP if they are loaded early. For a step by step approach, read how to implement a chat widget with perfect Core Web Vitals.

• Load chat widgets after the main content has loaded: No one in the history of the internet has ever needed to chat before the main content of the page has loaded. Defer chat widget initialization until the page has finished its initial render, using requestIdleCallback or a scroll-based trigger.
• Prevent chat widget layout shifts: If chat widgets cause a layout shift, it is usually a good idea to hide them with opacity: 0 until they have fully rendered on the page. This allows the widget to lay out in the background without causing visible content to jump. Use a CSS transition to fade the widget in smoothly.
• Choose lightweight chat widget providers: Shop around. Some chat widgets are much more lightweight and cause fewer Core Web Vitals problems than others. Compare the JavaScript bundle size, number of network requests, and INP impact of different providers before committing.

Optimize Service Worker Performance

Service workers can significantly improve repeat-visit performance by caching assets and even full page responses, reducing TTFB for returning visitors. However, a poorly implemented service worker can actually slow down navigation. Learn more about cache duration optimization.

• Cache critical assets in the service worker: Use a cache-first strategy for static assets like CSS, JavaScript, fonts, and images. This allows repeat visitors to load your site almost instantly from the local cache. Precache the most important resources during the service worker install event.
• Optimize service worker code: Keep your service worker lean and efficient. Avoid complex routing logic, excessive use of event.waitUntil(), and large precache manifests that slow down installation. Use the stale-while-revalidate pattern for resources that change frequently but do not require immediate freshness.

Optimize Video Content

Video elements can become the LCP element if they are the largest visible content in the viewport. Large, unoptimized videos also compete for bandwidth with other critical resources.

• Compress and optimize videos: Use modern codecs like H.264, VP9, or AV1 with appropriate quality settings. Reduce video resolution to match the maximum display size. A video that appears at 400px wide does not need to be encoded at 1920px. Use two-pass encoding for the best quality to file size ratio.
• Use lazy loading for videos: For videos below the fold, use the loading="lazy" attribute on <iframe> elements or delay video loading with the Intersection Observer API. Replace auto-playing background videos with poster images and load the video only when the user scrolls near it.
• Host videos on a fast CDN: Video files are large and benefit greatly from CDN distribution. Use a dedicated video CDN or hosting service (like Cloudflare Stream, Mux, or Bunny.net) that provides adaptive bitrate streaming, geographic distribution, and optimized delivery.
• Use poster images for video elements: Always set a poster attribute on <video> elements. The poster image gives the browser something to paint immediately while the video loads, which can serve as the LCP element. Optimize the poster image just like any other LCP image.