Gratisverktyg: Prestanda

Hastighetstest för din hemsida

Vi laddar din sida som en mellanklassmobil på en långsam 4G-anslutning, mäter hur snabbt huvudinnehållet visas och hur mycket sidan hoppar, och visar vad som gör den tung. När Google har data från riktiga användare för din webbplats ser du dem också.

Gratis. Brukar vara klart på under en minut.

Det här kontrollerar verktyget

  • En mobil på långsamt 4G

    Sidan laddas i Chromium som en mobil i Moto G Power-klassen (412 × 823) med 150 ms latens, cirka 1,6 Mbit/s nedströms och 750 kbit/s uppströms, och en 4× långsammare processor. Det är den profil som Lighthouse använder för mobiltester.

  • Largest Contentful Paint

    När den största bilden eller det största textblocket på den första skärmen hade renderats klart, och vilket element det var.

  • Cumulative Layout Shift

    Hur mycket synligt innehåll som flyttade sig oväntat medan sidan laddades.

  • Total Blocking Time

    Hur länge skripten höll webbläsaren för upptagen för att svara på ett tryck: den del av varje lång uppgift som överstiger 50 ms, sammanlagt. Det är labbtestets ersättare för Interaction to Next Paint.

  • Vad sidan laddar ner

    Totalt antal byte och förfrågningar, uppdelat på bilder, skript, CSS och typsnitt, och den andel som kommer från tredje part.

  • Tunga bilder och renderingsblockerande filer

    Bilder över 150 KB eller mycket bredare än ytan de visas i, och de CSS- och skriptfiler som håller tillbaka den första renderingen.

  • Data från riktiga användare i Chrome

    Googles Chrome UX Report för ditt ursprung på mobiler vid den 75:e percentilen: LCP, INP och CLS, när Google har tillräckligt med trafik för webbplatsen.

Det här kan det inte kontrollera

  • Ge samma siffror vid varje körning. Labbresultat varierar med nätverket, serverbelastningen och tredjepartsskript, så jämför trender snarare än enskilda körningar.
  • Stämma exakt med PageSpeed Insights. Båda använder en liknande mobilprofil men körs på olika maskiner och nätverk.
  • Mäta INP i labbet. INP kräver verkliga interaktioner, så labbtestet visar TBT och fältdata visar INP när sådana finns.
  • Visa fältdata för varje webbplats. Chrome UX Report omfattar de senaste 28 dagarna och bara ursprung med tillräckligt mycket trafik från Chrome.
  • Testa mer än den enda sida du anger. Den betalda Prestandarapporten testar 3 viktiga sidor och rangordnar orsakerna med åtgärder.

Därför spelar det roll

En sida som känns blixtsnabb på kontorets wifi och en snabb bärbar dator kan ta flera sekunder på en mellanklassmobil med svag signal. Det är den situationen som testet återskapar, eftersom det är där tunga bilder och skript gör mest skada.

Core Web Vitals är Googles mått på den upplevelsen: laddning (LCP), respons (INP) och visuell stabilitet (CLS). Google använder dem i rankingen, men säger att en bra sidupplevelse inte väger tyngre än relevant innehåll. Den större effekten gäller människor: en långsam eller hoppig sida tappar besökare innan de hunnit läsa något.

Orsakerna är oftast konkreta: en okomprimerad toppbild på flera megabyte, en chattwidget som laddas före innehållet, ett webbtypsnitt som döljer text eller en banner som infogas ovanför sidan efter att den har visats. Testet pekar ut LCP-elementet och de tyngsta filerna så att du kan se vilket av detta som gäller.

Så läser du resultaten

