Interaction to Next Paint - Behandlingstid

Interaction to Next Paint (INP)-problemer forårsaket av behandlingstid

I vår forrige artikkel snakket vi om interaction to next paint og hvordan man kan identifisere interaction to next paint-problemer. Hvis du ønsker å lese om det grunnleggende er dette et flott sted å begynne!

I denne artikkelen vil jeg fokusere på 'behandlingstid'. Hvordan dette påvirker Interaction to Next Paint-problemer og deretter forklare hvordan man kan minimere behandlingstid for å forbedre interaction to next paint!

Kort sagt: Interaction to Next Paint (INP) måler hvor lang tid det tar for en bruker å se en visuell endring på en side etter at brukeren har interagert med siden. Denne INP-en kan brytes ned i 3 komponenter: 'input delay', 'behandlingstid' og 'presentation delay'. Behandlingstid er en stor bidragsyter til den totale INP-en, og utgjør omtrent 40% av forsinkelsen i gjennomsnitt. Dette betyr at optimalisering av JavaScript-koden din, spesielt hendelses-håndterere, kan ha betydelig innvirkning på nettsidens INP-poengsum.

INP TIPS: behandlingstid kan optimaliseres ved å umiddelbart kjøre viktig kode som går forut for layoutoppdateringen og planlegge all annen kode til å kjøre etter det.

Hva er behandlingstid?

Interaction to Next Paint (INP) kan brytes ned i 3 deler: 'Input Delay', 'Behandlingstid' og 'Presentation Delay'

Behandlingstid refererer til tiden det tar for nettleseren å behandle den tilknyttede hendelses-callbacken etter at en bruker interagerer med en nettside (f.eks. ved å klikke på en knapp eller trykke på en tast). Selv om det alltid er noe behandlingstid, oppstår INP-problemer når hendelses-callbackene bruker for mye behandlingstid.

Behandlingstid og INP

Behandlingstid kan være 'det viktigste' når du tenker på å optimalisere Interaction to Next Paint. Det er 'jobben som må gjøres' før layouten kan oppdateres av nettleseren.

Mange utviklere tenker på å forbedre INP i form av å optimalisere callback-funksjoner (optimalisere behandlingstiden), og de har rett. Men når det gjelder viktighet, er behandlingstid ikke engang den viktigste delen å forbedre, men den utgjør likevel i gjennomsnitt omtrent 40% av den totale INP-tiden.

Hos CoreDash samler vi inn millioner av Core Web Vitals-datapunkter hver time. Basert på disse dataene utgjør behandlingstid 40% av Interaction to Next Paint. Og selv om det er mye, vil optimalisering av behandlingstid alene mest sannsynlig ikke være nok til å fikse INP-problemer

Eksempel på behandlingstid: Når en bruker interagerer med en nettside, for eksempel ved å klikke på en knapp, er tiden det tar for hendelses-håndtereren knyttet til det knappeklikket å fullføre sin utførelse kjent som behandlingstid. For eksempel, hvis en bruker klikker på en knapp for å sende inn et skjema, vil koden som validerer skjemadataene, sender dem til serveren og håndterer svaret bidra til behandlingstiden. Jo lengre disse operasjonene tar, jo lengre er behandlingstiden, og potensielt dårligere INP-poengsum.

Hva forårsaker høy behandlingstid?

For å begynne å fikse INP-problemer forårsaket av høy behandlingstid må vi forstå hva de mulige årsakene til høy behandlingstid kan være. Høy behandlingstid, tiden det tar for hendelses-callbackene å kjøre til fullføring, kan forårsakes av unødvendig kode, uoptimalisert kode, grupperte callbacker og layout thrashing. La oss se nærmere på disse 4 områdene.

1. Unødvendig kode. Gammel, ubrukt kode eller kode uten umiddelbar relevans for brukerinteraksjonen, kan forlenge utførelsestiden for callbacken.
   
2. Uoptimalisert kode. Ineffektiv kode (vanligvis løkker eller ineffektive DOM-oppslag) kan gjøre hendelses-callbackene tregere enn nødvendig.
   
3. Grupperte callbacker: Flere hendelses-callbacker planlagt tett sammen skaper en kø. Hvis en callback utløst av brukerinteraksjonen blir sittende fast i denne køen, virker responsen forsinket.
   
