Google PageSpeed Insights is een geweldige manier om snel een overzicht te krijgen van het optimalisatiepotentieel van je website. Vandaag laat ik je zien hoe je dit potentieel kunt benutten en je PageSpeed Score kunt verhogen. Je moet echter niet slaafs de resultaten van Google volgen. Want de PageSpeed foutmeldingen zijnniet altijd nuttig.

Enige tijd geleden vond Caspar Hübinger in een van zijn blogposts heel duidelijke woorden voor zijn Google Page Speed Insights resultaat. En hij bekritiseert niet alleen de tool, maar ook het gebruik ervan zelf. Want als je niet weet hoe je de afzonderlijke optimalisatiesuggesties moet interpreteren en oplossen, kun je snel verdwalen in de onzinnige jacht op een score van 100. Maar dat zou onverstandig zijn. Immers, utopische Google PageSpeed scores zijn meestal tijdverspilling. Het optimaliseren van de laadtijd is belangrijker.

Fully responsive, loads in 500 ms, and Google’s shiny shittool tells me my mobile performance is “fair”, bc of render-fucking-blockhead CSS.

Caspar Hübinger (Glueckpress)

Vandaag laat ik je zien hoe je de belangrijkste foutmeldingen van Google PageSpeed Insights kunt interpreteren en je website dienovereenkomstig kunt optimaliseren.

Maar voordat ik je laat zien hoe je de afzonderlijke foutmeldingen kunt interpreteren en oplossen, wil ik eerst ingaan op hoe je Google PageSpeed Insights correct kunt gebruiken. We hebben al gezien dat sommige mensen erg gefixeerd zijn op hun PageSpeed Score zonder de laadtijd van hun website in de gaten te houden.

Als je niet geïnteresseerd bent in dit gedeelte, sla het dan gewoon over en leer direct hoe je de foutmelding "CSS comprimeren" kunt oplossen.

Google PageSpeed foutmeldingen zijn niet altijd correct en belangrijk

Je moet nooit uitsluitend vertrouwen op de resultaten of foutmeldingen van Google PageSpeed Insights. Want de tool van Google meet niet de belangrijkste parameter van je website: de laadtijd van de pagina. Om dit correct te meten raad ik Webpagetest.org aan.

Alleen als je bij het optimaliseren van je website vanaf het begin de laadtijd van de pagina in gedachten hebt, kun je zinvolle uitspraken doen over het succes van de optimalisatie. Want het doel van elke optimalisatie moet altijd een verbeterde gebruikerservaring zijn. In het geval van prestatieoptimalisatie is dat natuurlijk de paginalaadtijd en de waargenomen paginalaadtijd.

Voor de gebruikerservaring zijn snellere laadtijden van pagina's en kleinere paginagroottes altijd gunstig. Het geduld en de aandachtsspanne van mensen blijft afnemen (zoals deze studie van Microsoft laat zien) – dit is vooral cruciaal voor e-commerce – en steeds meer traffic komt via mobiele apparaten. Al in 2016 ging 56 procent van de Duitsers regelmatig het internet op via smartphones of tablets. Hier zijn verbindingssnelheden en datavolumes niet altijd onbeperkt. Slanke, snelle websites zijn daarom op hun plaats.

Google PageSpeed geeft echter alleen informatie over het optimalisatiepotentieel van je website en laat slechts enkele conclusies toe over de gebruikerservaring. De lage informatieve waarde van Google PageSpeed foutmeldingen wordt versterkt door het feit dat de tool op bepaalde gebieden niet of alleen met aanzienlijke extra inspanning stil te krijgen is.

De verwijzing naar browser caching verschijnt bijvoorbeeld altijd wanneer externe bronnen – waaronder Google's eigen diensten – zijn geïntegreerd. Deze bronnen kunnen echter niet onder de browser caching van je website vallen. De foutmelding heeft daarom geen relevantie voor de gebruikerservaring van je website, maar wordt geproduceerd door de logica van de tool zelf. In het ergste geval wordt de melding geïnterpreteerd alsof er geen browser caching actief is.

