Vrijwel iedereen die zijn site door een snelheidstest haalt, komt hem tegen: “Elimineer bronnen die het weergeven blokkeren.” Renderblokkerende css is de meest voorkomende bevinding op WordPress-sites, en tegelijk de melding waar de meeste schade wordt aangericht door mensen die hem te enthousiast oplossen.
Dit artikel legt uit wat er gebeurt, waarom browsers dat zo doen, en welke oplossingen veilig zijn en welke uw site tijdelijk in een puinhoop veranderen.
Renderblokkerende CSS: wat er precies gebeurt
Een browser die uw pagina opent, leest de HTML van boven naar beneden. Komt hij een verwijzing naar een stylesheet tegen, dan stopt hij met het opbouwen van het scherm totdat dat bestand is opgehaald en verwerkt. Pas daarna tekent hij iets.
Dat is geen fout maar een bewuste keuze. Zou de browser alvast tekenen, dan zag u eerst kale zwarte tekst op wit, die een fractie later omspringt naar uw huisstijl. Dat effect heet ongestileerde inhoud en is voor bezoekers nog vervelender dan een korte witte pagina.
Het probleem is dus niet dat CSS blokkeert, maar hoeveel er blokkeert. Een stylesheet van twintig kilobyte is binnen een oogwenk binnen. Een zwaar thema dat vier stylesheets van samen vierhonderd kilobyte inlaadt, plus twee van plugins, houdt de pagina op een mobiele verbinding een seconde tegen.
Hoe u ziet hoe erg het is
- Open het netwerktabblad in uw browser en filter op CSS. Tel het aantal bestanden en het totale gewicht.
- Kijk naar de watervalgrafiek. Staan er stylesheets die pas beginnen te laden nadat een ander bestand klaar is, dan heeft u een keten die u kunt inkorten.
- Gebruik de dekkingsweergave in Chrome. Die kleurt in welk deel van uw CSS werkelijk op deze pagina wordt gebruikt. Bij zware thema’s is tien tot twintig procent normaal, en dat betekent dat u tachtig procent voor niets laadt.
- Meet met een mobiel profiel. Op wifi valt dit probleem grotendeels weg, en juist daarom wordt het onderschat.
Zit u onder de honderd kilobyte aan CSS in twee of drie bestanden, dan is deze melding bij u een schoonheidsfoutje. Dan levert het aanpakken hooguit een handvol punten op in een test en niets voor uw bezoeker.
De oplossingen, van veilig naar riskant
Minder CSS laden. Verreweg de beste oplossing en de enige zonder bijwerkingen. Zet ongebruikte modules van uw thema uit, verwijder plugins die u niet gebruikt, en zorg dat plugins hun opmaak alleen laden op pagina’s waar ze voorkomen. Een formulierplugin die zijn stylesheet op elke pagina meestuurt, is een klassieker.
Comprimeren en samenvoegen. Overbodige spaties eruit halen scheelt twintig tot dertig procent en is volstrekt risicoloos. Samenvoegen tot één bestand was vroeger belangrijk; met moderne verbindingen is de winst klein en soms zelfs negatief, omdat u dan één groot bestand opnieuw moet laden bij elke wijziging.
Kritieke opmaak apart zetten. Hierbij haalt u de opmaak voor het bovenste deel van de pagina eruit, zet die rechtstreeks in de HTML, en laadt de rest uitgesteld. Dit werkt goed, maar het vraagt onderhoud: verandert uw ontwerp, dan moet die kritieke opmaak opnieuw worden bepaald. Automatische plugins die dit doen, missen geregeld een element, met een korte flits van ongestileerde tekst tot gevolg.
Alle CSS uitgesteld laden. De agressieve stand in sommige optimalisatieplugins. Hiermee haalt u de melding weg en ziet uw bezoeker een halve seconde lang een pagina die eruitziet alsof er iets kapot is. Doe dit niet, tenzij u weet wat u doet en u het resultaat op drie apparaten heeft bekeken.
Let ook op stylesheets die van een ander domein komen, bijvoorbeeld van een lettertypedienst of een beoordelingswidget. Die blokkeren net zo goed, en daar komt de aanloop van een nieuwe verbinding nog bij. Een stylesheet van vijf kilobyte bij een externe partij kan zo alsnog tweehonderd milliseconden kosten. Waar het kan, haalt u zulke bestanden naar uw eigen server; dat is meestal een kwestie van downloaden en in uw thema opnemen.
De volgorde die wij aanhouden
- Eerst opruimen: welke plugin laadt hier opmaak die nergens voor dient?
- Dan comprimeren, want dat is gratis winst.
- Dan kijken of uw thema modules heeft die uit kunnen.
- Pas daarna, en alleen bij een aantoonbaar probleem, kritieke opmaak apart zetten.
- Na elke stap meten en met eigen ogen kijken op een telefoon.
Die laatste regel is de belangrijkste. Optimalisatieplugins geven zelden een foutmelding als er iets misgaat; u ziet het pas als een klant belt dat het menu er raar uitziet. Dat patroon staat ook beschreven in het artikel over plugins die elkaars werk overdoen.
Een praktische waarschuwing bij het testen: zet uw eigen cache uit én die van de site, anders meet u een pagina die al klaarstond. Wij zien geregeld dat iemand na een ingreep een prachtige uitkomst rapporteert die na een lege cache gewoon weer terug is bij af. Ververs dus eerst de cache van uw optimalisatieplugin, laad de pagina één keer om hem opnieuw te laten opbouwen, en meet daarna pas.
Wat u ervan mag verwachten
Op een site met een zwaar thema en zes stylesheets levert een goede opschoning doorgaans drie tot zeven tienden van een seconde op in de tijd tot de eerste zichtbare inhoud. Dat is echt merkbaar. Op een site die al netjes is, wint u een tiende en verliest u een uur.
Er is nog een reden om vooral te schrappen in plaats van te goochelen: alles wat u niet laadt, kan ook niet stukgaan bij de volgende update. Wij kiezen bij WebMaintor daarom binnen een aanpak die de site eenvoudiger maakt in plaats van ingewikkelder liever voor minder bestanden dan voor slimmere trucs.
Concrete volgende stap: filter uw netwerkverkeer op CSS en kijk hoeveel stylesheets er binnenkomen op uw contactpagina. Zijn dat er meer dan vier, dan laadt er vrijwel zeker een plugin mee die op die pagina niets te zoeken heeft.
