Google PageSpeed Insights: de waarheid over de 100/100 score

Google Pagespeed Insights is een handig hulpmiddel voor webmasters, ontwikkelaars en site-eigenaren. Toch merken we dat mensen buitensporig veel tijd steken om die gewilde 100/100-score te halen en er alles aan doen om hun site zo goed mogelijk te optimaliseren.

Dit was echter nooit de bedoeling achter Google PageSpeed Insights. Daarnaast is het een zinloze onderneming. Onze stelling: wanneer je je richt op de aanbevelingen die het platform je geeft, in plaats van je blind te staren op het nummer bovenaan de pagina, pas dan zal je voordeel halen uit deze tool.

Dit artikel is een uitgebreide handleiding over hoe je het beste gebruik maakt van Google PageSpeed Insights. We bespreken waar Google je score op baseert en hoe je de aanbevelingen die je ontvangt, kan verwerken.

Laten we beginnen!

Een inleiding tot Google PageSpeed Insights

Voor het geval je nog onbekend bent met Google PageSpeed Insights, dit is een tool die kan worden gebruikt om de prestaties van een website te testen. Je kan elke URL invoeren om deze te laten analyseren:

Google geeft je vervolgens een totaalscore van 0 tot 100. Deze score is gebaseerd op verschillende best practices in de wereld van website-optimalisatie:

Naast deze score zie je ook de verschillende aanbevelingen van Google over het verbeteren van je prestaties (en dus daarmee ook je PageSpeed Insights-score):

Vanaf 2018 worden PageSpeed Insights-scores berekend via Lighthouse, de opensource en geautomatiseerde tool van Google voor het verbeteren van de algehele kwaliteit van webpagina’s. Dit platform kan allerlei factoren evalueren, inclusief prestaties, toegankelijkheid, progressieve web-apps en meer.

Als je de uitgebreide beoordeling van Lighthouse voor je site wilt bekijken, kan je de Measure-tool van Google gebruiken:

Naast het uitvoeren van een prestatietest zoals die van Google PageSpeed Insights, krijg je ook scores voor toegankelijkheid, best practices en Search Engine Optimalisation (SEO).

De waarheid over het scoren van 100/100 in Google PageSpeed Insights

Zoals we aan het begin van dit bericht hebben vermeld, zien we dat veel website-eigenaren en ontwikkelaars geobsedeerd raken door het behalen van een perfecte PageSpeed Insights-score. Helaas heeft deze groep mensen de neiging om het belangrijkste onderdeel van de testresultaten over het hoofd te zien: de aanbevelingen.

Hoewel je zeker moet proberen om de laadtijden van je website zoveel mogelijk te verbeteren, is het behalen van 100/100 in Google PageSpeed Insights niet zo belangrijk. Om mee te beginnen is het niet eens de enige test voor prestaties.

In tegenstelling tot PageSpeed Insights kan je met Pingdom Tools je site vanaf meerdere locaties testen:

Ook kan je testen uitvoeren op platforms zoals GTmetrix (die scores van PageSpeed Insights en YSlow combineert) en WebPageTest. De kans is groot dat de scores op de verschillende platforms niet exact overeenkomen, wat een indicatie is hoe wispelturig en subjectief deze cijfers in de praktijk zijn.

Wat echt belangrijk is, is de daadwerkelijke snelheid van je site. Om het in perspectief te plaatsen: we hebben sites gezien met gemiddelde laadtijden van minder dan 500 milliseconden (wat extreem snel is!) die geen 100/100 score hadden op PageSpeed Insights.

Iets anders dat wellicht je perceptie van snelheidsoptimalisatie kan veranderen is de “perceived performance” van je site, oftewel hoe de snelheid wordt ervaren door je bezoekers. Als we het even bot zeggen: het boeit je bezoekers totaal niet wat jouw Google PageSpeed Insights-score is. Ze willen gewoon je content zo snel mogelijk bekijken.

Het échte doel van het testen van de prestaties van je website met Google PageSpeed Insights is dus niet om een hoge score te halen. Wat dan wel? Het is in de eerste plaats bedoeld om probleemplekken op je site te vinden, zodat je deze kan optimaliseren en zowel de daadwerkelijke laadtijd te verminderen als wel de laadtijd die door je bezoekers wordt ervaren.

Hoe Google naar PageSpeed Insights kijkt

Naast dat ze van invloed zijn op de gebruikerservaring (UX), spelen prestaties ook een rol in SEO. Aangezien PageSpeed Insights wordt gerund door de grootste en meest populaire zoekmachine ter wereld, is het logisch dat je score een effect kan hebben op de zoekmachinerankings van je site (in elk geval van die van Google zelf).

In de realiteit is dit ook het geval: Google gebruikt de PageSpeed Insights om hun rankings te bepalen – soort van. Kort door de bocht is sitesnelheid inderdaad een rankingfactor. En de prestatiescore geeft je een redelijk goed idee waar je op dat front staat.

Google kijkt echter naar veel meer dan alleen dat omcirkelde cijfer bovenaan je PageSpeed-resultaten. Het bereiken van een score van 100/100 garandeert niet dat je op de eerste plek komt in de zoekmachinerankings.