Richt je dus niet primair op de Google-rating, maar op de laadtijd. Dit is de enige echt belangrijke factor.

Maar hoe zit het met mijn Google ranking?

Het voorbeeld van het bericht met de ontbrekende browser caching maakt duidelijk waarom je je niet van de wijs moet laten brengen door een zogenaamd slecht PageSpeed resultaat.

Als je bijvoorbeeld Google Maps of Google Analytics op je website hebt geïntegreerd, zullen deze de volgende foutmelding genereren:

Hetzelfde geldt voor andere diensten van derden. Bijvoorbeeld onze support chat.

Daarom wordt bij elke test van onze website bij PageSpeed Insights dit punt doorgestreept. Dit betekent dat we weten dat deze factor onze resultaten altijd negatief verstoort en daarom gewoon negeren.

Voor de SEO van je website betekent dit dat de laadtijd en de gebruikerservaring ook veel belangrijker zijn voor de Google ranking dan de specifieke PageSpeed score.

Want als je de laadtijd van je website optimaliseert, werk je automatisch aan veel van de gebieden die voor Google belangrijk zijn. Het verbeteren van de laadtijd en de Google PageSpeed Score zijn daarom op een bepaalde manier met elkaar verbonden.

Naar mijn mening moet je je echter niet verliezen in de jacht op een score van 100.

Maar nu naar de optimalisatiestappen!

Foutmelding 1: CSS comprimeren

In onze ervaring is dit een van de meest afschrikwekkende foutmeldingen van Google PageSpeed Insights.

Betekenis: Deze foutmelding geeft aan dat de CSS-bestanden van je website nog gecomprimeerd kunnen worden (of in het bovenstaande geval, dat dit al met succes is gedaan). Met zo'n verkleining wordt het aantal tekens in de documenten verminderd. Hierdoor wordt de bestandsgrootte kleiner. Opmerkingen, spaties en opmaak worden bijvoorbeeld verwijderd.

Uitvoering: Ook al lijkt deze hint ontmoedigend, de uitvoering is denkbaar eenvoudig. In principe zijn er twee mogelijke oplossingen voor dit geval: Als je een ervaren CSS-gebruiker bent, kun je het aantal CSS-bestanden handmatig verkleinen. Je kunt ook zelf de grootte van de CSS-bestanden verkleinen met behulp van online tools zoals CSS Minifier.

Natuurlijk is er ook de handige oplossing van CSS minification plugins in WordPress. Sommige plugins doen allround werk en kunnen niet alleen CSS, maar ook JavaScript en HTML comprimeren en optimaliseren.

Met HTTP/2 heeft het samenvoegen van CSS niet noodzakelijkerwijs zin

De zojuist genoemde Minify plugins worden veel gebruikt. Dat komt omdat ze handig zijn en volledig automatisch zorgen voor het comprimeren en samenvoegen van CSS (en nog veel meer). Tot voor kort had het samenvoegen van CSS-bestanden ook veel zin. Inmiddels zijn de zaken veranderd: sinds de invoering van de HTTP/2 standaard kunnen browsers meerdere bestanden tegelijk van de webserver laden.

Dit betekent dat de gegevens niet meer per se gecombineerd hoeven te worden, want met HTTP/2 kunnen meerdere gegevenspakketten tegelijk worden uitgewisseld. HTTP/2 moet bijvoorbeeld door de hoster ingesteld worden, en kan alleen gebruikt worden met een SSL-certificaat.

Dus voordat je kiest voor een plugin met enkele tientallen functies en configuratiemogelijkheden, denk dan goed na of je die überhaupt nodig hebt. Vooral als je ervan overtuigd bent dat je CSS zelf kunt optimaliseren.

Want een extra plugin kan je website onder bepaalde omstandigheden trager maken. Vooral als de andere functies van de alleskunner plugins zich niet volledig kunnen ontplooien.

