Google PageSpeed Insights: Sanningen om att få 100/100 i betyg

Google PageSpeed Insights är utan tvekan ett användbart verktyg för webbansvariga, utvecklare och webbplatsägare av alla slag. Men vi har märkt att många människor spenderar timmar över att som besatta optimera sina webbplatser, för att försöka få 100/100 på detta test.

Sanningen är att det inte är så Google PageSpeed Insights är tänkt att användas, inte heller är det värt att försöka uppnå. När du fokuserar på att implementera plattformens rekommendationer istället för att titta på siffran högst upp på sidan, kommer du att skapa många fler fördelar för din webbplats.

Detta inlägg är en omfattande guide till att använda Google PageSpeed Insights till din fördel. Vi går igenom hur Google använder din poäng, samt hur du hanterar de rekommendationer du får.

Då sätter vi igång!

En introduktion till Google PageSpeed Insights

Om du ännu inte är bekant med Google PageSpeed Insights, är det ett verktyg som används för att testa webbplatsens prestanda. Du kan ange vilken webbadress som helst och analysera den:

Google ger sedan en total poäng av 100 för den webbplats du har testat, baserat på flera bästa praxis för prestandaoptimering:

Tillsammans med detta resultat ser du också flera rekommendationer från Google om hur du kan förbättra dina resultat (och därför din PageSpeed Insights-poäng också):

Sedan 2018 beräknas PageSpeed Insights poäng via Lighthouse, Googles öppna källkod, automatiserade verktyg för att förbättra den övergripande kvaliteten på webbsidor. Denna plattform kan utvärdera alla möjliga faktorer, inklusive prestanda, tillgänglighet, progressiva webbappar och mer.

För att se Lighthouses omfattande bedömning av din webbplats, kan du använda Googles Measure:

Google Webmasters Measure revisionsverktygFörutom att utföra en prestandarevision ungefär som Google PageSpeed Insights gör får du poäng för tillgänglighet, bästa praxis och Sökmotoroptimering (SEO).

Sanningen om att få 100/100 i poäng på Google PageSpeed Insights

Som vi nämnde i början av det här inlägget ser vi många webbplatsägare och utvecklare som blir besatta över att uppnå en perfekt PageSpeed Insights-poäng. Tyvärr tenderar dessa personer att förbise den viktigare aspekten av testets resultat: rekommendationerna.

Även om du verkligen bör sträva efter att förbättra din webbplats laddningstid så mycket som möjligt, är det faktisk inte så viktigt att få 100/100 i Google PageSpeed Insights. Till att börja med är det inte ens det viktigaste testet för prestanda.

Till skillnad från PageSpeed Insights, låter Pingdom Tools dig testa din webbplatsprestanda från olika platser:

Du kan också köra tester på plattformar som GTmetrix (som kombinerar dina poäng från PageSpeed Insights och YSlow) och WebPageTest. Chansen är stor att dina poäng över dessa olika verktyg inte kommer att stämma överens exakt, vilket visar hur godtyckliga dessa siffror kan vara.

Det som verkligen betyder något är den faktiska hastigheten på din webbplats. För att sätta det i perspektiv har vi sett platser med genomsnittliga laddningstider på under 500 millisekunder (vilket är extremt snabbt!) som inte har 100/100 poäng på PageSpeed Insights.

Den andra faktorn som bör påverka din inställning till hastighetsoptimering är upplevd prestanda på din webbplats. Dina besökare bryr sig inte om vad din Google PageSpeed Insights-poäng är. De vill bara kunna se ditt innehåll så snabbt som möjligt.

Det verkliga syftet med att testa webbplatsens prestanda med Google PageSpeed Insights är inte att uppnå en hög poäng. Istället är det att hitta problemområden på din webbplats, så att du kan optimera dem och minska både dina faktiska och upplevda laddningstider.

Så används PageSpeed Insights av Google

Förutom att påverka din webbplats användarupplevelse (UX), spelar prestanda också en roll för SEO. Med tanke på att PageSpeed Insights drivs av världens största och mest populära sökmotor är det rimligt att din poäng kan ha viss effekt på din rankning på sökmotorns resultatsida (SERP) (åtminstone på Google).

Verkligheten är att Google använder PageSpeed Insights för att bestämma rankning – ungefär. Sidhastighet är en rankningsfaktor, helt enkelt. Ditt prestandatestresultat kan ge dig en ganska bra uppfattning om var du står på den fronten.

