En djupdykning i GTmetrix verktyg för hastighetstest

Som webbplatsägare har du många alternativ när det gäller att köra hastighetstester för att kontrollera prestanda. Tidigare tog vi en djupgående titt på Pingdom-verktyget. Idag tänkte vi djupdyka i hur man bättre använder och förstår data från Gtmetrix, det populära testverktyget för webbplatshastighet. Detta verktyg förlitar sig på betygssystem och poäng, tillsammans med varningar om vad som kan vara fel på din webbplats. Ibland kan dessa vara väldigt förvirrande, så det kan vara värt att ta sig lite tid för att tolka vad de faktiskt betyder. Detta kan hjälpa dig att inte bara öka dina poäng utan även prestandan på din webbplats, vilket är det som verkligen betyder något.

GTmetrix utvecklades av GT.net, ett företag som är baserat i Kanada. Det skulle vara ett verktyg för kunderna som de hostade, så att de enkelt skulle kunna bestämma prestandan på sin webbplats. Förutom Pingdom är detta förmodligen ett av de mest kända och använda hastighetstestverktygen på webben idag! Faktum är att anledningen till att vi skriver detta är att det finns många Kinsta-kunder som frågar oss hur de ska följa råden som de ser i sina GTmetrix-rapporter. GTmetrix är ganska enkelt att använda jämfört med andra utvecklarverktyg och även en nybörjare kan lära sig detta ganska snabbt. Det använder en kombination av Google PageSpeed Insights och YSlow för att generera poäng och rekommendationer.

Alternativ för GTmetrix-analys

Den grundläggande versionen av GTmetrix är helt kostnadsfri och du kan få tillgång till ett antal alternativ bara genom att registrera dig för ett konto. De har även premiumplaner, men i dagens inlägg kommer vi att använda den kostnadsfria versionen. Om du har ett konto kan du använda ett antal ytterligare analysalternativ.

Det första är möjligheten att välja den plats där du vill testa webbadressen. Den fysiska platsen som du väljer är faktiskt mycket viktig eftersom den relaterar till var din webbplats faktiskt är hostad. Ju mindre latens, desto snabbare blir dina laddningstider. För närvarande är de tillgängliga platserna:

• Dallas, USA
• Hongkong, Kina
• London, Storbritannien
• Mumbai, Indien
• Sydney, Australien
• São Paulo, Brasilien
• Vancouver, Kanada

Du kan välja vilken webbläsare som du vill använda. Du kan testa med Chrome (Desktop) och Firefox (Desktop). Mobilversioner finns i deras premiumabonnemang. De låter dig även ändra anslutningshastigheten, vilket innebär att du kan simulera olika anslutningstyper för att se hur de påverkar dina sidladdningar.

Ytterligare alternativ inkluderar möjligheten att skapa en video. Detta kan hjälpa dig att felsöka problem eftersom du kan se hur sidan återges. AdBlock Plus är en trevlig funktion. Om du kör ett annonsnätverk från tredje part, exempelvis Google Adsense, kan du aktivera det här alternativet för att se den fulla effekten som annonser har på dina laddningstider.

Ytterligare alternativ inkluderar att stoppa test onload (som vi kommer att djupdyka i senare), kunna skicka en cookie tillsammans med din begäran, använda HTTP-autentisering, möjligheten att lägga till webbadresser i en tillåtelselista och blockeringslista, skärmupplösning och enhetspixelförhållande och åsidosättning av användaragent.

Analys med GTmetrix hastighetstestverktyg

En webbsida består av olika tillgångar, exempelvis HTML, JavaScript, CSS och bilder. Var och en av dessa genererar begäranden om att återge det som du ser på din webbplats. Ju fler begäranden du har, desto långsammare laddas vanligtvis din webbplats. Så är inte alltid fallet, men det stämmer för det mesta.

Nedan kommer vi att dela upp varje sektion av GTmetrix och förklara mer i detalj vad informationen betyder när det gäller den övergripande prestandan på din webbplats och vad du ska göra åt rekommendationerna.  Kom ihåg att inte vara alltför besatt av poängen, utan snarare på att göra faktiska hastighetsförbättringar på din webbplats.

