Web · Hastighed
Core Web Vitals
og arbejdet bag
LCP, INP og CLS, målt hos rigtige brugere
Core Web Vitals er Googles tre målinger af, hvordan en side opleves af rigtige besøgende: hvor hurtigt hovedindholdet vises (LCP), hvor hurtigt siden reagerer på input (INP), og hvor meget layoutet flytter sig (CLS). A+A Media & Events i København diagnosticerer dem ud fra dine egne feltdata, ikke en laboratoriescore, og retter årsagerne i prioriteret rækkefølge.
I hastighedsarbejdet
Fra diagnose
til dokumenteret gevinst
Et forløb om hastighed dækker de seks områder nedenfor. Skift af hosting, platformskift og at bygge skabeloner om fra bunden er separate opgaver, som afgrænses, når diagnosen viser, at der er brug for dem.
Spørgsmål om hastighed
Scorer, feltdata
og reel hastighed
Fordi en PageSpeed-score er en laboratorietest på én simuleret enhed, mens Core Web Vitals bedømmes ud fra det, dine rigtige besøgende oplever.
Laboratorietesten indlæser en enkelt side én gang under faste forhold, ofte uden det cookiebanner, den chatwidget eller det personaliserede indhold, som rigtige besøgende får. Rigtige besøgende bruger ældre telefoner, overbelastede mobilnetværk og sider, de når frem til efter at have interageret med hjemmesiden. Feltdata fra Chrome User Experience Report, som vises i Google Search Console og øverst i PageSpeed Insights, indfanger den virkelighed over 28 dage, og de ser ofte helt anderledes ud end laboratorietallet. Google bruger feltdata til søgning. Det gør vi også: hver diagnose starter med felttallene, og derefter bruges laboratorieværktøjer til at finde årsagen til det, feltdata afslører.
Ja, men kun beskedent: de er en del af Googles signaler for sideoplevelse og løfter ikke svagt indhold op over stærkere indhold.
Hvor to sider er lige relevante, kan en bedre oplevelse hjælpe, og langsomme sider står svagere i konkurrenceprægede resultater. Det stærkeste kommercielle argument er som regel konvertering. En side, der er flere sekunder om at vise sit hovedindhold, mister besøgende, før de har læst et ord, og en side, der hopper under indlæsningen, giver fejltryk og frustration. De tab viser sig som færre henvendelser og en højere reel pris for hvert annonceklik, du sender til siden. Derfor behandler vi Core Web Vitals som et forretningstal først og en søgefaktor dernæst, og vi rapporterer forbedringer sammen med konverteringsdata, hvor du har dem.
Google vurderer en side som god, når dens largest contentful paint er 2,5 sekunder eller mindre, dens interaction to next paint er 200 millisekunder eller mindre, og dens cumulative layout shift er 0,1 eller mindre.
Grænserne gælder for 75. percentil af rigtige besøg, så mindst tre fjerdedele af de besøgende skal have den oplevelse, ikke kun den gennemsnitlige. Mellem god og dårlig ligger et bånd markeret som behov for forbedring: LCP op til 4 sekunder, INP op til 500 millisekunder og CLS op til 0,25. Resultaterne opgøres separat for mobil og desktop, og mobil er som regel den sværeste at bestå. En side består kun vurderingen, når alle tre målinger er gode. Vi sætter mål med en vis margin under grænserne, fordi feltdata bevæger sig, når trafik og indhold ændrer sig.
Interaction to next paint (INP) måler, hvor hurtigt en side synligt reagerer på hvert klik, tryk og tastetryk under et besøg, og Google gjorde det til en Core Web Vital i marts 2024 i stedet for first input delay (FID).
FID målte kun forsinkelsen, før browseren begyndte at håndtere den allerførste interaktion, og den bestod de fleste hjemmesider let, selv om de stadig føltes træge senere. INP ser på alle interaktioner og rapporterer en af de langsomste, så den afspejler, hvor responsiv en side reelt føles. Dårlig INP skyldes som regel tung JavaScript: lange opgaver, der blokerer hovedtråden, store frameworks, tag managers, der indlæser mange scripts, og widgets fra tredjeparter. At rette det betyder at dele lange opgaver op, udskyde scripts, der ikke skal bruges med det samme, og fjerne tags, der koster mere, end de giver.
Selve rettelserne tager ofte et par uger, men Googles feltdata skal bruge op til 28 dage på at afspejle dem fuldt ud, så regn med, at resultaterne er bekræftet inden for en til to måneder.
Diagnosen kommer først: vi gennemgår feltdata i Search Console, finder ud af, hvilke sideskabeloner der fejler og hvorfor, og rangerer årsagerne efter effekt. Hurtige gevinster, som at komprimere billeder, forudindlæse hovedbilledet, reservere plads til indlejringer og fjerne ubrugte tags, kan gå live i løbet af dage. Dybere problemer, som en langsom server, et tungt tema eller en sidebygger, der genererer oppustet kode, tager længere tid og peger nogle gange mod en ombygning af de vigtigste skabeloner. Vi følger felttallene ugentligt efter hver udgivelse, så du kan se udviklingen i stedet for at vente på én samlet dom.
Ja, tredjepartsscripts er en af de mest almindelige årsager til langsom indlæsning og dårlig responsivitet, især på telefoner.
Chatwidgets, analytics, annoncepixels, heatmapværktøjer, indlejrede videoer, anmeldelsesbadges og cookiebannere tilføjer hver især kode, som den besøgendes enhed skal hente og køre, og mange indlæser mere, end de behøver. Hver for sig ser de harmløse ud; samlet kan de lægge sekunder til og få siden til at holde op med at reagere på tryk. Vores audit oplister alle tags på hjemmesiden, hvad de koster i indlæsningstid, og hvad de bruges til. Ofte bliver et par stykker ikke længere brugt af nogen, nogle kan indlæses efter hovedindholdet, og andre kan erstattes med lettere versioner. Målet er ikke at fjerne målingerne, men kun at beholde de tags, der er deres vægt værd.
Efter hastighedsarbejdet
Andre måder at
forbedre hjemmesiden
Hurtigere sider får alle andre dele af hjemmesiden til at fungere bedre. Disse ydelser bygger videre på det, fra mobile first-design til den vedligeholdelse, der forhindrer, at hastigheden glider igen.
Mere læsning
om Hastighed, Core Web Vitals og teknisk oprydning
Langsomme sider
Find ud af, hvad
der bremser dig
Send adressen og gerne adgang til Search Console. Vi læser feltdata og fortæller dig, hvilke rettelser der vil gøre den største forskel.