Google PageSpeed Insights is één van de handigste tools om de prestaties van websites te meten. Maar een aantal suggesties van de tool, zoals de “Leverage Browser Caching” waarschuwing, kunnen vooral bij beginnende beheerders voor verwarring zorgen.

Maar als je er even de tijd voor neemt om het te begrijpen, dan kom je er al snel achter dat het principe van caching niet eens zo ingewikkeld is. Met een paar kleine wijzigingen aan je kun je deze best practice voor development makkelijk op je website implementeren. Je zal zien dat je laadtijden korter worden en je PageSpeed score hoger wordt.

In dit artikel zullen we beginnen met een introductie over de waarschuwing “Leverage Browser Caching”, oftewel een melding dat je browsercaching moet inzetten op je site. Vervolgens zullen we een aantal tips geven hoe je dit probleem op kunt lossen voor je WordPress site.

Laten we er meteen mee beginnen!

Wat is de waarschuwing “Leverage Browser Caching”?

Om de waarschuwing “Leverage Browser Caching” goed te begrijpen, moet je eerst iets meer weten over Google PageSpeed Insights. Als je het platform voor het eerst gebruikt, raden we je zeker aan om eens onze volledige uitleg door te nemen: Google PageSpeed Insights: de waarheid over de 100/100 score.

De waarschuwing “Leverage Browser Caching” is één van de vele “diagnostics” die Google PageSpeed geeft als suggestie voor het verbeteren van je score en ziet er meestal zo uit:

De waarschuwing
De waarschuwing “Leverage Browser Caching” in Google PageSpeed Insights

In versie 5 van Google PageSpeed Insights, is dit bericht vervangen door de waarschuwing “Serve static assets with an efficient cache policy”:

“Serve static assets with an efficient cache policy” waarschuwing in Google PageSpeed Insights
“Serve static assets with an efficient cache policy” waarschuwing in Google PageSpeed Insights

Alhoewel de precieze melding en verschijning enigszins zijn veranderd, is de oplossing voor beide meldingen hetzelfde.

Google raadt aan om browsercaching te gebruiken om de laadtijden van pagina’s te verminderen en de prestaties te verbeteren. Kort gezegd worden bij caching statische kopieën van je pagina’s opgeslagen in de browsers van gebruikers. Daardoor kan content sneller opnieuw geladen worden bij volgende bezoeken, aangezien de browser niet opnieuw contact hoeft te maken met de server van je website om bepaalde bronnen te laden.

Elke gecachete bron heeft een specifieke vervaltijd nodig. Dit vertelt browsers wanneer content op de website als “verouderd” wordt beschouwd, zodat de gecachete kopie vervangen kan worden door een bijgewerkte versie.

Als je de waarschuwing “Leverage Browser Caching” in de testresultaten van je prestaties ziet, kan dat één van twee dingen betekenen:

  • De headers “Cache-Control” of “Expires” missen op de server van je website of die van een externe partij.
  • De benodigde headers zijn er wel, maar de vervaltijd is erg kort waardoor het weinig helpt bij het versnellen van je website.

Om deze waarschuwing op te lossen moet je dus één of beide problemen oplossen.

Hoe repareer je de waarschuwing “Leverage Browser Caching” in WordPress (3 manieren)

Er zijn verschillende manieren om te beginnen aan een oplossing voor de “Leverage Browser Caching” waarschuwing. Welke methode je kiest, hangt af van de oorzaak. Hier zijn drie oplossingen die je kunt proberen.

1. Voeg “Cache-Control” en “Expires” headers toe

Er zijn twee headers die een effect hebben op browsercaching: Cache-Control en Expires. Tenminste één van deze twee headers moet aanwezig zijn wil browsercaching werken op jouw website, aangezien browsers deze headers gebruiken om te bepalen wanneer ze bronnen moeten verversen.

Een eenvoudige manier om te bepalen wat de “Leverage Browser Caching” waarschuwing veroorzaakt is naar de details van elke bron kijken. In Google PageSpeed Insights versie 5, zul je “None” zien staan onder Cache TTL:

Cache TTL details in Google PageSpeed Insights
Cache TTL details in Google PageSpeed Insights

