Kort fortalt: En long task er en periode hvor main thread er optaget så længe, at browseren ikke kan reagere hurtigt på input eller male frames. Tommelfingerreglen er ofte >50 ms.
Hvorfor betyder det noget?
Hvis main thread er blokeret, kan browseren ikke male, scrolle eller reagere hurtigt.
Det rammer især:
- klik/tap (INP)
- scroll (hakker)
- input (tekst “lagger”)
Hvilken indflydelse har long tasks?
Long tasks er en af de mest direkte årsager til:
- dårlig INP
- dårlig oplevet respons
- “tung” følelse på mobil
Hvis du kun ændrer netværk (CDN/caching), kan du stadig have dårlig INP, hvis long tasks dominerer ved interaktion.
Hvornår blev long tasks et fokus?
Da moderne webapps begyndte at køre mere JavaScript i browseren, blev det tydeligt at CPU-arbejde kunne være en større flaskehals end netværk – især på mobil. Long tasks er en praktisk måde at se “hvorfor” interaktioner bliver forsinket.
Typiske årsager
- Tunge JavaScript-bundles
- Store frameworks/komplekse komponenter
- For mange tredjeparts scripts
Typiske forbedringer
- Split code og fjern unødvendig JS
- Brug requestIdleCallback / web workers hvor relevant
- Optimer rendering og event handlers
Sådan finder du long tasks (praktisk)
1) DevTools Performance
- start en optagelse
- udfør en interaktion (menu, søgning, filter)
- kig efter “Long task” og se stack traces for hvad der kører
2) Kig efter mønstre
Typiske mønstre:
- parsing/evaluation af store JS bundles
- rendering loops (komponenter rerenderer for meget)
- tredjepart der kører timers eller observers aggressivt
Konkrete optimeringer (i prioriteret rækkefølge)
1) Reducér bundle og JS i critical path
- fjern dependencies
- code splitting
- begræns hydration
2) Optimer event handlers
- undgå tungt arbejde i click/scroll/input handlers
- throttle/debounce hvor det giver mening
- batch DOM reads og DOM writes
3) Flyt arbejde væk fra main thread
- web workers til tung beregning
- requestIdleCallback til ikke-kritisk arbejde
4) Skær tredjepart ned
Tredjepart er ofte “udenfor din kontrol”, så den mest effektive løsning er:
- fjern
- udskyd
- begræns
Tjekliste
- De vigtigste interaktioner er optaget i Performance trace
- Top 3 long task-kilder er identificeret
- JS bundle er reduceret/splittet
- Tredjepart er gennemgået
Hvorfor long tasks ofte overses
Mange teams fokuserer først på netværk og billeder. Det er vigtigt, men long tasks opstår typisk i CPU-laget og er mindre synlige uden tracing. Derfor kan et site have “ok” loadtid, men stadig føles trægt ved interaktion.
Long tasks og forskellen mellem lab og virkelige brugere
I lab kan du få pæne tal på hurtig maskine, mens rigtige brugere på mobil oplever lag. Det skyldes ofte:
- langsommere CPU på enheder
- flere baggrundsprocesser på telefonen
- svagere netværk, som skubber flere scripts tættere på første interaktion
Derfor bør du validere på fysisk mobil eller realistisk throttling.
Hvilke typer kode skaber ofte long tasks?
Tunge init-sekvenser
Når en side initialiserer meget JS på én gang, kan første interaktion rammes.
Store rendering-opdateringer
Hvis mange komponenter rerenderer i samme frame, får browseren mindre tid til input.
Synkrone loops over store datamængder
Filtrering/sortering direkte på main thread kan være dyrt, især ved gentagne input-events.
Praktisk arbejdsmetode i teams
En enkel metode der virker:
- Vælg 2-3 kritiske interaktioner.
- Optag traces og identificér top long tasks.
- Lav små ændringer med tydelig hypotese.
- Mål igen og dokumentér effekt.
På den måde undgår du at lave “performance-arbejde” uden målbar forbedring.
Konkrete tegn på forbedring
Efter gode ændringer ser du ofte:
- kortere script tasks omkring interaktion
- færre blokeringer af input
- mere stabil respons på mobil
INP bliver mere robust, fordi worst-case interaktioner forbedres.
Ekstra tjekliste til release
- Kritiske interaktioner er testet på mobil
- Long tasks er reduceret i de vigtigste flows
- Tredjeparts scripts er vurderet og begrænset
- Der er dokumenteret før/efter traces
- Ændringerne giver ikke funktionelle regressioner
FAQ
Kan long tasks være “ok”?
Korte spikes kan ske. Problemet er når long tasks overlapper med brugerinteraktioner, eller når de sker tidligt så siden føles tung.
I praksis er “ok” ofte et spørgsmål om *timing*: en long task midt i et klik på menuen er langt værre end en tilsvarende opgave mens brugeren alligevel læser.
Er long tasks altid JavaScript?
Ofte ja – men ikke kun.
Layout, style recalculations og andre rendering-opgaver kan også være dyre. En Performance trace viser typisk præcist hvad der fylder, så du kan se om det er scripting, rendering eller noget tredjepart.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Fjern eller udsæt tunge tredjeparts scripts uden at ødelægge funktionalitet
Følg en praktisk guide til at finde, vurdere og udsætte tredjeparts scripts, så de ikke ødelægger LCP, INP og den samlede brugeroplevelse.
Sådan finder du lange tasks i DevTools og forbedrer INP
Lær hvordan du bruger DevTools til at finde lange tasks, tunge event handlers og JavaScript der gør siden træg at bruge.
Optimer cookie banner uden CLS og INP problemer
Lær hvordan du bygger eller justerer cookie bannere, så de ikke skubber indhold, blokerer interaktion eller gør siden tungere end nødvendigt.
Hvordan tredjeparts scripts gør din hjemmeside langsom
Få overblik over hvordan chat widgets, tracking, consent, video embeds og andre tredjeparts scripts påvirker LCP, INP, CLS og TTFB.
Cookie banner og Core Web Vitals: den oversete årsag til dårlig brugeroplevelse
Se hvordan cookie bannere og consent scripts kan påvirke load, layout og interaktion, og lær hvordan du undgår at de ødelægger brugeroplevelsen.
INP vs FID: hvorfor INP erstattede FID og hvad du skal optimere
Lær hvorfor INP har erstattet FID, hvad forskellen betyder i praksis, og hvordan du finder og løser JavaScript-problemer, der gør siden tung at bruge.