Google tar dock hänsyn till mer än bara siffran i cirkeln högst upp på dina PageSpeed-resultat. Att nå 100/100 garanterar dig inte en topposition på SERP.

Med det sagt, kan du fortfarande använda dina PageSpeed Insights praktiskt när du förbättrar din SEO. Till exempel, sedan 2018 har mobil sidhastighet varit en rankningsfaktor för Google. Du kommer att märka att prestandatestet ger data för både stationära och mobila versioner av din webbplats:

Eftersom mer än 73 procent av mobila internetanvändare hävdar att de har besökt webbplatser som tar för lång tid att ladda är informationen i Google PageSpeed Insights Mobil-flik ovärderlig. Använd rekommendationerna här för att minska laddningstider på smartphones och andra enheter för en god konkurrensfördel.

Google PageSpeed Insights rekommendationer (24 sätt att förbättra prestanda)

Vi har pratat mycket om Google PageSpeed Insights rekommendationer i det här inlägget. De är det verkliga resultat av dina prestandatester och mycket mer värdefullt än din faktiska poäng. Det är därför vi har dedikerat resten av det här inlägget till dem.

Innan vi dyker in i de enskilda förslagen måste du dock förstå skillnaden mellan dina Fältdata och Labbdata. Den förra jämför din webbplats med andra i rapporten om användarupplevelsen i Chrome under de senaste 30 dagarna.

Det finns också två diagram som visar var dina genomsnittliga First Contentful Paint (FCP) och First Input Delay (FID) faller:

I bilden ovan är vår webbplats FCP ungefär densamma som 45 procent av webbplatserna i den 75:e percentilen, och vår FID är ungefär densamma som 9 procent av den 95:e percentilen.

Labbdata visar specifika data för en simulerad sidladdning:

Du kommer att märka att våra Fältdata och Labbdata inte matchar exakt. Det är helt normalt. Labbdata skapas under fasta förhållanden, medan Fältdata använder faktiska laddningshastigheter som samlats in över tid.

När du tittar på det i kombination bör Fältdata och Labbdata ge dig en uppfattning om din webbplats faktiska laddningstider. Som vi nämnde tidigare är detta ännu viktigare än din totala PageSpeed-poäng, så du behöver vara uppmärksam på dessa siffror.

När du har övervägt den här informationen är det dags att börja förbättra webbplatsens prestanda med rekommendationerna från Google PageSpeed.

1. Eliminera renderingsblockerande resurser

En av de vanligaste rekommendationerna från Google PageSpeed Insights är att Eliminera renderingsblockerande resurser:

Detta handlar om JavaScript och CSS-skript som hindrar din sida från att laddas snabbt. Besökarens webbläsare måste ladda ner och bearbeta dessa filer innan den kan visa resten av sidan, så att ha en hel del av dem högt upp på sidan kan negativt påverka webbplatsens hastighet.

Du kan läsa mer om det här problemet i vår guide till att eliminera renderingsblockerande skript. När det gäller Google finns det två lösningar du bör överväga:

• Om du inte har mycket JavaScript eller CSS kan du infoga dem inline för att bli av med denna varning. Denna process innebär att införliva din JavaScript och/eller CSS i din HTML-fil. Du kan göra detta med plugin som Autoptimize. Detta gäller dock bara för mycket små webbplatser. De flesta WordPress-sajter har tillräckligt med JavaScript för att den här metoden faktiskt kan sakta ner sajten.
• Det andra alternativet är att skjuta upp JavaScript. Attributet ”defer” hämtar JavaScript-filen under HTML-parsning, men exekverar den bara efter att parsningen är klar. Skript med det här attributet exekveras också i den ordning det dyker upp på sidan.

Du hittar en lista över de resurser som påverkas mest av det här problemet under rekommendationen i dina PageSpeed-resultat.

Kolla denna video för att ta reda på mer om hur du eliminerar renderingsblockerande resurser:

2. Undvik att kedjekoppla kritiska förfrågningar

Begreppet kedjakoppla kritiska förfrågningar handlar om den kritiska renderingsvägen (CRP) och hur webbläsare laddar dina sidor. Vissa element – som JavaScript och CSS som vi diskuterade ovan – måste laddas helt innan din sida blir synlig.

