INP: gör webbplatsen snabbare att använda

INP, Interaction to Next Paint, mäter hur snabbt sidan reagerar när någon klickar, trycker eller använder tangentbordet. Ett högt värde kan göra menyer, filter och formulär tröga även när sidan redan har laddats. Testa därför vad som händer när besökaren använder sidan.

Mätningen löper fram till nästa visuella uppdatering efter en interaktion. Besökets INP sammanfattar de långsammaste interaktionerna och tar hänsyn till hur många som gjorts. En bra nivå är högst 200 millisekunder vid den 75:e percentilen. INP ingår i Core Web Vitals.

Ge snabb återkoppling medan arbetet fortsätter

En produktsökning kan behöva hämta svar från servern. Visa direkt att sökningen har startat, så att besökaren förstår att trycket registrerades och inte behöver trycka igen.

En laddningssymbol är bara den första återkopplingen. Kunden behöver också få rätt sökresultat inom rimlig tid. Kontrollera både reaktionen på trycket och tiden tills uppgiften är klar.

Testa menyer, filter och formulär

Prova vanliga handlingar: öppna menyn, använd filter, byt produktvariant, lägg i varukorgen och fyll i formulär. Gör testerna på mobil med de tillägg och externa tjänster som laddas på den publicerade webbplatsen.

Ett test som bara laddar sidan missar mycket av detta. Om verkliga besök har dålig INP behöver du hitta de klick och funktioner som reagerar långsamt, inte bara testa startsidans laddning igen.

Spela in en enda trög handling

Öppna sidan i Chrome och starta en inspelning i Performance. Gör en handling, till exempel att välja ett produktfilter, och stoppa inspelningen. Leta upp interaktionen och se vad huvudtråden gjorde före klickhanteringen, under den och fram till nästa bildruta.

Skriv ned hur du får fram felet: adress, enhet, valt filter och om sidan nyss har laddats. Testa även en andra gång. ”Storleksfiltret är långsamt på mobil första gången produktlistan öppnas” hjälper utvecklaren mer än ”filter långsamt”.

En lång aktivitet kan hålla huvudtråden upptagen och försena klickhanteringen, även om klickets egen kod är kort. Ligger väntan efter hanteringen granskar du layout och rendering. Upprepa samma test efter rättningen och kontrollera både hastighet och resultat. Använd sedan fältdata för att följa hur ändringen fungerar för besökarna.

Exempel: filter som uppdaterar hela produktlistan

Ett filter kan först sortera tusentals produkter, bygga om listan och uppdatera andra delar av sidan. Om allt sker före nästa visning får besökaren vänta på reaktionen.

Visa filtervalet direkt och se vad som går att förenkla eller göra senare. Utvecklaren behöver läsa prestandainspelningen för att välja rätt lösning. Om det är JavaScript som tar tid hjälper det inte att bara byta en bild till WebP.

Undersök externa tjänster

Chatt, recensioner, mätning, annonser och personalisering kan göra sidan trögare. Lista tjänsterna och när de behöver laddas. Kontrollera också om flera taggar gör samma arbete.

Prova att stänga av den misstänkta tjänsten i utvecklingsmiljön och jämför samma handling. Felet kan ligga i tjänsten, i installationen eller i hur flera komponenter fungerar tillsammans.

Testa både hastighet och funktion

Efter rättningen testar du att filtreringen både reagerar snabbt och visar rätt produkter. Ett filter ska inte se klart ut medan gamla resultat ligger kvar. Prova även med tangentbordet och upprepa handlingen flera gånger.

Följ upp verkliga besök på samma sidtyper. Är det huvudinnehållet som visas sent går du vidare med LCP. Flyttar sig knappen är CLS mer relevant.