Google PageSpeed Insights is een geweldige manier om snel een overzicht te krijgen van het optimalisatiepotentieel van je site. Vandaag laat ik je zien hoe je dit potentieel kunt gebruiken en je PageSpeed score kunt verhogen. Je moet echter niet slaafs de resultaten van Google volgen. Omdat de PageSpeed foutmeldingen niet altijd nuttig zijn.

Enige tijd geleden vond Caspar Hübinger in een van zijn blogberichten heel duidelijke woorden voor zijn Google PageSpeed Insights resultaat. En hij bekritiseert niet alleen het instrument, maar ook het gebruik ervan door de gebruikers. 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.

Volledig responsief, laadt in 500 ms, en Google's glimmende shittool vertelt me dat mijn mobiele prestaties "redelijk" zijn, vanwege 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 pagina 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 gebruikt. We hebben vaak gezien dat gebruikers gefixeerd zijn op hun PageSpeed score zonder de laadtijd van hun pagina 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 . Dat komt omdat de Google-tool niet de belangrijkste parameter van je website meet: de laadtijd van de pagina. Om dit goed te meten raad ik Webpagetest.org aan.

Alleen als je bij de optimalisatie van je site de laadtijd van de pagina vanaf het begin in gedachten heeft, kun je zinvolle uitspraken doen over het succes van de optimalisatie. Omdat het doel van elke optimalisatie altijd een verbeterde gebruikerservaring moet zijn. In het geval van prestatie-optimalisering gaat het natuurlijk om de laadtijd van de pagina en de waargenomen laadtijd van de pagina.

Vanuit het oogpunt van de gebruiker zijn snellere laadtijden en kleinere pagina's altijd gunstig. Het geduld en de aandachtsspanne van de gemiddelde gebruiker blijven afnemen(zoals deze studie van Microsoft laat zien) - dit is vooral cruciaal voor e-commerce - en steeds meer bezoekers komen via mobiele apparaten. Al in 2016 had 56 procent van de Duitsers regelmatig toegang tot het internet via smartphones of tablets. Hier zijn verbindingssnelheden en datavolumes niet altijd onbeperkt. Magere, snelle pagina's zijn daarom geschikt.

Google PageSpeed geeft echter alleen informatie over het optimalisatiepotentieel van je pagina en laat slechts enkele conclusies toe over de gebruikerservaring. De geringe betekenis 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 zal bijvoorbeeld altijd verschijnen wanneer externe bronnen - waaronder Google's eigen diensten - worden geïntegreerd. Deze bronnen kunnen echter niet gedekt worden door de browser caching van je pagina. De foutmelding is dus niet van belang voor de gebruikerservaring van je site, maar wordt geproduceerd door de logica van de tool zelf. In het slechtste geval wordt het bericht 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 ontbreken van browser caching maakt heel duidelijk waarom je je niet moet laten afschrikken door een zogenaamd slecht PageSpeed resultaat.

Als je bijvoorbeeld Google Maps of Google Analytics op je pagina 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 site op PageSpeed Insights dit punt afgekalkt. Dit betekent dat we weten dat deze factor onze resultaten altijd negatief verstoort en daarom gewoon negeren.

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

Want als je de laadtijd van je pagina 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 pagina nog gecomprimeerd kunnen worden (of in het bovenstaande geval, dat dit al met succes is gedaan). Een dergelijke reductie vermindert het aantal tekens in de documenten. Hierdoor wordt het bestand kleiner. Opmerkingen, spaties en opmaak, bijvoorbeeld, worden 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 zelf een CSS-expert bent, kun je het aantal CSS-bestanden handmatig verminderen en een stenografische notatie gebruiken bij het aanmaken ervan. Je kunt de CSS-bestanden ook zelf verkleinen met online tools als CSS Compressor of CSS Minifier.

Natuurlijk is er ook de handige oplossing van CSS minification plugins in WordPress. Sommige plug-ins 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 plug-ins worden veel gebruikt. Dit komt omdat ze handig zijn en volledig automatisch zorgen voor het comprimeren en samenvoegen van CSS (en nog veel meer). Tot voor kort was het combineren van CSS-bestanden ook heel zinvol. Intussen zijn de dingen veranderd: want sinds de HTTP/2 standaard is ingevoerd, 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 worden ingesteld, en kan alleen worden gebruikt 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.

Omdat een extra plugin je site onder bepaalde omstandigheden trager kan maken. Vooral als de andere functies van de alleskunner plugins niet hun volledige potentieel kunnen ontvouwen.

Foutmelding 2: Verwijder bronnen die het renderen blokkeren

Dit bericht brengt ook parels van zweet op het voorhoofd van veel gebruikers, want het is niet zo eenvoudig uit te voeren en is ook een van de eeuwige kritiekpunten van Google PageSpeed.

Betekenis: Een webpagina wordt in een bepaalde volgorde opgebouwd. Deze laadvolgorde kan worden geoptimaliseerd. PageSpeed klaagt bijna altijd dat CSS-bestanden deze optimale laadvolgorde blokkeren. En dit geldt zelfs voor pagina's die al heel goed geoptimaliseerd zijn(zoals het geval van Caspar Hübinger laat zien). Toch kan de hint zeer waardevol zijn voor laadtijdoptimalisatie. In principe vertelt deze hint je 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. Daardoor wordt het pas weergegeven als het bijbehorende CSS-commando is geladen. Dit verhoogt de laadtijd van je pagina, maar beïnvloedt vooral de gebruikerservaring, omdat de pagina aanvoelt alsof het langer duurt om te laden.

Umsetzung: Eine gängige Lösung ist die Umsetzung einer Daumenregel: CSS in den Header. Das bedeutet, dass du CSS-Code vom Hauptteil des HTML Dokuments, dem <body>, an den Anfang des Dokuments, den <head>, verschiebst und dort als <style> einbindest.

