Gratis værktøj: Performance

Hastighedstest af din hjemmeside

Vi indlæser din side som en mellemklassetelefon på en langsom 4G-forbindelse, måler, hvor hurtigt hovedindholdet vises, og hvor meget siden hopper, og viser, hvad der gør den tung. Når Google har data fra rigtige brugere for din hjemmeside, ser du også dem.

Gratis. Normalt færdig på under et minut.

Det tjekker værktøjet

  • En telefon på langsom 4G

    Siden indlæses i Chromium som en telefon i samme klasse som Moto G Power (412 × 823) med 150 ms latenstid, cirka 1,6 Mbps download og 750 Kbps upload og en 4× langsommere CPU. Det er den profil, Lighthouse bruger til mobiltest.

  • Largest Contentful Paint

    Hvornår det største billede eller den største tekstblok på den første skærm var færdig med at blive vist, og hvilket element det var.

  • Cumulative Layout Shift

    Hvor meget synligt indhold der flyttede sig uventet, mens siden blev indlæst.

  • Total Blocking Time

    Hvor længe scripts holdt browseren så travlt optaget, at den ikke kunne reagere på et tryk: den del af hver lang opgave, der ligger over 50 ms, lagt sammen. Det er laboratoriets stedfortræder for Interaction to Next Paint.

  • Hvad siden downloader

    Samlet antal bytes og forespørgsler, fordelt på billeder, scripts, CSS og skrifttyper, og den andel, der kommer fra tredjeparter.

  • Tunge billeder og filer, der blokerer gengivelsen

    Billeder over 150 KB eller langt bredere end den plads, de vises i, og de CSS- og scriptfiler, der forsinker den første gengivelse.

  • Data fra rigtige brugere i Chrome

    Googles Chrome UX Report for din oprindelse (origin) på telefoner ved 75. percentil: LCP, INP og CLS, når Google har nok trafik for hjemmesiden.

Det kan det ikke tjekke

  • Give de samme tal ved hver kørsel. Laboratorieresultater varierer med netværket, serverbelastningen og tredjepartsscripts, så sammenlign tendenser frem for enkelte kørsler.
  • Ramme præcis de samme tal som PageSpeed Insights. Begge bruger en lignende telefonprofil, men kører på forskellige maskiner og netværk.
  • Måle INP i laboratoriet. INP kræver rigtige interaktioner, så laboratorietesten viser TBT, og feltdataene viser INP, når de findes.
  • Vise feltdata for alle hjemmesider. Chrome UX Report dækker de seneste 28 dage og kun oprindelser med nok trafik fra Chrome.
  • Teste mere end den ene side, du indtaster. Den betalte Performancerapport tester 3 vigtige sider og prioriterer årsagerne med løsninger.

Hvorfor det er vigtigt

En side, der føles øjeblikkelig på kontorets wifi og en hurtig bærbar, kan tage flere sekunder på en mellemklassetelefon med dårligt signal. Det er den situation, testen genskaber, fordi det er her, tunge billeder og scripts gør mest skade.

Core Web Vitals er Googles mål for den oplevelse: indlæsning (LCP), responsivitet (INP) og visuel stabilitet (CLS). Google bruger dem i rangeringen, men siger, at en god sideoplevelse ikke vejer tungere end relevant indhold. Den største effekt har de på mennesker: en side, der er langsom eller hopper, mister besøgende, før de har læst noget.

Årsagerne er som regel konkrete: et ukomprimeret topbillede på flere megabyte, en chatwidget, der indlæses før indholdet, en webskrifttype, der skjuler tekst, eller et banner, der indsættes over siden, efter at den er blevet vist. Testen angiver LCP-elementet og de tungeste filer, så du kan se, hvilken af disse årsager der gælder.

Sådan læser du resultaterne

