Kritieke CSS instellen

Wat de module doet — en wat ze niet doet

Kakapo haalt per paginasjabloon een echte voorbeeldpagina van je site op via HTTP (alleen in het beheergedeelte of via cron, nooit tijdens het opbouwen van de pagina voor een bezoeker), leest de daar gelinkte lokale stylesheets rechtstreeks van de harde schijf en toetst elke afzonderlijke regel met DOMXPath aan het document. Daaruit ontstaan twee resultaten: de kritieke CSS, die inline in de head wordt gezet, en de lijst met regels die op dit sjabloon geen enkel element hebben geraakt.

Er wordt daarbij niets gerenderd. Er is geen browser, geen viewport en geen scrollpositie. ‘Boven zichtbaar’ is een benadering volgens een openbaar gemaakte regel: alle elementen onder body worden doorgenummerd, de eerste 30 procent (standaardinstelling, instelbaar tussen 5 en 90) gelden als boven, plus alles binnen de ingevoerde oriëntatiepunten. Altijd opgenomen worden html, body, :root en @font-face, evenals @keyframes die door een kritieke regel via animation worden genoemd. Regels die alleen via toestanden werken (:hover, :focus, :active), blijven erbuiten, @media print eveneens. Waar de methode aan haar grens komt, rondt ze naar boven af: de regel geldt als geraakt. Een paar kilobyte te veel kost minder dan een ontbrekende regel en geflikker.

Voorwaarden controleren voordat je analyseert

Twee dingen moeten kloppen. Ten eerste de PHP-extensie dom/libxml — de module controleert die niet via class_exists(), maar bouwt een miniatuurdocument en bevraagt dat echt. De reden: sommige hosters zetten disable_classes=DOMDocument, dan meldt class_exists() nog steeds ‘ja’, maar de new mislukt. Ontbreekt de extensie, dan zijn ‘Analyseren’ en ‘Dagelijks verversen’ geblokkeerd en staat de reden ernaast.

Ten tweede de loopback: de site moet zichzelf via HTTP kunnen bereiken. Daarvoor is er de knop ‘Loopback controleren’ in het gedeelte Voorwaarden; hij onthoudt HTTP-code, antwoordgrootte en duur. Mislukt hij, dan mislukt elke analysedoorloop — typische oorzaken zijn een firewall vóór de site, een Basic-Auth-beveiliging op de staging-omgeving of een hostnaam die intern niet wordt opgelost.

Wat de analyse niet kan lezen, wordt ook niet uitgesteld: stylesheets van vreemde hosts, van een CDN of uit Google Fonts blijven onveranderd renderblokkerend. Dat is de trage, maar veilige weg.

Sjabloon voor sjabloon te werk gaan

Er zijn zeven sjablonen: Startpagina, Blogpagina, Los bericht, Statische pagina, Archief, Zoekresultaten en Foutpagina 404. Elk sjabloon wordt afzonderlijk geanalyseerd en afzonderlijk vrijgegeven. Toont je startpagina de berichtenlijst, dan is ‘Blogpagina’ niet van toepassing — de schakelaar blijft geblokkeerd, omdat hij geen effect zou hebben. Is er geen gepubliceerd bericht of geen pagina, dan ontbreekt de voorbeeldpagina en blijft het sjabloon eveneens geblokkeerd.

De aanbevolen weg: eerst ‘Alles analyseren’ of afzonderlijk analyseren. Daarna open je bij een sjabloon ‘Voorbeeld’ en ‘zonder’ in twee tabbladen — dat is dezelfde echte pagina, één keer met en één keer zonder behandeling, alleen zichtbaar voor ingelogde beheerders en alleen met een geldige eenmalige sleutel in het adres. De hoofdschakelaar hoeft daarvoor niet aan te staan. Flikkeren tijdens het opbouwen zie je het betrouwbaarst in een eigen tabblad met een afgeknepen verbinding, niet in het ingebedde kader.

Pas als de vergelijking er schoon uitziet, geef je het sjabloon vrij en zet je de hoofdschakelaar aan. Hij begint in testmodus: daar krijgen alleen ingelogde beheerders de behandeling te zien, voor alle anderen blijft de pagina onveranderd. Op ‘scherp’ zet je hem pas als je meerdere sjablonen hebt doorgenomen.

De vier remmen en de uitzonderingslijsten

‘Geanalyseerde stylesheets vertraagd laden’ is de eigenlijke tijdwinst. Uit betekent: de kritieke CSS komt er inline bij, verder blijft alles zoals het was — risicoloos, maar zonder winst. Aan betekent: de geanalyseerde stylesheets laden via media="print" plus een onload-terugzetter, met een noscript-duplicaat voor bezoekers zonder JavaScript. Vertraagd wordt uitsluitend wat ook echt gelezen is, en alleen als handle en bestandsadres nog passen bij wat er geanalyseerd is.

‘Bij gewijzigde bronbestanden overslaan’ onthoudt van elk geanalyseerd bestand de wijzigingstijd en de grootte, plus het actieve thema. Verandert er iets, dan wordt er helemaal niet behandeld in plaats van met mogelijk verkeerde kritieke CSS — in de broncode staat dan een notitie met de reden.

Drie tekstvelden zijn de nooduitgang. Uitsluitings-URL’s: één regel per pad, ‘*’ als jokerteken, deze pagina’s worden nooit behandeld (typisch /checkout*, /mein-konto*). Stylesheets nooit vertragen: één WordPress-handle per regel, standaard admin-bar en dashicons. Oriëntatiepunten: één selector per regel, alles daarbinnen geldt als boven — standaard zijn dat header, [role="banner"], .site-header, #masthead, nav, .main-navigation, .site-branding, .hero en h1. Regels die niet te verwerken zijn, worden geweigerd in plaats van stilzwijgend opgeslagen.

Een wijziging aan het aandeel ‘boven’ of aan de oriëntatiepunten werkt pas na een nieuwe analysedoorloop. Al het andere gooit de paginacache meteen weg, omdat daar kant-en-klare HTML met de oude toestand ligt.

Als er iets misgaat

‘Tijdsbudget opgebruikt’: de doorloop heeft 25 seconden of het PHP-tijdslimiet bereikt. Het rapport is opgeslagen, de kritieke CSS bewust niet — onvolledige kritieke CSS zou flikkeren. De melding noemt het bestand waar het ophield. Analyseer opnieuw of haal een heel groot stylesheet er via de uitzonderingslijst uit.

‘Antwoordde met HTTP …’: de voorbeeldpagina leverde niet de verwachte code (200, bij de foutpagina 404). Er wordt niets opgeslagen. Controleer of de pagina in de browser bereikbaar is en of er een beveiliging voor zit.

Een sjabloon staat op ‘verouderd’: een geanalyseerd CSS-bestand is gewijzigd of het thema is gewisseld. Opnieuw analyseren. Staat daar ‘ander aandeel’, dan is het sjabloon met een ander percentage gemaakt dan nu is ingesteld — eveneens opnieuw analyseren.

Zodat dat geen handwerk blijft, is er ‘Dagelijks controleren en verversen’. De cron-doorloop analyseert alleen sjablonen die al vrijgegeven en verouderd zijn; hij schakelt nooit iets in en maakt geen analyse aan voor een niet-vrijgegeven sjabloon. Zijn laatste resultaat staat als notitie in het gedeelte Veiligheidsgordel.

Blijft een pagina toch onrustig, dan helpt een blik in de broncode: daar staat een commentaar met het behandelde sjabloon en de toestand (voorbeeld, testmodus, scherp) of de reden waarom er bewust niet is behandeld.