• Sammanfattning av GTmetrix
• Prestanda
• Struktur
• Vattenfallsdiagram
• Video
• Historia

GTmetrix Sammanfattning (prestandapoäng och detaljer)

När du kör din WordPress-webbplats via GTmetrix genereras en prestandarapport som innehåller din ”GTmetrix Grade ” och ”Web Vitals”.

GTmetrix Grade beräknas utifrån två mätvärden – Prestanda och struktur.

• GTmetrix Prestanda är prestandapoängen från Lighthouse webbplatsgranskningsverktyg
• GTmetrix Struktur är ett proprietärt prestandamått som mäter en sidas övergripande prestanda.

Under 2020 introducerade Google en standardiserad uppsättning mått för webbprestanda och användarupplevelse som heter Web Vitals. Web Vitals består av en mängd olika mätvärden, men de som GTmetrix tar hänsyn till är LCP (Largest Contentful Paint), Total Blocking Time (TBT) och Cumulative Layout Shift (CLS).

• Largest Contentful Paint (LCP) är hur lång tid det tar för den största delen av sidan att läsas in. För vissa webbplatser kan LCP vara en stor bild, medan LCP på andra webbplatser kan referera till brödtexten.
• Total Blocking Time (TBT) är den tid som en sida blockeras innan en användare kan interagera med den. Renderingsblockering av CSS och JS kan ha en enorm inverkan på TBT.
• Cumulative Layout Shift (CLS) refererar till förskjutning av element medan en sida läses in. Layouten för en sida som innehåller inbäddade tweets kan exempelvis skifta dramatiskt när sidan läses in.

I vårt exempel använder vi vår fallstudiedomänen kinstalife.com, som finns på Kinsta. I vårt första hastighetstest registrerade vår webbplats följande statistik.

• GTmetrix Grade – B
• GTmetrix Prestanda – 85%
• GTmetrix Struktur – 83%
• LCP – 1,0s
• TBT – 0ms
• CLS – 0

Sen gjorde vi ytterligare ett test och nu är vår GTmetrix Grade ”A”! Vad beror detta på? Du kanske även märker detta om du kör din webbplats via GTmetrix hastighetstestverktyg flera gånger. En av anledningarna till att detta händer är cachelagring, både DNS-cachelagring och servercache. Ta reda på anledningen längre ner i vår vattenfallsanalys.

Sammanfattningssidan för GTmetrix innehåller också en hastighetsvisualisering, som visar en tidslinje över viktiga händelser under en sidinläsning. I skärmdumpen nedan kan du se TTFB, FCP, LCP, onload-tid, Time to interactive och fully loaded time för kinstalife.com.

Prestanda

Härnäst kommer fliken GTmetrix ”Performance”, som visar ett antal användbara mätvärden som kommer från Lighthouse prestandadata. Förutom LCP, TBT och CLS som visas på sammanfattningssidan visar sektionen ”Performance Metrics” även Speed Index (SI), Time to Interactive (TTI) och First Contentful Paint (FCP).

Även om avsnittet ”Performance Metrics” inte visar dig exakt vad du behöver fixa, ger det en fin översikt över vilka viktiga användarupplevelsemått som du kan förbättra.

Längre ner på sidan visar GTmetrix även lite mer traditionell ”Browser Timing” -statistik inklusive Onload Time, Time to First Byte, Fully Loaded Time och mer. Tidigare var dessa traditionella mätvärden mycket viktiga. Men nu när Google banar väg med standardiserade mätvärden med Web Vitals rekommenderar vi att du optimerar för dem istället. I de flesta fall kommer du att upptäcka att optimering för Web Vitals även resulterar i bra tidsmått för webbläsare.

Struktur

