Two Drupal Modules Split Critical and Deferred CSS Delivery

Released on 28 September 2026, the first stable versions of SDC Critical CSS and Non-critical CSS give Drupal 10 and 11 sites a way to manage critical styles without a Node or npm build step. Developer Dražen Musa, who maintains both projects, published the 1.0.0 releases on Drupal.org. Their release notes describe complementary roles: one module inlines selected styles, and the other loads the remaining stylesheets asynchronously.

Cascading Style Sheets (CSS) determine how a page looks, and applicable stylesheets can delay its initial display while the browser downloads and processes them. Critical CSS supplies the styles needed for the first visible screen directly within the page's HTML. Deferring the remainder can shorten that wait, but deciding which styles belong in the initial delivery becomes more complicated when pages use different combinations of components.

Dražen described that maintenance problem in a Reddit post published the same day. He said his projects repeatedly required custom theme code to inline styles, remove those files from Drupal's aggregated CSS and arrange asynchronous delivery. Different page layouts also required different critical-style selections. The project pages credit Um ad gera ehf. with sponsoring development through client projects.

SDC Critical CSS selects files through Drupal's asset system. Its stable release notes describe detection through Drupal's library registry and a single site-wide component checklist. Selected stylesheets are embedded in the document head, and those files are removed from the CSS aggregate so their rules are not delivered twice. The module can also inline selected global stylesheets on themes that do not use Single-Directory Components (SDC).

Administrators choose components, arrange them in a rough visual order and set a limit on how many can be inlined on each page. Only selected components whose styles are attached to the current page qualify. The limit controls how much component CSS enters the initial HTML, rather than identifying what a visitor can actually see.

That distinction matters when layouts change. A component selected because it appears near the top of one page may sit much further down another. Because the checklist and its order apply across the whole site, they do not adjust when an editor rearranges a particular page. The project documentation therefore recommends checking representative pages at mobile, tablet and desktop widths before choosing the critical components.

Non-critical CSS handles the remaining stylesheets separately on selected front-end themes. Its release notes warn against enabling it before critical styles have been inlined, because pages can otherwise appear briefly without their styling. A small inline script applies the asynchronously loaded stylesheets, while an always-on noscript fallback supplies ordinary stylesheet links when JavaScript is disabled. Without the second module, SDC Critical CSS leaves the remaining stylesheets render-blocking.

Existing Drupal modules offer other ways to organise the same work. Critical CSS inlines pre-generated files stored in a theme, often produced by a build step, and can also load remaining stylesheets asynchronously. Critical CSS UI stores CSS fragments as entities and matches them to page contexts. SDC Critical CSS instead uses selected component libraries already attached to a page, reducing the need to maintain separate critical files for each page context.

Both new projects describe manual testing with the Summit, Convene, CareSphere and Pulse Drupal CMS Canvas templates, plus a custom theme using Mercury Editor. The documentation expressly distinguishes this testing scope from a support matrix. The SDC Critical CSS project page says Layout Builder and Paragraphs output is covered because both attach CSS through Drupal's asset system, and that Canvas is expected to behave the same way. The module skips inlining in administrative and editorial-preview contexts, including AJAX responses and iframe documents. Adoption is still early, with nine sites reporting use of SDC Critical CSS as of 13 October 2026.

Content Security Policy (CSP) remains a deployment consideration. Dražen opened requests on 29 September 2026 to add nonce support to the inline critical stylesheet and the asynchronous-loading script. A nonce allows a browser security policy to authorise a particular inline element. Both requests remained open as of 13 October 2026, so sites requiring CSP nonces for these inline elements need to account for that unfinished integration.

The delivery mechanism also needs to be assessed against a site's actual performance problem. Google's guidance on deferring non-critical CSS describes the technique as advanced, warns that incorrect implementation can cause bugs and notes that most sites can meet its recommended performance targets without it. A high Lighthouse score also does not establish how visitors experience a site: Google's explanation of lab and field data distinguishes controlled tests from measurements collected during real visits. For these modules, the practical checks are whether the chosen styles cover the initial screen, whether later styles arrive without visible disruption and whether measured loading performance improves.