Dat betekent natuurlijk niet dat je de resultaten van PageSpeed Insights links kan laten liggen bij het verbeteren van je SEO. Sinds 2018 is de snelheid van mobiele pagina’s bijvoorbeeld een belangrijke factor voor Google. Je zal zien dat de prestatietest voor zowel desktop als mobiel een aparte sectie en bijbehorende score heeft:

Aangezien meer dan 73% van de mobiele gebruikers aangeeft dat ze wel eens een site hebben afgesloten omdat het laden ervan te lang duurde, is de informatie die Google PageSpeed Insights in het tabblad Mobile geeft, van onschatbare waarde. Als je de aanbevelingen opvolgt om de laadtijden op smartphones en andere apparaten te verkorten, dan zou dit je een voorsprong op de concurrentie moeten geven.

Aanbevelingen voor Google PageSpeed Insights (24 manieren om prestaties te verbeteren)

Tot dusver hebben we het vooral gehad over de aanbevelingen die Google PageSpeed Insights maakt. Deze zijn veel waardevoller dan de score en zouden de reden moeten zijn dat je de test überhaupt uitvoert. Om die reden wijden we de rest van dit artikel aan deze aanbevelingen.

Voordat we de aanbevelingen stuk-voor-stuk bespreken, moet je echter wel het verschil begrijpen tussen Field Data en Lab Data. De eerste vergelijkt je site met andere sites op basis van het Chrome User Experience Report van de afgelopen 30 dagen.

Ook zijn er twee grafieken die je gemiddelde First Contentful Paint (FCP) en First Input Delay (FID) laten zien:

In bovenstaande afbeelding is de FCP van onze site ongeveer hetzelfde als 45% van de sites in het 75e percentiel. Onze FID is ongeveer hetzelfde als 9% van het 95e percentiel.

Lab Data toont specifieke gegevens voor een gesimuleerde page-load:

Je zal merken dat onze Field Data en Lab Data niet exact overeenkomen. Dat is volkomen normaal. De Lab Data wordt vergaard onder vooraf opgezette omstandigheden, terwijl de Field Data gebruikt maakt van de daadwerkelijke laadsnelheden – die in de loop van de tijd zijn verzameld.

De combinatie van Field Data en de Lab Data geven je een goede indicatie van de werkelijke laadtijden van je site. Zoals we eerder al aangaven, is deze score belangrijker dan je algemene PageSpeed-score, dus let goed op deze cijfers.

Nu we al deze informatie hebben behandeld, is het tijd om de prestaties van je site te verbeteren met de aanbevelingen van Google PageSpeed.

1. Verwijder bronnen die de weergave blokkeren

Een van de meest voorkomende aanbevelingen van Google PageSpeed Insights is Verwijder bronnen die de weergave blokkeren:

Deze aanbeveling verwijst naar JavaScript- en CSS-scripts die voorkomen dat je pagina snel wordt geladen. De browser van de bezoeker moet deze namelijk downloaden en verwerken voordat deze de rest van de pagina kan tonen. Als je “above the fold” dus veel van dit soort bronnen hebt, dan heeft dit een negatieve invloed op de sitesnelheid.

Meer informatie over dit probleem vind je in onze handleiding over het verwijderen van bronnen die de weergave blokkeren. Wat Google betreft, zijn er twee oplossingen die je kan overwegen:

• Als je niet veel JavaScript of CSS hebt, kan je ze inline plaatsen om van deze waarschuwing af te komen. Hiermee bedoelen we dat je deze JavaScript en/of CSS opneemt in je HTML-bestand. Een plugin als Autoptimize kan dit voor je regelen. Dit is echter alleen een goede oplossing voor hele kleine sites. De meeste WordPress-sites hebben zoveel JavaScript dat deze methode je site zelfs kan vertragen.
• De andere optie is om JavaScript uit te stellen. Dit attribuut zorgt ervoor dat je JavaScript wordt gedownload tijdens het parsen van HTML, maar het pas uitvoert als de parsing is voltooid. Ook worden scripts met dit attribuut geladen in volgorde van weergave op de pagina.

Onder deze PageSpeed-aanbeveling vind je de lijst met bronnen die het meest door dit probleem worden getroffen.

Bekijk deze video voor meer informatie over het elimineren van render-blocking resources:

2. Minimaliseer de diepte van kritieke verzoeken

Het concept van kritieke verzoekketens heeft te maken met het Critical Rendering Path (CRP) en hoe browsers je pagina’s laden. Bepaalde elementen – zoals JavaScript en CSS die we hierboven bespraken – moeten volledig worden geladen voordat je pagina zichtbaar wordt.

Als onderdeel van deze suggestie toont Google PageSpeed Insights je de verzoekketens van de pagina die je analyseert:

Dit diagram toont je de reeks van afhankelijke verzoeken waaraan moet worden voldaan voordat je pagina zichtbaar wordt. Ook geeft het de grootte aan van elke bron. Idealiter wil je het aantal verzoeken dat van elkaar afhankelijk is, evenals hun grootte, minimaliseren.