Under GTmetrix-fliken ”Structure” kan du visa specifika problem som påverkar webbplatsens prestanda. Den här sidan är mycket användbar eftersom den ger dig användbar information som ”eliminate render-blocking resources” och ”minify CSS”, så att du kan börja optimera din webbplats.

Vi kommer att försöka gå igenom de vanligaste och mest populära som vi ser WordPress webbplatsägare kämpa med. Se till att även bokmärka det här inlägget eftersom vi ständigt kommer att uppdatera det. Om du förbättrar dessa på din webbplats, bör du se en ökning av prestandan.

Visa skalade bilder

När det gäller att arbeta med bilder på din webbplats bör du alltid försöka ladda upp dem till skalan och inte låta CSS ändra storlek på dem. Om du inte gör detta kommer du att möta rekommendationen serve scaled images.  Om du använder WordPress, ändras storleken på dina bilder som standard när du laddar upp dem till mediebiblioteket. Dessa inställningar finns under ”Settings > Media”. Du bör se till att den maximala bredden ligger nära webbplatsens bredd. På så sätt försöker CSS inte ändra storlek på din bild för att passa inuti. Du kan även ändra storlek på dem automatiskt med ett bildoptimeringsplugin.

Linda in litet CSS

Att linda in din CSS rekommenderas vanligtvis inte eftersom det kommer att öka den totala nedladdningsstorleken för din sidbegäran. Men om din webbplats är liten, med minimalt antal begäranden, kan det förbättra din prestanda.

För att enkelt linda in din CSS kan du använda ett kostnadsfritt plugin som Autoptimize. Markera bara alternativet ”Inline all CSS?” och se sedan till att du har uteslutit de ytterligare CSS-filer som du inte lindar in.

Linda in litet JavaScript

Precis som med liten CSS kan du även linda in liten JavaScript. Det rekommenderas vanligtvis inte eftersom det kommer att öka den totala nedladdningsstorleken för din sidbegäran. Men om din webbplats är liten, med minimala förfrågningar, kan det förbättra din prestanda. Du kan återigen använda JavaScript-inställningarna för Autoptimize.

Utnyttja webbläsarens cacheminne

Att utnyttja webbläsarcache är en mycket vanlig rekommendation som människor kämpar med. Detta genereras på grund av att du inte har rätt HTTP-cacherubriker på webbservern. Se vårt djupgående inlägg om hur du fixar leverage caching-varningen. Du kan endast åtgärda detta på resurser som du kontrollerar. Om du exempelvis ser detta i annonsnätverk från tredje part finns det inget som du kan göra.

Betjäna resurser från en konsekvent URL

Om du får rekommendationen ”Serve Resources From a Consistent URL” är det troligt att du har identiska resurser som betjänas från samma URL. Många gånger kan detta hända när det finns frågesträngar inblandade. Kolla in hur du tar bort frågesträngar från statiska resurser. När de är borta ska den inte längre behöva ladda den två gånger.

Skjuta upp tolkning av JavaScript

JavaScript och CSS är som standard renderings-blockerande. Detta innebär att de kan förhindra att webbsidan visas tills den laddas ner och bearbetas av webbläsaren. Attributet ”defer” talar om för webbläsaren att den ska vänta med att hämta resursen tills HTML-tolkningen är klar. Några enkla sätt att fixa detta är att använda det kostnadsfria Autoptimize eller pluginet Async JavaScript. Se till att kolla in vårt djupgående inlägg om hur du eliminerar renderings-blockering av JavaScript och CSS.

För en djupgående förklaring, läs How to Defer Parsing of Javascript Warning in WordPress (4 Methods).

Minifiera CSS och JavaScript

Minifiering tar i huvudsak bort alla onödiga tecken från källkoden utan att ändra dess funktionalitet. Detta kan inkludera radbrytningar, tomt utrymme, indrag osv. Genom att göra detta kan det sparas bytes med data och påskynda nedladdning, tolkning och körningstid.

