Google PageSpeed Insights är ett av flera användbara verktyg för att mäta webbplatsens prestanda. Vissa av dess förslag – som varningen ”Leverage Browser Caching” – kan dock vara förvirrande för oerfarna webbplatsägare.
När man bryter ner det i sina beståndsdelar är cachelagring inte så svårt att förstå. Med några justeringar kan du implementera denna bästa praxis på din webbplats för att minska laddningstiderna och förbättra din PageSpeed-poäng.
I det här inlägget startar vi med en introduktion till Leverage Browser Caching-varningen. Efter detta delar vi flera tips om hur du löser problemet på din WordPress-webbplats.
Vi kör igång!
Föredrar du videoversion?
Vad är Leverage Browser Caching-varningen?
För att förstå vad Leverage Browser Caching-varningen är hjälper det att först veta lite om Google PageSpeed Insights. Om du är ny på plattformen rekommenderar vi att du läser vår kompletta guide, Google PageSpeed Insights: Få 100/100 poäng med WordPress.
Leverage Browser Caching-varningen är en diagnostik som Google PageSpeed använder för att förbättra din poäng:
I version 5 av Google PageSpeed Insights har det här meddelandet ersatts med varningen ”Serve static assets with an efficient cache policy”:
Trots förändringen i språk och utseende löser man dessa varningar på samma sätt.
Google föreslår att du använder cachelagring av webbläsaren för att minska sidinläsningstiderna och förbättra prestandan. Cachelagring innebär att användarnas webbläsare sparar statiska kopior av webbplatsens sidor. Vid efterföljande besök kan det här innehållet sedan laddas in snabbare eftersom webbläsaren inte behöver kontakta webbplatsens server för att komma åt de begärda resurserna.
Varje cachelagrad resurs behöver dock en angiven förfalloperiod. Detta talar om för webbläsare när innehållet på din webbplats har blivit inaktuellt, så att det kan ersätta sin cachelagrade kopia med en uppdaterad version.
Om du ser varningen ”Leverage Browser Caching” i resultatet av dina prestandatest betyder det sannolikt en av två saker:
- Sidhuvudena Cache-Control eller Expires saknas på webbplatsens server eller på en tredje part.
- De nödvändiga rubrikerna finns, men förfalloperioden är mycket kort och har därför inte så mycket inverkan på prestandan.
Lösningarna på denna varning är att åtgärda ett eller båda av dessa problem.
Så här fixar du Leverage Browser Caching-varningen i WordPress (3 metoder)
Du kan lösa Leverage Browser Caching-varningen i WordPress på några olika sätt, beroende på vad som orsakar det. Här är tre lösningar som du kan prova.
1. Lägg till Cachekontroll och Expires-sidhuvuden
Det finns två sidhuvuden som är relaterade till webbläsarcache: Cache-Control och Expires. Minst en av dessa måste finnas för att aktivera cachelagring av webbläsare för din webbplats. Det är nämligen med hjälp av dem som en webbläsare bestämmer hur länge de ska behålla resurser innan de uppdateras.
Ett enkelt sätt att avgöra om detta är vad som orsakar Leverage Browser Caching-varningen är att titta på informationen som ges för varje resurs. I Google PageSpeed Insights Version 5 är ”none” listad under Cache TTL:
Som en praktisk referens visade tidigare versioner av Google PageSpeed Insights ett meddelande som löd ”utgångsdatum ej angivet” när sidhuvudena saknades:
Medan Cache-control-sidhuvudet aktiverar cachelagring på klientsidan och anger maxåldern för en resurs, används Expires-sidhuvudet för att ange en tidpunkt när resursen inte längre är giltig.
Du behöver inte nödvändigtvis lägga till båda, eftersom det kan vara överflödigt. Cache-Control är nyare och är vanligtvis den rekommenderade metoden. Vissa verktyg för webbprestanda, såsom GTmetrix, söker fortfarande efter Expires-sidhuvuden.
Om du hostas av Kinsta, behöver du inte krångla med inställningar av dessa rubriker. Alla våra Nginx-servrar inkluderar dem redan. Även de som använder ett Content Delivery Network (CDN) bör ha tillämpning av dessa sidhuvuden.
Om du använder en annan hosting-leverantör, se till att säkerhetskopiera din webbplats innan du följer stegen nedan, eftersom redigering av .htaccess kan få din webbplats att krascha om du inte är försiktig.
Så här lägger du till Cache control-sidhuvuden i Nginx
Om du vill lägga till Cache control-sidhuvuden i Nginx kan du lägga till följande i serverns konfigurationsfil:
location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
expires 30d;
add_header Cache-Control "public, no-transform";
}
Detta talar om för servern att de angivna filtyperna inte kommer att ändras på minst 30 dagar. Det kommer att hålla de relevanta filerna sparade under den tidsperioden innan de uppdateras.
Så här lägger du till Cache control-sidhuvuden i Apache
Om du har en Apache-server kan du lägga till följande kod i HTACCESS-filen:
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
</filesMatch>
Detta utdrag bör läggas till före ”#BEGIN WordPress” eller efter ”#END WordPress”. I det här fallet är cachen inställd på att upphöra att gälla efter 84 600 sekunder.
Så här lägger du till Expires-sidhuvuden i Nginx
Du kan lägga till Expires-sidhuvuden i Nginx genom att lägga till följande i serverblocket. I det här exemplet kan du se hur du anger olika förfallotider baserat på filtyper:
location ~* \.(jpg|jpeg|gif|png|svg)$ {
expires 365d;
}
location ~* \.(pdf|css|html|js|swf)$ {
expires 2d;
}Så här lägger du till Expires-sidhuvuden i Apache
Du kan lägga till Expires-sidhuvuden i Apache genom att lägga till följande i .htaccess-filen:
## 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 ##Du kan sedan kontrollera dina sidhuvuden genom att än en gång köra din webbplats i Google PageSpeed Insights och se om varningen kvarstår.
2. Leverage Browser Caching för Google Analytics
Ironiskt nog, är Google Analytics ibland orsaken till Leverage Browser Caching-varningen och en ofullständig PageSpeed-poäng. Detta beror på att den har en låg cache-förfallotid på endast två timmar. Detta brukade vara den gamla varningen:
I PageSpeed Insights version 5 resulterar det här problemet inte längre i en varning, men Google Analytics kan fortfarande listas som en icke-optimerad resurs:
Du kan inte ändra detta med Cache control- eller Expires-sidhuvuden eftersom resursen inte finns på servern. Det finns dock ett sätt att utnyttja webbläsarcache för Google Analytics genom att hosta skriptet lokalt.
Observera dock att denna metod inte stöds av Google.
Leverage Browser Caching för Google Analytics med Complete Analytics Optimization Suite
Om du vill lösa ovanstående problem finns det ett kostnadsfritt plugin som heter Complete Analytics Optimization Suite (CAOS) som är utvecklat av Daan van den Bergh:
Du kan ladda ner CAOS från WordPress plugin-katalog eller genom att söka efter det under Plugins > Lägga till nytt i din WordPress-instrumentpanel.
En annan fördel med att hosta ditt Analytics-skript lokalt är att det minskar dina externa HTTP-begäranden till Google från två till en och gör att du kan få full kontroll över cachelagringen av filen. Detta innebär att du kan använda cache-sidhuvudena som vi visade dig tidigare.
Kom igång genom att installera pluginet och ange sedan ditt Spårnings-ID för Google Analytics. Pluginet lägger till den nödvändiga spårningskoden för Google Analytics på din WordPress-webbplats, laddar ner och sparar analytics.js-filen på din server och håller den uppdaterad med ett schemalagt skript i wp_cron().
Vi rekommenderar även att du ställer in så att den laddas i sidfoten:
Tänk på att CAOS inte fungerar med andra Google Analytics WordPress-plugins.
Leverage Browser Caching för Google Analytics med WP-Rocket
Du kan alternativt använda WordPress cachelagrings-plugin WP-Rocket för att uppnå samma mål:
Detta plugins tillägg för Google-spårning gör att du kan hosta ditt analysskript lokalt med ett klick på en knapp. Växla bara statusen under WP-Rocket >-tillägg.
WP-Rocket och dess tillägg är kompatibla med andra Google Analytics-plugins. Premiumverktyget har licenser som börjar på $ 49 per år.
3. Minimera din användning av tredjepartsskript
Ibland kan Google Analytics-skriptet orsaka problem för poängen med Google PageSpeed Insights eftersom det finns på Google’s server. Detta innebär att du inte har kontroll över cacheminnet.
Detsamma gäller för andra skript från tredje part. Om du hanterar ett företag via din WordPress-webbplats har du troligtvis ytterligare skript från tredje part för att spåra konverteringar, utföra A/B-tester, och mer.
Detta kan omfatta skript som Facebook Conversion Pixels, Crazy Egg, Hotjar och andra. Om du inte kan hitta ett sätt att hosta dessa skript lokalt, finns det inget som du kan göra för att få kontroll över dem.
Ett alternativ för Facebook Pixel-användare är att använda ännu en tillägg för WP-Rocket. Du bör helst minimera din användning av skript från tredje part om du vill förbättra din Google PageSpeed-poäng. Så det kan vara värt att utföra en granskning av din webbplats och ta bort alla skript som inte är nödvändiga för att köra den.
Sammanfattning
Även om det inte är ett definitivt mått på din webbplats prestanda, är Google PageSpeed-statistik fortfarande en anständig indikator på hur den mår. Att förbättra din poäng genom att lösa varningar som visas under ”Serve static assets with an efficient cache policy” kan hjälpa till att göra din webbplats snabbare och mer användbar för besökarna.
Om du ser den här varningen i Google PageSpeed Insights kan du lösa detta genom att:
- Lägga till Cache control- eller Expires-sidhuvuden.
- Utnyttja webbläsarcache för Google Analytics.
- Minimera din användning av skript från tredje part.
Har du några andra tips om hur du fixar Leverage Browser Caching? Låt oss veta i kommentarssektionen nedan!
Jon is the Chief Operating Officer at Kinsta and is involved with Kinsta's sales, customer service, and technical support teams on a daily basis. Jon's a family man. So when he isn't feverishly tapping the keys of his laptop he's usually helping one of his kids fix a bike or setting up Netflix for an impatient preschooler.
Lämna ett svar