Når en bruger første gang forsøger at gøre noget på en side, er det vigtigt, at siden reagerer hurtigt. First Input Delay (FID) måler tiden fra den første interaktion, til browseren kan begynde at behandle handlingen.
Det kan for eksempel være et klik på en knap, et tryk på et link eller et tastetryk i et felt. Målingen handler altså ikke om, hvornår handlingen er helt færdig, men om hvor hurtigt siden bliver klar til at svare.
En lav FID betyder, at siden føles mere responsiv og klar til brug. En høj FID kan derimod få brugeren til at opleve forsinkelse, selv om indholdet allerede ser ud til at være indlæst.
FID ser på, hvor lang tid der går, fra en bruger første gang interagerer med en side, til browseren faktisk kan begynde at behandle handlingen. Det gælder altså ikke hele forløbet frem til det synlige resultat, men ventetiden før behandlingen starter. Målingen handler derfor om, hvor hurtigt siden føles klar til at reagere.
Et input kan for eksempel være et klik på en knap, et tryk på et link eller et tastetryk i et felt. Hvis hovedtråden i browseren er optaget af tung JavaScript, kan siden ikke reagere med det samme. Brugeren har klikket, men intet sker endnu. Det er netop denne forsinkelse, FID registrerer.
Forestil dig en menu på mobil. Brugeren trykker på menuikonet, men browseren er stadig i gang med at udføre andre opgaver. Hvis menuens åbning først begynder 180 millisekunder efter trykket, er det denne ventetid, der måles. Hvor lang tid selve animationen bagefter tager, tæller ikke med i FID. Det samme gælder en knap, der først reagerer sent, selv om handlingen derefter udføres hurtigt.
Derfor siger metrikken noget vigtigt om oplevet reaktionsevne: om siden føles parat, når mennesker forsøger at bruge den, ikke om hele handlingen er afsluttet.
Når en bruger klikker, trykker eller vælger noget på en side, skal browserens hovedtråd have tid til at behandle handlingen. Hvis hovedtråden allerede er optaget af andet arbejde, bliver inputtet sat i kø. Det er kernen i høj First Input Delay: siden ser måske klar ud, men den kan ikke reagere med det samme, fordi de vigtigste processer er blokeret.
Den mest almindelige årsag er tung JavaScript-ydelse. Mange eller store scripts skal hentes, fortolkes og køres, før browseren kan gøre andet. Det gælder især, når JavaScript bruges til mange funktioner på én gang, eller når tredjepartsscripts til for eksempel statistik, annoncer og chat belaster siden. Jo mere arbejde der lægges på hovedtråden, desto større er risikoen for, at brugerens første handling bliver forsinket.
Et beslægtet problem er lange opgaver. Det er opgaver, som kører så længe uden pause, at browseren ikke kan komme til at håndtere nye input hurtigt nok. Lange opgaver opstår ofte ved tunge beregninger, omfattende rendering eller store mængder JavaScript, der afvikles samlet. Virkningen er direkte: brugeren oplever siden som træg eller uresponsiv, selv om indholdet allerede er synligt. Derfor hænger høj FID typisk sammen med en hovedtråd, der er overbelastet netop i det øjeblik, brugeren forsøger at interagere.
For at vurdere FID i praksis skal man bruge feldata, altså målinger fra rigtige brugere på rigtige enheder og netværk. Det skyldes, at First Input Delay først opstår, når en person faktisk forsøger at klikke, trykke eller bruge tastaturet på siden. Uden en reel interaktion findes der ingen FID at måle. Derfor er metrikken tæt knyttet til brugeradfærd og kan ikke fastslås pålideligt i et rent testmiljø.
Det mest almindelige sted at se disse data er i PageSpeed Insights, som viser feldata fra Chrome User Experience Report, også kaldet CrUX. Her kan man få indblik i, hvordan siden præsterer for virkelige brugere over tid, typisk som et 75-percentil for den valgte side eller hele oprindelsen. CrUX er derfor et centralt datagrundlag, når man vil vurdere, om FID er god, bør forbedres eller er dårlig i den virkelige verden.
Laboratorieværktøjer kan stadig bruges som pejlemærke, men med en vigtig begrænsning. google-lighthouse/” data-seo-ordbogen-internal=”1″>Lighthouse måler ikke FID direkte som laboratoriemetrik, netop fordi testen ikke bygger på ægte brugerinput fra mange besøgende. I stedet kan man bruge relaterede målinger til at finde sandsynlige årsager til forsinkelse, for eksempel tung JavaScript-behandling eller travle hovedtråde. Det gør laboratoriedata nyttige til fejlsøgning, mens selve vurderingen af FID skal baseres på feldata.
Som tommelfingerregel er en FID på højst 100 ms god. Ligger den mellem 100 og 300 ms, er der behov for forbedringer. Er den over 300 ms, betragtes den som dårlig og kan mærkes tydeligt af brugeren, især på knapper, menuer og formularer.
Resultatet skal dog læses i sammenhæng. En acceptabel FID betyder ikke nødvendigvis, at siden opleves som hurtig, hvis indholdet vises sent, eller hvis siden hakker under brug. Omvendt kan en side føles rimelig hurtig, men stadig have en problematisk FID på enkelte interaktioner.
Se derfor FID som et mål for respons på første handling, ikke som et samlet mål for sidehastighed. Vurder både tallet og den faktiske brugeroplevelse på tværs af enheder, sider og brugergrupper.
Når man vurderer brugeroplevelsen på en side, er det vigtigt ikke at blande disse målinger sammen. First Input Delay (FID) måler kun forsinkelsen fra brugerens første interaktion, for eksempel et klik eller et tryk, til browseren faktisk begynder at reagere. FID siger altså noget om den første oplevede ventetid, men ikke om hele forløbet bagefter. Målingen har været en del af Core Web Vitals og blev i mange år brugt som et centralt pejlemærke for interaktivitet.
Interaction to Next Paint (INP) går et skridt videre. I stedet for kun at se på den første interaktion vurderer INP den samlede respons på brugerens interaktioner gennem hele besøget. Den ser både på inputforsinkelse, behandlingstid og hvornår næste visuelle opdatering vises. Derfor giver INP som regel et mere retvisende billede af, hvordan en side føles i praksis. En side kan godt have en fin FID, men stadig føles langsom, hvis senere klik eller tastetryk reagerer trægt.
Total Blocking Time (TBT) er beslægtet, men ikke det samme. TBT måler, hvor meget hovedtråden er blokeret af lange opgaver i perioden mellem visning af det første indhold og tidspunktet, hvor siden bliver klar til input. Det er især en laboratoriemåling, som bruges i testværktøjer. TBT kan derfor pege på de JavaScript-problemer, der ofte også giver dårlig FID eller INP, men den måler ikke faktiske brugerinteraktioner direkte.
En høj FID skyldes ofte, at browserens hovedtråd er optaget, netop når brugeren prøver at klikke, trykke eller skrive. Derfor er den vigtigste opgave at frigøre hovedtråden hurtigere. Start med at gennemgå JavaScript-mængden: opdel store filer i mindre bidder, og indlæs kun det, der er nødvendigt for den første visning. Funktioner, der først bruges senere, kan hentes eller aktiveres efter den første interaktion.
Det er også effektivt at reducere antallet af lange opgaver. Hvis JavaScript kører i lange, sammenhængende blokke, må brugerens input vente. Del derfor tunge beregninger og komplekse processer op i mindre dele, så browseren får mulighed for at reagere mellem dem. Samtidig bør du fjerne overflødig kode, unødvendige biblioteker og gamle scripts, der belaster uden at skabe reel værdi.
Udsæt desuden ikke-kritiske scripts, især tredjepartsscripts til statistik, annoncer, chat eller sporing. Jo mindre arbejde der udføres ved indlæsning, desto hurtigere kan siden reagere. Overvej også at flytte tunge opgaver væk fra hovedtråden, hvor det er muligt, og begræns omfattende DOM-manipulationer, som kan gøre interaktioner træge. Til sidst bør du måle ændringerne løbende i praksis, så du kan se, hvilke forbedringer der faktisk sænker forsinkelsen for rigtige brugere.
First Input Delay (FID) er en måling af, hvor lang tid der går fra brugerens første interaktion med en side, til browseren kan begynde at behandle den. Det kan være et klik på en knap, et tryk på et link eller et tastetryk i et felt.
Metrikken beskriver altså sidens første oplevede reaktionsevne. Den måler ikke, hvornår handlingen er helt færdig, men hvor hurtigt siden kommer i gang med at reagere.
FID måles bedst med feldata fra rigtige brugere, fordi metrikken kræver en faktisk interaktion. Hvis ingen klikker, trykker eller skriver på siden, findes der ingen FID at registrere.
I praksis ses FID ofte i PageSpeed Insights via data fra Chrome User Experience Report (CrUX). Laboratorieværktøjer kan hjælpe med fejlsøgning, men de kan ikke måle FID direkte på samme måde som virkelige brugerdata.
En god FID er højst 100 millisekunder. Ligger værdien mellem 100 og 300 millisekunder, bør siden forbedres. Er den over 300 millisekunder, regnes den som dårlig.
Grænserne bruges som praktisk vurdering af, hvor hurtigt en side reagerer på den første handling. Jo lavere tallet er, desto mere responsiv føles siden normalt.
FID har været vigtig for SEO, fordi den tidligere indgik i Googles Core Web Vitals og dermed var en del af vurderingen af sideoplevelse. En lav forsinkelse ved første input er også vigtig for brugerne, fordi siden føles mere klar og mindre frustrerende at bruge.
Selv når fokus flytter sig mod nyere målinger, er princippet stadig relevant: langsom reaktion på klik og tryk kan svække både brugeroplevelse, engagement og i sidste ende forretningens resultater.
Den største årsag til høj FID er som regel, at browserens hovedtråd er optaget. Det sker ofte, når siden kører tung JavaScript, store scripts eller mange tredjepartsscripts samtidig.
Lange opgaver er et særligt problem, fordi de blokerer browseren i så lang tid, at brugerens første input må vente. Jo mere arbejde der ligger på hovedtråden ved indlæsning, desto større er risikoen for forsinkelse.
Det vigtigste er at mindske belastningen på hovedtråden. Det kan gøres ved at reducere mængden af JavaScript, opdele store scripts og udsætte kode, som ikke er nødvendig med det samme.
Det hjælper også at begrænse tredjepartsscripts, dele lange opgaver op i mindre bidder og fjerne funktioner eller biblioteker, der ikke skaber reel værdi. Målet er, at browseren hurtigere får tid til at reagere på brugerens første handling.
FID ser kun på forsinkelsen ved den første interaktion. INP måler derimod den samlede reaktionsevne på brugerens interaktioner gennem hele besøget.
Det gør INP mere dækkende i praksis. En side kan godt have en fin FID, men stadig føles langsom senere, hvis efterfølgende klik, tryk eller tastetryk reagerer trægt.
Nej, Lighthouse måler ikke FID direkte som laboratoriemetrik. Årsagen er, at FID afhænger af rigtige brugerinteraktioner, og det kan et syntetisk testforløb ikke gengive fuldt ud.
Lighthouse kan dog stadig være nyttigt, fordi det viser relaterede problemer som tung JavaScript, lange opgaver og høj Total Blocking Time. Det gør værktøjet velegnet til at finde sandsynlige årsager til en dårlig FID.
FID har været en del af Core Web Vitals, men fokus er flyttet til INP som nyere måling af interaktivitet. INP giver et bredere billede af, hvordan siden reagerer under hele besøget, ikke kun ved første input.
FID er derfor mindre central i dag, men den er stadig nyttig at forstå, fordi den forklarer et vigtigt aspekt af oplevet reaktionsevne og ofte peger på de samme tekniske problemer som nyere målinger.
FID måler ventetiden fra brugerens første interaktion, til browseren kan begynde at reagere. Total Blocking Time måler derimod, hvor meget hovedtråden er blokeret af lange opgaver i en bestemt del af indlæsningsforløbet.
Forskellen er derfor, at FID bygger på faktiske brugerinput, mens Total Blocking Time er en teknisk laboratoriemåling. TBT kan bruges til at finde årsagerne, men den erstatter ikke FID.