LCP Fix

How to Fix LCP Caused by Render-Blocking CSS

Updated May 2, 2026 14 min 5 steps By Alex Rivera, Senior Frontend Engineer

Render-blocking CSS is one of the most common and most avoidable causes of a slow Largest Contentful Paint. Every standard stylesheet linked in the <head> prevents the browser from rendering a single pixel until it has downloaded, parsed, and applied the full file. On a slow mobile connection, a 200KB stylesheet can add 800ms or more before the LCP element ever appears on screen -- pushing an otherwise fast page into the "Needs Improvement" or "Poor" category.

This guide walks through the complete playbook: understanding why CSS blocks rendering at a fundamental browser level, identifying which stylesheets are responsible, and applying a layered set of fixes from critical CSS inlining to modern HTTP-level strategies. Each technique is independent; apply as many as your architecture supports.

TL;DR -- What to do
  • Audit with Lighthouse "Eliminate render-blocking resources" and DevTools Coverage panel
  • Inline critical above-the-fold CSS directly in <head> (target under 14KB compressed)
  • Defer all remaining CSS with the media="print" onload swap pattern
  • Compress stylesheets with Brotli and remove unused rules with PurgeCSS or Tailwind JIT
  • Validate improvements with Lighthouse and real-user LCP monitoring at the 75th percentile

Before

4.1s

LCP (Poor) -- three render-blocking stylesheets delay paint by 900ms on a 4G connection

After

1.9s

LCP (Good) -- critical CSS inlined, non-critical deferred, Brotli compression enabled

What makes CSS render-blocking

To understand why CSS blocks rendering, you need to know what the browser must do before it can paint anything. When a browser parses HTML, it constructs the Document Object Model (DOM) -- a tree of every element on the page. Simultaneously, it constructs the CSS Object Model (CSSOM) from every stylesheet it encounters. Only when both trees are complete can the browser combine them into the Render Tree, which is the structure it actually uses to lay out and paint pixels.

This two-tree build is the fundamental constraint. The browser cannot produce a Render Tree -- and therefore cannot render anything -- until the CSSOM is complete. And the CSSOM cannot be complete until every render-blocking stylesheet has been downloaded and parsed. A single large stylesheet linked in the <head> with no special attributes is render-blocking by default: the browser halts HTML parsing, fetches the file, parses all its rules, updates the CSSOM, then resumes.

Why does the browser enforce this? Because a stylesheet loaded late could change the visual presentation of elements already laid out -- causing incorrect renders that would need to be repainted. Rather than risk that, the browser's rendering pipeline is conservative: it waits. This is the correct behavior for correctness, but it is a significant performance problem when stylesheets are large or hosted on slow connections.

The practical consequence for Largest Contentful Paint is direct: every millisecond the browser spends blocked waiting for CSS is a millisecond added to LCP. The LCP element -- your hero image, product photo, or above-the-fold heading -- simply cannot be painted until the CSSOM is ready. There is no workaround at the browser level; the fix must happen in how you deliver CSS.

How to identify render-blocking CSS

Before optimizing, you need to measure precisely which stylesheets are blocking rendering, how much time they add, and which rules within those stylesheets are actually needed above the fold.

Lighthouse "Eliminate render-blocking resources" audit

Run a Lighthouse audit from Chrome DevTools (or PageSpeed Insights) and look for the "Eliminate render-blocking resources" opportunity. Lighthouse lists each render-blocking stylesheet with its transfer size and the estimated savings in milliseconds if it were deferred. This is your starting point -- it tells you which stylesheets to target and quantifies the potential gain.

Lighthouse measures render-blocking resources by replaying the page load under throttled conditions and identifying resources that appear on the critical request chain before the first paint. If a stylesheet's download overlaps the period between HTML parse start and first paint, it is flagged.

Chrome DevTools Coverage panel

Lighthouse tells you which files are blocking; the Coverage panel tells you how much of each file is actually used on first load. Open DevTools, press Shift+Cmd+P (or Shift+Ctrl+P on Windows), type "Coverage", and select "Start instrumenting coverage and reload". The panel shows each stylesheet with a usage bar: red is unused bytes, green is used bytes.

A stylesheet showing 80% unused on first load is a strong candidate for critical CSS extraction: inline the used 20% in the <head> and defer the rest. The Chrome DevTools Performance panel adds another layer -- you can see the exact timeline of when stylesheets are requested, received, and when they unblock the rendering pipeline.