Er zijn verschillende manieren om dit voor elkaar te krijgen. Deze behandelen we op andere plekken in dit artikel, waaronder:

• Verwijder bronnen die de weergave blokkeren
• Laad afbeeldingen die niet in beeld zijn nog niet
• Verklein de css en JavaScript

Daarnaast kan je – om de CRP te verkorten – ook de volgorde wijzigingen waarin de assets worden geladen. Dit betekent dat je “above the fold” content naar de bovenkant van je HTML-bestand verplaatst. Je vindt meer informatie over het optimaliseren van CRP in ons artikel “How to Optimize the Critical Rendering Path in WordPress.”

Het is belangrijk om te weten dat er niet een magisch aantal kritieke verzoeken is waar je naartoe wil werken. In tegenstelling tot veel van de andere aanbevelingen telt Google Pagespeed Insights dit onderdeel niet als ‘geslaagd’ of ‘gezakt’. Deze informatie wordt simpelweg weergegeven om je te helpen de laadtijden te verbeteren.

3. Houd het aantal verzoeken laag en de overdrachtsgrootte klein

Hoe meer verzoeken een browser moet doen om je pagina’s te laden en hoe groter de bronnen zijn die je server retourneert, hoe langer het duurt om je website te laden. Daarom is het logisch dat Google je aanbeveelt om het aantal vereiste verzoeken te minimaliseren en de omvang van je bronnen te verminderen.

Net als de aanbeveling Minimaliseer de diepte van kritieke verzoeken is dit geen kwestie van ‘geslaagd’ of ‘gezakt’. Ook hier krijg je simpelweg een lijst te zien met het aantal verzoeken en hun groottes:

Er is geen perfect aantal verzoeken of maximale groottes waar je rekening mee kan houden. In plaats daarvan beveelt Google aan dat je die normen voor jezelf opstelt door een “performancebudget” te maken. Dit is een set gedefinieerde doelen die gerelateerd kunnen zijn aspecten als:

• Maximum afbeeldingsgroottes
• Het aantal gebruikte weblettertypen
• Hoeveel externe bronnen je opvraagt
• De grootte van scripts en frameworks

Het creëren van een prestatiebudget geeft je een reeks aan standaarden waar je jezelf aan kan houden. Als je je budget overschrijdt, kan je besluiten of je bronnen wil verwijderen of wil optimaliseren om binnen je vooraf vastgestelde richtlijnen te blijven. In de gids van Google kan je leren hoe je er een maakt.

4. Verklein de CSS

Css-bestanden zijn vaak groter dan ze moeten zijn, omdat ze dan makkelijker voor mensen te lezen zijn. Ze bevatten veel regelterugloop en spaties. Voor ontwikkelaars is dit erg handig, maar voor computers is het niet nodig.

Het minimaliseren van je css is het proces van het condenseren van je bestanden door onnodige tekens, spaties en duplicaten te verwijderen. Google beveelt deze praktijk aan omdat het je css-bestandsgroottes vermindert. Hierdoor kunnen laadsnelheden verbeteren:

Deze snelheidsvoordelen zijn de reden waarom Kinsta een codeminificatiefeature in het MyKinsta dashboard heeft ingebouwd. Klanten kunnen kiezen voor automatische codeminificatie voor hun CSS- en JavaScript bestanden, waardoor hun sites zonder handmatige inspanning worden versneld.

Als je geen Kinsta klant bent, raden we je aan een plugin zoals Autoptimize of WP Rocket te gebruiken om je CSS bestanden te verkleinen.

5. Verklein JavaScript

Net zoals je css-bestanden kan verkleinen, kan je hetzelfde met JavaScript-bestanden doen:

Ook hier kunnen Autoptimize of WP Rocket een rol van betekenis spelen.

6. Ongebruikte CSS Verwijderen

Elke code in je stylesheet is inhoud die moet worden geladen om je pagina zichtbaar te maken voor gebruikers. Niet elk stukje css op je site is daadwerkelijk nuttig, waardoor ze de prestaties van je site onnodig belasten.

Daarom beveelt Google aan om ongebruikte css te verwijderen:

De oplossing is hier in wezen dezelfde als die van het verwijderen van bronnen die de weergave blokkeren. Afhankelijk van wat het meest zinvol is voor je pagina’s, kan je stijlen inline leveren of uitstellen. Je kan een tool als Chrome DevTools gebruiken om ongebruikte css te vinden die moet worden geoptimaliseerd.

7. Primaire threadbewerkingen minimaliseren

De ‘primaire thread’ is een specifiek onderdeel van de browser van een gebruiker. Deze wordt gebruikt om de code van een webpagina om te zetten in de eigenlijke webpagina waar de bezoeker mee kan interacteren. Dit doet hij door HTML, CSS en JavaScript te parseren en uit te voeren. Daarnaast is dit onderdeel verantwoordelijk voor de afhandeling van gebruikersinteracties.

Dit heeft een belangrijke consequentie. Wanneer de primaire thread met de code van je site bezig is, kan deze niet tegelijkertijd de verzoeken van de gebruiker verwerken. Wanneer je site de primaire thread dus veel te doen geeft, dan kan dit resulteren in een slechte gebruikerservaring en trage laadtijden van pagina’s.