Foutmelding 2: Verwijder bronnen die het renderen blokkeren

Ook deze boodschap brengt bij veel mensen zweetdruppels op het voorhoofd, want het is niet zo eenvoudig uit te voeren en het is ook een van de eeuwige kritiekpunten van Google PageSpeed.

Betekenis: Een website wordt in een bepaalde volgorde gebouwd. Deze laadvolgorde kan worden geoptimaliseerd. PageSpeed klaagt bijna altijd dat CSS-bestanden deze optimale laadvolgorde blokkeren. En dat geldt zelfs voor websites die al heel goed geoptimaliseerd zijn (zoals het geval van Caspar Hübinger laat zien). Toch kan de hint heel waardevol zijn voor laadtijdoptimalisatie. In principe vertelt deze hint dat JavaScript- of CSS-code die belangrijk is voor het laden van een element – bijvoorbeeld een achtergrondkleur – nog niet beschikbaar is op het moment dat het element wordt geladen. Dit betekent dat het pas wordt weergegeven als het bijbehorende CSS-commando is geladen. Dit verhoogt de laadtijd van je website niet, maar heeft wel invloed op de gebruikerservaring, want het voelt alsof het laden van de website langer duurt.

Uitvoering: Een gebruikelijke oplossing is om een vuistregel toe te passen: CSS in de header. Dit betekent dat je CSS-code verplaatst van het belangrijkste deel van het HTML-document, de "body", naar het begin van het document, de "head", en het daar opneemt als "style".

Dit voorbeeld maakt duidelijk wat ik bedoel. Het onderstaande codefragment definieert een achtergrondkleur voor een blog. Het "style"-element wordt geladen in de "head" van het HTML document. Op deze manier wordt de achtergrond van de pagina niet aan het eind van het document geladen en ontstaat er een lelijke kleurensprong of wordt de weergave zelfs geblokkeerd.