4. Layout thrashing: Hyppige DOM-manipulasjoner som utløser layout-omberegninger kan belaste nettleseren og føre til ytelsesforringelser.

Minimere behandlingstid

For å minimere behandlingstid må vi sørge for at koden som er ansvarlig for den påfølgende layoutoppdateringen kjører så raskt som mulig. Vi kan gjøre dette ved å optimalisere eksisterende kode (fjerne unødvendig kode og optimalisere gjeldende kode) og ved å skille mellom kode som må kjøre før og etter layoutoppdateringen. I bunn og grunn må kode som er kritisk for layoutoppdateringen kjøre før den, og all annen kode kan kjøre etter layoutoppdateringen.

1. Fjern ubrukt kode. Selv om det å fjerne ubrukt kode kan virke opplagt, er det på de fleste nettsteder minst noe gammel ubrukt kode som bare kjører uten å virkelig tilføre noe til siden eller UX. Dette betyr at det første du bør gjøre er å sørge for at det ikke kjører kode som ikke trengs. Dette kan gjøres på mange måter. For eksempel gjennom en prosess kalt tree shaking eller code splitting. Eller manuelt ved å inspisere kodedekningsgraden i Chrome og også ved å bruke en god IDE som vil hinte om ubrukt kode. (Pro tips: ta også et kritisk blikk på ressurser lastet av Tag Manager-en din)
2. Minimer utførelsestiden for callbacker: Bruk en JavaScript-profiler til å identifisere flaskehalser i koden din og fokuser på disse områdene for optimalisering. Vurder teknikker som memoisering, forhåndsberegning og caching for å unngå overflødige beregninger. (Tips: du kan bruke Chrome sin ytelsespanel for å finne skript med lang utførelsestid!)
   
3. Prioriter kritisk kode og planlegg annen kode: Når callback-koden er optimalisert, del koden i kode som må kjøre umiddelbart og kode som kan utsettes. Ta en titt på dette eksempelet fra virkeligheten:
   
   I dette eksempelet kjøres Google Tag Manager- og Facebook-hendelses-callbacker før (REACT)-koden som gikk forut for layoutoppdateringen. Løsningen ville vært å planlegge GTM-callbackene til når nettleseren er inaktiv
4. Unngå Layout Thrashing eller reflow. Layout thrashing skjer når stiloppdateringer og stillesninger blandes i en løkke, noe som får nettleseren til å omberegne layouten mange ganger.
   For å unngå layout thrashing, utfør alle stilendringer ("settene") før du ber om stilverdier ("hentene"). Denne tilnærmingen minimerer frekvensen av layoutoppdateringer, noe som fører til en raskere nettside.
   For eksempel, i en løkke som setter bredden på hvert avsnitt til å matche et elements bredde, les elementets bredde én gang før løkken og bruk den verdien til å oppdatere avsnittenes bredder inne i løkken.

Hvordan prioritere kritisk kode

Det siste punktet 'Prioriter kritisk kode og planlegg annen kode' kan være litt abstrakt for mange av dere. Vi kan prioritere kritisk kode ved å bruke requestIdleCallback() og ved å yielde til hovedtråden.

Vi bruker requestIdleCallback for mindre viktige oppgaver som ikke trenger å kjøre umiddelbart: Her er et før- og etter-eksempel på planlegging av en GTM-hendelse.

