Interaction to Next Paint - Behandlingstid

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

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 op på det grundlæggende, er dette et godt sted at starte!

I denne artikel vil jeg fokusere på 'behandlingstid'. Hvordan dette påvirker Interaction to Next Paint problemerne og derefter forklare hvordan man minimerer behandlingstid for at forbedre Interaction to Next Paint!

Kort sagt: Interaction to Next Paint (INP) måler, hvor lang tid det tager at se en visuel ændring på en side, efter en bruger har interageret med siden. Denne INP kan opdeles i 3 komponenter: 'input delay', 'behandlingstid' og 'presentation delay'. Behandlingstid er en væsentlig bidragyder til den samlede INP og udgør i gennemsnit cirka 40% af forsinkelsen.  Det betyder, at optimering af din JavaScript kode, især event handlers, kan have en betydelig indvirkning på dit websteds INP-score.

INP TIP: behandlingstid kan optimeres ved straks at køre vigtig kode, der går forud for layoutopdateringen, og planlægge al anden kode til at køre derefter.

Hvad er behandlingstid?

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

Behandlingstid refererer til den tid, det tager for browseren at behandle den tilknyttede 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 nogen behandlingstid, opstår INP-problemer, når event callbacks tager for meget behandlingstid.

Behandlingstid og INP

Behandlingstid er måske 'det vigtigste', når du tænker på at optimere Interaction to Next Paint. Det er 'jobbet, der skal gøres', før layoutet kan opdateres af browseren.

Mange udviklere tænker på at forbedre INP i form af at optimere callback-funktioner (optimere behandlingstiden), og de har ret. Men hvad angår vigtighed, er behandlingstid ikke engang den vigtigste del at forbedre, men den udgør stadig i gennemsnit omkring 40% af den samlede INP-tid.

Hos CoreDash indsamler vi millioner af Core Web Vitals datapunkter hver time. Baseret på disse data udgør behandlingstid 40% af Interaction to Next Paint. Og selvom det er meget, vil optimering af behandlingstiden alene sandsynligvis ikke være nok til at løse INP-problemer

Eksempel på behandlingstid: Når en bruger interagerer med en webside, f.eks. klikker på en knap, er den tid, det tager for event handleren knyttet til det knapklik at fuldføre sin udførelse, kendt som behandlingstid. For eksempel, hvis en bruger klikker på en knap for at indsende en formular, vil koden, der validerer formulardataene, sender dem til serveren og håndterer svaret, bidrage til behandlingstiden. Jo længere disse operationer tager, jo længere er behandlingstiden og potentielt jo dårligere bliver INP-scoren.

Hvad forårsager høj behandlingstid?

For at begynde at løse INP-problemer forårsaget af høj behandlingstid skal vi forstå, hvad de mulige årsager til høj behandlingstid kan være.  Høj behandlingstid, den tid det tager for event callbacks at køre til afslutning, kan forårsages af unødvendig kode, uoptimeret kode, klyngede callbacks og layout thrashing. Lad os se nærmere på disse 4 områder.

1. Unødvendig kode. Gammel, ubrugt kode eller kode uden umiddelbar relevans for brugerinteraktionen kan forlænge callback-udførelsestiden.
   
2. Uoptimeret kode. Ineffektiv kode (normalt loops eller ineffektive DOM-opslag) kan få event callbacks til at køre langsommere end nødvendigt.
   
3. Klyngede callbacks: Flere event callbacks planlagt tæt sammen skaber en kø. Hvis en callback udløst af brugerinteraktionen sidder fast i denne kø, fremstår svaret forsinket.
   
4. Layout thrashing: Hyppige DOM-manipulationer, der udløser layout-genberegninger, kan belaste browseren og føre til ydeevneforringelser.

Minimer behandlingstid

For at minimere behandlingstiden skal vi sørge for, at koden, der er ansvarlig for den efterfølgende layoutopdatering, kører så hurtigt som muligt. Vi kan gøre dette ved at optimere eksisterende kode (fjerne unødvendig kode og optimere den nuværende kode) og ved at skelne mellem kode, der skal køre før og efter layoutopdateringen. Grundlæggende skal kode, der er kritisk for layoutopdateringen, køre før den, og al anden kode kan køre efter layoutopdateringen.