Google PageSpeed markeert pagina’s waarvan het de primaire thread langer dan vier seconden kost om een bruikbare webpagina te presenteren:

Een aantal methoden waarmee je het werk voor de primaire thread kan verminderen, hebben we ook al in andere secties behandeld. Denk hierbij aan:

• Je code verkleinen
• Ongebruikte code verwijderen
• Caching implementeren

Ook kan je code-splitting overwegen. Hiermee splits je je JavaScript op in hapklare bundels. Deze worden uitgevoerd wanneer ze nodig zijn, in plaats van dat browsers ze eerst allemaal moeten laden voordat de pagina interactief wordt.

Webpack is een populaire oplossing om code te splitten. Let op dat dit een vrij gecompliceerde ingreep is en dat we beginners afraden om hier zonder assistentie mee aan de slag te gaan.

8. Verkort de JavaScript-uitvoeringstijd

De uitvoering van JavaScript levert vaak de meest prominente bijdrage aan main-thread-werk. PageSpeed Insights heeft daarom een aparte aanbeveling in het leven geroepen om je te waarschuwen als deze taak een aanzienlijke invloed heeft op de prestaties van je site:

De methodes die we hierboven bespraken (om de primaire thread te ontlasten) zouden ook de waarschuwing in deze sectie moeten oplossen.

9. Beperk serverreactietijden (TTFB)

Time to First Byte (TTFB) is een maat voor hoe lang het duurt voordat de browser de eerste byte aan gegevens ontvangt van de server van je site na het indienen van het verzoek. Dit is niet hetzelfde als de snelheid van je site, maar het is logisch dat een lage TTFB de prestaties van je site ten goede komt.

Om die reden is het verlagen van de serverreactietijden een van de aanbevelingen van Google PageSpeed Insights. Bij een lage TTFB zie je dit bericht onder Geslaagde controles:

Er zijn een aantal factoren die van invloed zijn op je TTFB. Een aantal strategieën om deze te verlagen zijn:

• Kiezen voor een hoogwaardige webhostingprovider die zich richt op snelheid
• Lichtgewicht thema’s en plugins gebruiken
• Het aantal op je site geïnstalleerde plugins verminderen
• Een Content Delivery Network (CDN) gebruiken
• Browsercaching implementeren
• Een solide Domain Name Server (DNS) kiezen

Ons artikel over TTFB is een uitstekende bron voor meer informatie over optimalisatie van dit onderdeel.

10. Geef afbeeldingen het juiste formaat

Media files such as images can be a real drag on your site’s performance. Properly sizing them is a simple way to reduce your loading times:

Als je pagina’s afbeeldingen bevatten die groter zijn dan nodig, wordt css gebruikt om ze in de juiste grootte te laten zien. Dit duurt uiteraard langer dan wanneer de afbeelding al de juiste grootte heeft. Dit beïnvloedt de prestaties van de pagina.

Om dit probleem op te lossen, dien je de afbeeldingen in de juiste formaten te uploaden of ‘responsieve afbeeldingen’ te gebruiken. Hierbij maak je voor de meest voorkomende schermgroottes aparte afbeeldingen aan.

Dit kan je doen met behulp van het srcset-attribuut die je toevoegt aan de <img>-tags om de verschillende bestanden te koppelen aan verschillende (scherm)formaten. Browsers lezen deze lijst, bepalen welke optie het beste is voor het huidige scherm en leveren de juiste versie van de afbeelding.

Stel dat je bijvoorbeeld een headerafbeelding hebt en deze responsief wil maken. Je kan drie versies uploaden met breedtes van 800, 480 en 320 pixels. Vervolgens zet je het srcset-attribuut als volgt op:

<img srcset="header-image-800w.jpg 880w,
		Header-image-480w.jpg 480w,
		Header-image-320w.jpg 320w"
	sizes="(max-width: 320px) 280px,
		(max-width: 480px) 440px,
		800px"
	src="header-image-800w.jpg">

Het srcset-attribuut geeft de verschillende beschikbare bestanden aan en het sizes-attribuut vertelt browsers welke ze moeten gebruiken op basis van de huidige schermgrootte.

11. Laad afbeeldingen die niet in beeld zijn nog niet

Het uitstellen van off-screen afbeeldingen staat beter bekend als ‘lazy loading’. In plaats van dat de browser elke afbeelding laadt bij het openen van een pagina, worden nu alleen de afbeeldingen geladen die direct zichtbaar zijn. De overige afbeeldingen worden “on-demand” geladen, dus tijdens het scrollen.

Hoe minder er geladen moet worden voordat de pagina zichtbaar is, hoe beter de prestaties. Daarom beveelt Google deze methode aan:

Er zijn verschillende WordPress-plugins die helpen met lazy-loading, waaronder a3 Lazy Load en Lazy Load by WP Rocket. Ook beschikken een aantal algemene performance-plugins, zoals Autoptimize, over lazy-loadfunctionaliteiten. Bekijk onze complete gids over dit onderwerp: “Dit is hoe je in WordPress Lazyload instelt voor afbeeldingen en video’s”.