Som en del av detta förslag kommer Google PageSpeed Insights att visa dig förfrågningskedjorna på sidan du analyserar:

Detta diagram visar dig den serie av beroende förfrågningar som måste uppfyllas innan din sida blir synlig. Det kommer också att visa storleken på varje resurs. Helst bör du minimera antalet beroende förfrågningar, liksom deras storlekar.

Flera metoder för att uppnå dessa mål omfattas av andra rekommendationer som diskuteras i detta inlägg, inklusive:

• Eliminera renderingsblockerande resurser
• Skjut upp inläsningen av bilder som inte visas på skärmen
• Minifiera CSS och JavaScript

Dessutom kan du optimera den ordning i vilken tillgångar laddas, för att förkorta CRP. Detta innebär att flytta det översta innehållet till högst upp av din HTML-fil. Du kan läsa mer om att optimera CRP i vårt inlägg, ”Så optimerar du den kritiska renderingsvägen i WordPress”.

Det är viktigt att notera att det inte finns ett magiskt antal kritiska förfrågningskedjor som du behöver arbeta ner till. Google PageSpeed Insights räknar inte denna granskning som godkänd eller misslyckad, till skillnad från många av dess andra rekommendationer. Denna information görs helt enkelt tillgänglig för att hjälpa dig att förbättra laddningstiderna.

3. Begränsa antalet begäranden och storleken på överföringar

Ju fler begäranden webbläsare måste göra för att ladda dina sidor, och ju större resurser servern returnerar som svar, desto längre tar din webbplats att ladda. Därför är det bra att Google rekommenderar att du begränsar antalet begäranden och storleken på överföringar av dina resurser.

Som Undvik att kedjekoppla kritiska förfrågningar-rekommendationen resulterar detta inte i ett ”godkänt” eller ”underkänt”. Istället ser du helt enkelt en lista över antalet förfrågningar som gjorts och deras storlekar:

Det finns inget idealiskt antal begäranden/förfrågningar eller maximala storlekar att hålla sig under. Istället rekommenderar Google att du sätter dina egna standarderna själv genom att skapa en prestandabudget. Detta är en uppsättning definierade mål som kan relateras till aspekter som:

• Maximal bildstorlek
• Antalet webbtypsnitt som används
• Hur många externa resurser du anropar
• Storleken på skript och ramverk

Att skapa en prestandabudget ger dig en uppsättning standarder att förhålla dig till. När du går över din budget kan du då fatta beslut om att eliminera eller optimera resurser för att hålla dig inom dina förutbestämda riktlinjer. Du kan läsa mer om att skapa en i Googles egen guide.

4. Minifiera CSS

CSS-filer är ofta större än de behöver vara, för att göra dem lättare för människor att läsa. De kan innehålla olika returer och mellanslag som inte är nödvändiga för att datorn ska förstå deras innehåll.

Att minifera din CSS är processen att kondensera dina filer genom att eliminera onödiga tecken, mellanslag och dubbletter. Google rekommenderar detta eftersom det minskar dina CSS-filstorlekar och kan därför förbättra laddningshastigheten:

Dessa hastighetsfördelar är anledningen till att Kinsta byggde in en kodminifieringsfunktion i MyKinsta-instrumentpanelen. Våra kunder kan välja automatisk kodminifiering för sina CSS- och JavaScript-filer, vilket snabbar upp deras webbplatser utan manuell ansträngning.

Om du inte är Kinsta-kund rekommenderar vi att du använder ett plugin som Autoptimize eller WP Rocket för att minifiera dina CSS-filer.

5. Minifiera JavaScript

Förutom att du kan minska CSS-filens storlek genom minifiering kan du göra det för dina JavaScript-filer också:

Autoptimize eller WP Rocket kan hantera denna uppgift för din WordPress-sajt också.

6. Ta bort CSS som inte används

Varje kod i din stilmall är innehåll som måste laddas för att din sida ska bli synlig för användarna. Om det finns CSS på din webbplats som inte är faktiskt användbar tynger det ner din prestanda i onödan.

Därför rekommenderar Google att ta bort CSS som inte används:

Lösningen här är i princip samma som för att eliminera renderingsblockerande CSS. Du kan skjuta upp stilar eller skriva dem inline på det sätt som är mest logiskt för dina sidor. Du kan också använda ett verktyg som Chrome Devtools för att hitta oanvänd CSS som behöver optimeras.