Det kostnadsfria Autoptimize-pluginet är återigen bra för detta. Se bara till att du både kryssar för ”Optimize JavaScript Code ” och ”Optimize CSS Code” Om du har en stor webbplats kanske du också bör kolla de avancerade inställningarna undertill, eftersom vissa kan skada prestandan på din webbplats. Att linda in eller kombinera CSS och JavaScript på stora webbplatser rekommenderas vanligtvis inte. Det är här kraften hos HTTP/ 2 kommer in i bilden.

Om du är Kinsta-kund kan du dra nytta av kodminifierings-funktionen som är inbyggd direkt i MyKinsta-instrumentpanelen. Den gör att våra kunder snabbt och enkelt kan aktivera automatisk CSS- och JavaScript-minifiering med ett enda klick. Detta snabbar upp deras webbplatser utan manuell ansträngning.

Optimera bilder

Enligt HTTP Archive, utgör bilder i genomsnitt 66% av en webbsidas totala vikt, från och med april 2017. Så när det gäller att optimera din WordPress-webbplats är bilder verkligen det första du ska kolla in! Det är viktigare än skript och teckensnitt.

I en perfekt värld bör varje bild komprimeras och optimeras innan den laddas upp till WordPress. Men tyvärr är detta inte realistiskt. Vi rekommenderar med andra ord att du använder ett bra bildoptimeringsplugin. Detta hjälper till att automatiskt komprimera dina bilder, ändra storlek på dem och se till att de är lättviktiga och snabba att ladda på din webbplats. Kolla in vårt djupgående inlägg om hur du optimerar bilder för webben.

Minska den initierande serverns svarstid

För WordPress är bristen på sidcache den främsta boven i dramat för långsamma initiala serversvarstider. Utan sidcache använder WordPress PHP för att dynamiskt bygga sidor för varje enskild begäran, vilket innebär att det snabbt kan bli överväldigat med begäranden. Med sidcache aktiverat kan webbplatsen visa förgenererade HTML-filer, vilket är mycket snabbare och mer skalbart än att använda PHP för att uppfylla varje sidbegäran.

Om du hostas hos Kinsta behöver du inte oroa dig för sidcache eftersom vi tar hand om det åt dig med vår Nginx-konfiguration. Om din WordPress-host inte stöder sidcache kan du installera ett cache-plugin som WP Rocket eller W3 Total Cache. För att minska serverns svarstid ytterligare rekommenderar vi att du integrerar  Cloudflare APO med din WordPress-webbplats. Denna innovativa optimeringstjänst från Cloudflare distribuerar webbplatsens HTML-sidor runt om i världen, vilket kan minska serverns svarstid globalt.

Minifiera HTML

Precis som CSS och JavaScript kan även HTML minifieras för att få bort onödiga tecken och spara byte med data för att påskynda körningstiden.

Även det kostnadsfria Autoptimize-pluginet är bra för detta. Aktivera bara alternativet ”Optimera HTML-kod”.

Aktivera GZIP-komprimering

GZIP är ett filformat och ett program som används för filkomprimering och dekomprimering. GZIP-komprimering aktiveras på serversidan och gör det möjligt att ytterligare minska storleken på HTML-, formatmalls- och JavaScript-filer. Det fungerar inte på bilder eftersom dessa redan är komprimerade på ett annat sätt. Vissa har fått upp till 70% minskningar på grund av komprimering. Det är förmodligen en av de enklaste optimeringarna som du kan göra när det gäller WordPress. GZIP-komprimering är aktiverad som standard på alla Kinsta-servrar.

Om du vill aktivera GZIP-komprimering i Apache lägger du bara till följande kod i htaccess-filen.

# 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

Om du kör på NGINX lägger du bara till följande i filen nginx.conf.

gzip on;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
gzip_vary on;
gzip_types text/plain text/css text/javascript image/svg+xml image/x-icon application/javascript application/x-javascript;

Se till att även kolla in vårt djupgående inlägg om hur du aktiverar GZIP-komprimering.

Minimera omdirigeringar