Ter gemak lieten vorige versies van Google PageSpeed Insights een bericht zien met “expiration not specified” (vervaldatum niet gespecificeerd), wanneer de headers er niet waren:

Lijst van bronnen in de
Lijst van bronnen in de “Leverage Browser Caching” waarschuwing

Waar de Cache-Control header de client-side caching inschakelt en de maximale leeftijd van een bron instelt, wordt de Expires-header gebruikt om een specifiek moment aan te geven wanneer de bron vervalt.

Je hoeft niet per se beide headers toe te voegen, aangezien dat dubbelop kan zijn. Cache-Control is nieuwer en is meestal de aanbevolen manier. Maar sommige prestatietools, zoals GTmetrix controleren nog altijd op Expires headers.

Als je gehost wordt door Kinsta, hoef je je geen zorgen te maken over deze headers. Al onze Nginx servers bevatten ze al. Iedereen die een Content Delivery Network (CDN) gebruikt, zou deze headers ook al actief moeten hebben.

In het geval je een andere hostingprovider gebruikt, zorg dan dat je eerst een back-up maakt van je website voordat je de stappen hieronder volgt, aangezien het aanpassen van .htaccess je website stuk kan maken als je niet oppast.

Zo voeg je Cache-Control headers toe in Nginx

Om Cache-Control headers toe te voegen in Nginx kun je de volgende regels toevoegen aan het configuratiebestand van je server:

Zo voeg je Cache-Control headers toe in Nginx

Om Cache-Control headers toe te voegen in Nginx kun je de volgende regels toevoegen aan het configuratiebestand van je server:

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

Dit vertelt de server dat de genoemde bestandstypen in elk geval de komende 30 dagen niet zullen veranderen. Hiermee zorg je ervoor dat de desbetreffende bestanden voor dat specifieke interval worden opgeslagen. Achteraf worden ze ververst.

Zo voeg je Cache-Control headers toe in Apache

Als je een Apache server gebruikt, kun je de volgende code toevoegen aan je .htaccess bestand:

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

Dit stukje moet je toevoegen vóór “#BEGIN WordPress” of na “#END WordPress”. In dit geval zal de cache vervallen na 84.600 seconden, oftewel bijna 24 uur.

Zo voeg je Expires headers toe in Nginx

Je kunt Expires headers toevoegen binnen Nginx door de volgende code toe te voegen aan je serverblock. In dit voorbeeld zie je hoe je verschillende vervaltijden kunt aangeven per bestandstype:

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

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

Zo voeg je Expires headers toe in Apache

Je kunt Expires headers toevoegen binnen Apache door de volgende code toe te voegen aan je .htaccess bestand:

## EXPIRES HEADER CACHING ##

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"

## EXPIRES HEADER CACHING ##

Je kunt vervolgens je headers controleren door je website weer door Google PageSpeed Insights te halen en kijken of de waarschuwing inderdaad verdwenen is.

2. “Leverage Browser Caching” door Google Analythttps://kinsta.com/nl/wp-admin/edit.php?post_type=newsics

Ironisch genoeg wordt de “Leverage Browser Caching” waarschuwing soms door Google Analytics veroorzaakt. Dat komt doordat het een vrij lage vervaltijd heeft van slechts twee uur. Dit was altijd de oude waarschuwing:

Leverage Browser Caching waarschuwing bij Google Analytics script
Leverage Browser Caching waarschuwing bij Google Analytics script

In PageSpeed Insights versie 5, zal dit probleem niet langer resulteren in een waarschuwing, maar wordt Google Analytics nog wel genoemd als een niet-optimale bron:

Google PageSpeed Insights audits met Google Analytics
Google PageSpeed Insights audits met Google Analytics

Dit kun je helaas niet veranderen via een Cache-Control of Expires header doordat de bron zich niet op jouw server bevindt. Toch is er een manier om browsercaching te kunnen gebruiken voor Google Analytics, door het script lokaal te hosten.

Let hierbij wel op, dat deze methode niet ondersteund wordt door Google.

Browsercaching voor Google Analytics inschakelen met Complete Analytics Optimization Suite