12. Codeer afbeeldingen op een efficiënte manier

Zoals we eerder in dit artikel al vermeldden, hebben afbeeldingen een wezenlijke impact op de prestaties van je site. Een van de meest in het oog springende best practices is compressie. Hiermee verklein je de grootte van je bestanden, zodat ze sneller laden. Het is ook de belangrijkste methode als je de aanbeveling Google wil opvolgen om afbeeldingen efficiënt te coderen:

De sleutel hierbij is het bereiken van de kleinst mogelijke bestandsgroottes, zonder dat de kwaliteit van de afbeeldingen hierbij inboet. Plugins als Imagify en Smush kunnen hierbij helpen. In onze gids over afbeeldingsoptimalisatie kan je hier meer over leren.

Andere aanbevelingen die beïnvloeden of je ‘slaagt’ of ‘zakt’ voor Codeer afbeeldingen op een efficiënte manier zijn:

• Afbeeldingen op de juiste grootte weergeven
• Lazy-loading implementeren (offscreen-afbeeldingen uitstellen)
• Afbeeldingen converteren naar next-gen bestandsformaten, zoals WebP
• Video-formats gebruiken voor geanimeerde inhoud, zoals GIF’s

Naast het comprimeren van je afbeeldingen, kan je ook de stappen uitvoeren die bij bovenstaande aanbevelingen horen. Deze vind je elders in dit artikel.

13. Lever afbeeldingen in moderne indelingen

Sommige afbeeldingsbestandsindelingen laden sneller dan andere. Helaas voor jou zijn dit niet de gebruikelijke PNG of JPEG. WebP afbeeldingen worden de nieuwe standaard en Google PageSpeed informeert je dan ook graag als je je hier (nog) niet aan houdt:

Deze aanbeveling lijkt erg streng. Je hebt waarschijnlijk al veel afbeeldingen op je WordPress-site en de kans is groot dat ze nog van ‘oudere’ formaten zijn. Gelukkig zijn er plugins die je hierbij kunnen helpen. Kijk bijvoorbeeld eens naar Imagify en Smush. Beiden bieden ze een functie om naar WebP te converteren.

14. Gebruik video-indelingen voor content met animaties

GIF’s kunnen een effectieve vorm zijn van visuele content. Bovendien zijn ze toepasbaar in verschillende situaties. Walkthroughs, tutorials, beoordelingen en zelfs humoristische animaties: allemaal zijn ze in staat om je artikelen te verbeteren en ze aangenamer en waardevoller te maken voor de lezer.

Helaas gaan deze voordelen vaak ten goede van je prestaties. Het laden van GIF’s is bijvoorbeeld veeleisend. Daarom beveelt PageSpeed Insights aan om in plaats daarvan video-content te presenteren:

Helaas is het omzetten van GIF’s naar videoformaten geen eenvoudig proces. Eerst moet je bepalen welke soort video je wil gebruiken:

• MP4: hiermee krijg je iets grotere bestanden, maar is wel compatibel met de meeste grote browsers.
• WebM: het meest geoptimaliseerde videoformaat, maar is wel beperkt in browsercompatibiliteit.

Nadat je hebt besloten welke het meest geschikt is voor je site, moet je de bestandsindelingen converteren. De beste manier om dit te doen is via de command line, de opdrachtregel. Om te beginnen, installeer FFmpeg. Dit is een open-source tool voor het converteren van bestandsindelingen:

Vervolgens open je de command-line-interface en voer je de volgende opdracht uit:

ffmpeg -i input.gif output.mp4

Hiermee converteer je de GIF met de bestandsnaam inpug.gif naar een MP4-bestand met de naam output.mp4. Het wijzigen van het formaat is echter nog maar het begin. Je moet ook nog de omgezette video insluiten in WordPress – op zo’n manier dat deze op een geanimeerde GIF lijkt.

Video-inhoud voor animaties

Als je ooit wel eens een GIF hebt gezien, dan weet je dat ze iets anders zijn dan normale video’s. Vaak spelen ze automatisch af en zitten ze in een loop. Ze zijn altijd zonder geluid. Als je je nieuwe MP4 of WebM-bestand op je WordPress-site insluit, kan je helaas niet gebruikmaken van deze features.

Wat je wel kan doen, is ze recreëren middels een regel zeer eenvoudige code. Upload je video naar je mediabibliotheek en voeg vervolgens het volgende toe aan de pagina of het artikel waar je de GIF wil opnemen:

<video autoplay loop muted playsinline>
<source src="output.mp4" type="video/mp4">
</video>

Hiermee worden de opgegeven kenmerken toegepast op je video, waardoor deze ‘GIF-achtig’ lijkt. Zorg wel dat je de bestandsnaam en -formaat uit het voorbeeld wijzigt, zodat ze overeenkomen met die van jouw bron. Als je meer wil lezen over dit onderwerp, kijk dan eens naar de handleiding van Google over het converteren van GIF’s naar video’s.

15. Zorg ervoor dat tekst zichtbaar blijft tijdens het laden van weblettertypen