WebPageTest waterfall reading

WebPageTest provides a waterfall chart where each resource appears as a horizontal bar. A vertical orange line marks "Start Render" -- the first moment any pixel appears on screen. Any stylesheet bar that extends past the Start Render line and that appears before it on the waterfall was render-blocking. Bars that complete before Start Render but whose download time is significant are candidates for inlining or deferring.

Pay particular attention to third-party stylesheets -- fonts from Google Fonts, icon libraries, or widget CSS. These require external DNS lookups and TCP connections that add latency entirely outside your control. Replacing them with self-hosted equivalents is frequently the highest-impact single change.

Inline critical CSS

Critical CSS is the subset of your stylesheet rules needed to render the above-the-fold content -- everything visible without scrolling on a typical viewport. By inlining these rules directly in a <style> tag in the <head>, you eliminate the external request entirely for those rules. The browser gets the styles it needs to paint the LCP element inside the HTML document itself, in the first network round-trip.

The 14KB first-packet target

The initial TCP congestion window is typically 10 TCP segments, each roughly 1460 bytes -- about 14KB of data. If your entire HTML document (including inlined critical CSS) fits within 14KB compressed, the browser receives all of it in a single round-trip before the server waits for an acknowledgment. This is the theoretical sweet spot: the browser has everything it needs to start rendering without waiting for additional network round-trips.

In practice, your HTML will take some of that budget, so aim for critical CSS that compresses to 7-10KB, leaving headroom for the HTML markup. Above 14KB total, you are adding at minimum one additional round-trip before the browser can start rendering.

Tooling: Critters, Beasties, and Penthouse

Critters (by the Chrome team) and its maintained fork Beasties automate critical CSS extraction as part of your build process. They inline the critical CSS and automatically apply the media="print" defer pattern for the remaining stylesheet. Penthouse is an older but widely used alternative that uses Puppeteer to render your page and extract the styles actually applied to above-the-fold elements.

Bash -- Install Beasties 
npm install --save-dev beasties
JavaScript -- Beasties in a build script 
import Beasties from 'beasties';
import fs from 'fs/promises';

const beasties = new Beasties({
  path: './dist',          // directory of built HTML files
  publicPath: '/',
  compress: true,          // minify inlined CSS
  pruneSource: true,       // remove inlined rules from external file
  mergeStylesheets: true,  // merge multiple <style> tags into one
  preload: 'swap',         // apply media="print" defer pattern automatically
  noscriptFallback: true,  // add <noscript> fallback
});

// Process a single HTML file
const result = await beasties.process(
  await fs.readFile('./dist/index.html', 'utf8')
);
await fs.writeFile('./dist/index.html', result);

Framework options

Next.js App Router performs automatic per-page CSS chunking; pair it with the experimental.optimizeCss flag (which wraps Critters) to inline critical CSS automatically at build time. Astro uses scoped component styles that are extracted per page at build time; adding is:inline to a <style> block forces it to render inline in the HTML. Nuxt provides the inlineStyles option in nuxt.config.ts which inlines component styles for SSR responses.

Defer non-critical CSS

Once you have identified or extracted the critical CSS, the rest of your stylesheet should load without blocking rendering. The standard approach is the media="print" onload swap pattern -- a robust, widely supported technique that requires no JavaScript framework and works in every modern browser.

How the media="print" pattern works

Setting media="print" on a <link> element tells the browser this stylesheet only applies to print media. The browser still downloads it (at low priority, without blocking rendering), but it does not apply it to the current screen render. The onload handler fires when the download completes; at that point, this.media = 'all' activates the stylesheet for screen display. The onload handler resets itself to null to avoid re-firing. A <noscript> fallback loads the stylesheet normally for users with JavaScript disabled.

HTML -- media="print" onload swap (full working pattern) 
<!-- Critical CSS inlined for above-the-fold content -->
<style>
  /* ... your extracted critical CSS here ... */
  body { margin: 0; font-family: system-ui, sans-serif; }
  .hero { display: flex; align-items: center; min-height: 60vh; }
  .nav { display: flex; gap: 1rem; padding: 1rem; }
</style>

<!-- Non-critical CSS deferred with media="print" swap -->
<link
  rel="stylesheet"
  href="/styles/main.css"
  media="print"
  onload="this.media='all'; this.onload=null"
