En side føles langsom, men årsagen er ikke altid synlig. Det kan være et stort billede, JavaScript, en langsom server eller indhold, der flytter sig under indlæsningen. Skal du skabe en hurtigere hjemmeside, så mål først, hvor ventetiden eller forstyrrelsen opstår. Ellers risikerer du at bruge tid på ændringer, der ikke løser det mærkbare problem.
Gå fra symptom til målepunkt: Er det første indhold længe om at komme frem, undersøger du indlæsningen. Reagerer siden trægt på klik, ser du på JavaScript og interaktion. Flytter knapper eller tekst sig, måler du layoutstabiliteten. Den rækkefølge retter fejlsøgningen mod det, brugerne oplever, og hjælper med at skelne mellem en langsom fornemmelse og en teknisk flaskehals.
Læs målingerne som tegn på, hvor siden taber fart
Core Web Vitals beskriver forskellige dele af brugeroplevelsen, ikke én samlet karakter for hele hjemmesiden. LCP handler om, hvor hurtigt sidens største synlige indholdselement bliver vist. INP siger noget om sidens reaktion på brugerens handlinger, mens CLS beskriver uventede layoutskift. TTFB måler tiden, indtil browseren modtager det første svar fra serveren, og kan hjælpe med at undersøge server og cache.
Hvilket symptom mærker besøgende? Hvis sidens hovedbillede eller overskrift kommer sent, så undersøg LCP og ressourcerne, der blokerer visningen. Hvis knapper reagerer med forsinkelse, er INP et relevant spor. Hopper indholdet, når siden indlæses, så kig på CLS og elementernes plads i layoutet. En høj TTFB peger på serverens svartid, cache eller den måde, siden bliver dannet på.
Brug målepunkterne sammen. En langsom TTFB kan forsinke resten af indlæsningen, mens et stort billede stadig kan være den direkte årsag til en sen LCP. JavaScript kan også påvirke både interaktion og visning, især hvis det holder browseren beskæftiget. Målingen viser, hvor du bør undersøge nærmere, men ikke altid hvilken fil eller indstilling der skal ændres.
Brug værktøjerne til hvert sit spørgsmål
I Search Console kan du se, om der findes grupper af sider med problemer i Core Web Vitals. CrUX giver indblik i brugeroplevelsen baseret på faktiske besøg, mens Lighthouse analyserer en side under en kontrolleret test. De supplerer hinanden: Search Console giver overblik, CrUX viser oplevelser fra brugere, og Lighthouse peger på forhold, du kan undersøge på en bestemt side.
Vil du se rækkefølgen på netværkskald, er et waterfall nyttigt. Her kan du følge, hvornår dokumenter, billeder, skrifttyper og scripts hentes, og om nogle ressourcer først starter efter andre. I DevTools kan du undersøge netværksaktivitet, konsolbeskeder og JavaScript tættere. Test den samme sidetype under sammenlignelige forhold, og notér hvilken side, testtype og ændring der hører til hver måling.
Resultater fra en laboratorietest og oplevelser fra brugere kan afvige. En test påvirkes blandt andet af netværk, enhed og sidens tilstand, mens CrUX afspejler besøg over tid. Brug derfor ikke et enkelt resultat som facit. Se efter et mønster: Gentager problemet sig på samme sidetype, og peger flere målepunkter mod samme årsag?
På hurtigere-hjemmeside.dk findes trin-for-trin-guides om hastighed på nettet, Core Web Vitals og teknisk SEO. Sitet har korte ordforklaringer på blandt andet LCP, INP, TTFB og CLS samt vejledning om måling med Search Console, CrUX, Lighthouse, waterfall og DevTools. Brug ordbogen til at slå et begreb op, eller følg en guide med tjekliste og målepunkt.
Følg det spor, som symptomet peger på
Billeder og indlæsning
Når hovedindholdet vises sent, så undersøg først det største synlige billede og de ressourcer, der skal hentes, før indholdet kommer frem. Kontrollér billedets format og dimensioner i forhold til den plads, det vises på. Se også efter render-blocking CSS eller scripts, der forsinker den første visning. Et billede kan være optimeret, selv om rækkefølgen for indlæsningen stadig er uhensigtsmæssig.
Efter en ændring skal du måle LCP på samme side igen og kontrollere waterfall-visningen. Se efter, om billedet begynder at blive hentet tidligere, og om noget andet nu forsinker visningen. Notér resultatet, og behold kun ændringen, hvis den forbedrer det relevante målepunkt uden at give nye problemer.
JavaScript og interaktion
Hvis siden reagerer trægt på klik eller tastaturinput, så undersøg hvilke scripts der kører, og hvornår de gør det. DevTools kan vise langvarigt arbejde på hovedtråden og hjælpe med at finde scripts, der optager browseren. Overvej, om funktioner kan indlæses senere, eller om unødvendig kode kan fjernes. Test samtidig de handlinger, besøgende bruger, såsom menu, søgning eller formular.
Brug INP som kontrolpunkt, og gentag de samme handlinger efter ændringen. En hurtigere første visning er ikke nok, hvis interaktionen stadig føles forsinket. Fjern ikke funktioner alene for at ændre et måleresultat; kontrollér, at sidens vigtige funktioner fortsat virker.
Server, cache og layoutskift
Kommer serverens første svar sent, så sammenlign TTFB på forskellige sidetyper og undersøg, om cache rammer som forventet. Se også på, om siden udfører unødvendigt arbejde, før den sender indholdet. Hvis problemet kun optræder på bestemte sider, kan forskelle i indhold, plugins eller forespørgsler vise, hvor fejlsøgningen skal fortsætte.
Ved layoutskift skal du finde det element, der flytter sig. Kontrollér især billeder, annoncer, indlejret indhold og skrifttyper, hvor pladsen måske først bliver reserveret efter indlæsning. Mål CLS efter ændringen, og prøv siden igen med langsom indlæsning. Et stabilt layout mindsker risikoen for, at besøgende rammer et andet element end det, de havde tænkt sig.
Prioritér ændringer efter måling, og gentag testen
Vælg det tydeligste symptom, find det tilhørende målepunkt, og undersøg den mest sandsynlige flaskehals. Lav én ændring ad gangen, og gentag testen på samme sidetype. Skriv ned, hvad du ændrede, hvad du forventede at se, og hvilket resultat der kom. Hvis målepunktet ikke flytter sig, så gå tilbage til waterfall eller DevTools i stedet for at lægge flere gæt oven i hinanden.
Brug en tjekliste, så undersøgelsen kommer omkring de vigtige trin: Hvilket element eller hvilken handling er langsom? Hvilket målepunkt passer til symptomet? Hvilken ressource eller proces ser ud til at forsinke den? Hvad viser målingen efter ændringen? Guides på hurtigere-hjemmeside.dk samler tjeklister og målepunkter om blandt andet billeder, JavaScript, cache, TTFB, CLS og render-blocking. Følg ét afgrænset spor ad gangen frem for at ændre alt på én gang.
Når flere problemer dukker op, så prioritér dem, der påvirker brugeroplevelsen og kan knyttes til en tydelig årsag. En sen LCP for sidens hovedindhold kan for eksempel kræve opmærksomhed før et mindre layoutskift langt nede på siden. Lad målingerne vise rækkefølgen: En hurtigere hjemmeside kommer ikke af flest mulige ændringer, men af ændringer, der løser flaskehalsen, testen afslører.
Gentag kontrollen efter større ændringer, og sammenlign ensartede tests. Hold øje med både brugeroplevelse og funktionalitet, så en forbedring på ét område ikke skjuler en forringelse et andet sted. Når næste skridt bygger på det målte symptom, bliver arbejdet mere præcist og lettere at efterprøve.