Gratis verktøy: Ytelse

Hastighetstest for nettsiden din

Vi laster inn siden din som en mellomklassetelefon på en treg 4G-forbindelse, måler hvor raskt hovedinnholdet vises og hvor mye siden hopper, og viser hva som gjør den tung. Når Google har data fra ekte brukere for nettstedet ditt, ser du dem også.

Gratis. Vanligvis ferdig på under ett minutt.

Hva verktøyet sjekker

  • En telefon på treg 4G

    Siden lastes i Chromium som en telefon i Moto G Power-klassen (412 × 823) med 150 ms latens, rundt 1,6 Mbps ned og 750 Kbps opp, og en CPU som er 4× tregere. Dette er profilen Lighthouse bruker for mobiltester.

  • Largest Contentful Paint

    Når det største bildet eller den største tekstblokken i det første skjermbildet var ferdig gjengitt, og hvilket element det var.

  • Cumulative Layout Shift

    Hvor mye synlig innhold som flyttet seg uventet mens siden ble lastet inn.

  • Total Blocking Time

    Hvor lenge skript holdt nettleseren for opptatt til å reagere på et trykk: den delen av hver lange oppgave som går over 50 ms, lagt sammen. Den er labtestens stedfortreder for Interaction to Next Paint.

  • Hva siden laster ned

    Totalt antall byte og forespørsler, fordelt på bilder, skript, CSS og fonter, og andelen som kommer fra tredjeparter.

  • Tunge bilder og gjengivelsesblokkerende filer

    Bilder over 150 KB eller langt bredere enn plassen de vises i, og CSS- og skriptfilene som holder igjen den første gjengivelsen.

  • Data fra ekte brukere i Chrome

    Googles Chrome UX Report for opprinnelsen (origin) din på telefoner ved 75. persentil: LCP, INP og CLS, når Google har nok trafikk for nettstedet.

Hva det ikke kan sjekke

  • Gi de samme tallene hver gang. Labresultater varierer med nettverket, serverbelastningen og tredjepartsskript, så sammenlign trender i stedet for enkeltkjøringer.
  • Samsvare nøyaktig med PageSpeed Insights. Begge bruker en lignende telefonprofil, men kjører på ulike maskiner og nettverk.
  • Måle INP i labtesten. INP krever ekte interaksjoner, så labtesten viser TBT, og feltdataene viser INP når de finnes.
  • Vise feltdata for alle nettsteder. Chrome UX Report dekker de siste 28 dagene og bare opprinnelser med nok Chrome-trafikk.
  • Teste mer enn den ene siden du skriver inn. Den betalte ytelsesrapporten tester 3 viktige sider og rangerer årsakene med løsninger.

Hvorfor det er viktig

En side som føles umiddelbar på kontorets wifi og en rask bærbar PC, kan ta flere sekunder på en mellomklassetelefon med svakt signal. Det er den situasjonen denne testen gjenskaper, fordi det er der tunge bilder og skript gjør mest skade.

Core Web Vitals er Googles mål på den opplevelsen: lasting (LCP), respons (INP) og visuell stabilitet (CLS). Google bruker dem i rangeringen, men sier at en god sideopplevelse ikke veier tyngre enn relevant innhold. Den største effekten har de på mennesker: en treg eller hoppende side mister besøkende før de har lest noe.

Årsakene er som regel konkrete: et ukomprimert toppbilde på flere megabyte, en chat-widget som lastes før innholdet, en webfont som skjuler tekst, eller et banner som settes inn over siden etter at den har blitt vist. Testen navngir LCP-elementet og de tyngste filene, så du ser hvilken av disse som gjelder.

Slik leser du resultatene