>

<!-- Fallback for browsers with JavaScript disabled -->
<noscript>
  <link rel="stylesheet" href="/styles/main.css">
</noscript>

Preload-then-swap pattern

You can combine rel="preload" with the media swap to start downloading the stylesheet at high priority while still not blocking rendering. The rel="preload" link fetches the resource early; the second <link> with media="print" applies it non-blocking after download.

HTML -- Preload-then-swap pattern 
<!-- Preload: fetch at high priority but do not block rendering -->
<link
  rel="preload"
  href="/styles/main.css"
  as="style"
  onload="this.rel='stylesheet'; this.onload=null"
>

<!-- media query that only matches after DOMContentLoaded -->
<link
  rel="stylesheet"
  href="/styles/above-mobile.css"
  media="(min-width: 601px)"
>

<noscript><link rel="stylesheet" href="/styles/main.css"></noscript>

Using media queries that only match certain conditions (e.g., media="(min-width: 601px)" for desktop-only styles) is another built-in deferral mechanism: the browser downloads but does not block on stylesheets whose media query does not match the current viewport. Split your CSS into mobile-first critical styles and larger viewport enhancements to exploit this naturally.

Modern CSS loading strategies

Beyond critical CSS inlining and deferral, several newer platform features enable more precise control over the CSS loading pipeline.

@layer cascade

The CSS @layer at-rule (baseline supported since 2022 across Chrome, Firefox, and Safari) lets you explicitly declare the cascade order of CSS blocks. Beyond cascade control, @layer enables a pattern where you define a layer ordering in an inlined <style> block, then load layer-specific stylesheets asynchronously. Because the layer order is already established, the browser can apply each stylesheet as it arrives without risking cascade conflicts.

CSS -- @layer with deferred loading 
/* Inline in <head>: establish layer order first */
@layer base, components, utilities;

/* base.css (loaded non-blocking) */
@layer base {
  *, *::before, *::after { box-sizing: border-box; }
  body { margin: 0; line-height: 1.5; }
}

/* components.css (loaded non-blocking) */
@layer components {
  .btn { display: inline-flex; padding: 0.5rem 1rem; border-radius: 0.375rem; }
  .card { border: 1px solid var(--color-border); border-radius: 0.5rem; }
}

/* utilities.css (loaded non-blocking) */
@layer utilities {
  .sr-only { position: absolute; width: 1px; height: 1px; overflow: hidden; clip: rect(0,0,0,0); }
}

HTTP 103 Early Hints

HTTP 103 Early Hints is a server-side technique that allows your server to send Link: </styles/main.css>; rel=preload; as=style headers before the full HTML response is ready. The browser starts downloading the stylesheet during the time the server is generating the page. This is especially valuable for server-side rendered applications where the HTML response may take 100-300ms to generate: that generation time becomes free prefetch time for your CSS.

HTTP -- 103 Early Hints response headers 
HTTP/1.1 103 Early Hints
Link: </styles/critical.css>; rel=preload; as=style
Link: </styles/main.css>; rel=preload; as=style

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
...rest of response

Cloudflare, Fastly, and Nginx (1.25+) support Early Hints. Vercel and Netlify edge functions can emit 103 responses. Chrome 103+ and Safari 17+ implement Early Hints handling.

Scoped CSS in components

Component-scoped CSS (as implemented in Astro, Vue SFCs, and CSS Modules) naturally reduces per-page stylesheet size because each page only ships the styles used by components actually rendered on that page. This is structurally superior to a global stylesheet: a product detail page does not ship blog post styles, and a landing page does not ship dashboard styles. The result is smaller stylesheets that take less time to download and parse, reducing the render-blocking window even before any deferral techniques are applied.

Speculation Rules API and bfcache

The Speculation Rules API (Chrome 109+) lets you prerender entire pages speculatively. When a user navigates to a prerendered page, the LCP is near-instant because the page was already fully rendered in a background context. The back-forward cache (bfcache) similarly restores full page state from memory for back/forward navigations, bypassing CSS loading entirely. These are not CSS loading techniques per se, but they can mask render-blocking CSS problems for repeat navigations and are worth enabling alongside the CSS optimizations above.

Framework-specific notes

