Critical CSS

Een browser begint pas met renderen als alle CSS in de head is opgehaald en verwerkt. CSS is render-blocking. Is je stylesheet groot of komt hij van een trage server, dan staart de bezoeker zo lang naar een wit scherm.

Critical CSS lost dat op door de stijlen te splitsen. De regels die nodig zijn voor het eerste scherm, zoals header, navigatie, hero en de eerste productkaarten, komen inline in een style-element in de head. De volledige stylesheet laad je daarna asynchroon. De browser kan dan direct renderen met wat hij al heeft.

Het effect zie je in FCP en vaak ook in LCP, zeker op mobiel met een langzamere verbinding.

Een tweede techniek is CSS per paginatype opsplitsen. De homepage laadt dan geen stijlen voor de checkout, de checkout geen stijlen voor de productgalerij. Dat verkleint wat render-blocking is, ook zonder inline CSS.

Webshop-thema's hebben vaak veel CSS. Stijlen voor checkout, account, productvergelijking, sliders en modals worden meegeladen op elke pagina, ook op de homepage waar ze niet nodig zijn. Elke kilobyte daarvan vertraagt het eerste beeld.

Critical CSS is wel een middel, geen doel. Als je stylesheet klein en goed opgeschoond is, is de winst beperkt en de extra complexiteit niet de moeite waard. Het probleem moet dan eerder bij de omvang van de CSS worden opgelost.

Lighthouse en PageSpeed Insights tonen bij de audit "Render-blocking resources" welke stylesheets het eerste beeld tegenhouden en hoeveel tijd dat kost. Dat is het startpunt om te bepalen of critical CSS de moeite waard is. Staat daar een groot CSS-bestand met veel ongebruikte regels, dan is opschonen meestal de eerste stap.

Ook de levering telt. Een stylesheet die van een ander domein komt, kost een extra verbinding. Serveer je CSS bij voorkeur vanaf hetzelfde domein of via een CDN dat al in gebruik is.

Magento heeft sinds versie 2.3.4 een ingebouwde optie: Stores > Configuration > Advanced > Developer > CSS Settings > Use CSS critical path. Die instelling is alleen zichtbaar in developer mode. Magento zet dan de inhoud van web/css/critical.css uit je thema inline en laadt de overige CSS asynchroon. Je moet dat bestand zelf genereren en onderhouden, bijvoorbeeld met een tool als critical van Addy Osmani.

Bij Hyvä is critical CSS zelden nodig. Tailwind genereert alleen de klassen die echt in je templates voorkomen. De stylesheet is daardoor klein, en één klein bestand dat snel binnen is, werkt in de praktijk net zo goed.

Shopify-thema's zoals Dawn laden een basis-stylesheet en per sectie eigen CSS. Je kunt kritieke stijlen inline in theme.liquid zetten, maar let op dat apps vaak hun eigen CSS toevoegen die je niet beheert. In Laravel met Vite en Tailwind geldt hetzelfde als bij Hyvä: houd de CSS klein, dan heb je de splitsing meestal niet nodig.

Critical CSS één keer genereren en nooit meer bijwerken. Na een redesign of nieuwe header klopt de inline CSS niet meer en verspringt de pagina zodra de volledige stylesheet laadt. Dat kost je CLS.

Ook fout: zo veel CSS inline zetten dat de HTML zelf groot en traag wordt. En vergeten een fallback te geven voor bezoekers zonder JavaScript, als de asynchrone stylesheet via een script wordt geladen.

Automatiseer het genereren als je er wel voor kiest. Een stap in de build-pipeline die per paginatype de critical CSS opnieuw maakt, voorkomt dat de inline stijlen achterlopen.