Idag vill vi dyka in i hur man bättre använder och förstår data från det populära hastighetstestsverktyget för webbplatser, Pingdom. Du kan använda den för att göra vad vi kallar en vattenfallsanalys av din WordPress-webbplats. Detta kan hjälpa dig att snabbt diagnostisera prestandaproblem, och också slippa feldiagnostisera ett problem.
Många gånger ser vi WordPress-användare som tolkar data fel i Pingdoms hastighetstestverktyg och detta leder ibland till att de konfigurerat en webbplats till ett tillstånd som är ännu värre än tidigare. Kom ihåg att alla verktyg som detta ska användas som guider, de är aldrig 100% exakta. Det viktiga är att vara konsekvent och använda samma verktyg under alla dina tester.
Pingdom
Pingdom är ett företag baserat i Sverige (som nu ägs av SolarWinds) som erbjuder en mängd olika tjänster, såsom driftstidsövervakning, sidhastighetsövervakning, transaktionsövervakning, serverövervakning och besökarinsikter (RUM). Förmodligen en av de saker som de är mest kända för är deras hastighetstestsverktyg för webbplatser. Det är ett av de mest populära prestandatestverktygen i WordPressvärlden.
Varför är det så populärt? Tja, först och främst, det är förmodligen det enklaste hastighetstestverktyget du kan använda! Inte alla är en webbprestandaexpert, så för den typiska WordPressanvändaren kan några av de andra alternativa verktygen på marknaden vara ganska överväldigande. Ibland är lagom helt enkelt bäst. När allt kommer omkring bryr du dig bara om två saker: hur snabb är din webbplats och hur kan du göra den snabbare.
Pingdom låter dig för närvarande kan hastigheten på olika webbplatser från 7 olika platser (5 kontinenter) strategiskt placerade runt om i världen:
- Asien – Japan – Tokyo
- Europa – Tyskland – Frankfurt
- Europa – Storbritannien – London
- Nordamerika – USA – Washington D. C.
- Nordamerika – USA – San Fransisco
- Stillahavsregionen – Australien – Sydney
- Sydamerika – Brasilien – Sao Paulo
Observera: Vi har märkt att ibland kommer inte alla testplatser att vara tillgängliga. Detta är mest troligt eftersom de är nere för underhåll eller blivit överbelastade med för många människor som försöker köra tester på dem. Om en testplats som du har använt tidigare inte längre är där, kolla tillbaka om en timme eller två. Mest troligt kommer den att dyka upp igen.
Testplatsen du väljer är faktiskt mycket viktigt eftersom det gäller den fysiska platsen där din webbplats faktiskt är hostad. Det är här en liten sak som kallas nätverkslatens kommer in i bilden. Men vi kommer att komma in på detta mer detaljerat nedan.
Vattenfallsanalys med Pingdom Hastighetstestverktyg
En webbsida består av olika tillgångar, såsom HTML, JavaScript, CSS, bilder och videor. Var och en av dessa genererar förfrågningar om att ladda upp det du ser på din webbplats. Vanligtvis gäller att ju fler förfrågningar du har, desto långsammare kommer din webbplats att ladda. Så är inte alltid fallet, men det är sant för det mesta.
Nedan kommer vi att bryta upp varje Pingdom-avsnitt och förklara mer i detalj vad informationen betyder eftersom det gäller den totala prestandan på din webbplats och hur man gör en vattenfallsanalys.
- Pingdom Sammanfattning
- Prestanda-insikter
- Svarskoder
- Innehållsstorlek och begäran efter innehållstyp
- Innehållsstorlek och begäranden efter domän
- Vattenfallsdiagram
- Fallstudie Domänkonfiguration
Pingdom Sammanfattning
När du kör din WordPress-webbplats via Pingdom genererar det en prestandaklass, en total laddningstid, den totala sidstorleken, och antalet förfrågningar du har på din webbplats. I vårt exempel använder vi perfmatters.io, en e-handelsplats som kör Easy Digital Downloads. Det är hostad på Kinstas blixtsnabba servrar.
Som du kan se körde vi vårt första test och vi fick en 88/100 på Pingdom och den totala laddningstiden är 541 ms. Det låter oss veta den totala storleken på våra kombinerade tillgångar och antalet förfrågningar.
Vi körde sedan ett extra test och nu är vår totala laddningstid 392 ms. med samma sidstorlek och antal förfrågningar! Vad handlar det om? 🤔Du kanske märker detta om du kör din webbplats via Pingdom hastighetstestverktyg flera gånger. Större webbplatser kommer att märka ännu större skillnader.
Det finns tre huvudorsaker till varför detta händer: DNS-cachning, CDN-cachning, och WordPress-cachning. Det är därför du alltid ska köra tester flera gånger. Naturligtvis kan externa anrop till tredjepartsresurser och API också påverka detta. Ta reda på varför längre ner i vår vattenfallsanalys.
Vill du få en bättre Pingdom-poäng på din WordPress-webbplats? Beroende på din webbplats och konfiguration kan det inte alltid vara möjligt att få en perfekt 100/100, särskilt för dig som kör e-handelsplatser och marknadsföringspixlar. Men bara att spendera lite tid på att förbättra din poäng är ett bra ställe att börja. Den totala hastigheten är egentligen vad som är viktigt.
Ibland kan användarupplevelsen också trumfa några av de webbprestandatrick du läser om på webben. Du kan inte glömma användarupplevelsen! Men var lugn, vi kommer att dela med oss av några tips och tricks nedan om hur vi fick ovanstående webbplats där den är, så fortsätt läsa.
Förbättra Sidprestanda
Avsnittet prestandainsikter, nu ”förbättra sidprestanda” uppdaterades 2018 och de har tagit bort några gamla objekt och lagt till nya. Detta är sannolikt eftersom några av de förslag som de rapporterade inte längre är lika relevanta som de brukade vara. När det gäller webbprestandaoptimeringar förändras alltid saker och ting med tiden. Och det kan ibland vara besvärligt om folk helt enkelt försöker jaga efter den perfekta Pingdom-poängen.
Vi lämnar dock hela detta avsnitt i vårt inlägg (några gamla och nya) eftersom det är viktigt att förstå hur dessa poäng beräknas. Dessa är i huvudsak alla baserade på regler för Google PageSpeed Insight. Generellt, om du förbättrar dessa på din webbplats, bör du se en minskning av dina totala laddningstider.
Här är några av de kategorier som avsnittet förbättra sidprestanda består av:
- Använd ett Innehållsleveransnätverk (CDN)
- Undvik HTTP 404 (Hittades inte)-fel
- Minimera Omdirigeringar
- Lägg till Expires-Rubriker
- Ta Bort Frågesträngar Från Statiska Resurser
- Använd Cookie-Fria Domäner
- Parallellisera Nedladdningar Över Värdnamn
- Ange en Cache-validator
- Ange en Vary: Accept-Encoding-rubrik
Låt oss nu dyka in i några av dessa och se vilka som fortfarande är relevanta idag.
Använd ett Innehållsleveransnätverk (CDN)
En av de viktigaste tjänsterna att implementera på din WordPress-webbplats idag är ett Innehållsleveransnätverk (CDN). Dessa är ett nätverk av servrar (även känd som POPs) som ligger runt om i världen. De är utformade för att vara hosta och leverera kopior av din WordPress-webbplats statiska (och ibland dynamiska) innehåll som bilder, CSS, JavaScript och videoströmmar.
Om du är en Kinsta-klient, inkluderar vi ett CDN i alla våra hosting-planer. Att aktivera det tar några klick. Några fördelar med ett CDN inkluderar en prestandaökning (lägre TTFB och nätverkslatens), lägre bandbredds och värdkostnader, och även SEO-fördelar.
Kinsta-kunder kan också njuta av en snabb och enkel ökning av den övergripande webbplatsoptimeringen genom att förminska din kod med hjälp av kodminifieringsfunktionen som är inbyggd i MyKinsta-instrumentpanelen. Detta tillåter kunder att aktivera automatisk CSS- och JavaScript-minifiering med ett enkelt klick, vilket effektivt påskyndar deras webbplatser utan manuell ansträngning.
Viktigt: Det nyligen uppdaterade Pingdom-verktyget har för närvarande en bugg som inte korrekt detekterar CDN-leverantörer.
Vissa CDN-leverantörer från tredje part som vi rekommenderar inkluderar:
- KeyCDN (detta är vad som driver Kinstas CDN)
- Cloudflare
- StackPath
- CDN77
I våra egna CDN-hastighetstester har vi funnit att ett CDN kan minska sidladdningstiden med över 50% i vissa fall!
Undvik HTTP 404 (Hittades inte)-fel
Detta avsnitt kallades tidigare ”undvik dåliga förfrågningar.” Och det här är alltid relevant! Denna varning är precis som den låter, det är en förfrågan som inte kunde slutföras framgångsrikt. Detta händer vanligtvis att du manuellt länkar till en tillgång eller bild som sedan har tagits bort, vilket resulterar i ett 404-fel. Detta visas som en orange cirkel i Pingdom, tillsammans med en 404 på svarsrubriksstatusen
Se alltid till att varje begäran på din webbplats returnerar framgångsrikt. Detta kommer att säkerställa att det inte genereras några frågor till tillgångar som inte längre existerar.
Minimera Omdirigeringar
För många omdirigeringar är alltid något du behöver se upp för. Enkla omdirigeringar som en enda 301-omdirigering HTTP till HTTPS, eller www till icke-www (vice versa) är okej. Och många gånger behövs dessa i vissa områden på din webbplats. Men var och en har en kostnad för webbplatsens prestanda. Och om du börjar stapla omdirigeringar ovanpå varandra är det viktigt att inse hur de påverkar webbplatsens prestanda. Detta gäller för sido- och post-omdirigeringar, bildomdirigeringar, allt.
En omdirigering visas som en blå cirkel i Pingdom, tillsammans med en 301 eller 302 på svarsrubriksstatusen.
Hur mycket påverkar omdirigeringar din webbplats? Låt oss göra ett litet test. Först kör vi ett hastighetstest på vår Kontakta Oss sida: https://perfmatters.io/contact/. Som du kan se nedan får vi en total laddningstid på 417 ms.
Vi ändrar sedan webbadressen något och kör ett annat hastighetstest för att se effekten av flera omdirigeringar. http://www.perfmatters.io/contact. Som du kan se tar samma sida nu 695 ms. att ladda. Det är en ökning med 66%. Usch!
Kolla in vårt djupgående inlägg på WordPress-omdirigeringar, och de bästa metoderna för snabbare prestanda.
Lägg till Expires-Rubriker
Detta förslag kallades tidigare utnyttja webbläsar-cachning. För att uttrycka det i lekmannatermer måste varje skript på din WordPress-webbplats ha en HTTP-cache-rubrik kopplad till den (eller borde ha det). Detta bestämmer när cacheminnet på filen löper ut. För att åtgärda detta, se till att din WordPress-värd har rätt cache-control och expires. Kinsta har dessa rubriker på plats på alla våra servrar. Kolla in stegen för hur du lägger till cachehuvuden på servern manuellt och läs vår guide om hur du lägger till expires-rubriker.
Det andra problemet är att när du laddar skript från tredje part har du inte tillgång till cachningsrubrikerna, eftersom du inte har någon kontroll över deras webbservrar. Vanliga syndabockar är Google Analytics-skript och marknadsföringspixlar, som Facebook och Twitter. För att åtgärda detta kan du hosta ditt Google Analytics-skript lokalt (även om detta inte stöds officiellt) med ett plugin som Perfmatters. WP Rocket har nu också möjlighet att hosta din Facebook marknadsföringspixel lokalt.
Att flytta skript lokalt kan variera när det gäller hur mycket det påverkar webbplatsens prestanda. Den enda fördelen är att du sedan har fullständig kontroll över filen och kan serva den från ditt eget CDN. Detta tar också bort en annan DNS-begäran från tredje part. Det är dock också viktigt att komma ihåg att dessa filer redan kanske cachas i folks webbläsare.
Se vårt djupgående inlägg om hur man fixar utnyttja webbläsarcachnings-varningen.
Ta Bort Frågesträngar Från Statiska Resurser
En annan vanlig fråga handlar om frågesträngar. Dina CSS- och JavaScript-filer har vanligtvis filversionen i slutet av deras webbadresser, till exempel https://domain.com/file.min.css?ver=4.5.3. Vissa servrar och proxyservrar kan inte cacha frågesträngar. Så genom att ta bort dem kan du ibland förbättra din cachning.
Du kan använda ett premiumplugin som Perfmatters som har ett enkelt en-klicks-alternativ för att ta bort frågesträngar.
Eller så kan du lägga till följande kod manuellt till temats functions.php-fil. Ett bättre alternativ skulle vara att använda ett gratis plugin som Code Snippets för att lägga till koden. På så sätt behöver du inte redigera ditt tema direkt.
function remove_query_strings() {
if(!is_admin()) {
add_filter('script_loader_src', 'remove_query_strings_split', 15);
add_filter('style_loader_src', 'remove_query_strings_split', 15);
}
}
function remove_query_strings_split($src){
$output = preg_split("/(&ver|\?ver)/", $src);
return $output[0];
}
add_action('init', 'remove_query_strings');Men innan du omedelbart går och rycker ut frågesträngar på din webbplats är det viktigt att veta varför frågesträngar används. Versionshantering på filer används vanligtvis av WordPress-utvecklare för att komma runt cachningsproblem.
Till exempel, om de trycker ut en uppdatering och ändrar style.css från ?ver=4.6 to ?ver=4.7, kommer det att behandlas som en helt ny URL och kommer inte att cachas. Om du tar bort frågesträngarna och uppdaterar ett plugin kan det leda till att cachad version fortsätter att visas. I vissa fall kan detta förstöra utseendet på din webbplats tills den cachade resursen löper ut eller cacheminnet raderas helt.
Dessutom kan vissa CDN cacha frågesträngar. Kinsta CDN kan och gör så som standard. Så om du är en Kinsta-kund, är frågesträngar redan cachade på dina tillgångar.
Se vår djupgående handledning om hur du tar bort frågesträngar från statiska resurser.
Använd Cookie-Fria Domäner
Vi har ett djupgående inlägg om hur man hanterar servera statiskt innehåll från en cookie-fri domän-varning. Många gånger kan du ignorera denna varning eftersom nya protokoll som HTTP/2 nu gör detta mindre viktigt. Kostnaden för en ny anslutning är vanligtvis dyrare än att strömma allt över samma anslutning. Två sätt att lösa detta är dock att använda en CDN-leverantör som tar bort cookies eller skapar en separat domän och/eller underdomän.
Komprimera komponenter med GZIP
Varningen ”Komprimera komponenter med GZIP” inträffar när Pingdom upptäcker en tillgång som inte har komprimerats med GZIP. GZIP är en komprimeringsmetod som används för att minska storleken på textbaserade filer som HTML-dokument och CSS/JS-filer. GZIP-komprimering är aktiverat på servern och komprimerar webbsidor och resurser innan de skickas till en besökare. Från våra tester såg vi att aktivering av GZIP-komprimering minskade filstorleken för en begäran med över 78%.
På Kinsta behöver du inte krångla med att aktivera GZIP manuellt eftersom det redan är aktiverat som standard på alla våra servrar. Om du märker att din hosting-leverantör inte har aktiverat GZIP rekommenderar vi att du hör av dig till deras supportteam för att aktivera det omedelbart. Det kan nämligen ha en enorm inverkan på din sidhastighet. Om du fortfarande möter ”Komprimera komponenter med GZIP”-varningen efter att ha aktiverat GZIP på servern är det möjligt att en server som hostar en extern tillgång som krävs av din webbplats inte har GZIP aktiverat. Om så är fallet finns det inget du kan göra från ditt håll för att ändra serverbeteendet.
Parallellisera Nedladdningar Över Värdnamn
Varningen ”parallellisera nedladdningar över värdnamn” är på grund av en begränsning hos HTTP/1.1 och webbläsare begränsas för antalet samtidiga anslutningar som de kan göra till en värd; vanligtvis 6 anslutningar. Denna varning ses vanligtvis på webbplatser med ett stort antal förfrågningar. Tidigare var det enda sättet att komma runt denna begränsning att genomföra vad som kallas för domän-sharding. Men om du använder en webbvärd eller CDN-leverantör som stöder HTTP/2, kan du tryggt ignorera detta nu eftersom flera resurser nu kan laddas parallellt över en enda anslutning. Men du kan också kolla in vår handledning om hur man fixar parallellisera nedladdningar över värdnamn-varningen genom att implementera domän-sharding.
Ange en Cache-validator
Denna varning avser saknade HTTP-cachningsrubriker som bör ingå på varje ursprungsserversvar, eftersom de både validerar och ställa in längden på cacheminnet. Om rubrikerna inte hittas, kommer det att generera en ny begäran om resursen varje gång, vilket ökar belastningen på din server. Dessa rubriker inkluderar last-modified, ETag, Cache-Control, och Expires. Precis som med utnyttja webbläsarcachning-varningen, bör dessa rubriker automatiskt läggas till av din WordPress-värd. Om du har förfrågningar från tredje part du ser detta på, finns det inget du kan göra eftersom du inte har kontroll över deras webbservrar.
Läs vårt djupgående inlägg om hur du fixar ange en cache validator-varningen.
Ange en Vary: Accept-Encoding-rubrik
Vi har ett djupgående inlägg om hur man fixar Ange en Vary: Accept-Encoding-rubrik-varning. Detta är en HTTP-rubrik och bör ingå på varje ursprungserversvar, eftersom det berättar för webbläsaren om klienten kan hantera komprimerade versioner av innehållet. Detta läggs automatiskt till på alla Kinstas servrar
Pingdoms Svarskoder
Nästa avsnitt i Pingdom hastighetstestverktyg är svarskoderna. Svarskoder, även kallad HTTP-statuskoder är som en kort anteckning från webbservern som spåras på toppen av en webbsida. Det är ett meddelande från webbservern som låter dig veta hur saker gick när begäran om att visa sidan mottogs. Några vanliga är:
- 200: ”Allt är okej.” Detta är den kod som levereras när en webbsida eller resurs fungerar precis som förväntat.
Exempel på Pingdom 200 svarskod - 301: ”Den begärda resursen har flyttats permanent.” Denna kod levereras när en webbsida eller resurs har ersatts permanent med en annan resurs. Den används för permanent URL-omdirigering.
Exempel på Pingdom 301 svarskod - 404: ”Den begärda resursen hittades inte.” Det vanligaste felmeddelandet av dem alla. Denna kod innebär att den begärda resursen inte existerar och att servern inte vet om den någonsin existerade.
Exempel på Pingdom 404 svarskod
Du kan läsa mer om alla olika svarskoder i vårt djupgående inlägg på HTTP-statuskoder.
Innehållsstorlek och begäran efter innehållstyp
Nästa avsnitt är innehållsstorleken efter innehållstyp och begäran efter innehållstyp. Var och en av dessa är användbara för att snabbt se vad som tar upp mest resurser på din webbsida. Enligt HTTP-arkivet utgör bilder i allmänhet 43% av den genomsnittliga webbsidans totala storlek. Vi ser också att detta vanligtvis också är fallet. Men som du kan se nedan på den här sidan är det inte alltid fallet.
För att optimera dina bilder rekommenderar vi starkt att du läser vårt djupgående inlägg om hur du optimerar bilder för webben och om WebP. Det finns många bra verktyg och plugins där ute för att ytterligare komprimera dina bilder och se till att de inte är huvuddelen av webbplatsens sidladdning. Och i vårt fall ovan, drar webbplatsen perfmatters.io nytta av att använda stora font awesome-ikoner i stället för bilder. Detta kan vara en bra strategi som gör en stor skillnad. Och naturligtvis, har vi några ytterligare tips i vår sidhastighetsguide om hur du ytterligare minskar din innehållsstorlek.
Innehållsstorlek och begäranden efter domän
Innehållsstorleken och begäran efter domänsektionen är ett bra sätt att snabbt se vilka externa tjänster och skript som körs på din webbplats. I vårt exempel kan du se att vi laddar alla våra tillgångar från vårt CDN. Sedan finns den ursprungliga HTML DOC-laddningen för webbplatsen från webbservern och ett externt anrop till Google Analytics-domänen. Beroende på din webbplats kan du ha många fler externa tjänster, såsom Facebook, Twitter, Hotjar, SumoMe, AdRoll, New Relic, CrazyEgg, etc.
Generellt gäller att ju färre externa förfrågningar du kan göra desto bättre, eftersom varje extern tjänst introducerar sin egen latens, TLS-handslagsförseningar, DNS-uppslagningar, etc. Se till att läsa vårt djupgående inlägg om hur man identifierar och analyserar externa tjänster på din WordPress-webbplats.
Generellt är det bäst att minska antalet förfrågningar så mycket som möjligt och hosta tillgångarna på ett ställe, till exempel att flytta dem till din webbserver eller CDN. Ett exempel skulle vara font awesome. Istället för att länka till det externa skriptet för font awesome, ladda ner det och servera det direkt.
Pingdom Vattenfallsdiagram
Och sist men inte minst har vi förfrågningsavsnittet i Pingdom Hastighetstestverktyg som genererar ett vattenfallsdiagram över alla enskilda förfrågningar på din webbsida (som visas nedan). Du kan sedan analysera varje förfrågan för att se vad som orsakar förseningar och prestandaproblem på din webbplats. Det här är vad vi menar när vi säger att vi gör en vattenfallsanalys. Nedan följer en mer djupgående sammanfattning och eller definition av vad varje statusfärg betyder.
DNS (Rosa)
Så vad är DNS? Tänk på det som en telefonbok. Det finns servrar som kallas domännamnsservrar som håller informationen om din webbplats och vilken IP den ska dirigeras till. När du först kör din webbplats via Pingdom, utförs en ny sökning, och det måste fråga DNS-poster för att få IP-information. Detta resulterar i ytterligare uppslagstid. Platsen för DNS-servern spelar också roll.
När du kör din webbplats via Pingdom mer än en gång, cachar den DNS eftersom den redan vet IP-informationen och behöver inte utföra uppslagningen igen. Detta är en anledning till att din webbplats visas snabbare efter att ha körts genom Pingdom flera gånger.
Som du kan se på skärmen nedan; på det andra testet vi körde var DNS-uppslagstiden på den ursprungliga DOC-laddningen på 3,6 ms. Vanligtvis kommer det att sjunka till 0 ms., i själva verket borde det göra det, eftersom begäran redan cachas. Detta är ett område en hel del människor misstolkar!
Dessutom kan du ytterligare optimera den genom att använda en premium DNS-tjänst, det kommer också med en hel del extra fördelar. Vår Cloudflares gratis-DNS är också snabb! Kolla in Cloudflares automatiska plattformsoptimering.
Det finns också andra skäl till att din webbplats kan visas snabbare efter flera tester. En av dessa är om du använder ett Innehållsleverantörsnätverk (CDN). För de som inte är bekant med ett CDN; det är ett nätverk av globala servrar som cachar ditt innehåll (JS, CSS, bilder, etc.) på platser närmare besökaren. När du först kör din webbplats via Pingdom, kan det behöva ta tillgångarna från CDN på nytt. En CDN-cache fungerar ungefär som DNS. När den är cachad är det mycket snabbare på efterföljande laddningar.
Ett annat tips för att påskynda DNS är att använda DNS-prefetching. Detta gör det möjligt för webbläsaren att utföra DNS-uppslagningar på en sida i bakgrunden. Du kan göra det genom att lägga till några rader kod i sidhuvudet 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">
Eller om du kör WordPress version 4.6 eller nyare, kanske du vill använda recource hints Utvecklare kan använda wp_resource_hints-filtret för att lägga till egna domäner och webbadresser för dns-prefetch, preconnect, prefetch eller prerender.
SSL (lila)
Den lila statusfärgen står för den tid som din webbläsare tar för att göra ett SSL/TLS-handslag. När du kör en webbplats över HTTPS betyder det att det finns ett SSL-certifikat involverat och extra tid på grund av krypteringsprocessen (SSL/TLS-handslag). På vår exempeldomän har vi ett certifikat på både vår webbserver på Kinsta och vårt CDN, KeyCDN. Så det finns en SSL-förhandlingstid på både den ursprungliga HTML-doc-laddningen från webbservern och våra tillgångar.
Medan det finns en liten overhead för att köra HTTPS, är den mycket försumbar nu tack vare HTTP/2, vilket är ett nytt protokoll som hjälper till att snabba på webben! På grund av webbläsarstöd krävs HTTPS för att använda HTTP/2. Kolla in vår ultimata guide till HTTP/2.
Det är också viktigt att notera att inte ens under 2018 stöder alla leverantörer HTTP/2 ännu. Detta inkluderar både från webbhotell- och CDN-sidan. Så när du letar efter hosting och CDN, se till att båda stöder det! Kinsta är stolta över att stödja HTTP/2 för alla sina WordPress-kunder.
Från och med mitten av 2018 uppgraderade Pingdom äntligen sitt verktyg för att använda Chrome 60 och högre. Du kan se user-agent som används i begäran-rubriken. Tidigare använde de Chrome 39, och Chrome stödde inte HTTP/2 förrän version 49. Så vi är glada att säga att Pingdom-verktyget nu visar alla fördelar med HTTP/2 när du kör dina test! 👏
Anslutning (Blågrön)
Anslutningstiden i Pingdom hänvisar till TCP-anslutningen, eller den totala tid som krävs för att skapa en TCP-anslutning. Du behöver inte egentligen förstå hur det fungerar, men det här är helt enkelt en kommunikationsmetod mellan värd/klient och servern som måste äga rum.
Vänta (Gul)
Väntetiden i Pingdom hänvisar faktiskt till tiden till första byte, även känd som TTFB i vissa verktyg. TTFB är ett mått som används som en indikation på responsen hos en webbserver eller annan nätverksresurs. Generellt är allt under 100 ms. acceptabelt och bra ttfb. Om du närmar dig 300–400 ms.-intervallet kan du ha något fel konfigurerat på din server eller det kan vara dags att uppgradera till en bättre webblösning.
Det enklaste sättet att minska din TTFB? De bästa två sätten är effektiv WordPress-cachning och ett CDN. Så låt oss köra ett par tester.
TTFB utan WordPress-värdcache
Vi körde först ett test efter att ha rensat cacheminnet på vår WordPress-webbplats. Det betyder att det måste ladda cacheminnet igen. Som du kan se var vår totala laddningstid 541 ms. och TTFB (väntetid) på vår ursprungliga begäran var 185,2 ms.
TTFB med WordPress-värdcache
Vi körde sedan testet igen. Det servas nu direkt från cache. Som ni kan se sjönk våra totala laddningstider ner till 392 ms. och TTFB på den ursprungliga begäran är nu 52.8 ms.! Det är den skillnaden som cachning kan göra.
Om du har en webbplats som betjänar besökare i olika delar av landet, eller runt om i världen, är det andra enkla sättet att drastiskt minska din TTFB att använda ett CDN. Vi körde igen några tester för att visa skillnaden.
TTFB utan CDN
Vi körde först ett test med vårt CDN inaktiverad och som du kan se var vår totala laddningstid 1,93 s och vår genomsnittliga TTFB på en tillgång var runt 176 ms.
TTFB med CDN
Vi aktiverade sedan vårt CDN och körde testet igen. Som du kan se sjönk våra totala laddningstider ner till 1.21 s och vår genomsnittliga TTFB på en CDN-tillgång är nu 4.6 ms.! Vilken skillnad ett CDN kan göra.
En annan viktig sak att notera är att vi valde ”Stillahavsregionen – Australien – Sydney”-platsen för att utföra detta test. Varför? För att vi ville visa dig den verkliga förbättringen som kan göras. Vår WordPress-webbplats i detta exempel är hostad på Kinsta på Google Cloud och har ett centralt läge i USA. Genom att utföra testet mot Australien kan vi visa hur Kinstas CDN-cachning ökar hastigheten och minskar TTFB.
Och naturligtvis är att ha en bra WordPress-värd med en genomtänkt arkitektur också avgörande för att sänka din TTFB.
Sänd (Orange) och Ta emot (grön)
Sänd och ta emot-statusen i Pingdom behöver egentligen inte särskilt mycket förklaring. Sändningstiden är helt enkelt den tid det tar för webbläsaren att skicka data till servern. Och mottagningstiden är den tid det tar för webbläsaren att ta emot data från servern. Båda dessa kommer vanligtvis att vara mycket låga eller obefintliga i dina tester.
HTTP Svarsrubriker
Du kan också klicka på en enskild begäran medan du gör din vattenfallsanalys och se HTTP svarsrubriker. Detta ger värdefull information. På skärmen nedan kan vi omedelbart se att saker som gzip är aktiverat på webbservern, och att det serveras från cache (HIT, skulle visa MISS annars), cache-control-rubrikerna, expires-rubriker, webbläsarens användaragent och mer.
Fallstudie Domänkonfiguration
Om du kommit så här långt ner i vårt vattenfallsanalys-inlägg väntar en överraskning. Det är alltid irriterande att se människor dela tips och fallstudier men sedan inte dela hur de kom dit. Så nedan är vår exakta konfiguration för fallstudiedomänen som används ovan! Känn dig fri att härma den.
Arkitektur
- Fallstudiedomänen (perfmatters.io) är hostad på Kinsta på Google Cloud Platform i USA (Council Bluffs, Iowa, USA (us-central1). Kinsta erbjuder för närvarande 37 olika datacenter att välja mellan. GCP:s premiumnivå-nätverk ingår med alla planer för blixtsnabb nätverkslatens.
- Kinsta använder HTTP/2, Nginx, MariaDB, som alla bidrar till de snabba laddningstiderna.
- Webbplatsen använder KeyCDN, som driver Kinstas CDN. Gratis CDN-bandbredd ingår i alla värdplaner.
- Webbplatsen använder inte något cachningsplugin. Kinsta cachar allt på servernivå vilket förenklar saker och ting!
- Webbplatsen använder PHP 7.3. Nyare versioner av PHP har alltid visat bra prestandaförbättringar. Kolla in dessa PHP benchmarks. Kinsta låter dig växla mellan de två med en knapptryckning.
WordPressplugin och Tema
Här är en lista över de plugin som påverkar prestanda som används på WordPress e-handelswebbplatsen.
- Premiumpluginet perfmatters, utvecklad av en teammedlem på Kinsta. Detta gör sig av med onödiga HTTP-förfrågningar som inbäddningar, emojis och har också en script-hanterare för att aktivera/inaktivera vissa skript från att laddas på en per sida/inlägg/webbplatsbasis.
- Premiumpluginet Imagify används för att komprimera bilder.
- Det kostnadsfria pluginet Safe SVG används för att ladda upp SVG-bilder till WordPress-webbplatsen.
- Premiumtemat GeneratePress för WordPress användes för att bygga EDD-webbplatsen.
Rekommenderade handledningar för vidare läsning:
- Så eliminerar du renderingsblockerande JavaScript och CSS
- Så inaktiverar du Emojis i WordPress
- Så inaktiverar du inbäddning i WordPress
- Så får du 100/100 i Google PageSpeed Insights med WordPress
- Så diagnostiseras du Hög Admin-Ajax-Användning på din WordPress-webbplats
Sammanfattning
Som ni kan se, kan kunskap om hur Pingdom Hastighetstestverktyg fungerar lite bättre och vad alla diagram betyder, hjälpa dig att göra ett mer informerat beslut när det gäller prestanda. En vattenfallsanalys som vi kallar det är viktigt för att veta hur dina enskilda tillgångar laddas och hur de påverkas av din WordPress-värd, fysiska plats, CDN, etc. Har du några andra bra Pingdom-tips?
Om du vill se mer djupgående artiklar som den ovan, låt oss veta nedan i kommentarerna!
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