Om du någonsin har kört din WordPress-webbplats genom Google Page Speed Insights eller Pingdom så har du antagligen sett den stora gula Hävstångseffekter för Webbläsarcaching-varningen (Leverage Browser Caching). Och det är förmodligen därför du hamnade på den här sidan. Idag kommer vi att dyka ner i vad denna varning betyder, hur det påverkar dig och vad dina alternativ är vad gäller din WordPress-webbplats.
- Vad är Hävstångseffekter för Webbläsarcaching-varningen?
- Fixa Hävstångseffekter för Webbläsarcaching-varningen i WordPress
Vad är Hävstångseffekter för Webbläsarcaching-varningen?
Hävstångseffekter för webbläsarcaching-varningen, som visas nedan på skärmbilden, hänvisar till webbläsarens cache. När du besöker en webbplats laddar den ner tillgångar, till exempel HTML, CSS, JavaScript och bilder i webbläsarens lokala cache. På så sätt behöver man inte hämta dem på varje sidladdning. Varningen själv returneras när din webbserver, eller en tredje part, inte har rätt HTTP-cacherubriker implementerade. Eller så kan rubrikerna existera, men cachetiden är inställd på för kort tid.
Du kan också se denna varning i det nya ”think with Google”-webbplatshastighetstestet, som drivs av Google PageSpeed Insights. Detta var utformat för att vara mer av ett marknadsföringsverktyg av Google, men det har dragit till sig många kunder nu som enkelt vidarebefordrar dessa fel till sina webbansvariga, vilket innebär att WordPress-utvecklare och designers letar efter sätt att snabbt fixa det för att tilltala deras kunder.
När vi pratar om Google Pagespeed Insights, se till att du tittar på den här detaljerade guiden -> Hur du får 100/100 i Google PageSpeed Insights med WordPress
Fixa Hävstångseffekter för Webbläsarcaching i WordPress
När det gäller att fixa Hävstångseffekter för Webbläsarcaching-varningen är det ett par olika scenarier som vanligtvis möter WordPress-användare. Självklart är det vanligaste att din webbserver inte är korrekt konfigurerad. Det andra är att Google Analytics skript ger oss varningen. Och den tredje är andra tredjepartsskript som returnerar varningen. Se vad dina alternativ är nedan.
1. Hävstångseffekter för Webbläsarcaching Leverage på server
Den första och vanligaste orsaken till att Hävstångseffekter för Webbläsarcaching-varningen aktiveras är att din webbserver inte har rätt rubriker på plats. I skärmdumpen nedan i Google PageSpeed Insights ser du orsaken är att utgång inte är specificerad. När det gäller cachning finns två primära metoder som används, Cache-Control-rubriker och Expires-rubriker. Medan Cache-Control-rubriker slår på cachen på klientsidan och ställer in en resursens maximala ålder, används Expires-rubriken för att ange en specifik tidpunkt som resursen inte längre är giltig.
Så nu ska vi undersöka hur du lägger till dessa rubriker på din webbserver. Obs! Du behöver inte nödvändigtvis lägga till båda rubrikerna, eftersom det är lite överflödigt. Cache-Control är nyare och vanligtvis den rekommenderade metoden, men vissa webbprestandaverktyg som GTmetrix söker fortfarande efter Expires-rubriker. Det här är alla exempel, du kan ändra filtyper, utgångstider etc. baserat på dina behov.
Lägga till Cache-Control-rubriker i Nginx
Du kan lägga till Cache-Control-rubriker i Nginx genom att lägga till följande på din server configs serverplats eller block.
location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
expires 30d;
add_header Cache-Control "public, no-transform";
}Så vad exakt gör koden ovan? I grund och botten berättar servern att filtyperna inte kommer att förändras på minst en månad. Så istället för att behöva ladda ner resursen varje gång, cachas den på din dator. På så vis går det snabbare vid återbesöken.
Lägga till Expires-rubriker in Nginx
Du kan lägga till Expires-rubriker i Nginx genom att lägga till följande i ditt serverblock. I det här exemplet kan du se hur du anger olika utgångstider baserat på filtyper.
location ~* \.(jpg|jpeg|gif|png|svg)$ {
expires 365d;
}
location ~* \.(pdf|css|html|js|swf)$ {
expires 2d;
}Lägga till Cache-Control-rubriker i Apache
Du kan lägga till Cache-Control-rubriker i Apache genom att lägga till följande i din .htaccess-fil. Bitar kod kan läggas upp längst upp eller ner i filen (före # BEGIN WordPress eller efter # END WordPress).
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
Lägga till Expires-rubriker i Apache
Du kan lägga till Expires-rubriker i Apache genom att lägga till följande i din .htaccess-fil.
## 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 ##Om du är en Kinsta-kund behöver du inte oroa dig för att lägga till dessa rubriker. Dessa finns redan på alla våra Nginx-servrar. Och kom ihåg, om du använder en CDN-leverantör som KeyCDN, är dessa rubriker sannolikt redan inställda på dina tillgångar.
Du kan kolla dina rubriker i Chrome DevTools nätverkspanel eller helt enkelt köra din WordPress-webbplats via Google PageSpeed Insights igen för att försäkra att varningen är borta.
2. Hävstångseffekter för Webbläsarcaching Leverage och Google Analytics
kommer faktiskt från Google Analytics. Det här är lite ironiskt eftersom det här är Googles eget skript. Problemet är att de ställer in en låg 2 timmars cache-tid på deras tillgång, vilket ses på skärmdumpen nedan. De gör det med största sannolikhet för att om de av någon anledning skulle modifiera någonting vill de att alla användare ska få ändringarna så fort som möjligt. Det finns dock ett sätt att komma runt detta, och det är genom att hosta Google Analytics-skript på din egen server. Var dock medveten om att detta inte stöds av Google.
Det finns ett bra gratis litet plugin som heter Complete Analytics Optimization Suite, skapad och utvecklad av Daan van den Bergh, som låter dig vara värd för Google Analytics lokalt på din WordPress-webbplats.
Du kan ladda ner Complete Analytics Optimization Suite från WordPress-repository eller genom att söka efter det under ”Lägg till nya” plugin i din WordPress-instrumentpanel. Med detta plugin kan du vara värd för din Google Analytics JavaScript-fil (analytics.js) lokalt och hålla den uppdaterad med wp_cron (). Andra funktioner inkluderar att enkelt anonymisera din besökares IP-adress, ange en anpassad avvisningsfrekvens och placering av skriptet (sidhuvud eller sidfot).
Några ytterligare fördelar med att vara värd för ditt Analytics-skript lokalt är att du minskar dina externa HTTP-förfrågningar till Google från 2 till 1 och du har nu fullständig kontroll över filens cachning. Det betyder att du kan använda cache-rubrikerna som vi visade dig ovan.
Installera bara pluginet, ange ditt Google Analytics Tracking ID och pluginet lägger till den nödvändiga spårningskoden för Google Analytics på din WordPress-webbplats, hämtar och sparar filen analytics.js till din server och håller den uppdaterad med ett schemalagt skript i wp_cron ( ). Vi rekommenderar att du ställer in den för att ladda i sidfoten. Obs! Det här pluginet fungerar inte med andra Google Analytics WordPress-plugin.
3. Vad gäller för tredjepartsskript?
Om du driver ett företag på din WordPress-webbplats, har du förmodligen ytterligare tredjepartsskript som körs för att spåra konverteringar, A / B-tester, etc. Det här kan innehålla skript som Facebook-konverteringspixlar, Twitter, CrazyEgg, Hotjar, etc. Tyvärr, eftersom du inte kan vara värd för dem lokalt finns det så mycket som kan göras eftersom du inte har kontroll över cachingen av dessa tredjepartstillgångar. Men för många mindre webbplatser och bloggare kan du med största sannolikhet bli av med den här Hävstångseffekter för Webbläsarcaching-varningen helt och hållet genom att följa rekommendationerna ovan.
Sammanfattning
Du har definitivt några alternativ tillgängliga när du försöker fixa den irriterande hävstångseffekten för webbläsarcaching-varning på din WordPress-webbplats. För det mesta kan du förmodligen rensa upp det helt. Kom ihåg att dessa verktyg för webbprestanda ska användas som riktlinjer. Vi skulle inte rekommendera att stressa över poängen för mycket. Men att fixa varningarna kommer vanligen att resultera i en snabbare WordPress-webbplats i slutet.
Har du några andra tips om hur du ställer in hävstångseffekten för webbläsarcaching-varning? Om så är fallet, skriv gärna en kommentar nedan.
Brian har stor passion för WordPress och har använt det i över ett årtionde, han har till och med utvecklat ett par premium-plugins. Brian gillar att blogga, kolla filmer och hiking. Ta kontakt med Brian via Twitter.
Lämna ett svar