Net als afbeeldingen zijn lettertypes meestal ook grote bestanden waarvan het laden lang duurt. In sommige gevallen verbergen browsers je tekst, totdat het door jou gebruikte lettertype volledig is geladen. In dat geval krijg je deze aanbeveling van Google PageSpeed Insights:

Google adviseert om dit probleem op te lossen door de Font Display API-swap-richtlijn toe te passen in je @font-face style. Om dit te doen ga je naar je stylesheet (style.css) en voeg je na het src-kenmerk onder @font-face het volgende toe:

font-display: swap

In onze artikelen “Zo verander je het lettertype in WordPress” en onze handleiding over het lokaal hosten van lettertypes lees je hier meer over.

16. Schakel tekstcompressie in

De aanbeveling Schakel tekstcompressie in van Google PageSpeed Insights gaat over het gebruik van GZIP-compressie:

In sommige gevallen (zoals in bovenstaande afbeelding) wordt tekstcompressie automatisch ingeschakeld op je webserver. Als dit niet het geval is voor jouw site, dan heb je hier een aantal opties om deze aanbeveling op te volgen.

De eerste is het installeren van een plugin die GZIP-compressie voor je regelt. Als je het geld ervoor over hebt, is WP Rocket een goede oplossing.

Ook kan je je tekst handmatig comprimeren. Hierbij moet je aan de slag gaan met je .htaccess-bestand. Dit is riskant, dus zorg ervoor dat je over een (recente) back-up beschikt.

De meeste WordPress-sites draaien op Apache-servers. De code om GZIP-compressie in te schakelen ziet er als volgt uit:

<IfModule mod_deflate.c>
  # Compress HTML, CSS, JavaScript, Text, XML and fonts
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/rss+xml
  AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
  AddOutputFilterByType DEFLATE application/x-font
  AddOutputFilterByType DEFLATE application/x-font-opentype
  AddOutputFilterByType DEFLATE application/x-font-otf
  AddOutputFilterByType DEFLATE application/x-font-truetype
  AddOutputFilterByType DEFLATE application/x-font-ttf
  AddOutputFilterByType DEFLATE application/x-javascript
  AddOutputFilterByType DEFLATE application/xhtml+xml
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE font/opentype
  AddOutputFilterByType DEFLATE font/otf
  AddOutputFilterByType DEFLATE font/ttf
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE image/x-icon
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE text/plain
  AddOutputFilterByType DEFLATE text/xml

  # Remove browser bugs (only needed for really old browsers)
  BrowserMatch ^Mozilla/4 gzip-only-text/html
  BrowserMatch ^Mozilla/4\.0[678] no-gzip
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
  Header append Vary User-Agent
</IfModule>

Voeg het in je .thaccess-bestand na #END. Als je WordPress-site op een Nginx-server wordt gehost, voeg dan de volgende code toe aan het nginx.conf-bestand:

36 gzip on;
37 gzip_disable "MSIE [1-6]\.(?!.*SV1)";
38 gzip_vary on;
39 gzip_types text/plain text/css text/javascript application/javascript application/x-javascript;

Als je de tekstcompressie van je site wil checken, kijk dan eens naar een tool als GiftOfSpeed:

Deze tool laat je weten of GZIP-compressie is ingeschakeld, op welke server je site draait en nog een aantal andere belangrijke zaken.

17. Maak vooraf verbinding met vereiste herkomsten

De kans is groot dat je site ten minste één externe bron bevat – Google Analytics is een bekend voorbeeld. Het kan enige tijd duren voordat browsers een verbinding met deze bronnen tot stand brengen. Dit kan je laadsnelheden vertragen.

Door gebruik te maken van het preconnect-attribuut laat je browsers direct weten dat er externe scripts op je pagina staan – en dat deze moeten worden geladen. Het proces om ze op te roepen kan hiermee eerder worden gestart, waardoor je prestaties verbeteren.

Als Google vermoedt dat je kan profiteren van deze techniek, dan zie je de suggestie Maak vooraf verbinding met vereiste herkomsten:

Er zijn een aantal manieren waarop je deze optimalisatiestrategie kan implementeren. Als je vertrouwd bent met het bewerken van je WordPress-themabestanden, dan kan je een linktag toevoegen aan je header.php-bestand. Een voorbeeld:

<link rel=“preconnect” href=“example.com”>

In dit geval vertelt de tag dat browsers zo snel mogelijk een verbinding met voorbeeld.com moeten maken. Google PageSpeed Insights geeft een lijst weer met alle relevante bronnen waarvoor je linktags met het preconnect-attribuut moet toevoegen.

Een andere optie is om een plugin te gebruiken. Permatters bevat een preconnect-functie (disclaimer: ik ben een van de oprichters van Perfmatters). WP Rocket en Pre* Party Resource Hints bevatten soortgelijke functionaliteiten.

18. Laad belangrijke verzoeken vooraf

Net als bij de aanbeveling Maak vooraf verbinding met vereiste herkomsten, zorgt deze aanbeveling ervoor dat je het aantal verzoeken vermindert, specifiek het aantal verzoeken dat je browser maakt bij de server van je site. Maar in plaats van verbinding maken met externe bronnen, richt de aanbeveling Laad belangrijke verzoeken vooraf zich op het laden van kritieke assets van je eigen server:

