Gepubliceerd: 8 okt. 2025
Een lange cachelevensduur kan herhaalde bezoeken aan uw pagina versnellen.
Wanneer een browser een resource opvraagt, kan de server die de resource levert de browser vertellen hoe lang deze tijdelijk in de cache moet worden opgeslagen. Bij elke volgende aanvraag voor die resource gebruikt de browser de lokale kopie in plaats van deze van het netwerk te halen.
Latentie is voor de webprestaties veel belangrijker dan bandbreedte. Door netwerklatentie voor belangrijke verzoeken te vermijden, kunt u de prestaties voor de gebruiker aanzienlijk verbeteren.
Hoe dit inzicht over te brengen
Alle cachebare subresource-aanvragen moeten een cachelevensduur hebben van minimaal 30 dagen (2592000 seconden). Wij zijn van mening dat alle statische assets de hier beschreven beslissingsboom moeten volgen: cachebare resources moeten een zeer lange levensduur hebben (30 dagen of 1 jaar).
Een verzoek wordt als cachebaar beschouwd als:
- De bron is een lettertype, afbeelding, mediabestand, script of stijlpagina.
- De resource heeft een HTTP-statuscode 200, 203 of 206.
- De resourceresponsheaders sluiten het niet expliciet uit van cache (bijvoorbeeld:
no-cache, must-revalidate, no-store).
Leer hoe u bronnen kunt cachen in de handleiding HTTP-cache: uw eerste verdedigingslinie en de codelab HTTP-cachegedrag configureren .
Gebruik het paneel Netwerk in Chrome DevTools om te controleren of de Cache-Control-headers naar behoren zijn ingesteld. Bovendien geeft de kolom Size in het paneel Netwerk aan of een verzoek daadwerkelijk vanuit de cache is verwerkt.
Stapelspecifieke begeleiding
Dit inzicht biedt ook stackspecifieke richtlijnen voor pagina's die de volgende technologieën gebruiken:
Drupal
Stel de maximale leeftijd van de browser- en proxycache in op de pagina Beheer » Configuratie » Ontwikkeling . Lees meer over Drupal-cache en optimalisatie voor prestaties .
Joomla
Zie Cache .
WordPress
Zie Browser Caching .