SDC Critical CSS

SDC Critical CSS inlines the stylesheets needed to paint the top of the page into a <style> element in the document head, and removes exactly those files from Drupal's CSS aggregate. Rules are delivered once. Works with CSS aggregation on or off. With aggregation on, inlined files are removed from the aggregate so rules are not sent twice.

There is no Node or npm build. You select global CSS files and all Single-Directory Components above the fold in the UI. The module reads those files at request time.

Features

• Zero-build. No Gulp/critical pipeline. Configuration is at /admin/config/development/sdc-critical-css.
• Works without SDC. Tick only the global stylesheets needed for the first paint (base, variables, layout, header). Component inlining is extra capacity when the default theme uses Single-Directory Components.
• Native SDC. Detects component CSS from the page asset list (not from a hardcoded bundle map). Enable components and set visual order; the first N attached components are inlined.
• Page builders. Anything that attaches CSS through Drupal's asset system is visible to the module, including Layout Builder and Paragraphs. Experience Builder / Canvas is expected to work the same way when it attaches SDC libraries normally.
• Editorial overlays. Inlining is skipped on the admin theme, AJAX/dialog responses, _admin_route, _hide_admin_toolbar, and iframe documents (Sec-Fetch-Dest: iframe), so preview UIs are not left with stripped CSS and no inline styles.

Choosing SDC components

One site-wide list is enough. You do not configure critical CSS per content
type, vocabulary, or similar.

On each request the module inlines only **checked** components whose CSS is
actually attached to that page. A checked component that is not on the page
is skipped.

The checklist is one site-wide list. On each page only checked components whose CSS is attached are inlined; components not on the page are skipped. The top content limit is a budget: of those present, only the first N in your order are inlined, because CSS is attached for the whole page, not just the first screen. Set it to 0 for global files only. If you only tick true above-the-fold components, a high limit is fine. This will never be perfect and does not need to be.

Suggested workflow:

1. Turn on Twig debug and open representative front-end pages.
2. Note the SDCs that sit above the fold. Do this at mobile, tablet, and
desktop widths — header and hero often change by breakpoint.
3. Check those components and drag them into a rough visual order (top of
the page first). Close enough is enough; this will never be perfect and
does not need to be.
4. Choose the number of SDCs to be inlined in critical CSS.
5. Turn Twig debug off when you are done.

An SDC with no CSS does not appear on the form.

Remaining CSS

This module does not load the remaining stylesheets asynchronously. After inlining, leftover CSS is still a normal render-blocking <link rel="stylesheet">. That is safe. For async delivery of the remainder, use Non-critical CSS. Do not enable an async-CSS module unless critical CSS is already inlined.

Fonts

Include @font-face rules for above-the-fold type in the global critical CSS selection. Preload the .woff2 files used in the first paint from the theme, not from this module.

Requirements

• Drupal 10 or 11
• The site default (front-end) theme; the admin theme is never processed
• CSS aggregation recommended (system.performance: css.preprocess: true)

Tested with

Manual testing against Drupal CMS Canvas site templates (Summit, Convene, CareSphere, Pulse) and a custom theme using Mercury
Editor, together with Non-critical CSS.
That is a test surface, not a support matrix for those templates.

Similar projects

• Critical CSS — inlines pre-generated theme files (often from a build step) and can load the rest asynchronously.
• Critical CSS UI — stores CSS fragments as entities and matches them to page context.