Om du minimerar HTTP-omdirigeringar från en URL till en annan minskar du RTT ännu mer samt väntetider för användare. Kolla in vårt inlägg om WordPress-omdirigeringar där vi upptäckte att 2 dåliga omdirigeringar ökade webbplatsens laddningstider med 58%! WordPress omdirigeringar saktar helt enkelt ner din webbplats. Det är därför värt att ta sig tid att minimera antalet omdirigeringar.

Ange en cache-validerare

Rekommendationen att ange en cache-validerare visas när HTTP-cachelagringshuvuden saknas. Dessa bör inkluderas i varje ursprungsserversvar, eftersom de både validerar och anger cachens längd. Om rubrikerna inte hittas genereras en ny begäran om resursen varje gång, vilket ökar belastningen på servern.  Att använda cachelagringshuvuden säkerställer  att efterföljande begäranden inte behöver läsas in från servern, vilket sparar bandbredd och förbättrar prestandan för användaren. Och kom ihåg, du kan inte fixa detta på resurser från tredje part som du inte kontrollerar.

Det finns ett antal olika HTTP-cachehuvuden som kan användas för att åtgärda den här rekommendationen. Kolla in vårt djupgående inlägg om hur du anger en cache-validerare.

Ange bilddimensioner

Lika viktigt som att inte låta CSS ändra storlek på dina bilder är att ange bilddimensioner. Det innebär att du inkluderar bredden och höjden i HTML-koden.

Felaktig

<img src="https://domain.com/images/image1.png">

Korrekt

<img src="https://domain.com/images/image1.png" width="200" height="100">

Ta bort frågesträngar från statiska resurser

Dina CSS- och JavaScript-filer har vanligtvis filversionen i slutet av sina webbadresser, exempelvis domain.com/style.css?ver=4.6. Vissa servrar och proxyservrar kan inte cachelagra frågesträngar, även om det finns ett cache-control:public-huvud. Så genom att ta bort dem kan du ibland förbättra din cache. Detta kan enkelt göras med kod eller med ett kostnadsfritt WordPress-plugin.

Kolla in vårt djupgående inlägg om hur du tar bort frågesträngar från statiska resurser. Och kom ihåg, du kan inte fixa detta på resurser från tredje part som du inte kontrollerar.

Ange en variation: Acceptera kodningshuvud

Detta är ett HTTP-huvud och bör inkluderas i varje ursprungsserversvar, eftersom det talar om för webbläsaren om klienten kan hantera komprimerade versioner av innehållet eller inte. När GZIP-komprimering är aktiverad, fixas vanligtvis även detta. Men kolla gärna in vårt djupgående inlägg om hur du åtgärdar ange en variation: acceptera kodningshuvud-rekommendationen. Och du kan återigen inte fixa detta på resurser från tredje part.

GTmetrix vattenfallsdiagram

GTmetrix vattenfallsdiagram visar alla enskilda begäranden på din webbsida (som du ser nedan). Du kan sedan analysera varje begäran för att se vad som orsakar förseningar och prestandaproblem på din webbplats. Nedan följer en mer djupgående sammanfattning och eller definition av vad var och en av färgerna betyder på varje begäran.

Blockering (brun)

När en webbläsare läser in en webbsida förhindrar JavaScript- och CSS-resurser vanligtvis att webbsidan visas tills de har hämtats och bearbetats av webbläsaren. Den här tidsfördröjningen visas som blockering i GTmetrix vattenfallsdiagram. Kolla in vårt djupgående inlägg om hur du eliminerar renderings-blockering av JavaScript och CSS för mer information.

DNS-sökning (Teal)

Du kan tänka på DNS-sökning som en telefonbok. Det finns servrar som heter Domännamnsservrar och innehåller informationen om din webbplats och vilken IP den ska dirigeras till. När du först kör din webbplats via GTmetrix utför den en ny sökning och måste fråga DNS-posterna för att få IP-informationen. Detta resulterar i ytterligare uppslagstid.