7. Minska arbetsbelastningen på modertråden

”Modertråden” är det primära elementet i en användares webbläsare som ansvarar för att omvandla kod till en webbsida som besökare kan interagera med. Den tolkar och exekverar HTML, CSS och JavaScript. Dessutom ansvarar den för hantering av användarinteraktioner.

Detta innebär att när modertråden arbetar igenom webbplatsens kod, kan den inte också hantera användarförfrågningar. Om webbplatsens modertrådsarbete tar för lång tid kan detta leda till dålig UX och långsamma sidladdningstider.

Google PageSpeed kommer att flagga sidor som tar längre tid än fyra sekunder att slutföra modertrådsarbetet och presentera en användbar webbsida:

Några av de metoder som används för att minska modertrådsarbetet har vi redan tagit upp i andra delar av detta inlägg, inklusive:

• Minifiera din kod
• Ta bort oanvänd kod
• Använd cachning

Du kanske också vill överväga koddelning. Det innebär att dela upp JavaScript i buntar som körs när de behövs, istället för att kräva att webbläsare ska ladda dem alla innan sidan blir interaktiv.

Webpack används ofta för att implementera koddelning. Observera att detta är en ganska avancerad teknik och nybörjare bör vara försiktiga innan de testar detta ensamma.

8. Minska exekveringstiden för JavaScript

JavaScript-exekvering är ofta den mest framträdande bidragsgivaren till modertrådsarbetet. PageSpeed Insights har en separat rekommendation för att varna dig om den här uppgiften har en betydande inverkan på webbplatsens prestanda:

De metoder som föreslås ovan för att minska modertrådsarbetet bör också lösa denna varning i dina PageSpeed-resultat.

9. Reducera serversvarstider (TTFB)

Tid till första byte (TTFB) är ett mått på hur lång tid det tar för en webbläsare att ta emot första byte av data från din webbplatsserver efter att ha gjort en förfrågan. Även om detta inte är samma sak som din totala webbplatshastighet, är en låg TTFB förståeligt bra för webbplatsens prestanda.

Att minska serversvarstiderna är därför bland rekommendationerna från Google PageSpeed Insights. Om du kan uppnå en låg TTFB ser du det här meddelandet under Godkända granskningar:

Det finns flera faktorer som kan påverka din TTFB. Vissa strategier för att sänka den inkluderar:

• Välj ett högkvalitativt webbhotell som fokuserar på hastighet
• Använda lättviktiga teman och plugins
• Minska antalet plugins på din webbplats
• Använda ett innehållsleveransnätverk (CDN)
• Implementera cachning för webbläsare
• Välja en solid Domain Name System-leverantör (DNS)

Vårt inlägg om TTFB är en utmärkt resurs för mer information om optimering inom detta område.

10. Använd bilder med rätt storlek

Mediefiler som bilder kan vara verkligen dra ner webbplatsens prestanda. Att använda rätt storlek är ett enkelt sätt att minska dina laddningstider:

Om din sida innehåller bilder som är större än de behöver vara, används CSS för att ändra storlek på dem på lämpligt sätt. Detta tar dock längre tid än att bara ladda bilderna i rätt storlek från början, vilket påverkar sidans prestanda.

För att fixa detta kan du antingen ladda upp bilder i rätt storlek eller använda ”responsiva bilder”. Detta innebär att skapa olika storlekar på bilderna för olika enheter.

Du kan göra detta med hjälp av srcset–attributet, som läggs till <img>-taggar för att ange alternativa bildfiler i olika storlekar. Webbläsare kan läsa den här listan, bestämma vilket alternativ som är bäst för den aktuella skärmen och leverera den versionen av din bild.

Säg till exempel att du har en headerbild och du vill göra den responsiv. Du kan ladda upp tre versioner av dem på 800, 480 och 320 pixlar bred. Då skulle du tillämpa srcset-attributet så här:

<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">

srcset-attributet anger de olika tillgängliga filerna och sizes-attributet berättar för webbläsaren vilken som ska användas baserat på den aktuella skärmstorleken.

11. Skjut upp inläsningen av bilder som inte visas på skärmen