<head>
<style type="text/css" id="custom-background-css">
body.custom-background { background-color: #f5faff; }
</style>
</head>

Je kunt deze optimalisatiemaatregel op twee manieren doorvoeren: Je kunt zelf de code aanpassen en de CSS-codes naar de header verplaatsen, of je kunt een plugin het werk laten doen.

De plugin Autoptimize, bijvoorbeeld, kiest voor een allround aanpak: Hier selecteer je de opties voor alle CSS bestanden die niet worden uitgesloten van het proces.

Het fragment uit de opties van de plugin laat zien: Zelfs de plugin variant kan niet worden uitgevoerd zonder een basiskennis van het proces. Je moet je dus ook vertrouwd maken met de plugins.

Foutmelding 3: Afbeeldingen efficiënt coderen

Dit is een ander punt waar PageSpeed Insights vaak over moppert. Dit geval is echter bijna altijd snel en eenvoudig uit te voeren en levert meestal ook tastbare voordelen op voor de laadtijd.

Betekenis: Velen onderschatten de rol van de grootte van afbeeldingen voor de laadtijd van hun website. Toch zijn afbeeldingen heel vaak een van de grootste laadtijdremmers. Zelfs als slechts kleine hoeveelheden gegevens worden opgeslagen voor afzonderlijke afbeeldingen, kan het totale volume dat wordt bespaard een aanzienlijke hoeveelheid gegevens opleveren.

Want een afbeelding is zelden zomaar een afbeelding. WordPress genereert automatisch meerdere miniaturen van de afbeelding als je die uploadt. Dus als je niet de originelen op je homepage gebruikt, maar kleinere versies ervan, bijvoorbeeld thumbnails of features images, dan moeten die natuurlijk ook geoptimaliseerd worden. Eén afbeelding wordt al snel meerdere bestanden, die ook een meervoudige gegevenslading met zich meebrengen.

Uitvoering: In principe heb je twee mogelijkheden om je afbeeldingen te optimaliseren. Of je optimaliseert de afbeeldingen vóór het uploaden of na of tijdens het uploaden. Het eerste kan worden gedaan met online of offline tools, het laatste met geschikte WordPress plugins voor beeldoptimalisatie.

Als je compressie in je workflow kunt integreren, is het zinvol om de afbeeldingen te optimaliseren voordat je ze uploadt. Daar zijn online tools voor, zoals Kraken.io. Of je kunt de kwaliteit en dus de bestandsgrootte van je afbeeldingen offline verminderen, bijvoorbeeld direct in Photoshop. Dit bespaart je de extra plugin en houdt je website slank.

De handigere oplossing is natuurlijk een plugin. Plugins als Optimus of Smush optimaliseren niet alleen de hoofdafbeelding, maar ook alle variaties daarvan. Smush kan achteraf ook al je bestaande afbeeldingen optimaliseren.

De plugins werken onder andere met een zogenaamde "lossless compression". Dit betekent dat de bestandsgrootte van de afbeeldingen kleiner wordt, maar dat hun zichtbare kwaliteit niet afneemt.

Foutmelding 4: Tekstcompressie activeren

Deze foutmelding van Google PageSpeed is heel snel te verhelpen en kan de laadtijd van je website aanzienlijk verkorten.

Dat wil zeggen: Je hebt de afbeeldingen en CSS van je website al zoveel mogelijk verkleind. Dat is goed! Maar dat is nog niet alles. Want nu kun je een ander compressiemechanisme gebruiken. Je kent dit proces waarschijnlijk van het downloaden van grote gegevenspakketten: Die heb je meestal in gezipte, dus gecomprimeerde, vorm. Dit maakt de gegevens kleiner en het downloaden sneller. Maar de gegevenspakketten moeten na het downloaden nog steeds worden uitgepakt. Precies hetzelfde gebeurt bij het laden van een pagina: De webserver levert de gegevenspakketten gecomprimeerd aan, de webserver pakt ze uit. Dit maakt de gegevensoverdracht sneller en verkort de laadtijd van de pagina.

Implementatie: Of de datacompressie is al ingesteld op de server of je moet het zelf activeren. Bij Raidboxes hoef je je nergens zorgen over te maken. Wij hebben standaard de bijzonder sterke Brotli compressie geactiveerd.

Met de volgende vermelding in je .htaccess kun je de zogenaamde GZIP compressie ook handmatig activeren. Mits je een Apache webserver hebt.

<ifModule mod_gzip.c>
 mod_gzip_on Yes
 mod_gzip_dechunk Yes
 mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
 mod_gzip_item_include handler ^cgi-script$
 mod_gzip_item_include mime ^text/.*
 mod_gzip_item_include mime ^application/x-javascript.*
 mod_gzip_item_exclude mime ^image/.*
 mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
 </ifModule>
 
 <IfModule mod_deflate.c>
 AddOutputFilterByType DEFLATE text/plain
 AddOutputFilterByType DEFLATE text/html
 AddOutputFilterByType DEFLATE text/xml
 AddOutputFilterByType DEFLATE text/css
 AddOutputFilterByType DEFLATE application/xml
 AddOutputFilterByType DEFLATE application/xhtml+xml
 AddOutputFilterByType DEFLATE application/rss+xml
 AddOutputFilterByType DEFLATE application/javascript
 AddOutputFilterByType DEFLATE application/x-javascript
 </IfModule>

Foutmelding 5: statische inhoud met een efficiënt cachebeleid leveren 

Naar mijn mening is de verwijzing naar browser caching verreweg het meest vervelend bij Google PageSpeed Insights. Dat komt omdat je browser caching alleen kunt instellen voor je eigen bronnen. Browser caching is niet mogelijk voor externe bronnen.

Betekenis: Browser caching betekent dat de browser een statische versie van je website opslaat en die niet hoeft op te vragen bij de webserver als je hem opnieuw bezoekt, maar dat de website al geladen is.

Implementatie: Of je hoster heeft browser caching aan de serverzijde al geactiveerd, of je kunt het instellen door het .htaccess bestand te manipuleren (onthoud: deze instelling werkt alleen op Apache webservers). De onderstaande voorbeeldcode stelt bijvoorbeeld de browsercache in op één maand, d.w.z. dat de statische versie van je website één maand in de browser van de bezoeker wordt opgeslagen.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access 60 seconds"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/ico "access plus 1 month"
ExpiresByType text/css "access 1 month"
ExpiresByType text/javascript "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
</IfModule>

Ook hier geldt: Als je een Raidboxes klant bent, dan is browser caching standaard al actief.

My 2 Cents: Zonder cache is alles niets

Goed, nu heb je de afbeeldingen van je website geoptimaliseerd, CSS verkleind, gecomprimeerd en in de juiste volgorde gezet en de browser van je bezoekers de website laten cachen. Al deze maatregelen verkorten de laadtijd van je website.

Betekenis: Zonder een goede cache geef je echter veel van dit potentieel weg. Caching is en blijft verreweg de belangrijkste prestatiefactor. Een cache slaat de inhoud van je WordPress website tijdelijk op en zorgt ervoor dat niet telkens de hele website opnieuw geladen hoeft te worden. In plaats daarvan wordt een statische, d.w.z. reeds gerenderde versie van je website geleverd vanuit een cache. Dit omzeilt het trage PHP en de database in het bijzonder.

Implementatie: Ook hier heeft je hoster al een server-side cache ingesteld of gebruik je een caching plugin. Er zijn enkele zeer krachtige plugins die grote delen van je website cachen en leiden tot een aanzienlijke verkorting van de laadtijd bij terugkerende websitebezoeken.

De grote kracht van caching plugins is ook hun grootste zwakte. Het kan best zijn dat een caching plugin je website aanvankelijk trager maakt voor de eerste bezoekers. Want hoe ingewikkelder je blog of website is, hoe ingewikkelder en uitgebreider de cache engine moet zijn die je blog cacht. Dit is vooral relevant voor webwinkels.

Als je een relatief eenvoudige website hebt, dan zijn minimalistische oplossingen misschien wel beter dan caching alleskunner. Een van deze slanke plugins is bijvoorbeeld Cache Enabler.

Je moet er rekening mee houden dat caching-plugins meestal ook het verkleinen en samenvoegen van CSS of JavaScript overnemen. Daarom moet je nagaan of je caching-plugin de plugins voor CSS-optimalisatie niet al overbodig maakt.

Als je server-side caching gebruikt, is het raadzaam de cachingfuncties van plugins zoals Autoptimize uit te schakelen, of te testen of ze überhaupt nog prestatievoordelen opleveren.

Conclusie: Veel bewegen met slechts een paar plugins

Je hebt het tijdens het lezen al gemerkt: voor het optimaliseren van CSS, afbeeldingen en het optimaliseren van de laadvolgorde zijn er plugins die je veel werk uit handen nemen. Maar niet al het werk. Caching plugins leveren ook snel een merkbaar effect, maar zijn soms erg uitgebreid en bieden veel configuratiemogelijkheden en soms overbodige functies.

Kijk in elk geval eens goed naar de plugins die je gebruikt. Alleen als je weet wat er gebeurt als je bepaalde functies gebruikt, kun je verstandig optimaliseren. Het overladen van de website met optimalisatieplugins heeft de neiging om weinig goeds te doen.

En bij het optimaliseren moet je ervoor zorgen dat je je succes goed meet. Het maakt niet uit of je handmatig of via een plugin optimaliseert. Gebruik PageSpeed Insights als eerste referentiepunt om de zwakke punten van je website te identificeren. Meet vervolgens de laadtijd van je website vóór de optimalisatie. Pas als je de beginsituatie hebt vastgelegd, heeft het echt zin om je website stap voor stap te optimaliseren. Want pas als je de laadtijd vóór optimalisatie en na elke optimalisatiestap kent, kun je bepalen wat de afzonderlijke optimalisatiemaatregelen hebben opgeleverd.