This guide covers the full WooCommerce critical CSS workflow: why the render path blocks, extracting per-template critical styles, the inline-plus-defer loading pattern, plugin automation versus manual tooling, and the WooCommerce-specific pitfalls — dynamic cart classes and checkout exclusions chief among them. It pairs with our CDN setup guide (delivery layer) and image optimisation guide (the other half of LCP). Google’s extract critical CSS guide covers the browser mechanics in depth.

WooCommerce critical CSS — render-blocking problem, per-template extraction, inline + defer pattern and automation by CodeAtoZ

WooCommerce critical CSS must be generated per template type, not once per site — the above-fold view of the homepage, a product page, a category archive and the blog differ completely. Extract at two viewports minimum (1300×900 desktop, 375×812 mobile) and merge. Tooling options: the critical npm package or Penthouse for build-pipeline extraction, or plugin-managed generation (WP Rocket, FlyingPress) which handles per-page extraction automatically on a remote service — the critical package repository documents the build-pipeline approach. For custom builds, wire extraction into CI so critical styles regenerate whenever the theme’s CSS changes.

// extract-critical.js — run per template URL
import { generate } from 'critical';

const templates = [
  { url: 'https://store.com/', name: 'home' },
  { url: 'https://store.com/product/sample/', name: 'product' },
  { url: 'https://store.com/shop/', name: 'category' },
];

for (const t of templates) {
  await generate({
    src: t.url,
    target: { css: `critical/${t.name}.css` },
    width: 1300, height: 900,
    // mobile pass merged automatically with dimensions array:
    dimensions: [{ width: 375, height: 812 }, { width: 1300, height: 900 }],
    penthouse: { timeout: 60000 }
  });
}

The loading pattern for WooCommerce critical CSS has three parts: the extracted critical styles inline in a <style> tag in the head (keep it under 14KB compressed — beyond that, inlining costs more than it saves on every page view since inline CSS is never browser-cached); the full stylesheet loaded with rel="preload" as="style" plus an onload swap to rel="stylesheet" so it downloads without blocking render; and a <noscript> fallback link for JavaScript-disabled visitors. The result: the browser paints the above-fold view from inline styles immediately while the complete stylesheet arrives asynchronously. The defer non-critical CSS guide documents the exact preload-onload markup and its browser support.

For most stores, plugin automation is the right call: WP Rocket and FlyingPress generate WooCommerce critical CSS per page via remote services, handle the inline-defer markup, and regenerate on content changes — configuration over code. Verify the result in PageSpeed Insights: the “Eliminate render-blocking resources” audit should drop your main stylesheets, and FCP/LCP should improve measurably on mobile. Watch for flash-of-unstyled-content (FOUC) — if visible, the extraction missed above-fold selectors, usually from JavaScript-injected elements; add those selectors to the forced-include list. Our WooCommerce performance team implements WooCommerce critical CSS as part of every Core Web Vitals engagement, after unused-CSS removal and before font optimisation in the priority order.