Processen att skjuta upp inläsningen av bilder som inte visas på skärmen är mer allmänt känt som ”latladdning”, eller ”lat inläsning”. Detta innebär att i stället för att webbläsaren laddar varje bild på en sida innan den visar innehållet längst upp kommer den bara att ladda de som är omedelbart synliga.

Mindre laddning innan sidan blir synlig innebär bättre prestanda, vilket är varför Google rekommenderar den här metoden:

Det finns flera WordPressplugins gjorda speciellt för latladdning, inklusive a3 Lazy Load och Lazy Load by WP Rocket. Olika bild- och prestanda-optimeringsplugins som Autoptimize har också latladdningsfunktioner. Kolla in vår kompletta guide om att Latladda bilder och videor på WordPress.

12. Koda bilder effektivt

Som vi nämnde tidigare i det här inlägget har bilder en betydande inverkan på webbplatsens prestanda. En av de mest grundläggande optimeringar som du kanske vill överväga är komprimering, vilket kan bidra till att minska dina filstorlekar så att de laddas snabbare. Det är också den primära metoden för att följa Googles rekommendation att Koda bilder effektivt:

Nyckeln är att uppnå minsta möjliga filstorlekar, utan att offra kvaliteten på själva bilderna. Plugins som Imagify och Smush kan hjälpa till med denna uppgift. Du kan lära dig mer om dem i vår guide till bildoptimering.

Andra rekommendationer som påverkar om du får godkänt eller inte på granskningen Koda bilder effektivt inkluderar:

• Visa bilder i rätt storlek
• Använd latladdning (skjut upp inläsningen av bilder som inte visas på skärmen)
• Konvertera bilder till modernare filformat, till exempel WebP
• Använd videoformat för animationer, till exempel Gif

In addition to compressing your images, you can follow the steps for fulfilling these suggestions as described elsewhere in this post.

13. Skicka bilder i modernare bildformat

Det finns vissa bildfilformat som laddas snabbare än andra. Tyvärr är de inte de vanliga PNG eller JPEG-formaten. WebP-bilder håller på att bli den nya standarden, och Google PageSpeed kommer att informera dig om dina bilder inte följer den:

Detta kan tyckas en svår rekommendation att nå, eftersom du säkert redan har gott om bilder på din WordPress-sajt. Lyckligtvis finns det plugins som kan hjälpa dig. Till exempel erbjuder Imagify och Smush båda en WebP-konverteringsfunktion.

14. Använd videoformat för animationer

GIFs kan vara en effektiv form av visuellt innehåll i en mängd olika situationer. Handledningar, funktionsrecensioner, och även humoristiska animationer kan alla lyfta dina inlägg och göra dem roligare och mer värdefulla för läsarna.

Tyvärr kommer dessa fördelar till en kostnad för din prestanda. GIFs kräver att bli laddade, vilket är varför PageSpeed Insights rekommenderar att visa videoinnehåll istället:

Tyvärr är det inte så värst enkelt att konvertera GIF till videoformat. Först måste du bestämma vilken typ av video du vill använda:

• MP4: Producerar något större filer, men är kompatibelt med de flesta större webbläsare.
• WebM: Det mest optimerade videoformatet, även om det har begränsad webbläsarkompatibilitet.

När du har gjort det val som är mest meningsfullt för din webbplats, måste du konvertera filformatet. Det bästa sättet att göra detta är via kommandoraden. Installera FFmpeg för att komma igång. Detta är ett öppet källkodsverktyg för att konvertera filformat:

Öppna sedan ditt kommandoradsgränssnitt och kör följande kommando:

ffmpeg -i input.gif output.mp4

Detta konverterar en GIF med filnamnet input.gif till en MP4-video med filnamnet output.mp4. Att ändra formatet är bara början, dock. Du måste nu bädda in den resulterande videon på din WordPress-sajt på ett sätt som gör att den verkar vara en animerad GIF.

Bädda in videoinnehåll för animationer

Som du förmodligen har märkt om du någonsin har sett en GIF tidigare är det något annorlunda från vanliga videor. De brukar spelas upp automatiskt och i en slinga, och de är alltid utan ljud. Att bädda in din nya MP4 eller WebM-fil på din WordPress-sajt kommer inte att ge dem det beteendet.
Men du kan återskapa dem med lite mycket enkel kod. Ladda upp videon till mediebiblioteket och lägg sedan till följande på sidan eller inlägget där du vill inkludera din GIF:

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

