Interaction to Next Paint - Input Delay

Interaction to Next Paint (INP) problemer forårsaget af input delay

I vores forrige artikel talte vi om interaction to next paint og hvordan man identificerer interaction to next paint problemer. Hvis du gerne vil læse om det grundlæggende er dette et godt sted at starte!

I denne artikel vil jeg fokusere på 'Input Delay'. Hvordan dette påvirker Interaction To Next Paint problemerne og derefter forklare hvordan man minimerer input delays for at forbedre interaction to next paint.!

INP TIP: oftest vil input delay forekomme i de tidlige indlæsningsstadier af websiden!

Hvad er input delay?

Input delay refererer til den tid det tager for browseren at begynde at behandle et event callback efter en bruger interagerer med en webside (f.eks. at klikke på en knap eller trykke på en tast). Selvom der altid er noget input delay (selv browsere har brug for tid til at planlægge callbacks), opstår input delay når browseren er optaget af at udføre andre planlagte opgaver og ikke umiddelbart kan planlægge de callbacks der anmodes om ved interaktionen.

Input delay og INP

Interaction to Next Paint (INP) kan opdeles i 3 underdele: 'Input Delay', 'Processing Time' og 'Presentation Delay'

Du bemærker måske at der er navneligheder mellem Input Delay og den ældre Core Web Vital 'First Input Delay'. For dem der ikke ved det: Interaction to Next Paint er efterfølgeren til den pensionerede 'First Input Delay'. First input delay målte tiden mellem den første interaktion og event callback. Selvom First Input Delay er blevet pensioneret, spiller 'Input Delay' stadig en vigtig rolle i forbedringen af web responsiveness fordi Input Delay er ved grundlaget af hver Interaction to Next Paint.

Vigtigheden af input delay

Da mange udviklere tænker på at forbedre INP i form af optimering af callback funktioner (optimering af process time) bliver 'Input Delay' ofte overset. Ganske vist er Input Delay ikke normalt den største del af INP men ikke desto mindre, hvis vi optimerer INP delay vil vi ofte optimere alle INP interaktioner på én gang!

Hos CoreDash indsamler vi millioner af core web vitals datapunkter hver time. Baseret på disse data tegner Input Delay sig for kun 18% af Interaction to Next Paint. Og selvom det ikke er næsten så meget som Presentation Delay eller Processing time er det stadig en betydelig del.

Input Delay årsager:

Input delay opstår når main thread er optaget af at udføre andre opgaver. Disse opgaver kan stamme fra:

1. Tidlige opgaver. Normale, deferred og asynced scripts der sættes i kø tidligt vil skabe tidlige opgaver
   
2. Planlagte opgaver. Nogle opgaver kører ikke ved starten af sideindlæsningen men kan være planlagt til efter siden er blevet indlæst. Disse opgaver kan også forstyrre INP og forårsage en input delay. For eksempel scripts der kører efter window.onload eventet eller scripts der bliver forsinket af såkaldte optimeringsplugins.
   
3. Gentagne opgaver. Tilbagevendende opgaver via setInterval() der tager relativt lang tid at udføre og sker samtidig med INP
4. Overlappende callbacks: Overlappende Callbacks er en almindelig årsag til input delay. Flere callbacks planlagt tæt på hinanden kan skabe en kø, der forsinker behandlingen af den næste interaktion.

Minimer input delay