Each major framework has its own CSS delivery model, and understanding it lets you apply the right optimizations without fighting the framework's defaults.

Next.js App Router

The Next.js App Router performs automatic CSS chunking: global CSS imported in layout.tsx is split from route-specific CSS imported in page.tsx, so each route ships only the CSS it uses. Enable experimental.optimizeCss: true in next.config.js to add Critters-based critical CSS inlining at build time. Avoid importing large third-party stylesheets at the root layout level -- instead, import them only in the route components that need them, so the chunking works correctly.

JavaScript -- next.config.js with CSS optimization 
/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    optimizeCss: true,   // Enables Critters critical CSS extraction
  },
};

export default nextConfig;

Astro scoped CSS

Astro scopes component styles by default with a generated data attribute. At build time, Astro extracts and deduplicates styles for each page, producing a minimal per-page stylesheet. Use <style is:global> sparingly -- it opts out of scoping and produces a global stylesheet that ships on every page. For critical above-the-fold styles, use <style is:inline> to force styles into the HTML output rather than an external file.

Astro -- Inlining critical styles 
---
// src/layouts/Base.astro
---
<html>
  <head>
    <!-- Scoped styles extracted to external file (default) -->
    <style>
      .hero { display: flex; min-height: 60vh; }
    </style>

    <!-- Critical styles forced inline in HTML output -->
    <style is:inline>
      body { margin: 0; font-family: system-ui, sans-serif; }
      .nav { display: flex; gap: 1rem; padding: 1rem 1.5rem; }
    </style>
  </head>
  <body><slot /></body>
</html>

Tailwind CSS JIT purging

Tailwind's JIT (Just-In-Time) engine, the default since Tailwind v3, generates only the utility classes present in your markup at build time. A typical production Tailwind build results in a stylesheet of 5-15KB uncompressed -- well within the critical CSS inlining budget. Configure the content array in tailwind.config.js precisely to avoid scanning files that include class names not rendered in production, which would bloat the output. Enable Brotli on your server: Tailwind's repetitive utility class structure compresses exceptionally well.

styled-components SSR

styled-components injects styles via JavaScript at runtime by default, which means styles are unavailable until the JS bundle executes -- a significant LCP problem on content-heavy pages. The fix is server-side rendering via ServerStyleSheet. With SSR enabled, styled-components collects all styles used during the server render and injects them as a <style> block in the HTML, making them available without waiting for JavaScript. In Next.js, use the official styled-components babel plugin or the SWC transform (compiler.styledComponents: true in next.config.js) to enable SSR automatically.

JavaScript -- next.config.js with styled-components SSR 
/** @type {import('next').NextConfig} */
const nextConfig = {
  compiler: {
    styledComponents: true,  // Enables SSR style extraction
  },
};

export default nextConfig;

Step-by-step fix

Step 1: Audit render-blocking CSS with Lighthouse and Coverage panel

Start with a baseline measurement. Run Lighthouse in Chrome DevTools on an incognito window (to avoid extension interference) and note the "Eliminate render-blocking resources" opportunity -- record the estimated savings in milliseconds and the list of offending stylesheets. Then open the Coverage panel, reload the page, and note the percentage of used versus unused CSS bytes in each stylesheet. Document your starting LCP from the Lighthouse "Largest Contentful Paint" metric so you have a before/after comparison. Repeat the WebPageTest test from a representative location to get a waterfall confirming which files block Start Render.

Measure in throttled mode: Lighthouse defaults to Slow 4G throttling for mobile audits. Run audits in both mobile and desktop modes -- a stylesheet that is borderline on desktop may be severely blocking on mobile due to bandwidth constraints.

Step 2: Extract and inline critical CSS for above-the-fold content

Use Beasties or Critters to automate critical CSS extraction as part of your build. For manual extraction, use the DevTools Coverage panel: the green-highlighted rules are used on first load. Focus on rules that affect the layout shell, navigation, hero section, and the LCP element specifically. Paste these rules into a <style> block at the top of <head>, before any external stylesheet links. Measure the resulting <style> block size -- target under 14KB when compressed with Brotli or gzip.