Als je het probleem hierboven wilt oplossen, is er een gratis plugin die Complete Analytics Optimization Suite (CAOS) heet, ontwikkeld door Daan van den Bergh:

CAOS WordPress-plugin
CAOS WordPress-plugin

Je kunt CAOS downloaden uit de WordPress pluginbibliotheek of door er op te zoeken onder Plugins > Nieuwe toevoegen in je WordPress dashboard.

Een bijkomend voordeel van het lokaal hosten van je Analytics scripts is dat je minder externe HTTP verzoeken naar Google stuurt. Bovendien geeft het je volledige controle over de caching van het bestand. Dit betekent dat je toch nog de cacheheaders kunt gebruiken die we hierboven noemden.

Om te beginnen: installeer de plugin, en vul je Google Analytics Tracking ID in. De plugin voegt de benodigde tracking code voor Google Analytics toe aan je WordPress website, downloadt en bewaart het analytics.js-bestand op je server, en zorgt dat het bijgewerkt blijft door een script in wp_cron().

We raden je aan om het in de footer te laten laden:

Instellingen voor de plek van de CAOS tracking code
Instellingen voor de plek van de CAOS tracking code

Onthoud dat CAOS niet communiceert met andere Google Analytics WordPress plugins.

Browsercaching voor Google Analytics inschakelen met WP-Rocket

In plaats hiervan kun je ook de WordPress cachingplugin WP-Rocket gebruiken om hetzelfde resultaat te bereiken:

WP-Rocket WordPress plugin
WP-Rocket WordPress plugin

De Google Tracking Add-on van deze plugin maakt het mogelijk om je Analytics script lokaal te hosten, met slechts één klik op de knop. Je kunt de status aanklikken onder WP-Rocket > Add-ons.

WP-Rocket en de add-on zijn wel compatibel met andere Google Analytics plugins. Als premium tool beginnen de licenties vanaf $49 per jaar..

3. Maak zo weinig mogelijk gebruik van externe scripts

Soms wordt je Google PageSpeed Insights score dus lager door het Google Analytics, omdat het op de server van Google wordt gehost en je de caching dus niet kunt beheren.

Hetzelfde geldt voor scripts van externe partijen. Als je een bedrijf runt via je WordPress website, heb je waarschijnlijk externe scripts op je website om conversie te tracken, A/B tests uit te voeren, en nog veel meer.

Dit kunnen script zijn zoals de Facebook conversiepixels, Crazy Egg, Hotjar, enzovoort. Tenzij je een manier kunt vinden om dergelijke scripts lokaal te hosten, kun je helaas weinig doen wat beheer betreft.

Een optie voor gebruikers van de Facebook Pixel is om nog een andere WP-Rocket add-on te gaan gebruiken. Maar in algemene zin wil je vooral zo weinig mogelijk scripts van derden gebruiken, als je wilt dat je Google PageSpeed score hoger wordt. Het kan dus zeker de moeite waard zijn om je website eens te auditen en scripts te verwijderen die eigenlijk niet nodig zijn.

Samenvatting

Alhoewel het zeker geen onomstreden maatstaf is van de prestaties van je website, is Google PageSpeed Insights nog altijd een goede indicator voor hoe soepel je website draait. Je kunt je score verbeteren door waarschuwingen onder “Serve static assets with an efficient cache policy” op te lossen, waardoor je website sneller en gebruiksvriendelijker wordt.

Als je deze waarschuwing ziet in Google PageSpeed Insights, kun je het oplossen door:

  1. Het toevoegen van de “Cache-Control” of “Expires” headers.
  2. Browsercaching voor Google Analytics te gaan gebruiken.
  3. Zo weinig mogelijk gebruik te maken van externe scripts.

Nog andere tips hoe je browsercaching kunt verbeteren? Laat het ons weten in de reacties hieronder!

Jon Penland

Jon is de Chief Operating Officer bij Kinsta en is dagelijks betrokken bij de sales-, klantenservice- en technische ondersteuningsteams van Kinsta. Jon is een familieman. Dus als hij niet koortsachtig op de toetsen van zijn laptop aan het tikken is, is hij meestal een van zijn kinderen aan het helpen met het repareren van een fiets of het opzetten van Netflix voor een ongeduldige kleuter.