När du kör din webbplats via GTmetrix en andra gång cachelagrar den DNS eftersom den redan känner till IP-informationen och inte behöver utföra sökningen igen. Detta är en anledning till att din webbplats visas snabbare efter att den har körts genom GTmetrix flera gånger. Som du kan se på skärmen nedan, på det andra testet vi körde, är DNS-uppslagstiden på den första DOC-belastningen 0 ms. Detta är ett område som många misstolkar! Vi rekommenderar att du kör ditt test flera gånger och tar medelvärdet, såvida du inte vill ha DNS som en del av rapporten. I så fall kan du göra det första testet.

Detsamma gäller dina tillgångar (JavaScript, CSS, bilder) om du använder ett CDN. En CDN-cache fungerar ungefär som ett DNS, när den cachelagras blir den mycket snabbare på kommande laddningar. Ett annat sätt att påskynda DNS är att använda DNS-förhämtning. Detta gör det möjligt för webbläsaren att utföra DNS-sökningar på en sida i bakgrunden. Du kan göra detta genom att lägga till några kodrader i rubriken på din WordPress-webbplats. Se några exempel nedan.

<!-- Prefetch DNS for external assets -->
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//www.google-analytics.com"> 
<link rel="dns-prefetch" href="//cdn.domain.com">

Om du kör WordPress version 4.6 eller nyare, kanske du vill använda resurstips. Utvecklare kan använda wp_resource_hints för att lägga till anpassade domäner och webbadresser för dns-prefetch, preconnect, prefetch eller prerender.

Anslutning (grön)

Anslutningstiden i GTmetrix refererar till TCP-anslutningen eller den totala tid som krävs för att skapa en TCP-anslutning. Du behöver egentligen inte förstå hur detta fungerar, men det här är helt enkelt en kommunikationsmetod mellan hosten / klienten och servern som måste äga rum.

Utskick (röd)

Sändningstiden är helt enkelt den tid som det tar för webbläsaren att skicka data till servern.

Väntetid (Lila)

Väntetiden i GTmetrix hänvisar faktiskt till tiden till första byte, även känt som TTFB i vissa verktyg. TTFB  är en mätning som används som en indikation på svarstider för en webbserver eller annan nätverksresurs. Generellt är allt under 100 ms acceptabelt och bra TTFB. Om du närmar dig intervallet 300-400 ms kan det vara något som är felkonfigurerat på servern eller så kan det vara dags att uppgradera till en bättre webbstack. Som du kan se, låg vårt test nedan på cirka 100 ms vilket är bra.

Några enkla sätt att minska din TTFB är att se till att din host har korrekt cachelagring på plats och använder ett CDN. Kolla in vårt djupgående inlägg om alla sätt att minska TTFB på din WordPress-webbplats.

Mottagning (grå)

Mottagningstiden är helt enkelt den tid som det tar för webbläsaren att ta emot data från servern.

Händelsetid

Varje gång du begär en sida infaller en händelsetid där saker renderas och blir inlästa.

• Första punkten (grön linje): Den första punkten där webbläsaren gör någon form av rendering på sidan, exempelvis att den visar bakgrundsfärgen.
• DOM Laddat (blå linje): Den punkt där DOM (Document Object Model) är klar.
• Onload (Röd linje): När bearbetningen av sidan är klar och alla resurser på sidan (bilder, CSS, etc.) är klar med nedladdningen.
• Fullt inläst (Lila linje): Punkten efter onload-händelsen när det inte har varit någon nätverksaktivitet på 2 sekunder.

HTTP-svarshuvuden

Du kan även klicka på en enskild begäran och se vad de kallar HTTP-svarsrubrikerna. Detta ger värdefull information. På skärmen nedan kan vi direkt se saker som att gzip är aktiverat på webbservern, det körs över HHVM, det betjänas från cache (HIT, skulle visa MISS annars), cache-kontrollhuvuden, serverarkitektur (detta är inte alltid synligt), upphör att gälla-rubriker, webbläsarens användaragent och mer.