Largest Contentful Paint (LCP)
God under 2,5 s, dårlig over 4 s. Hvis LCP-elementet er et billede, betyder dets størrelse og indlæsningsprioritet mest; hvis det er tekst, så se på webskrifttyper og CSS, der blokerer gengivelsen.
Cumulative Layout Shift (CLS)
God under 0,1, dårlig over 0,25. En score uden enhed, der kombinerer, hvor stor en del af skærmen der flyttede sig, og hvor langt.
Total Blocking Time (TBT)
God under 200 ms, dårlig over 600 ms. En høj TBT varsler langsomme reaktioner på tryk for rigtige brugere.
Bytes og forespørgsler
Der er ingen officiel grænse; se på, hvilken type der fylder mest. Billeder udgør som regel den største andel, og en høj andel fra tredjeparter peger på apps, tags og widgets.
Tunge billeder
Hvert billede over 150 KB, eller som downloades langt bredere, end det vises, med filstørrelse og dimensioner.
Filer, der blokerer gengivelsen
CSS og synkrone scripts, som browseren skal downloade, før den kan vise noget.
Feltdata (75. percentil)
Rigtige Chrome-brugere på telefoner i de seneste 28 dage. 75. percentil betyder, at tre ud af fire sidevisninger var mindst så hurtige. INP er god under 200 ms og dårlig over 500 ms.
Ingen feltdata
Google har ikke nok trafik fra Chrome for din oprindelse. Det siger intet om din hastighed; brug laboratorieresultaterne.

Sådan retter du de mest almindelige problemer

  • Et langsomt LCP-billede

    Lever topbilledet i den størrelse, det vises i, med srcset og i WebP eller AVIF. Brug ikke lazy loading på det, tilføj fetchpriority="high", og placer det i HTML’en som et img-element i stedet for at indlæse det fra et script eller som CSS-baggrund.

  • Indhold, der hopper under indlæsningen

    Giv billeder, videoer og indlejret indhold width- og height-attributter eller en CSS-aspect-ratio. Reservér plads til bannere, cookiemeddelelser og annoncer, eller vis dem som overlays, der ikke skubber indholdet ned. Til webskrifttyper kan du bruge font-display: optional eller en reserveskrifttype, der er tilpasset i størrelsen.

  • Høj Total Blocking Time

    Fjern først apps, tags og plugins, du ikke længere bruger; deres scripts bliver ofte liggende, efter at du er holdt op med at bruge dem. Indlæs chat, anmeldelser og analyseværktøjer med defer eller efter, at siden er blevet interaktiv. I Shopify skal du tjekke Online Store › Themes › Customize › App embeds.

  • CSS og scripts, der blokerer gengivelsen

    Tilføj defer til scripts, der ikke behøver at køre før den første visning, indsæt den lille mængde CSS, som den første skærm har brug for, direkte i siden (inline), og fjern stylesheets til funktioner, som siden ikke bruger.

  • Billeder, der er for tunge

    Skalér billeder ned, før du uploader dem (omkring 2000 px i bredden er rigeligt til et banner i fuld bredde), og komprimér dem. Shopify og WordPress kan automatisk levere mindre versioner, når temaet beder om dem, så tjek, at dit tema bruger responsive billedstørrelser.

Spørgsmål om værktøjet

Hvorfor er mine resultater anderledes end i PageSpeed Insights?

Laboratorietest afhænger af maskinen, netværket og tidspunktet. PageSpeed Insights kører Lighthouse på Googles servere og simulerer den langsomme forbindelse, mens vi begrænser forbindelsen (throttling) i en rigtig browser. Forvent lignende intervaller, ikke identiske tal.

Hvad er en god LCP?

2,5 sekunder eller mindre for mindst 75 % af sidevisningerne ifølge web.dev. Over 4 sekunder er dårligt.

Hvorfor er der ingen data fra rigtige brugere for min hjemmeside?

Chrome UX Report omfatter kun oprindelser, der er offentligt tilgængelige og får nok besøg fra Chrome-brugere, der deler brugsstatistik. Mange små hjemmesider når ikke det niveau; laboratorietesten viser stadig, hvad der skal rettes.

Hvorfor teste på en langsom telefon i stedet for en computer?

Fordi problemerne viser sig der først. En hurtig bærbar skjuler tunge billeder og scripts, der koster sekunder på en mellemklassetelefon, og Lighthouse bruger den samme telefonprofil til sine mobiltest.

Hvad skete der med First Input Delay?

Interaction to Next Paint (INP) erstattede First Input Delay som Core Web Vital i marts 2024. INP ser på forsinkelsen ved interaktioner gennem hele besøget, ikke kun ved den første.

Kilder

Relaterede værktøjer

Performancerapport ($55, engangsbetaling) bygger videre på den fulde gratis scanning og tilføjer flere sider, ændringen til hvert fund, en PDF og gentests, så du kan bekræfte dine rettelser.

Om Performancerapport