Implementatie van deze techniek lijkt erg op die van de vorige aanbeveling. PageSpeed Insights geeft je een aantal bronnen. Zorg dat je de linktags daarvan toevoegt aan je header.php-bestand:

<link rel=“preload” href=“example.com”>

Ook kan je Perfmatters, WP Rocket of Pre* Party Resource Hints gebruiken om dit voor je te doen.

19. Vermijd meerdere pagina-omleidingen

Je gebruikt omleidingen wanneer je wil dat de ene URL naar de andere verwijst. Meestal worden ze gebruikt wanneer je een pagina op je site verplaatst of verwijdert. Hoewel er normaal gesproken niets mis is met het gebruik van omleidingen, veroorzaken ze extra vertraging in de laadtijd.

Als je site te veel omleidingen bevat, dan zie je deze aanbeveling in Google PageSpeed Insights:

Het enige wat je kan doen om deze aanbeveling op te volgen, is om ervoor te zorgen dat je alleen omleidingen gebruikt wanneer dit absoluut noodzakelijk is. Je kan meer lezen over omleidingen en hoe je ze maakt in ons artikel “WordPress Redirect – Best practices voor snellere prestaties“.

20. Lever statische items met een efficiënt cachebeleid

Als je al een tijdje gebruik maakt van Google PageSpeed Insights, dan ken je aanbeveling wellicht nog onder de oude naam Maak gebruik van browsercaching. Vanaf versie 5 is het gelabeld als Lever statische items met een efficiënt cachebeleid:

Deze suggestie bevat meerdere lagen. Laten we ze eens doorlopen. De eerste laag is definiëren wat ‘caching’ precies inhoudt. In het kort is dit het proces waarbij browsers kopieën van je pagina’s opslaan, zodat ze bij toekomstige bezoeken sneller kunnen worden geladen.

De populairste manier om op een WordPress-site caching te implementeren is door het gebruik van plugins. WP Rocket en W3 Total Cache zijn populaire opties. Sommige hostingproviders – waaronder Kinsta – gebruiken servers om de caching te regelen. Zorg dat je checkt of dit voor jouw host ook geldt, voordat je een cachingplugin installeert.

Zodra je caching voor je site hebt ingeschakeld, kan je je bezighouden met het tweede deel van deze aanbeveling. Wat is ‘efficiënt cachebeleid’? Browsers wissen hun caches namelijk regelmatig om te zorgen dat ze met up-to-date kopieën werken.

Idealiter wil je dat deze periode zo hoog mogelijk ligt. Als je site om de twee uur van browsercache wisselt (door deze te wissen), dan heb je vrijwel niets aan caching en kan je het bijna net zo goed niet gebruiken. Je kan de vervalperiode van je cache optimaliseren met behulp van de headers Cache-Control en Expires.

Cache-control headers toevoegen

Gebruik de volgende code om Cache-Control headers toe te voegen in Nginx:

location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
 expires 30d;
 add_header Cache-Control "public, no-transform";
}

Voeg deze toe aan het configuratiebestand van je server. In bovenstaand voorbeeld verlopen de opgegeven bestandstypen na 30 dagen.

Gebruik je een Apache server? Voeg dan dit toe aan je .htaccess bestand:

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"

Voeg deze code toe vóór #BEGIN WordPress of na #END WordPress. In dit voorbeeld is de cache-vervalperiode ingesteld op 84.600 seconden.

Expires headers toevoegen

Cache-Control headers zijn tegenwoordig zo’n beetje de standaard. Er zijn echter enkele tools (waaronder GTMetrix) die nog steeds controleren op Expires-headers.

Je kan expires headers toevoegen aan een Nginx server door het volgende op te nemen in je serverblock:

location ~*  \.(jpg|jpeg|gif|png|svg)$ {
        expires 365d;
    }

    location ~*  \.(pdf|css|html|js|swf)$ {
        expires 2d;
    }

Stel op basis van bestandstypen verschillende vervaltijden in. Je kan op Apache-servers hetzelfde resultaat behalen door de volgende code aan je .htaccess-bestand toe te voegen:

## EXPIRES HEADER CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
</IfModule>
## EXPIRES HEADER CACHING ##

Nogmaals, voeg deze code toe vóór #BEGIN WordPress of na #END WordPress.

Efficiënt cachen van Google Analytics

Ironisch genoeg gebruikt het Google Analytics-script – dat je waarschijnlijk hebt toegevoegd aan de headers van je pagina’s om gebruikersgedrag te volgen – een cache-vervalperiode van slechts twee uur. Dit doen ze waarschijnlijk zodat gebruikers snel toegang hebben tot de wijzigingen, wanneer updates op het platform worden aangebracht

Dit script wordt weergegeven in de lijst met bronnen onder de aanbeveling Lever statische items met een efficiënt cachebeleid. Omdat het eigendom is van een externe partij, kan je de vervalperiode niet wijzigen met de headers Cache-Control of Expires.

