Interaction to Next Paint - Input Delay

Interaction to Next Paint (INP)-problem orsakade av input delay

I vår tidigare artikel pratade vi om Interaction to Next Paint och hur man identifierar Interaction to Next Paint-problem. Om du vill läsa mer om grunderna är detta ett bra ställe att börja!

I den här artikeln kommer jag att fokusera på 'Input Delay'. Hur detta påverkar Interaction to Next Paint-problem och sedan förklara hur man minimerar input delays för att förbättra Interaction to Next Paint.!

INP-TIPS: oftast uppstår input delay under de tidiga laddningsfaserna av webbsidan!

Vad är input delay?

Input delay avser den tid det tar för webbläsaren att börja bearbeta en event callback efter att en användare interagerar med en webbsida (t.ex. klickar på en knapp eller trycker på en tangent). Även om det alltid finns viss input delay (även webbläsare behöver tid för att schemalägga callbacks) uppstår input delay när webbläsaren är upptagen med att utföra andra schemalagda uppgifter och inte omedelbart kan schemalägga de callbacks som begärs av interaktionen.

Input delay och INP

Interaction to Next Paint (INP) kan delas upp i 3 delar: 'Input Delay', 'Processing Time' och 'Presentation Delay'

Du kanske märker att det finns namnlikheter mellan Input Delay och det äldre Core Web Vital 'First Input Delay'. För dem som inte vet: Interaction to Next Paint är efterföljaren till det pensionerade 'First Input Delay'. First Input Delay mätte tiden mellan den första interaktionen och event callback. Även om First Input Delay har pensionerats spelar 'Input Delay' fortfarande en viktig roll för att förbättra webbens responsivitet eftersom Input Delay ligger till grund för varje Interaction to Next Paint.

Betydelsen av input delay

Eftersom många utvecklare tänker på att förbättra INP i termer av att optimera callback-funktioner (optimera processtiden) förbises 'Input Delay' ofta. Visserligen är Input Delay vanligtvis inte den största delen av INP men icke desto mindre, om vi optimerar INP-fördröjningen optimerar vi ofta alla INP-interaktioner på en gång!

På CoreDash samlar vi in miljontals Core Web Vitals-datapunkter varje timme. Baserat på den datan står Input Delay för bara 18% av Interaction to Next Paint. Och även om det inte är i närheten av lika mycket som Presentation Delay eller Processing Time är det fortfarande en betydande andel.

Orsaker till Input Delay:

Input delay uppstår när huvudtråden är upptagen med att utföra andra uppgifter. Dessa uppgifter kan komma från:

1. Tidiga uppgifter. Normala, uppskjutna och asynkrona skript som köas tidigt skapar tidiga uppgifter
   
2. Schemalagda uppgifter. Vissa uppgifter körs inte vid sidladdningens start utan kan vara schemalagda till efter att sidan har laddats. Dessa uppgifter kan också störa INP och orsaka en input delay. Till exempel skript som körs efter window.onload-eventet eller skript som fördröjs av så kallade optimeringsplugins.
   
3. Upprepade uppgifter. Återkommande uppgifter via setInterval() som tar relativt lång tid att exekvera och sammanfaller med INP
4. Överlappande callbacks: Överlappande callbacks är en vanlig orsak till input delay. Flera callbacks som schemaläggs nära varandra kan skapa en kö, vilket fördröjer bearbetningen av nästa interaktion.

Minimera input delay

