# How to Implement Critical CSS for Above‑the‑Fold Content: A Complete Guide

> Learn to implement critical CSS for above-the-fold content. Inline essential styles in your head to boost FCP and LCP for faster page rendering. Get the complete guide.

- Repository: [David Dias/Front-End-Checklist](https://github.com/thedaviddias/Front-End-Checklist)
- Tags: how-to-guide
- Published: 2026-03-02

---

**Critical CSS is the subset of styles required to render the visible portion of a webpage before scrolling, which you inline in the `<head>` to eliminate render-blocking requests and improve First Contentful Paint (FCP) and Largest Contentful Paint (LCP).**

The [Front‑End Checklist](https://github.com/thedaviddias/Front-End-Checklist) by David Dias flags this optimization as a **Medium‑priority** item under the *CSS Critical* section at [[`README.md`](https://github.com/thedaviddias/Front-End-Checklist/blob/main/README.md) line 238](https://github.com/thedaviddias/Front-End-Checklist/blob/main/README.md#L238). When you implement critical CSS for above‑the‑fold content, you extract the minimum styles needed for the initial viewport, inline them directly in your HTML, and defer the remaining stylesheet to prevent blocking the browser's render path.

## What Is Critical CSS and Why It Matters

Critical CSS represents only the rules necessary to paint the "above‑the‑fold" area—the content users see before scrolling. By inlining these styles directly into your HTML document's `<head>`, you remove the network round‑trip typically required to fetch an external stylesheet, directly reducing **render‑blocking time**. This technique targets the performance metrics that search engines prioritize: improving **First Contentful Paint (FCP)** and **Largest Contentful Paint (LCP)** by ensuring the browser can render the initial view immediately upon receiving the HTML.

The Front‑End Checklist recommends using Addy Osmani's [`critical`](https://github.com/addyosmani/critical) automation tool to handle this extraction reliably. According to the checklist source code in [`README.md`](https://github.com/thedaviddias/Front-End-Checklist/blob/main/README.md), this practice is categorized as medium priority because it requires build‑step integration but delivers measurable Core Web Vitals improvements.

## Step‑by‑Step Implementation Guide

### Identify Above‑the‑Fold Styles

Before automating, understand which rules actually apply to your initial viewport. Open your page in Chrome DevTools, select the root `<html>` or `<body>` node, and open the **Coverage** panel (Command Menu → Coverage). Reload the page and record which CSS rules execute during the initial paint—these selectors and declarations constitute your critical set.

### Generate Critical CSS Automatically

The `critical` CLI analyzes your URL, simulates a viewport, and outputs the exact CSS used above the fold. Install the tool globally or as a dev dependency:

```bash
npm install -g critical

```

Run the generator with viewport dimensions matching your target device and optimization flags:

```bash
critical https://example.com \
    --base ./dist \
    --width 1300 \
    --height 900 \
    --extract \
    --inline \
    --minify \
    --output dist/index.html

```

**Key parameters explained:**

- `--width` and `--height` define the viewport dimensions for critical extraction (1300×900 covers most desktop above‑the‑fold areas).
- `--extract` removes the used rules from your original stylesheet, creating a separate file containing only non‑critical styles.
- `--inline` automatically injects the generated critical CSS into the `<head>` of the specified output HTML file.
- `--minify` compresses the inline CSS to reduce HTML payload size.

### Inline the Critical CSS Manually

If you prefer manual control over the CLI's automatic injection, copy the generated CSS block and place it inside `<style>` tags in your HTML `<head>`, ensuring it appears before any external resource hints:

```html
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>My Page</title>

  <!-- Critical CSS: above‑the‑fold only -->
  <style>
    .hero{background:#fff;padding:2rem}h1{font-size:2rem;margin:0}
    /* Additional minified critical rules */
  </style>

  <!-- Preload full stylesheet asynchronously -->
  <link rel="preload" href="styles.css" as="style" onload="this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="styles.css"></noscript>
</head>

```

This pattern ensures the browser has immediate access to rendering instructions while avoiding **render‑blocking** behavior for the complete stylesheet.

### Load Non‑Critical CSS Asynchronously

After inlining critical styles, you must defer the remaining CSS without blocking subsequent renders. The `preload` with `onload` pattern shown above transforms the link into a stylesheet only after the file downloads, or use the `loadCSS` polyfill for broader browser support:

```html
<link rel="preload" href="styles.css" as="style" onload="this.rel='stylesheet'">
<script>
  !function(e){"use strict";
  var n=function(t){var n=document.createElement("link");
  n.rel="stylesheet",n.href=t,n.media="only x",n.onload=function(){n.media="all"};
  document.getElementsByTagName("head")[0].appendChild(n)};
  e.loadCSS=n}(this);
</script>

```

Always include a `<noscript>` fallback to ensure styles apply when JavaScript is disabled.

### Verify the Results

Validation ensures your extraction captured the correct rules. Disable caching in DevTools, reload the page, and examine the **Network** tab to confirm the first paint occurs before the external stylesheet request completes. Run Lighthouse or PageSpeed Insights to verify the **"Eliminate render‑blocking resources"** audit passes and that FCP/LCP metrics have improved compared to the baseline.

## Automating Critical CSS in Build Pipelines

Manual extraction breaks quickly when styles change. Integrate the `critical` step into your build script to regenerate above‑the‑fold CSS automatically whenever your main stylesheet updates. Add the command to your [`package.json`](https://github.com/thedaviddias/Front-End-Checklist/blob/main/package.json) scripts:

```json
{
  "scripts": {
    "build": "npm run css && critical src/index.html --base dist --inline --minify --width 1300 --height 900 --output dist/index.html"
  }
}

```

This automation ensures the Front‑End Checklist item for CSS Critical remains satisfied on every deployment without manual intervention. The checklist repository includes validation workflows in [`.github/workflows/readme-check.yml`](https://github.com/thedaviddias/Front-End-Checklist/blob/main/.github/workflows/readme-check.yml) that ensure such performance items stay synchronized with your implementation.

## Summary

- **Critical CSS** is the minimal set of styles required to render above‑the‑fold content before any external resources load.
- Inline these styles directly in the HTML `<head>` to eliminate render‑blocking requests and improve **First Contentful Paint (FCP)** and **Largest Contentful Paint (LCP)**.
- Use the [`critical`](https://github.com/addyosmani/critical) CLI tool (recommended by the Front‑End Checklist in [`README.md`](https://github.com/thedaviddias/Front-End-Checklist/blob/main/README.md) at line 238) to automate extraction with `--extract`, `--inline`, and `--minify` flags.
- Defer non‑critical styles using `rel="preload"` with an `onload` handler or the `loadCSS` polyfill, always providing a `<noscript>` fallback.
- Integrate the generation step into your [`package.json`](https://github.com/thedaviddias/Front-End-Checklist/blob/main/package.json) build pipeline to maintain performance standards automatically.

## Frequently Asked Questions

### What exactly constitutes "above‑the‑fold" CSS?

Above‑the‑fold CSS includes every rule required to render the portion of the webpage visible in the initial viewport without scrolling. This typically encompasses navigation headers, hero sections, typography, and layout grids that appear immediately upon load. The `critical` tool determines these rules by rendering your page in a headless browser at specified viewport dimensions (e.g., 1300×900) and capturing only the used styles.

### Does inlining critical CSS increase HTML payload size?

Yes, inlining adds bytes to your initial HTML document, but the trade‑off typically benefits performance. The eliminated round‑trip request for a blocking CSS file usually outweighs the modest increase in HTML size, particularly when you **minify** the critical CSS block. For optimal results, keep the critical set under 14KB (gzipped) to fit within a single TCP packet when possible.

### Can I implement critical CSS without the `critical` CLI tool?

While manual extraction through DevTools **Coverage** is possible, it is error‑prone and difficult to maintain. The Front‑End Checklist specifically recommends Addy Osmani's `critical` automation tool because it reliably handles dynamic viewport changes, media queries, and extraction from complex stylesheets. Manual implementation requires copying coverage results into your HTML by hand and updating them every time your design changes.

### How do I handle critical CSS for responsive designs with multiple breakpoints?

Run the `critical` tool multiple times with different `--width` and `--height` parameters for your key breakpoints (e.g., mobile 375×667, tablet 768×1024, desktop 1300×900), then merge the results or use server‑side device detection to serve the appropriate critical CSS block. Alternatively, include all critical rules for all breakpoints in a single inline block—modern browsers ignore rules with non‑matching media queries during initial layout, though this slightly increases HTML size.