HTML -- Inlining extracted critical CSS 
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">

  <!-- Critical CSS inlined (extracted by Beasties at build time) -->
  <style>
    /* Reset */
    *, *::before, *::after { box-sizing: border-box; }
    body { margin: 0; font-family: system-ui, -apple-system, sans-serif; line-height: 1.5; }

    /* Navigation shell */
    .site-header { position: sticky; top: 0; z-index: 10; background: #fff; border-bottom: 1px solid #e5e7eb; }
    .site-header__inner { max-width: 1200px; margin: 0 auto; padding: 0 1.5rem; display: flex; align-items: center; height: 4rem; }

    /* Hero section (LCP element lives here) */
    .hero { display: flex; flex-direction: column; align-items: flex-start; padding: 5rem 1.5rem; max-width: 1200px; margin: 0 auto; }
    .hero__title { font-size: clamp(2rem, 5vw, 3.5rem); font-weight: 800; line-height: 1.1; margin: 0 0 1rem; }
    .hero__image { width: 100%; height: auto; border-radius: 0.75rem; }
  </style>

  <!-- Non-critical CSS deferred -->
  <link rel="stylesheet" href="/styles/main.css" media="print" onload="this.media='all'; this.onload=null">
  <noscript><link rel="stylesheet" href="/styles/main.css"></noscript>
</head>

Step 3: Defer non-critical CSS with media="print" onload swap

For every stylesheet that is not inlined, apply the media="print" onload swap pattern. This is safe to apply to your main stylesheet, any component library stylesheet, icon library CSS, and third-party widget styles. The browser will still download these files (at lower priority) and apply them once downloaded, without ever blocking the initial render. If you have multiple non-critical stylesheets, apply the pattern to each independently -- they will load in parallel and activate as each finishes.

HTML -- Deferring multiple stylesheets 
<!-- Main stylesheet -->
<link rel="stylesheet" href="/styles/main.css"
  media="print" onload="this.media='all'; this.onload=null">

<!-- Component library -->
<link rel="stylesheet" href="/styles/components.css"
  media="print" onload="this.media='all'; this.onload=null">

<!-- Below-the-fold animation styles -->
<link rel="stylesheet" href="/styles/animations.css"
  media="print" onload="this.media='all'; this.onload=null">

<!-- Fallback for no-JS users -->
<noscript>
  <link rel="stylesheet" href="/styles/main.css">
  <link rel="stylesheet" href="/styles/components.css">
  <link rel="stylesheet" href="/styles/animations.css">
</noscript>

Step 4: Self-host and compress stylesheets

Self-hosting eliminates third-party DNS lookups that add 50-200ms per external domain. Serve all stylesheets from the same origin as your HTML (or your CDN). Enable Brotli compression on your server or CDN -- Brotli typically reduces CSS by 15-25% better than gzip because of its larger compression dictionary. Run PurgeCSS or use Tailwind JIT to remove unused rules before the final build. Set long-lived Cache-Control: public, max-age=31536000, immutable headers on versioned stylesheet URLs so returning visitors skip the download entirely.

Nginx -- Brotli and long-lived caching for CSS 
# Enable Brotli compression (requires ngx_brotli module)
brotli on;
brotli_comp_level 6;
brotli_types text/css text/plain application/javascript;

# Long-lived caching for versioned static assets
location ~* \.(css|js|woff2)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
  add_header Vary "Accept-Encoding";
}

Step 5: Validate with Lighthouse and real-user LCP monitoring

Re-run your Lighthouse audit and confirm that the "Eliminate render-blocking resources" opportunity is gone or reduced to a negligible savings amount. Record the new LCP value and compare to your baseline. For real-user validation, deploy the web-vitals JavaScript library to capture field LCP at the 75th percentile -- this is what Google's Core Web Vitals assessment uses. See the real-user monitoring setup tutorial for implementation details. Monitor for at least 28 days to account for traffic variation.

JavaScript -- Real-user LCP monitoring with web-vitals 
import { onLCP } from 'web-vitals';

onLCP((metric) => {
  // Send to your analytics endpoint
  fetch('/analytics', {
    method: 'POST',
    body: JSON.stringify({
      name: metric.name,          // 'LCP'
      value: metric.value,        // milliseconds
      rating: metric.rating,      // 'good' | 'needs-improvement' | 'poor'
      id: metric.id,              // unique ID for deduplication
      navigationType: metric.navigationType,
    }),
    keepalive: true,
  });
});