Detta kommer att tillämpa de angivna attributen till din video, vilket gör att den visas mer som GIFs. Anpassa helt enkelt filnamnet och typen för att matcha din resurs. För mer information om detta ämne föreslår vi att du läser Googles guide om att konvertera GIFs till videoklipp.

15. Se till att all text förblir synlig medan webbtypsnitten läses in

Liksom bilder tenderar typsnitt att vara stora filer som tar lång tid att ladda. I vissa fall kan webbläsare dölja din text tills typsnittet du använder laddas helt, vilket resulterar i denna rekommendation från Google PageSpeed Insights:

Google råder dig att lösa problemet genom att använda Font display API-direktivet swap i din @font-face-stil. För att göra detta, öppna din stilmall (style.css) och lägg till följande efter src-attributet under @font-face:

font-display: swap

Du kan läsa mer om att optimera webbtypsnitt i vår fördjupade guide till att hosta lokala typsnitt.

16. Aktivera textkomprimering

Google PageSpeed Insights rekommendation Aktivera textkomprimering avser användningen av Gzip-komprimering:

I vissa fall (som du kan se i bilden ovan) aktiveras textkomprimering automatiskt på din server. Om så inte är fallet för din webbplats har du ett par alternativ för att följa denna rekommendation.

Det första är att installera ett plugin med en Gzip-komprimeringsfunktion. WP Rocket är en bra lösning om du är villig att betala för det.

Du kan också komprimera din text manuellt. Detta innebär att redigera din .htaccess– fil, vilket kan vara riskabelt, så se till att du har en färsk säkerhetskopia till hands.

De flesta WordPress-sajter körs på Apache-servrar. Koden för att aktivera Gzip-komprimering ser ut så här:

<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>

Du bör lägga till det efter #END i din .htaccess-fil. Om du råkar ha din WordPress-sajt på en Nginx-server bör du lägga till följande kod till din nginx.conf-fil istället:

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;

Om du vill kontrollera webbplatsens textkomprimering föreslår vi att du använder ett verktyg som GiftOfSpeed:

Detta kommer att låta dig veta om Gzip-komprimering har genomförts framgångsrikt, liksom vilken typ av server din webbplats körs på och några andra viktiga detaljer.

17. Föranslut till obligatoriska källor

Chansen är stor att du förmodligen har minst en resurs från tredje part på din webbplats – Google Analytics är ett vanligt exempel. Det kan ta tid för webbläsare att upprätta en anslutning till dessa resurser, vilket segar ner dina laddningshastigheter.

Med attributet preconnect kan webbplatsen berätta för webbläsare direkt att det finns skript från tredje part på din sida som måste laddas. Processen att begära dem kan sedan initieras så snart som möjligt, vilket förbättrar din prestation.

Om Google anser att din sida kan dra nytta av den här tekniken ser du förslaget Föranslut till obligatoriska källor:

Det finns några sätt att implementera denna optimeringsstrategi. Om du är bekväm med att redigera dina WordPress-temafiler kan du lägga till en länktagg till din header.php-fil. Här är ett exempel:

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

I det här fallet berättar taggen för webbläsaren att den behöver upprätta en anslutning till example.com så fort som möjligt. Google PageSpeed Insights kommer att lista alla relevanta resurser för vilka du bör lägga till länktaggar med preconnect-attributet.

Det andra alternativet är att använda ett plugin för att uppnå samma effekt. Perfmatters har en föranslutningsfunktion (Notis: jag är en av grundarna av Perfmatters). WP Rocket och Pre* Party Recourse Hints har liknande funktioner.

18. Läs in viktiga resurser i förväg

Denna rekommendation liknar Föranslut till obligatoriska källor och att följa detta förslag låter dig minimera antalet förfrågningar webbläsaren måste göra till din webbplatsserver. I stället för att ansluta till resurser från tredje part handlar Läs in viktiga resurser i förväg om att ladda viktiga tillgångar på din egen server:

Att implementera denna teknik är också mycket likt den tidigare rekommendationen. Du kan lägga till länktaggar som anger de resurser som listas i PageSpeed Insights till din header.php-fil:

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

Du kan också införliva denna tagg med hjälp av Perfmatters, WP Rocket, eller Pre* Party Resource Hints.

19. Undvik upprepade omdirigeringar