1. Bryt upp långa tidiga uppgifter i flera mindre uppgifter. Under långa uppgifter kan webbläsaren inte svara på användarinmatning medan den efter varje kort uppgift kan svara på användarinmatning. Så bryt upp långa uppgifter med scheduler.yield() (experimentell) eller genom att omsluta varje funktion i en timeout på 0 med setTimeout(callback,0)
2. Hantera interaktiva element. Överväg att inte visa interaktiva element (som ett sökfält) innan JavaScript-koden som styr dem är helt laddad. Detta förhindrar tidiga klick på element som inte är redo att ta emot klick. För att optimera UX för detta mönster kan du antingen prioritera laddningen av nödvändig JavaScript eller tillfälligt dölja/inaktivera elementet tills det är funktionellt.
3. Skriptexekvering vid ledig tid: Schemalägg icke-kritiska skript att köras under webbläsarens lediga perioder med requestIdleCallback(). requestIdleCallback körs när webbläsaren är ledig och inte behöver bearbeta användarinmatning.
4. Använd web workers för att köra JavaScript utanför webbläsarens huvudtråd. Web workers tillåter skript att köras utanför huvudtråden. Detta förhindrar att huvudtråden blockeras och orsakar INP input delay-problem.
5. Kontrollera väntande inmatning under upprepade uppgifter. Innan du utför en uppsättning schemalagda uppgifter, kontrollera om det finns väntande inmatning innan du startar uppgifterna. Om det finns någon väntande inmatning, ge efter till huvudtråden först.
6. Ta bort onödig kod. Granska regelbundet dina skript och ta bort all onödig kod eller till och med skript eftersom varje kodrad potentiellt kan orsaka en input delay som påverkar 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);
  });
}

Praktiska konsekvenser

Låt oss komma till den viktigaste frågan: 'Vad betyder allt detta för min webbplats'. Låt oss bryta ner det för WordPress & REACT.

WordPress

WordPress, på grund av sin natur, kommer ofta med ett tema och ett stort antal plugins. Både plugins och teman förlitar sig ofta på JavaScript för funktionalitet. Eftersom dessa plugins och teman underhålls av tredjepartsutvecklare har vi ingen kontroll över innehållet. Det betyder att vi inte kan ändra filerna och optimera 'dålig kod'. Även om skripten beter sig bra finns det ingen garanti att de kommer att göra det i framtiden.

Så för att minimera input delay och optimera Interaction to Next Paint (INP), gör följande:

• Undvik att använda plugins när det är möjligt. Även om plugins är ett enkelt sätt att lägga till funktionalitet lägger de ofta till skript på sidan. Dessa skript kommer att orsaka en input delay som påverkar INP. För varje plugin, fråga dig själv: Kan jag uppnå samma funktionalitet med egen kod?
• Välj lätta teman. Många WordPress-teman 'erbjuder allt'. Även om det verkar som en bra idé betyder det att de sannolikt är fyllda med funktionalitet som inte används men som ändå tar upp värdefull CPU-tid.
• Undvik sidbyggare. Sidbyggare som Elementor eller WPBakery ger dig ett användarvänligt, visuellt gränssnitt för att bygga layouter. Tyvärr förlitar de sig ofta på skript för att presentera den layouten för besökarna.
• Ladda bara skript när de behövs. WordPress har en tendens att ladda alla skript på alla sidor. För att åtgärda detta, skapa helt enkelt ett barntema och avregistrera onödiga skript per sidtyp. Till exempel:

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-sajter drivs huvudsakligen av JavaScript. Att exekvera dessa skript tar tid och orsakar input delay för Interaction to Next Paint (INP)

• Använd serverkomponenter. Serverkomponenter renderas på servern och inte på klienten vilket leder till en minskad mängd JavaScript
• Ladda tredjepartsskript med rätt strategi. Ladda tredjepartsskript efter hydration eller till och med under webbläsarens lediga tid
• Implementera ett idle until urgent-mönster: Detta mönster prioriterar användarinteraktioner framför bakgrundsuppgifter och skapar tillfälliga tillstånd medan webbläsaren använder requestIdleCallback för att utföra icke-kritiska uppgifter under webbläsarens lediga perioder.
• Lazy load-komponenter. Lazy load-komponenter som inte behövs omedelbart med hjälp av React.lazy() eller NextJS dynamic()
• Använd suspense för interaktiva komponenter. Överväg att bara rendera interaktiva komponenter på klientsidan som behöver hydration för att bli interaktiva.