1. Fjern ubrugt kode.  Selvom det at fjerne ubrugt kode kan virke indlysende, er der på de fleste sites i det mindste noget gammel ubrugt kode, der bare kører uden rigtig at tilføje noget til siden eller UX.  Det betyder, at det første, der skal gøres, er at sikre, at der ikke kører kode, som ikke er nødvendig. Dette kan gøres på mange måder. For eksempel ved en proces kaldet tree shaking eller code splitting. Eller manuelt ved at inspicere din kodedækning i Chrome og også ved at bruge en god IDE, der vil påpege ubrugt kode. (Pro tip: tag også et kritisk blik på ressourcer indlæst af din Tag Manager)
2. Minimer callback-udførelsestid: Brug en JavaScript profiler til at identificere flaskehalse i din kode og målret disse områder til optimering. Overvej teknikker som memoization, forudberegning og caching for at undgå overflødige beregninger. (Tip: du kan bruge Chrome performance panelet til at finde scripts med lang udførelsestid!)
   
3. Prioriter kritisk kode og planlæg anden kode: Når callback-koden er blevet optimeret, opdel koden i kode, der skal køre med det samme, og kode, der kan udskydes. Se på dette eksempel fra virkeligheden:
   
   I dette eksempel køres Google Tag Manager og Facebook events callback før (REACT) koden, der går forud for layoutopdateringen. Løsningen ville have været at planlægge GTM callbacks, når browseren er inaktiv
4. Undgå Layout Thrashing eller reflow. Layout thrashing sker, når stilopdateringer og stillæsninger blandes i en loop, hvilket får browseren til at genberegne layoutet talrige gange. 
   For at undgå layout thrashing skal du udføre alle stilændringer ("sets") før du anmoder om stilværdier ("gets"). Denne tilgang minimerer hyppigheden af layoutopdateringer, hvilket fører til en hurtigere webside.
   For eksempel, i en loop der sætter hver paragrafs bredde til at matche et elements bredde, læs elementets bredde én gang før loopet og brug den værdi til at opdatere paragrafernes bredder inde i loopet.

Sådan prioriterer du kritisk kode

Det sidste punkt 'Prioriter kritisk kode og planlæg anden kode' kan være lidt abstrakt for mange af jer. Vi kan prioritere kritisk kode ved at bruge requestIdleCallback() og ved at yielde til hovedtråden.

Vi bruger requestIdleCallback til mindre vigtige opgaver, der ikke behøver at køre med det samme: Her er et før- og efter-eksempel på planlægning af en GTM event.

/* before :: immediately run code  */
gtag('event', '<event_name>', {
   'event_category': '<event_category>',
 });

/* after :: run the same code during browser idle */
requestIdleCallback(() => {
  gtag('event', '<event_name>', {
    'event_category': '<event_category>',
  });
}, { timeout: 1000 });

Ulempen ved requestIdleCallback er, at koden muligvis ikke kører så hurtigt, som du ønsker. I det tilfælde kan vi 'yielde til hovedtråden' efter den vigtigste kode er kørt og derved give browseren et øjeblik til at køre layoutopdateringerne. Her er et eksempel på, hvordan man opdeler opgaver ved at yielde til hovedtråden

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

async function handleClick(){
 // do the most important layout updates here
 await yieldToMain();
 // do other tasks that need to run as asap after the layout update
}

I fremtiden kunne vi gøre meget mere med window.scheduler end bare at yielde til hovedtråden. Vi kunne også prioritere opgaver ved hjælp af scheduler API'en (se Supporttabel).

Scheduler API'en tilbyder funktionen postTask() til finere planlægning af opgaver ved at sætte prioriteter, hvilket hjælper browseren med at prioritere arbejde, så lavprioritetsopgaver yielder til hovedtråden. 

Funktionen postTask() accepterer tre prioritetsindstillinger: 'background' for opgaver med lavest prioritet, 'user-visible' for opgaver med medium prioritet og 'user-blocking' for kritiske opgaver, der kræver høj prioritet. 