1. Opdel lange tidlige opgaver i flere mindre opgaver. Under lange opgaver kan browseren ikke reagere på brugerinput mens browseren efter hver kort opgave kan reagere på brugerinput. Så opdel lange opgaver med scheduler.yield() (eksperimentel) eller ved at pakke hver funktion ind i en timeout på 0 med setTimeout(callback,0)
2. Håndter interaktive elementer. Overvej ikke at præsentere interaktive elementer (som en søgebar) før JavaScript koden der styrer dem er fuldt indlæst. Dette vil forhindre tidlige klik på elementer der ikke er klar til at modtage klik. For at optimere UX for dette mønster kan du enten prioritere indlæsning af den nødvendige JavaScript eller midlertidigt skjule/deaktivere elementet indtil det er funktionelt.
3. Idle Time Script Execution: Planlæg ikke-kritiske scripts til at køre under browserens idle perioder med requestIdleCallback(). RequestIdleCallback kører når browseren er idle og ikke behøver at behandle brugerinput.
4. Brug web workers til at køre JavaScript uden for browserens main thread. Web workers tillader Script at køre uden for main thread. Dette vil forhindre main thread i at blokere og forårsage INP input delay problemer.
5. Tjek for afventende input under gentagne opgaver. Før udførelse af et sæt eller planlagte opgaver tjek for afventende input før opstart af opgaverne. Hvis der er noget afventende input yield til main thread først.
6. Fjern unødvendig kode. Gennemgå regelmæssigt dine scripts og fjern unødvendig kode eller endda scripts fordi hver kodelinje potentielt kan forårsage en input delay der påvirker interaction to next paint.

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

Praktiske konsekvenser

Lad os komme til det vigtigste spørgsmål: 'Hvad betyder dette alt sammen for min side'. Lad os nedbryde det for WordPress & REACT.

WordPress

WordPress kommer på grund af sin natur ofte med et tema og et stort antal plugins. Både plugins og temaerne er ofte afhængige af JavaScript for funktionalitet. Da disse plugins og temaer vedligeholdes af tredjeparts udviklere har vi ingen kontrol over indholdet. Dette betyder at vi ikke kan ændre filerne og optimere 'dårlig kode'. Selvom scripts opfører sig pænt er der ingen garanti for at de vil gøre det i fremtiden.

Så for at minimere input delay og optimere Interaction to Next Paint (INP) gør følgende:

• Undgå at bruge plugins når det er muligt. Selvom plugins er en nem måde at tilføje funktionalitet på, tilføjer de ofte scripts til siden. Disse scripts vil forårsage en input delay der påvirker INP. For hvert plugin spørg dig selv: Kan jeg opnå den samme funktionalitet med custom kode?
• Vælg lette temaer. Mange WordPress temaer 'tilbyder alt'. Selvom det lyder som en god idé betyder det at de sandsynligvis er fyldt med funktionalitet der ikke bruges men bruger værdifuld CPU tid.
• Undgå page builders. Page builders som Elementor eller WPBakery giver dig en brugervenlig, visuel grænseflade til at bygge layouts. Desværre er de ofte afhængige af scripts for at præsentere det layout til besøgende.
• Indlæs kun scripts når de er nødvendige. WordPress har en tendens til at indlæse alle scripts på alle sider. For at rette dette skal du blot oprette et child tema og afregistrere unødvendige scripts per side type. For eksempel:

function my_deregister_scripts() {
  if ( ! is_page( 'contact' ) ) { 
    // Example: Deregister contact form script on non-contact pages
    wp_dequeue_script( 'contact-form-script' );
  }
}
add_action( 'wp_enqueue_scripts', 'my_deregister_scripts' );

REACT / NextJS

React eller NextJS sider drives for det meste af JavaScript. Udførelse af disse scripts vil tage tid og forårsage input delay for Interaction to Next Paint (INP)

• Brug server components. Server components bliver renderet på serveren og ikke på klienten hvilket vil føre til en reduceret mængde JavaScript
• Indlæs tredjeparts scripts med den korrekte strategi. Indlæs tredjeparts scripts efter hydration eller endda under browserens idle tid
• Implementer et idle until urgent mønster: Dette mønster prioriterer brugerinteraktioner over baggrundsopgaver og skaber midlertidige tilstande mens browseren bruger requestIdleCallback til at udføre ikke-kritiske opgaver under browserens idle perioder.
• Lazy load components. Lazy load components der ikke er umiddelbart nødvendige ved at bruge React.lazy() eller NextJS dynamic()
• Brug suspense til interaktive components. Overvej kun client side rendering af interaktive components der har brug for hydration for at blive interaktive.