/* 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 med requestIdleCallback er at koden kanskje ikke kjører så snart du ønsker. I så fall kan vi 'yielde til hovedtråden' etter at den viktigste koden har kjørt, og dermed gi nettleseren et øyeblikk til å kjøre layoutoppdateringene. Her er et eksempel på hvordan man kan bryte opp oppgaver ved å 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 kan vi gjøre mye mer med window.scheduler enn bare å yielde til hovedtråden. Vi kan også prioritere oppgaver ved å bruke scheduler-API-et (se støttetabell).

Scheduler-API-et tilbyr postTask()-funksjonen for mer finkornet planlegging av oppgaver ved å sette prioriteringer, noe som hjelper nettleseren med å prioritere arbeid slik at oppgaver med lav prioritet yielder til hovedtråden.

postTask()-funksjonen aksepterer tre prioritetsinnstillinger: 'background' for oppgaver med lavest prioritet, 'user-visible' for oppgaver med middels prioritet, og 'user-blocking' for kritiske oppgaver som krever høy prioritet.

Ved å prioritere kritiske oppgaver med 'user-blocking' kan utviklere sikre at de utføres med høyere prioritet, slik at nettleseren kan håndtere brukerinteraksjoner mer responsivt. Scheduler-API-et tilbyr postTask()-funksjonen for mer finkornet planlegging av oppgaver ved å sette prioriteringer, noe som hjelper nettleseren med å prioritere arbeid slik at oppgaver med lav prioritet yielder til hovedtråden.

Praktiske implikasjoner

La oss komme til det viktigste spørsmålet: 'Hva betyr alt dette for min nettside'. La oss bryte det ned for WordPress og REACT og se hvordan du kan forbedre Interaction to Next Paint når det gjelder behandlingstid.

WordPress

WordPress tilbyr svært lite kontroll når det gjelder skript. Mange skript legges til gjennom plugins. Mesteparten av tiden vil disse skriptene legge til 'event listeners' på siden som ikke gjør annet enn å forsinke interaction to next paint (INP). Hvis WordPress-nettstedet ditt har problemer med Interaction to Next Paint forårsaket av lang behandlingstid, følg disse stegene:

• Sjekk temainnstillingene. Fjern avmerkingen for alle unødvendige alternativer som 'smooth scroll' eller 'animert meny'. Innstillinger som disse har en tendens til å forårsake INP-problemer.
• Sjekk hvilke skript som er ansvarlige for lang behandlingstid (tips: bruk Chrome sin ytelsespanel). Hvis disse skriptene er plugin-relaterte, vurder å finne en annen plugin som gjør omtrent det samme
• Ofte kjører det egendefinerte skript på siden. Sjekk disse skriptene og sørg for at de yielder til hovedtråden ofte og pakk mindre viktige callbacker i en requestIdleCallback-funksjon
• Last av ubrukte skript på en per-side-basis (tips: bruk wp_deregister_script). Noen plugins har en tendens til å injisere skript på hver side selv når funksjonaliteten ikke trengs.
• Sjekk Tag Manager-en din og fjern ubrukte eller unødvendige tagger.
• Bruk rene og enkle temaer. Ofte har flerbrukstemaer som 'gjør alt' flere skript
• Unngå sidebyggere siden de ofte er avhengige av JavaScript for å presentere sider til sluttbrukeren

REACT / NextJS

Reacts hooks og funksjoner gjør det mulig å redusere INP-behandlingstiden:

Prioriter brukerinteraksjon med React Concurrency-funksjoner:

Reacts concurrency-funksjoner introdusert i versjon 16 og 18 tilbyr hooks og mekanismer for å optimalisere rendering for en jevnere user experience, spesielt under input.

• useTransition og startTransition: Merk ikke-kritiske oppdateringer for senere rendering. Dette forhindrer at store oppdateringer blokkerer brukerinteraksjon.
• useDeferredValue: Del brukergrensesnittet ditt i essensielle og mindre kritiske seksjoner. React kan avbryte rendering av de mindre kritiske delene for en mer responsiv opplevelse.
• useOptimistic: Vis en midlertidig, optimistisk tilstand mens asynkrone operasjoner (som nettverksforespørsler) pågår. Dette holder brukergrensesnittet responsivt selv under datahenting.

Suspense for datahenting (React 18+):

Suspense i React 18 kan brukes til å forbedre INP (Interaction to Next Paint) ved å la nettleseren prioritere brukerinteraksjoner og optimalisere rendering. Mens React 16 introduserte Suspense for code splitting, utvider React 18 denne funksjonaliteten til å omfatte datahenting.

• En fallback-komponent, som en lasteindikator, vises mens data lastes.
  
• Når dataene ankommer, gjenopptar React renderingen av den suspenderte komponenten.
• Suspense, kombinert med avbrytbar rendering i Concurrent React, prioriterer brukerinteraksjoner. Hvis en bruker interagerer med en suspendert komponent, prioriterer React rendering av den komponenten, og opprettholder responsivitet.

Samlet sett fungerer disse funksjonene sammen for å sikre at React prioriterer brukerinteraksjoner og unngår å blokkere brukergrensesnittet under oppdateringer eller datahenting.