An diesem Beispiel wird deutlich, was ich meine. Der Codeschnipsel unten definiert unsere spezifische Hintergrundfarbe für den Blog. Das <style>-Element wird im head des HTML-Dokuments geladen. So lädt der Seitenhintergrund nicht erst am Ende des Dokuments und erzeugt einen unschönen Farbsprung oder blockiert gar das Rendering.

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

Je kunt deze optimalisatiemaatregel op twee manieren uitvoeren: Je kunt de code zelf aanraken en de CSS-codes in de header verplaatsen, of je kunt een plugin het werk laten doen. Plugins als Better WordPress Minify kunnen hier ook helpen.

De Minify plugin laat in de opties bijvoorbeeld zien welke CSS bestanden al naar de header zijn verplaatst. Je zou hier ook handmatig meer CSS-bronnen kunnen toevoegen.

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

De fragmenten uit de plug-in opties laten zien: Zelfs de plug-in variant kan niet worden uitgevoerd zonder basiskennis van het proces. Je moet je dus ook vertrouwd maken met de plug-ins.

Foutmelding 3: beelden 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: Veel gebruikers onderschatten de rol van de beeldgrootte voor de laadtijd van hun pagina. Toch zijn afbeeldingen heel vaak een van de grootste laadtijdremmen. Zelfs als slechts kleine hoeveelheden gegevens worden opgeslagen voor afzonderlijke beelden, kan het totale volume dat wordt opgeslagen 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 uitgelichte afbeeldingen, 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 plug-ins voor beeldoptimalisatie.

Als je compressie in je workflow kunt integreren, is het zinvol om de beelden 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 pagina slank.

De handigere oplossing is natuurlijk een plug-in. Add-ons zoals Optimus of Smush optimaliseren niet alleen de hoofdafbeelding, maar ook alle variaties daarvan. Smush kan ook al je bestaande afbeeldingen achteraf optimaliseren.

De plug-ins 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: Activeer tekstcompressie

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

Dat wil zeggen: Je hebt je afbeeldingen en CSS al zoveel mogelijk verkleind. Dat is goed! Maar dat is nog niet alles. Nu kun je een ander compressiemechanisme gebruiken. Je kent dit proces waarschijnlijk van het downloaden van grote gegevenspakketten: Je hebt ze meestal in gezipte, dus gecomprimeerde, vorm. Dit maakt de gegevens kleiner en het downloaden sneller. De gegevenspakketten moeten na het downloaden echter nog 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 vermindert de laadtijd van de pagina.

Uitvoering: Of de datacompressie is al ingesteld op de server, of je moet hem zelf activeren. Als je een Raidboxes klant bent, hoef je je nergens zorgen over te maken. Dat komt omdat we standaard de bijzonder sterke Brotli compressie hebben 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: Lever statische inhoud met een efficiënt cachebeleid 

Naar mijn mening is de verwijzing naar browser caching verreweg het vervelendst bij Google PageSpeed Insights. Dit 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 pagina opslaat en die niet opnieuw bij de webserver hoeft op te vragen als je de site bezoekt, maar de pagina 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 browser cache in op één maand, dat wil zeggen dat de statische versie van je pagina éé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 op je pagina geoptimaliseerd, CSS verkleind, gecomprimeerd en in de juiste volgorde gezet en de browser van je bezoekers de pagina laten cachen. Al deze maatregelen verkorten de laadtijd van je pagina.

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 pagina tijdelijk op en zorgt ervoor dat niet telkens de hele pagina opnieuw geladen hoeft te worden. In plaats daarvan wordt een statische, d.w.z. reeds gerenderde versie van je pagina 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 plug-ins die grote delen van je pagina cachen en leiden tot een aanzienlijke verkorting van de laadtijd voor terugkerende websitebezoekers.

De grote kracht van caching plug-ins is ook hun grootste zwakte. Het kan best zijn dat een caching plugin je site aanvankelijk trager maakt voor de eerste bezoekers. Want hoe ingewikkelder je blog of je pagina is, hoe ingewikkelder en uitgebreider de cache engine moet zijn die je blog cached. Dit is vooral relevant voor winkels.

Als je een relatief eenvoudige website beheert, kunnen minimalistische oplossingen beter zijn dan caching alleskunners. Een van deze magere plugins is bijvoorbeeld Cache Enabler.

Merk op dat caching plug-ins meestal ook het verkleinen en samenvoegen van CSS of JavaScript overnemen. Daarom moet je controleren 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 plug-ins zoals Autoptimize uit te schakelen, of te testen of ze überhaupt nog prestatievoordelen opleveren.

Conclusie: Veel bewegen met slechts een paar plug-ins

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 ze zijn soms erg uitgebreid en bieden veel configuratiemogelijkheden en soms overbodige functies.

Kijk in elk geval eens goed naar de plug-ins die je gebruikt. Alleen als je weet wat er gebeurt als je bepaalde functies gebruikt, kun je verstandig optimaliseren. De pagina overladen met optimalisatieplugins brengt meestal weinig op.

En bij het optimaliseren moet je ervoor zorgen dat je je succes goed meet. Het maakt niet uit of je met de hand of via een plugin optimaliseert. Gebruik PageSpeed Insights als eerste referentiepunt om de zwakke punten van je pagina op te sporen. Meet dan de laadtijd van je pagina vóór de optimalisatie. Het heeft pas zin om je pagina stap voor stap te optimaliseren als je de beginsituatie hebt bepaald. Alleen als je de laadtijd vóór optimalisatie en na elke optimalisatiestap kent, kun je bepalen wat de afzonderlijke optimalisatiemaatregelen hebben opgeleverd.