En annan sak som man ska vara medveten om är att GTmetrix-verktyget stöder HTTP / 2, till skillnad från Pingdom, eftersom det för närvarande använder Chrome 58 + för att köra sina tester. Chrome  har lagt till HTTP/2-stöd i version 49. Kom ihåg detta när du väljer vilket hastighetstestverktyg du ska använda.

Video

För att hjälpa dig att felsöka visuella problem och prestandaproblem med frontend innehåller den senaste versionen av GTmetrix fliken ”Video”. När videofunktionen är aktiverad spelar GTmetrix automatiskt in en inbäddningsbar video som visar hur en sida läses in för varje prestandatest. Den här funktionen är mycket användbar för felsökning av visuella problem som endast visas i vissa kombinationer av webbläsare och skärmstorlek.

Historik

Under fliken historik kan du se alla dina tidigare hastighetstester. Det finns en gräns för hur många som lagras i kostnadsfria konton. Du kan även övervaka en URL som gör att du kan hålla reda på prestanda över tid och se eventuella ändringar när de inträffar.

En riktigt cool funktion är att du kan välja dina tidigare rapporter och jämföra dem sida vid sida. Detta kan vara mycket användbart, särskilt när du gör optimeringar på din webbplats för att se om det kan göras förbättringar. Kom dock ihåg att man ibland kan optimera för mycket.

Konfiguration av fallstudiedomän

Om du har kommit så här långt i vår djupgående GTmetrix-artikel så får du strax din belöning. Det är alltid irriterande att se människor dela tips och fallstudier men sedan inte visa hur de kommit dit. Så nedan kan du se vår exakta konfiguration för fallstudiedomänen som används ovan! Replikera gärna.

Arkitekturen

• Fallstudiedomänen (perfmatters.io) hostas av Kinsta på Google Cloud Platform i USA (Central plats). Kinsta använder HTTP/2, NGINX, MariaDB, som alla bidrar till de snabba laddningstiderna.
• Webbplatsen använder HHVM. Nu finns PHP 7.3 på Kinsta, ännu snabbare än HHVM! Du kan byta PHP-versioner med ett knapptryck.
• Webbplatsen använder inte något cacheplugin. Kinsta cachelagrar allt på servernivå vilket förenklar saker och ting avsevärt, och i de flesta fall går det snabbare!

WordPress-plugins

Och här är en lista över plugins som används på WordPress-webbplatsen.

• Det kostnadsfria PLUGIN-programmet CDN Enabler används för att distribuera KeyCDN.
• Det kostnadsfria CAOS-pluginet används för att synkronisera Google Analytics lokalt.
• Premium perfmatters-pluginet används för att bli av med onödiga HTTP-förfrågningar och inaktivera saker som Emojis och Embeds.
• Premium Gonzalez-pluginet används för att inaktivera vissa skript från att laddas.
• Premium Imagify-pluginet används för att komprimera bilder.

Rekommenderade självstudier för vidare läsning:

• Hur man snabbar upp sin WordPress-webbplats (Den ultimata guiden)
• Inaktivera emojis i WordPress
• Inaktivera inbäddningar i WordPress
• Identifiera och analysera externa tjänster på din WordPress-webbplats
• Så här får man 100/100 i Google PageSpeed Insights med WordPress
• Hur man diagnostiserar hög Admin-Ajax-användning på sin WordPress-webbplats
• 7 tips om hur man minskar antalet DNS-sökningar och påskyndar dem

Sammanfattning

Som du kan se kan lärdomen om hur GTmetrix hastighetstestverktyg fungerar och vad alla diagram betyder hjälpa dig att fatta ett mer datadrivet beslut när det gäller prestanda. Vi kallar det för en vattenfallsanalys, och det är avgörande för att veta hur dina enskilda tillgångar laddas. Och kom ihåg, det är svårt att jämföra med Pingdom eftersom de är olika verktyg och beräknar saker annorlunda. Det är med andra ord bäst att hålla sig till det ena eller det andra. Har du några andra bra GTmetrix tips?

Om du vill se mer djupgående artiklar som den ovan, vänligen meddela oss nedan i kommentarerna!