Omdirigeringar används när du vill att en webbadress ska peka mot en annan. De används ofta när du flyttar eller tar bort en sida på din webbplats. Även om det inte är något fel med att använda omdirigeringar i allmänhet, orsakar de ytterligare förseningar i laddningstiden.

Om du har för många omdirigeringar på din webbplats kan du se denna rekommendation i Google PageSpeed Insights:

Det enda du kan göra som svar på denna rekommendation är att se till att du bara använder omdirigeringar när du absolut måste. Du kan lära dig mer om processen att skapa dem i vårt inlägg, ”WordPress-omdirigeringar – bästa praxis för bättre prestanda”.

20. Skicka statiska tillgångar med en effektiv cachelagringspolicy

Om du har använt Google PageSpeed Insights ett tag kanske du känner till den här rekommendationen bättre som Utnyttja webbläsarcachning-varningen. I Version 5 heter den nu Skicka statiska tillgångar med en effektiv cachelagringspolicy:

Detta förslag har flera lager vi behöver pussla oss igenom. Det första är vad ”cachning” betyder. Kort sagt är det en process där webbläsare sparar kopior av dina sidor, så att de kan laddas snabbare vid framtida besök.

Det vanligaste sättet WordPress-sajter använder cachning är med plugins. WP Rocket och W3 Total Cache är populära alternativ. Men vissa webbhotell – inklusive vi här på Kinsta – aktiverar cachning via sina servrar. Se till att kontrollera om detta är fallet för ditt webbhotell innan du installerar ett cachningsplugin.

När du har aktiverat cachning för din webbplats kan du oroa dig för den andra delen av denna rekommendation, som är cachelagringspolicyns ”effektivitet”. Webbläsare rensar sina cacheminnen regelbundet för att skapa uppdaterade kopior.

Du vill att denna tidsperiod ska vara högre snarare än lägre. Om du rensar din webbplats från webbläsarcache med några timmars mellanrum besegrar det syftet med att använda denna teknik överhuvudtaget. Du kan optimera din cacheperiod med hjälp av Cache-Control och Expires-rubriker.

Lägga till cache-control-rubriker.

Använd följande kod för att lägga till cache-control-rubriker i Nginx:

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

Du bör lägga till detta i serverns konfigurationsfil. I exemplet ovan är de angivna filtyperna inställda att löpa ut efter 30 dagar.

Användare med Apache-servrar ska använda detta kodavsnitt i sin .htaccess-fil istället:

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

Lägg till den här koden innan #BEGIN WordPress eller efter #END WordPress. I det här exemplet är cacheperioden inställd på 84 600 sekunder.

Lägga till Expires-rubriker

Cache-control-rubriker är i princip standard nu. Det finns dock några verktyg (inklusive GTMetrix) som fortfarande letar efter Expires-rubriker.

Du kan lägga till expires-rubriker till en Nginx-server genom att införliva följande i ditt serverblock:

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

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

Du bör ställa in olika utgångstider baserat på filtyper. Apache-servrar kommer att ge samma resultat om du lägger till den här koden i din .htaccess-fil:

## 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 ##

Återigen bör du lägga till den här koden antingen innan #BEGIN WordPress eller efter #END WordPress.

Effektiv Cachning av Google Analytics

Ironiskt nog har Google Analytics-skript du kan ha lagt till i dina sidors headers för att spåra användarbeteende en utgångsperiod på bara två timmar. Detta är troligt så att användarna, om uppdateringar görs till plattformen, kommer att få tillgång till ändringarna snabbt.

Det här skriptet visas i listan över resurser som kräver din uppmärksamhet under Skicka statiska tillgångar med en effektiv cachelagringspolicy-rekommendationen. Eftersom det tillhör en tredje part kan du inte ändra utgångsperioden med Cache-Control eller Expires-rubriker.

Om det här är det enda skriptet i denna rekommendation kan du fortfarande få godkänt i granskningen:

Men som vi har noterat i hela det här inlägget betyder din PageSpeed-poäng mindre än din faktiska och upplevda prestanda. För att kunna nyttja den här resursen effektivt kan du överväga att hosta Google Analytics lokalt.

Plugins som Complete Analytics Optimization Suite (CAOS) och Perfmatters låter dig göra det här. Du kan läsa mer om processen i vår kompletta guide till detta PageSpeed-förslag.