Common mistakes

  • Inlining too much CSS. Inlining your entire stylesheet defeats the purpose -- it bloats the HTML document, delays TTFB, and prevents caching. Inline only the rules needed to render above-the-fold content, targeting under 14KB compressed total HTML.
  • Forgetting the noscript fallback. The media="print" swap relies on JavaScript. Without a <noscript> fallback that loads the stylesheet with media="all", users with JavaScript disabled see an unstyled page.
  • Loading third-party CSS from external domains. Google Fonts, icon CDNs, and widget stylesheets each add an external connection round-trip. Self-host or bundle these resources to eliminate the extra DNS and TCP overhead.
  • Skipping validation with real-user data. Lighthouse runs under controlled lab conditions. Field LCP includes real-world network variance, device diversity, and cache behavior. Always validate fixes with RUM data before claiming success.
  • Treating critical CSS extraction as a one-time task. Critical CSS extraction is tied to your markup. Every time you add a new above-the-fold component, update design tokens, or change the layout, the extracted critical CSS may become stale. Automate extraction as part of your CI build pipeline, not as a manual step.

Quick checklist

  • Lighthouse "Eliminate render-blocking resources" audit cleared or savings under 50ms
  • Critical CSS inlined in <style> block, under 14KB compressed total HTML
  • All external stylesheets deferred with media="print" onload swap + noscript fallback
  • No CSS loaded from external domains (Google Fonts, icon CDNs self-hosted)
  • Brotli compression enabled on server or CDN for stylesheet responses
  • Unused CSS rules removed via PurgeCSS, Tailwind JIT, or equivalent
  • Critical CSS extraction automated in CI (not a manual step)
  • Field LCP at 75th percentile below 2.5s, confirmed with RUM

Frequently asked questions

Aim for roughly 14KB compressed. That is the typical size of the initial TCP congestion window, meaning the browser can receive those bytes in the very first network round-trip without waiting for additional acknowledgments. Inlining more than approximately 14KB compressed can actually delay the HTML response itself and hurt TTFB. Extract only the CSS rules that affect above-the-fold elements -- hero images, navigation, headings, and the layout shell that contains the LCP element.

Yes. Setting media="print" tells the browser the stylesheet is only needed for printing, so it downloads it at low priority without blocking rendering. The onload handler then changes the media attribute to "all", activating the styles. This pattern has broad browser support and is the most reliable way to defer CSS without JavaScript-only solutions. Always include a <noscript> fallback with media="all" for users with JavaScript disabled.

CSS modules generate plain CSS files at build time, which means they can be statically extracted, minified, and served as regular stylesheets -- the same optimization pipeline applies. Styled-components injects styles at runtime via a JavaScript bundle, which can delay the first paint and interfere with critical CSS extraction unless you enable server-side rendering with the ServerStyleSheet API. For LCP-critical pages, CSS modules or scoped CSS (as in Astro) tend to produce better results because styles are available before JavaScript executes.

HTTP/2 Server Push has largely been deprecated or disabled in major browsers due to push storms and cache invalidation problems -- Chrome removed it in 2022. HTTP/3 (QUIC) improves connection setup but does not push resources by default. The modern replacement is HTTP 103 Early Hints, which lets the server stream Link: preload headers before the full HTML response is ready. Preload link tags in HTML remain the most universally supported mechanism and should be used regardless of protocol.

Tailwind CSS with JIT mode generates only the utility classes actually used in your markup, resulting in very small CSS bundles -- often under 10KB for typical pages. This makes it inherently favorable for LCP because there is less CSS to block rendering. However, utility-class HTML can still ship a monolithic stylesheet if your build is misconfigured. The key metric is final stylesheet size after purging: a hand-crafted stylesheet and a Tailwind JIT bundle at the same byte count will perform identically. See the WebVitals FAQ for more framework comparison details.

Alex Rivera

Senior Frontend Engineer

Alex specializes in browser rendering performance and Core Web Vitals optimization. He has worked on performance engineering at several large-scale web platforms and contributes to open-source tooling around CSS and JavaScript bundling.

Related fixes

Fix

Critical CSS Extraction

Automate above-the-fold CSS extraction with Beasties, Critters, and Penthouse across any build pipeline.

 Fix

Font Loading CLS

Eliminate Cumulative Layout Shift caused by web font swapping using font-display, size-adjust, and preload.

 Fix

CDN Optimization for LCP

Reduce LCP with edge caching, cache-control tuning, and CDN-level image optimization.