Ved at prioritere kritiske opgaver med 'user-blocking' kan udviklere sikre, at de udføres med højere prioritet, hvilket giver browseren mulighed for at håndtere brugerinteraktioner mere responsivt. Scheduler API'en tilbyder funktionen postTask() til finere planlægning af opgaver ved at sætte prioriteter, hvilket hjælper browseren med at prioritere arbejde, så lavprioritetsopgaver yielder til hovedtråden. 

Praktiske implikationer

Lad os komme til det vigtigste spørgsmål: 'Hvad betyder alt dette for mit site'. Lad os gennemgå det for WordPress & REACT og se, hvordan du kan forbedre Interaction to Next Paint, når det kommer til behandlingstid.

WordPress

WordPress tilbyder meget lidt kontrol, når det kommer til scripts. Mange scripts tilføjes gennem plugins. Det meste af tiden vil disse scripts tilføje 'event listeners' til siden, der ikke gør andet end at forsinke Interaction to Next Paint (INP).  Hvis dit WordPress-site har problemer med Interaction to Next Paint forårsaget af lang behandlingstid, tag følgende skridt:

• Tjek temaindstillingerne. Fjern markeringen af unødvendige indstillinger som 'smooth scroll' eller 'animated menu'. Indstillinger som disse har tendens til at forårsage INP-problemer.
• Tjek hvilke scripts der er ansvarlige for den lange behandlingstid (tip: brug Chrome performance panelet). Hvis disse scripts er plugin-relaterede, overvej at finde et andet plugin, der gør omtrent det samme
• Ofte kører der brugerdefinerede scripts på siden. Tjek disse scripts og sørg for, at de yielder til hovedtråden ofte og pakker mindre vigtige callbacks ind i en requestIdleCallback funktion
• Afregistrer ubrugte scripts på sidebasis (tip: brug wp_deregister_script). Nogle plugins har tendens til at indsætte scripts på hver side, selv når funktionaliteten ikke er nødvendig.
• Tjek din Tag Manager og fjern ubrugte eller unødvendige tags.
• Brug slanke og rene temaer. Ofte har multifunktionstemaer, der 'gør alt', tendens til at have flere scripts
• Undgå page builders, da de ofte er stærkt afhængige af JavaScript til at præsentere sider for slutbrugeren

REACT / NextJS

Reacts hooks og features gør det muligt at reducere INP behandlingstiden:

Prioriter brugerinteraktion med React Concurrency Features:

Reacts concurrency features introduceret i version 16 og 18 tilbyder hooks og mekanismer til at optimere rendering for en mere flydende brugeroplevelse, især under input.

• useTransition & startTransition: Markér ikke-kritiske opdateringer til senere rendering. Dette forhindrer store opdateringer i at blokere brugerinteraktion.
• useDeferredValue: Opdel din UI i essentielle og mindre kritiske sektioner. React kan afbryde rendering af de mindre kritiske dele for en mere responsiv oplevelse.
• useOptimistic: Vis en midlertidig, optimistisk tilstand, mens asynkrone operationer (som netværksanmodninger) er i gang. Dette holder UI'en responsiv selv under datahentning.

Suspense til datahentning (React 18+):

Suspense i React 18 kan bruges til at forbedre INP (Interaction to Next Paint) ved at give browseren mulighed for at prioritere brugerinteraktioner og optimere rendering. Mens React 16 introducerede Suspense til code splitting, udvider React 18 denne funktionalitet til også at omfatte datahentning.

• En fallback komponent, som en indlæsningsindikator, vises mens data indlæses.
  
• Når data ankommer, genoptager React rendering af den suspenderede komponent.
• Suspense, kombineret med afbrydelig rendering i Concurrent React, prioriterer brugerinteraktioner. Hvis en bruger interagerer med en suspenderet komponent, prioriterer React rendering af den komponent og opretholder responsiviteten.

Overordnet set arbejder disse features sammen for at sikre, at React prioriterer brugerinteraktioner og undgår at blokere UI'en under opdateringer eller datahentning.