Largest Contentful Paint (LCP)
God under 2,5 s, dårlig over 4 s. Hvis LCP-elementet er et bilde, betyr størrelsen og lasteprioriteten mest; hvis det er tekst, bør du se på webfonter og gjengivelsesblokkerende CSS.
Cumulative Layout Shift (CLS)
God under 0,1, dårlig over 0,25. En verdi uten enhet som kombinerer hvor mye av skjermen som flyttet seg, og hvor langt.
Total Blocking Time (TBT)
God under 200 ms, dårlig over 600 ms. En høy TBT varsler trege reaksjoner på trykk for ekte brukere.
Byte og forespørsler
Det finnes ingen offisiell grense; se på hvilken type som dominerer. Bilder er som regel den største andelen, og en høy tredjepartsandel peker mot apper, tagger og widgeter.
Tunge bilder
Hvert bilde over 150 KB, eller som lastes ned langt bredere enn det vises, med filstørrelse og dimensjoner.
Gjengivelsesblokkerende filer
CSS og synkrone skript som nettleseren må laste ned før den kan vise noe som helst.
Feltdata (75. persentil)
Ekte Chrome-brukere på telefoner de siste 28 dagene. 75. persentil betyr at tre av fire sideinnlastinger var minst så raske. INP er god under 200 ms og dårlig over 500 ms.
Ingen feltdata
Google har ikke nok Chrome-trafikk for opprinnelsen din. Det sier ingenting om hastigheten din; støtt deg på labresultatene.

Slik fikser du de vanligste problemene

  • Et tregt LCP-bilde

    Lever toppbildet i den størrelsen det vises i, med srcset, i WebP eller AVIF. Ikke bruk lazy loading på det, legg til fetchpriority="high", og legg det i HTML-en som et img-element i stedet for å laste det fra et skript eller som CSS-bakgrunn.

  • Innhold som hopper mens siden lastes

    Gi bilder, videoer og innbygginger width- og height-attributter eller en CSS aspect-ratio. Sett av plass til bannere, cookie-varsler og annonser, eller vis dem som overlegg som ikke skyver innholdet ned. For webfonter bruker du font-display: optional eller en reservefont med tilpasset størrelse.

  • Høy Total Blocking Time

    Fjern først apper, tagger og utvidelser du ikke lenger bruker; skriptene deres blir ofte liggende etter at du har sluttet å bruke dem. Last inn chat, anmeldelser og analyse med defer eller etter at siden er interaktiv. I Shopify sjekker du Nettbutikk › Temaer › Tilpass › Appinnbygginger (Online Store › Themes › Customize › App embeds).

  • Gjengivelsesblokkerende CSS og skript

    Legg til defer på skript som ikke trenger å kjøre før første opptegning, legg den lille mengden CSS som det første skjermbildet trenger, direkte inn i HTML-en (inline), og fjern stilark for funksjoner som siden ikke bruker.

  • Bilder som er for tunge

    Endre størrelsen på bilder før du laster dem opp (rundt 2000 px bredde er mer enn nok for et banner i full bredde), og komprimer dem. Shopify og WordPress kan levere mindre versjoner automatisk når temaet ber om dem, så sjekk at temaet ditt bruker responsive bildestørrelser.

Spørsmål om verktøyet

Hvorfor er resultatene mine annerledes enn i PageSpeed Insights?

Labtester avhenger av maskinen, nettverket og øyeblikket. PageSpeed Insights kjører Lighthouse på Googles servere og simulerer den trege forbindelsen, mens vi bruker strupingen (throttling) i en ekte nettleser. Forvent lignende spenn, ikke identiske tall.

Hva er en god LCP?

2,5 sekunder eller mindre for minst 75 % av sideinnlastingene, ifølge web.dev. Over 4 sekunder er dårlig.

Hvorfor finnes det ingen data fra ekte brukere for nettstedet mitt?

Chrome UX Report tar bare med opprinnelser som er offentlig synlige og får nok besøk fra Chrome-brukere som deler bruksstatistikk. Mange små nettsteder når ikke det nivået; labtesten viser likevel hva som bør rettes.

Hvorfor teste på en treg telefon i stedet for på en datamaskin?

Fordi problemene viser seg der først. En rask bærbar PC skjuler tunge bilder og skript som koster flere sekunder på en mellomklassetelefon, og Lighthouse bruker den samme telefonprofilen for sine mobiltester.

Hva skjedde med First Input Delay?

Interaction to Next Paint (INP) erstattet First Input Delay som Core Web Vital i mars 2024. INP ser på forsinkelsen i interaksjoner gjennom hele besøket, ikke bare den første.

Kilder

Relaterte verktøy

«Ytelsesrapport» ($55, engangspris) bygger på hele den gratis skanningen og legger til flere sider, endringen du skal gjøre for hvert funn, en PDF og kontrolltester som bekrefter utbedringene dine.

Les mer om «Ytelsesrapport»