LoAF

Kort fortalt: LoAF (Long Animation Frames) handler om de frames hvor browseren bruger for lang tid på at nå fra “input” til “næste paint”. I praksis er det en måde at tænke (og i stigende grad måle) “hvorfor føles UI tungt?”, fordi en lang frame kan skyldes både JavaScript, layout, paint og compositing.

Hvis du har arbejdet med Long Task, er LoAF næste naturlige niveau: ikke kun “hvor længe kørte JS?”, men “hvorfor blev hele frame-budgettet sprængt?”

Hvad betyder LoAF i praksis?

En browser prøver at tegne UI i en stabil rytme. Når en frame tager for lang tid, kan brugeren mærke:

• klik der reagerer “sent”
• hover/scroll der hakker
• animationer der “stutter”

En lang frame kan være:

• JS der fylder main thread (store handlers, tredjepart, heavy frameworks)
• style/layout der bliver dyrt (store DOM-opdateringer, dårlig CSS-struktur)
• paint der er tung (dyre effekter, mange layers, store gradients)
• compositing der ikke kan følge med (for mange lag/filters)

Hvorfor er det vigtigt ift. INP?

INP måler hvor hurtigt siden reagerer på interaktion og når til næste paint. Hvis du har lange frames, er der god chance for at de “stjæler” tid i netop den kæde.

Det er også derfor du kan have en side der loader “ok”, men stadig føles langsom: load-metrics fanger ikke alt ved interaktion.

Eksempel fra praksis

Forestil dig et filterpanel:

1. Brugeren klikker “Filtrér”.
2. JS bygger 200 DOM-noder (kort, badges, billeder).
3. CSS triggers layout på en stor container.
4. Der er en baggrund med blur/gradients der gør paint tung.

Resultat: en enkelt frame bliver meget lang. Det føles som lag – også selvom det “kun” er 200–400ms.

Her kan du ofte få mest effekt ved at:

• reducere DOM-mængden
• batch’e DOM writes/reads (se Layout thrashing)
• udskyde ikke-kritisk rendering
• minimere dyre visuelle effekter i kritiske øjeblikke

Typiske fejl og misforståelser

“Hvis jeg fjerner Long Tasks, er alt godt”

Ikke altid. Du kan godt have korte tasks, men stadig lange frames pga. paint/layout. Det er ofte her LoAF-tankegangen hjælper.

“Det er kun et problem på dårlige telefoner”

Det viser sig først på svage enheder, men det betyder bare at oplevelsen for en stor del af dine brugere er dårligere end din egen desktop-test. Performance skal måles på realistiske enheder.

Sådan arbejder du dig frem til årsagen

Start med:

• Chrome DevTools Performance og optag en interaktion.
• Kig efter hvor tiden går: Scripting vs. Rendering vs. Painting.

Hvis du ser at “Rendering/Painting” fylder meget:

• tjek om du bruger dyre CSS-effekter (blur, store gradients, store fixed overlays)
• tjek om der er store layout-skift (CLS) – se CLS

Hvis du ser at “Scripting” fylder:

• kig efter store bundles og tredjepart – se JavaScript bundle og Third-party scripts

Relaterede begreber og næste skridt

• INP – målet for interaktionsrespons
• Long Task – JS der blokerer main thread
• Main thread – hvorfor alt kæmper om samme kø
• Chrome DevTools Performance – dit bedste værktøj til at se “hvad tog tid?”