21. Minska påverkan från tredjepartskod

Vi har nu nämnt några olika sätt på vilka skript från tredje part kan påverka din prestanda negativt och resultera i misslyckade granskningar från PageSpeed Insights. Helst bör du begränsa ditt beroende av dessa verktyg för att förhindra negativa effekter.

Men i vissa fall är den bästa lösningen på ett av din webbplats behov att införliva ett skript från tredje part. Google Analytics är ett utmärkt exempel. Andra inkluderar:

• Sociala medier-delningsknappar och flöden
• YouTube-videoinbäddningar
• iFrames för annonser och annat innehåll
• Bibliotek för JavaScript, typsnitt och andra element

I de fall där du anser att användningen av ett tredjepartsskript är nödvändigt är det viktigt att fortfarande minska dess påverkan på webbplatsens prestanda, eftersom dina PageSpeed-analysresultat kommer att säga till dig att:

För att ladda kod från en tredje part mer effektivt kan du överväga en av de tekniker vi redan har nämnt i det här inlägget:

• Skjuta upp laddning av JavaScript
• Använda länktaggar med preconnect-attributet
• Självhosta tredjepartsskript (som vi beskrev med Google Analytics ovan)

Dessa metoder bör minimera påverkan på webbplatsens prestanda.

22. Undvik enorm nätverksbelastning

Denna rekommendation är särskilt relevant för dina mobila besökare. Höga belastningar kan kräva användning av surfdata, vilket kostar pengar för dina användare. Att minimera antalet nätverksförfrågningar som behövs för att nå dina sidor kan förhindra detta:

Google rekommenderar att du behåller din totala byte-storlek till 1600 KB eller mindre. De metoder som oftast används för att uppnå detta mål finns på andra ställen i detta inlägg, inklusive:

• Skjuta upp CSS, JavaScript och bilder som inte syns på skärmen direkt
• Minifiera kod
• Komprimera bildfiler
• Använda WebP-formatet för bilder
• Använd cachning

Följ de relevanta stegen för dessa strategier, och du bör få godkänt i denna granskning utan någon ytterligare ansträngning.

23. User Timing API – tidsstämplar och mått

Denna rekommendation är endast relevant om du använder User Timing API. Detta verktyg skapar tidsstämplar som hjälper dig att utvärdera JavaScript-prestanda. Om du har konfigurerat API:n för din webbplats ser du dina tidstämplar och mått under den här rubriken i PageSpeed Insights:

Som du kan se är detta ett annat förslag från Google som inte resulterar i ett godkänt eller underkänt. PageSpeed Insights gör helt enkelt denna information lätt att hämta, så att du kan använda den för att bedöma områden som kan kräva optimering.

Om du är intresserad av att införliva User Timing API i din WordPress-sajt kan du lära dig mer i Mozillas guide om ämnet.

24. Undvik ett onödigt stort DOM-träd

I enklaste termer är DOM hur webbläsare förvandlar HTML till objekt. Det innebär användning av en trädstruktur som består av enskilda noder som var och en representerar ett objekt. Ju större din sidas DOM är, desto längre tid tar det såklart att ladda.

Om din sida överstiger vissa standarder avseende DOM-storlek, kommer den rekommendera att minska antalet noder såväl som komplexiteten i din CSS-styling:

En vanlig bov om du har ”misslyckats” med denna granskning i PageSpeed Insights är ditt WordPresstema. Tunga teman lägger ofta till stora volymer av element till DOM, och kan också innehålla invecklad styling som saktar ner din webbplats. Om så är fallet kan du behöva byta teman.

Sammanfattning

Google PageSpeed Insights bör vara ett standardverktyg för alla webbansvariga. Dock är fixering på din poäng och besatthet över att nå det eftertraktade 100/100 förmodligen inte det bästa du kan göra med din tid. Det kan stjäla din uppmärksamhet dig från andra viktiga uppgifter som kan ge mer betydande fördelar.

I det här inlägget täckte vi hur din Google PageSpeed-poäng spelar och inte spelar någon roll. Vi delade också några korta riktlinjer för att sätta plattformens rekommendationer i arbete på din WordPress-sajt, för att förbättra dess prestanda.

Har du frågor om Google PageSpeed Insights eller att optimera webbplatsens prestanda? Fråga oss i kommentarfältet nedan!