PageSpeed often blames your stylesheet for a reason. If the browser has to download a large CSS file before it can paint anything useful, visitors stare at a blank or half-drawn page longer than they should.

The fix is not to delete your theme styles or hand-write tiny CSS files for every template. On a real WordPress site, that does not scale. This is where Swift Performance helps by generating critical CSS per page automatically, then deferring the rest.

What render-blocking CSS actually means

When a browser loads a page, it tries to build the layout as early as possible. CSS is part of that process, so external stylesheets in the <head> are treated as render-blocking by default.

That matters because your page may only need a small portion of the stylesheet to draw the first visible screen. But the browser still waits for the full file, even if most of that CSS is only needed lower on the page, on a different device, or on another template entirely.

In WordPress, this problem gets worse fast:

  • themes load global styles for every page
  • builders add layout CSS for many modules
  • plugins enqueue their own frontend styles
  • mobile and desktop rules ship together

The real problem is not that CSS exists. The real problem is that too much of it blocks first paint.

What a better critical CSS setup looks like

A good critical CSS WordPress setup does two things:

  1. It inlines only the minimum CSS needed for above-the-fold content.
  2. It defers the full stylesheet until after the initial render.

In practice, that means the visitor gets a visible page sooner, while the rest of the styling loads in the background. This can improve First Contentful Paint and Largest Contentful Paint, which is exactly why PageSpeed cares about it.

With Swift Performance, the process is automated during optimization:

  1. We collect the page CSS during cache prebuild.
  2. Our API renders the page in Chrome for desktop and mobile viewports.
  3. Swift Performance identifies the above-the-fold styles.
  4. It generates device-specific critical CSS files.
  5. The critical CSS is inlined in the <head>.
  6. The original stylesheets are deferred and loaded after render.

For most sites, this is the only practical way to maintain critical CSS without constant breakage.

Enable CSS optimization in Swift Performance

If you want a working result quickly, start with the recommended CSS optimization level and test from there.

  1. Install and activate Swift Performance.
  2. In WordPress admin, open the Swift Performance configuration screen.
  3. Find the Optimize CSS section.
  4. Set the optimization level to Level 2 – Full (Recommended).
  5. Save your changes.
  6. Let Swift Performance warm and optimize the affected pages.

Level 2 includes:

  • critical CSS extraction
  • unused CSS removal
  • CSS minification
  • media query optimization
  • font subsetting
  • WOFF2 conversion
  • font preloading
  • font-display: swap

If your site uses custom fonts with licensing restrictions, icon fonts, or special character sets that need extra care, start with Level 1 – Basic instead. You still get critical CSS generation, just without the font optimization layer.

How Swift Performance generates critical CSS per page

One reason manual critical CSS fails is that WordPress pages are not all the same. Your homepage, blog post, contact page, archive, and landing pages usually have different layouts, assets, and above-the-fold elements.

Swift Performance handles that page by page.

  1. During prebuild, it visits the URL with a headless browser.
  2. It collects all stylesheet links and inline styles from that specific page.
  3. The API renders the page in Chrome using desktop and mobile viewports.
  4. It runs CSS coverage analysis to detect what is actually needed above the fold.
  5. Swift Performance outputs separate critical CSS for desktop and mobile.

On delivery, the plugin inlines those rules using media queries:

  • @media (min-width: 768px) for desktop
  • @media (max-width: 767px) for mobile

At the same time, the original stylesheets are changed to rel="swift/stylesheet", then loaded after the initial render via JavaScript.

In other words, visitors get the visible styling first, then the full CSS later. That is the point.

Why doing this by hand is unrealistic on a real site

It is tempting to think you can export a little critical CSS once and be done. On most WordPress sites, that breaks down almost immediately.

Here is why:

  1. Templates change over time, especially on marketing sites and stores.
  2. Plugins add or remove styles when features change.
  3. Builders output different markup per page.
  4. Mobile and desktop above-the-fold areas are not the same.
  5. Menus, widgets, and hero sections often change after routine edits.

Now multiply that across dozens or hundreds of URLs.

You would need to regenerate and validate critical CSS constantly. That is why we built this into Swift Performance as an automatic per-page process, not a one-time manual task. It is not just faster to set up. It is easier to keep correct.

Test the result and handle common issues

After enabling CSS optimization, check a few representative pages instead of only the homepage.

  1. Open your homepage, a blog post, a landing page, and any key archive page.
  2. Test on both desktop and mobile.
  3. Run PageSpeed Insights before and after.
  4. Look for improvements in FCP and LCP.
  5. Check visually for missing styles, font issues, or layout shifts.

If something looks off, the fix is usually straightforward:

  • Missing font characters: use Level 1, or make sure the needed characters are present in the page content during optimization.
  • Icon fonts broken: use Level 1, or exclude the icon font if needed.
  • External CSS not optimized: make sure the CSS is served from the same domain or is CORS-enabled.
  • Layout shifts: enable Optimize CLS if your layout still shifts after render.

If you are debugging a page, you can temporarily disable CSS optimization by switching to Level 0. That gives you a clean baseline.

For deeper configuration details, see our Swift Performance documentation.

Take-home message

Critical CSS WordPress optimization is really about delivery order. The browser should get the small amount of CSS needed to paint the first screen immediately, and the rest later.

Doing that manually on a living WordPress site is not realistic. Swift Performance automates critical CSS generation per page, per viewport, which makes the setup both practical and maintainable. If PageSpeed keeps flagging render-blocking CSS, this is one of the highest-impact places to start.