Largest Contentful Paint (LCP)
Bra under 2,5 s, dåligt över 4 s. Om LCP-elementet är en bild spelar dess storlek och laddningsprioritet störst roll; om det är text, titta på webbtypsnitt och renderingsblockerande CSS.
Cumulative Layout Shift (CLS)
Bra under 0,1, dåligt över 0,25. Ett poängtal utan enhet som kombinerar hur stor del av skärmen som flyttade sig och hur långt.
Total Blocking Time (TBT)
Bra under 200 ms, dåligt över 600 ms. En hög TBT förutsäger långsamma svar på tryck för riktiga användare.
Byte och förfrågningar
Det finns ingen officiell gräns; titta på vilken typ som dominerar. Bilder står oftast för den största andelen, och en hög andel från tredje part pekar på appar, taggar och widgets.
Tunga bilder
Varje bild över 150 KB, eller som laddas ner mycket bredare än den visas, med filstorlek och mått.
Renderingsblockerande filer
CSS och synkrona skript som webbläsaren måste ladda ner innan den kan visa något.
Fältdata (75:e percentilen)
Riktiga Chrome-användare på mobiler under de senaste 28 dagarna. Den 75:e percentilen betyder att tre av fyra sidladdningar var minst så här snabba. INP är bra under 200 ms och dåligt över 500 ms.
Inga fältdata
Google har inte tillräckligt med trafik från Chrome för ditt ursprung. Det säger ingenting om din hastighet; förlita dig på labbresultaten.

Så åtgärdar du de vanligaste problemen

  • En långsam LCP-bild

    Leverera toppbilden i den storlek den visas med srcset, i WebP eller AVIF. Använd inte lazy loading för den, lägg till fetchpriority="high" och lägg den i HTML-koden som ett img-element i stället för att ladda den från ett skript eller som CSS-bakgrund.

  • Innehåll som hoppar under laddningen

    Ge bilder, videor och inbäddningar width- och height-attribut eller ett CSS aspect-ratio. Reservera plats för banners, cookiemeddelanden och annonser, eller visa dem som överlägg som inte trycker ner innehållet. För webbtypsnitt, använd font-display: optional eller ett reservtypsnitt med matchande storlek.

  • Hög Total Blocking Time

    Ta först bort appar, taggar och tillägg som du inte längre använder; deras skript ligger ofta kvar efter att du slutat använda dem. Ladda chatt, recensioner och analysverktyg med defer eller efter att sidan har blivit interaktiv. I Shopify, kontrollera Onlinebutik › Teman › Anpassa › Appinbäddningar (Online Store › Themes › Customize › App embeds).

  • Renderingsblockerande CSS och skript

    Lägg till defer på skript som inte behöver köras före den första renderingen, lägg den lilla mängd CSS som den första skärmen behöver direkt i HTML-koden (inline) och ta bort stilmallar för funktioner som sidan inte använder.

  • Bilder som är för tunga

    Ändra storlek på bilderna innan du laddar upp dem (cirka 2000 px bredd räcker gott för en banner i full bredd) och komprimera dem. Shopify och WordPress kan automatiskt leverera mindre versioner när temat begär dem, så kontrollera att ditt tema använder responsiva bildstorlekar.

Frågor om verktyget

Varför skiljer sig mina resultat från PageSpeed Insights?

Labbtester beror på maskinen, nätverket och tidpunkten. PageSpeed Insights kör Lighthouse på Googles servrar och simulerar den långsamma anslutningen, medan vi tillämpar strypningen i en riktig webbläsare. Räkna med liknande intervall, inte identiska siffror.

Vad är en bra LCP?

2,5 sekunder eller mindre för minst 75 % av sidladdningarna, enligt web.dev. Över 4 sekunder är dåligt.

Varför finns det inga data från riktiga användare för min webbplats?

Chrome UX Report omfattar bara ursprung som är offentligt upptäckbara och får tillräckligt många besök från Chrome-användare som delar användningsstatistik. Många små webbplatser når inte den nivån; labbtestet visar ändå vad du ska åtgärda.

Varför testa på en långsam mobil i stället för en dator?

Eftersom problemen visar sig där först. En snabb bärbar dator döljer tunga bilder och skript som kostar sekunder på en mellanklassmobil, och Lighthouse använder samma mobilprofil för sina mobiltester.

Vad hände med First Input Delay?

Interaction to Next Paint (INP) ersatte First Input Delay som Core Web Vital i mars 2024. INP tittar på fördröjningen för interaktioner under hela besöket, inte bara den första.

Källor

Relaterade verktyg

Vår Prestandarapport ($55, engångspris) utgår från den fullständiga gratisskanningen och lägger till fler sidor, ändringen som ska göras för varje fynd, en PDF och omtester för att verifiera dina åtgärder.

Läs mer om vår Prestandarapport