Två sidor kan få exakt samma poäng i ett hastighetstest och ändå fungera helt olika för verkliga besökare. Att köra ett test är enkelt. Att tolka resultatet rätt är det som får de flesta att fastna: vilka siffror som spelar roll, vad de egentligen mäter och var du hittar data från verkliga besökare i stället för simulerade poäng. Den här artikeln går igenom hur du kör ett hastighetstest, vad varje mätvärde betyder, varför simulerade poäng och verkliga poäng ofta skiljer sig åt och hur du använder resultaten för förbättringar som faktiskt märks för dina besökare.
Ett hastighetstest är mest användbart när du vet vad du ska göra med resultatet. En ensam poäng av 100 säger väldigt lite. Det är de enskilda mätvärdena bakom poängen, och om de kommer från en simulering eller från verkliga besökare, som avgör om resultatet speglar vad dina besökare upplever. Läs mer om vad mätvärdena mäter i artikeln vad sidladdningstid är och hur den mäts.
Vad mäter ett hastighetstest egentligen?
Ett hastighetstest laddar en sida i en kontrollerad miljö och registrerar hur lång tid olika delar av laddningen tar. Verktyget mäter bland annat hur snabbt servern svarar, när det första innehållet syns på skärmen, när det största synliga elementet är färdigladdat, hur mycket layouten hoppar under laddningen och hur lång tid det går innan sidan reagerar på klick. Måtten jämförs sedan med standardgränser för att ge en poäng och peka ut vad som kan bli bättre.
Labbdata jämfört med fältdata
- Labbdata: tas fram av ett testverktyg. Sidan laddas från en fast plats med en simulerad enhet och anslutning. Resultaten är kontrollerade och går att upprepa, men de speglar inte hela bredden av verkliga besökares förhållanden
- Fältdata: samlas in från verkliga besökare och summeras över ett rullande fönster på 28 dagar. Det är den data som sökmotorer använder för Core Web Vitals och rankning
- En webbplats kan få 90 i ett labbtest och ändå ha svag fältdata för Core Web Vitals om verkliga besökare använder långsammare enheter, ostabila anslutningar eller befinner sig långt från servern
- Kolla alltid båda. Labbdata är bra för att hitta specifika problem. Fältdata avgör den verkliga effekten och påverkan på rankningen
Hur kör du ett hastighetstest på rätt sätt?
Testa mobilen först
- Sökmotorer använder mobile-first indexing, vilket betyder att de bedömer sidor utifrån hur de fungerar på mobil
- Mobilpoängen är nästan alltid lägre än datorpoängen för samma sida, eftersom mobiler har långsammare processorer och mer varierande anslutningar
- Kör både mobil- och datortest, men se mobilresultatet som ditt viktigaste mått
Testa dina mest besökta sidor, inte bara startsidan
- Startsidan är ofta den snabbaste sidan på en webbplats eftersom den brukar ha färre bilder och skript än andra sidor
- Produktsidor, blogginlägg och landningssidor får ofta betydligt sämre resultat och kan påverka besöksupplevelsen och rankningen mer
- Testa sidorna som får mest trafik, inte de som troligast ser bra ut
Kör varje test mer än en gång
- Resultaten i labbtester kan variera mellan körningar på grund av serverbelastning just då, nätverksförhållanden på testplatsen och cachelagring
- Kör varje test två eller tre gånger och använd medelvärdet som utgångsnivå i stället för att lita på ett enda resultat
Testa före och efter ändringar
- Ta fram en utgångspoäng innan du ändrar något på webbplatsen
- Kör samma test efter varje förbättring för att mäta just dess effekt
- För fältdata: vänta minst 28 dagar efter ändringar innan du bedömer effekten, eftersom datan är ett rullande medelvärde över 28 dagar som uppdateras gradvis
Hur tolkar du ett hastighetstest?
Börja med mätvärdena som misslyckas, inte totalpoängen
- En totalpoäng på 65 säger inte vad du ska åtgärda. Det gör de enskilda mätvärdena som underkänns
- Titta på vilka Core Web Vitals som ligger i intervallet behöver förbättras eller dåligt: LCP, INP och CLS
- Varje underkänt mätvärde pekar mot en annan del av sidan eller laddningsprocessen att undersöka
Vad varje underkänt mätvärde pekar på
- Hög Time to First Byte: serversvaret är långsamt. Undersök kvaliteten på webbhotellet, cachelagring på servern och databasens prestanda
- Långsam Largest Contentful Paint: det viktigaste synliga elementet tar för lång tid att laddas. Orsakas oftast av ooptimerade bilder, resurser som blockerar rendering eller ett långsamt serversvar
- Hög Total Blocking Time eller dålig Interaction to Next Paint: JavaScript blockerar huvudtråden. Stora skriptfiler och skript från tredje part är vanliga orsaker
- Hög Cumulative Layout Shift: element byter plats medan sidan laddas. Orsakas av bilder utan angivna mått, innehåll som laddas sent och läggs in ovanför befintliga element, eller banners som läggs till dynamiskt
Läs rekommendationerna
- Hastighetsverktyg listar konkreta rekommendationer tillsammans med en uppskattad tidsvinst för varje åtgärd
- Börja med rekommendationerna som ger störst uppskattad vinst, så får du mest effekt för varje insats
- Vissa rekommendationer gäller skript eller tjänster från tredje part som du inte styr över. Notera dem, men fokusera på det du kan ändra
Vad är bra poäng i ett hastighetstest?
Gränser för Core Web Vitals
- Largest Contentful Paint under 2,5 sekunder: bra
- Interaction to Next Paint under 200 millisekunder: bra
- Cumulative Layout Shift under 0,1: bra
Intervall för totalpoäng
- 90 till 100: bra
- 50 till 89: behöver förbättras
- 0 till 49: dåligt
Så använder du riktvärden i praktiken
- Det här är absoluta riktvärden, men din poäng behöver vara bättre än sidorna du konkurrerar med om samma sökord, inte bara över en generell gräns
- Sök på ditt viktigaste sökord och kör hastighetstest på sidorna som rankar över dig. Om din LCP är 3,2 sekunder och deras är 2,1 sekunder är den skillnaden lättare att agera på än en poängskillnad i sig
En detaljerad genomgång av vad LCP, INP och CLS mäter och hur de poängsätts finns i artikeln vad Core Web Vitals är.
Hur följer du webbplatsens hastighet över tid?
Ta fram en utgångsnivå innan du börjar optimera
- Anteckna dina nuvarande poäng för sidorna du tänker förbättra innan du ändrar något
- Notera vilka mätvärden som underkänns och med hur mycket
- Kör testerna igen efter varje omgång ändringar och jämför med utgångsnivån för att mäta verklig förbättring
Kolla fältdata regelbundet, inte bara efter ändringar
- Fältdata i prestandarapporter uppdateras i ett rullande fönster på 28 dagar
- Kolla den en gång i månaden, eller efter varje större ändring av innehåll, kod eller webbhotell
- En nedgång i fältdata sammanfaller ofta med att en ny stor bild lagts till, ett nytt skript från tredje part installerats eller att inställningarna hos webbhotellet ändrats
Testa efter att du publicerat nytt innehåll
- Ett nytt blogginlägg med ooptimerade bilder kan göra just den sidan märkbart långsammare utan att påverka andra
- En ny landningssida med tunga skript kan skapa blockeringsproblem som ett test av startsidan aldrig skulle avslöja
- Om hastighetstest ingår i publiceringsrutinen hopar sig inte försämringarna obemärkt
En komplett guide till de mest effektiva förbättringarna utifrån dina testresultat finns i artikeln så minskar du webbplatsens laddningstid. För problem som rör bilder specifikt, läs artikeln så optimerar du bilder för snabbare laddning.
Så hjälper WEMASY dig att testa hastigheten
WEMASY:s analysöversikt innehåller data för Core Web Vitals för alla sidor som byggts på plattformen, hämtad från fältdata från verkliga besökare. Poängen för LCP, INP och CLS syns per sida utan att du behöver köra externa tester. Sidor som hamnar under gränsen för bra markeras med det mätvärde som misslyckas, så att du kan gå direkt till problemet i stället för att läsa en hel rapport.
Eftersom plattformen sköter bildkomprimering, cachelagring, minifiering och CDN-leverans automatiskt är de vanligaste orsakerna som externa hastighetstest pekar ut redan åtgärdade. Ett hastighetstest av en webbplats byggd i WEMASY visar därför oftast problem i själva innehållet och inte på plattformsnivå, vilket gör resultaten lättare att agera på.
Se vad som ingår i WEMASY webbplatsbyggare, eller jämför planerna på prissidan.
Vanliga frågor
Hur testar jag hastigheten på min webbplats?
Ange webbplatsens webbadress i ett hastighetsverktyg. Verktyget laddar sidan under kontrollerade förhållanden och ger poäng för varje laddningsmått, för både mobil och dator. Titta på poängen för de enskilda mätvärdena tillsammans med totalpoängen: de som underkänns visar var du ska lägga fokus. För prestandadata från verkliga besökare kan du titta i webbplatsens analys, om den innehåller fältdata för Core Web Vitals. Med WEMASY:s webbplatsbyggare kan du ställa in det direkt på din webbplats.
Vad är en bra hastighetspoäng för en webbplats?
90 eller högre räknas som bra, 50 till 89 behöver förbättras och under 50 är dåligt. För Core Web Vitals är målen Largest Contentful Paint under 2,5 sekunder, Interaction to Next Paint under 200 millisekunder och Cumulative Layout Shift under 0,1. En sida klarar bedömningen av Core Web Vitals först när alla tre mätvärdena ligger i det bra intervallet enligt fältdata från verkliga besökare.
Varför varierar poängen i mitt hastighetstest mellan körningar?
Poängen i labbtester varierar eftersom förhållandena ändras mellan körningar: serverbelastningen just då, nätverksförhållandena på testleverantörens plats och cachelagring påverkar alla resultatet. Om du kör testet flera gånger och tar medelvärdet får du en mer pålitlig utgångsnivå. Fältdata, som bygger på 28 dagars mätningar från verkliga besökare, är stabilare och en bättre indikator på jämn prestanda för rankningen.
Varför är min mobilpoäng lägre än min datorpoäng?
Hastighetstest för mobil simulerar långsammare processorer och mobilnät, vilket ger lägre poäng för samma sida jämfört med dator. Sökmotorer använder mobile-first indexing, så det är sidans prestanda på mobil som räknas för rankningen. Se mobilpoängen som huvudresultatet att optimera för, även om datorpoängen ser acceptabel ut.
Vad är skillnaden mellan labbdata och fältdata i ett hastighetstest?
Labbdata kommer från en simulerad testkörning under kontrollerade förhållanden från en fast plats och enhet. Den är jämn och användbar för att hitta specifika problem. Fältdata kommer från verkliga besökare, summeras över ett rullande fönster på 28 dagar och speglar hela bredden av enheter, anslutningar och platser som dina besökare använder. Sökmotorer använder fältdata för Core Web Vitals. En webbplats kan få bra poäng i ett labbtest och ändå ha svag fältdata om besökarnas verkliga förhållanden skiljer sig mycket från testmiljön.
Hur ofta bör jag köra ett hastighetstest?
Kör ett hastighetstest efter varje större ändring av webbplatsen: när du lägger till stora bilder, installerar nya skript, byter webbhotell eller publicerar en ny sidtyp. För löpande uppföljning räcker det att gå igenom fältdata i analysen eller prestandaöversikten en gång i månaden. Fältdata uppdateras i ett rullande fönster på 28 dagar, så täta manuella tester behövs inte, men månatliga genomgångar hjälper dig upptäcka försämringar innan de påverkar rankningen eller besöksupplevelsen.