Als dit het enige script is dat onder deze aanbeveling staat, kan je gelukkig nog steeds slagen voor deze audit:

Echter, zoals al eerder aangaven is je PageSpeed-score minder belangrijk dan de werkelijke en waargenomen prestaties. Dat gezegd hebbende, om deze bron efficiënt te leveren, kan je ervoor kiezen om Google Analytics lokaal te hosten.

Plugins zoals Complete Analytics Optimization Suite (CAOS) en Perfmatters kunnen je hierbij helpen. Je kan meer lezen hierover in onze complete handleiding voor deze PageSpeed-aanbeveling.

21. De impact van code van derden beperken

We hebben nu verschillende manieren besproken waarop externe scripts een negatieve impact kunnen hebben op je prestaties en kunnen leiden tot onvoldoendes op PageSpeed Insights. In het ideale geval wil minder afhankelijk zijn van deze tools om nadelige effecten te voorkomen.

In sommige gevallen kun je echter niet om het gebruik van extern scripts heen. Google Analytics is hiervan een uitstekend voorbeeld. Anderen zijn:

• Knoppen en feeds voor het delen van sociale media
• YouTube video-insluitingen
• iFrames voor advertenties en andere inhoud
• Bibliotheken voor JavaScript, lettertypen en andere elementen

In gevallen waarin je het gebruik van externe scripts noodzakelijk acht, is het zaak om de impact hiervan op de prestaties van je site te minimaliseren. Ook de PageSpeed-analyse zal je dit vertellen:

Om externe code efficiënter te laden, kan je een van de technieken gebruiken die we al eerder in dit artikel noemden:

• Stel het laden van JavaScript uit
• Gebruik linktags met het attribuut preconnect.
• Host externe scripts lokaal (zoals we hierboven beschreven met Google Analytics)

Met deze methodes kan je de impact van deze scripts op de prestaties van je site minimaliseren.

22. Vermijdt enorme netwerkpayloads

Deze aanbeveling is vooral relevant voor je mobiele bezoekers. Grote payloads zorgen voor meer mobiele data en dus voor hogere kosten voor de mobiele gebruiker. Dit kan je voorkomen door het aantal netwerkverzoeken – die nodig zijn om je pagina te laden – te minimaliseren:

Google raadt een maximale grootte van 1.600KB of minder aan. De meest gebruikte methoden om dit te gebruiken staan her en der verspreid in dit artikel, waaronder:

• Het uitstellen van ‘below the fold’ CSS, JavaScript en afbeeldingen
• Code verkleinen
• Afbeeldingsbestanden comprimeren
• Het WebP-formaat gebruiken voor afbeeldingen
• Caching implementeren

Als je deze stappen opvolgt, dan zou je met vlag en wimpel moeten slagen voor deze test.

23. Markeringen en metingen voor gebruikerstiming

Deze aanbeveling is alleen relevant als je gebruikt maakt van de User Timing API. Deze tool maakt timestamps die je helpen om de prestaties van JavaScript te evalueren. Als je deze API op jouw site hebt ingesteld, zie je onder deze kop in PageSpeed de markeringen en metingen:

Zoals je ziet, is deze aanbeveling van Google ook geen kwestie van ‘slagen’ of ‘zakken’. PageSpeed Insights zorgt alleen dat je deze informatie eenvoudig terug kan vinden, zodat je het kan gebruiken om gebieden te vinden die je kan optimaliseren.

Als je geïnteresseerd bent in het opnemen van de User Timing API op je WordPress-site, lees dan vooral deze handleiding van Mozilla.

24. Vermijd een overmatig grote DOM

In eenvoudige termen is de DOM hoe browsers HTML in objecten omzetten. Het maakt gebruik van een boomstructuur met afzonderlijke knooppunten. Elk van deze knooppunten vertegenwoordigt een object. Hoe groter de DOM van je pagina is, hoe langer het duurt om deze te laden.

Als je pagina bepaalde normen met betrekking tot DOM-grootte overschrijdt, raadt Google aan om het aantal knooppunten en de complexiteit van je css-stijl te verminderen:

Een veelvoorkomende boosdoener die zorgt dat je ‘zakt’ voor deze test is je WordPress-thema. Zware thema’s voegen vaak grote hoeveelheden elementen toe aan de DOM. Ook kunnen ze ingewikkelde styling bevatten die je site vertraagt. Als dit het geval is, moet je mogelijk van thema wisselen.

Samenvatting

Google PageSpeed Insights zou een belangrijk onderdeel van je webmaster-toolbox moeten zijn. Toch is het zonde van je tijd om je blind te staren op die 100/100 score. De kans is groot dat je je tijd beter en efficiënter kan besteden.

In dit artikel hebben we de zin en onzin van de Google PageSpeed Insights-score behandeld. Ook hebben we een aantal korte richtlijnen gedeeld waarmee je de aanbevelingen op jouw WordPress-site kan implementeren en waarmee de prestaties van je verbeteren.

Heb je vragen over Google PageSpeed Insights of het optimaliseren van je site? Stel ons gerust een vraag in de reacties hieronder!