Što je INP (Interaction to Next Paint) i kako ga popraviti

Interaction to Next Paint je najmlađa od tri Core Web Vitals metrike i oko koje se na internetu nalazi najviše zastarjelih i netočnih informacija. Razlog je jednostavan: Google je tek u ožujku 2024. INP-om zamijenio stariju metriku FID, pa velik dio tekstova još uvijek opisuje pogrešnu stvar. U ovom tekstu objašnjavam što INP zapravo mjeri, po čemu se razlikuje od FID-a i kako ga smanjiti na WordPress stranicama, posebno na webshopovima gdje najčešće zadaje probleme.

Što je INP?

INP (Interaction to Next Paint, u prijevodu „od interakcije do sljedećeg iscrtavanja”) mjeri koliko brzo stranica vizualno odgovori na ono što korisnik napravi. Svaki put kad netko klikne na gumb, otvori izbornik, doda proizvod u košaricu ili upiše nešto u polje, mjeri se vrijeme od te radnje do trenutka kad preglednik prikaže sljedeći vizualni odgovor na ekranu.

Bitno je razumjeti da INP ne mjeri jednu interakciju, nego prati sve interakcije tijekom posjeta i kao reprezentativnu vrijednost uzima najsporiju od njih. Rezultat se izračuna kad korisnik napusti stranicu, pa dobijete jednu brojku koja pokazuje koliko je stranica bila responzivna kroz cijeli posjet, a ne samo na prvi klik.

Pragovi za INP, koje Google mjeri:

Po čemu se INP razlikuje od FID-a

Stara metrika FID (First Input Delay) mjerila je samo kašnjenje prije prve interakcije na stranici, i to samo onaj početni dio, vrijeme do trenutka kad preglednik uopće počne obrađivati klik. FID nije mjerio koliko dugo traje sama obrada ni koliko treba da se rezultat prikaže.

INP je puno stroži i realniji. Promatra cijeli put od interakcije do prikaza, i to za sve interakcije, ne samo prvu. Zbog toga stranica koja je imala odličan FID lako može imati loš INP, jer su problemi često baš u obradi i prikazu, a ne u početnom kašnjenju.

Od čega se INP sastoji

Kao i kod LCP-a, najlakše je INP razumjeti kad se razloži na faze. Svaka interakcija ima tri dijela:

• Kašnjenje unosa (input delay) je vrijeme od trenutka kad korisnik nešto napravi do trenutka kad preglednik uopće može početi obrađivati tu radnju. Ovo kašnjenje najčešće nastaje zato što je glavna nit preglednika zauzeta nekim drugim poslom, obično JavaScriptom koji se izvršava u pozadini.
• Vrijeme obrade (processing time) je vrijeme potrebno da se izvrši sav JavaScript koji reagira na tu interakciju, dakle sami event handleri.
• Kašnjenje prikaza (presentation delay) je vrijeme od završetka obrade do trenutka kad preglednik stvarno prikaže sljedeći kadar s vizualnim rezultatom interakcije.

Kad razmišljam o tome gdje stranica gubi vrijeme, korisno mi je odvojiti kašnjenje unosa od ostalog. Kašnjenje unosa nastaje zato što nešto drugo blokira glavnu nit, dakle uzrok je izvan same interakcije. Vrijeme obrade i kašnjenje prikaza, s druge strane, odnose se na to koliko posla radi kôd koji reagira na klik. Tipičan primjer: kliknete na hamburger izbornik, ali baš u tom trenutku još se izvršava neka skripta, recimo chat widget ili analitika, pa preglednik ne može odmah pokrenuti otvaranje izbornika.

Zašto webshopovi najčešće imaju problema s INP-om

INP je gotovo uvijek loš na strnaicama koje imaju više JavaScripta. Zato složenije stranice, a webshopovi su najbolji primjer, najčešće padaju na ovoj metrici. Na takvim stranicama tipično se vrti mnoštvo skripti: praćenje, brojači, chat widgeti, skripte za košaricu, popusti, baneri za kolačiće i razni dodaci trećih strana.

To je i razlog zašto INP nema pravi laboratorijski ekvivalent. Alati poput Lighthousea ne mogu predvidjeti kada će korisnik kliknuti, pa umjesto INP-a prikazuju metriku TBT (Total Blocking Time) kao zamjenu. TBT mjeri koliko je glavna nit blokirana tijekom učitavanja, što jest povezano s INP-om, ali nije isto. Zato stranica može imati uredan TBT u laboratoriju, a loš INP na terenu, kod stvarnih korisnika. Više o razlici laboratorijskih i terenskih podataka napisao sam u glavnom tekstu o Core Web Vitals.

Kako smanjiti INP na WordPress stranicama

Pristup ovisi o tome u kojoj se fazi gubi najviše vremena, ali u praksi se svodi na nekoliko stvari:

• Smanjenje količine JS-a, posebno skripti trećih strana. Prva stvar koju radim je provjera je li svaki dodatak koji ubacuje skripte uopće potreban i učitava li se na svakoj stranici s razlogom. Svaki suvišan dodatak koji se vrti na glavnoj niti potencijalno pogoršava INP.
• Odgoda učitavanja i izvršavanja nekritičnih skripti tako da se ne natječu s interakcijama korisnika u prvim sekundama, kad je glavna nit najopterećenija.
• Razbijanje dugih zadataka. Kad event handler radi puno posla odjednom, stvara dugi zadatak koji blokira glavnu nit. Razbijanjem tog posla u manje dijelove omogućuje se pregledniku da u međuvremenu obradi druge interakcije.

Kod WordPress webshopova najveći učinak obično dolazi od prve točke, dakle od kritičkog pregleda dodataka i skripti trećih strana. Stranice se s vremenom nakupe dodacima, a svaki donese svoj JavaScript, pa INP tiho raste iako se ništa drugo na stranici nije promijenilo.

Kako izmjeriti INP

Budući da INP ovisi o stvarnoj interakciji, mjeri se drugačije od ostalih metrika. U PageSpeed Insightsu INP ćete vidjeti u odjeljku terenskih podataka, ako stranica ima dovoljno prometa preko Chromea. Za dijagnostiku tijekom rada koristim Performance profiler u Chrome DevToolsima, koji pokazuje razlaganje pojedine interakcije na kašnjenje unosa, vrijeme obrade i kašnjenje prikaza, pa se točno vidi gdje se gubi vrijeme. Vrijednost se prikazuje tek nakon što stvarno kliknete ili nešto upišete na stranici.

Zaključak

INP mjeri koliko brzo stranica odgovara na interakcije korisnika kroz cijeli posjet, a cilj je da to bude unutar 200 milisekundi. Za razliku od starog FID-a, koji je gledao samo prvi klik i samo početno kašnjenje, INP prati cijeli put od interakcije do prikaza i sve interakcije tijekom posjeta. U praksi je glavni uzrok lošeg INP-a previše JavaScripta na glavnoj niti, što je razlog zašto webshopovi i stranice s mnogo dodataka najčešće imaju problema.

Ako vaša stranica djeluje sporo na klik ili sumnjate da imate loš INP, kontaktirajte h1 design za usluge održavanja i/ili SEO optimizacije. Pregledat ću koje skripte opterećuju glavnu nit i smanjiti vrijeme odziva stranice kako bi pružila posjetiteljima dobro korisničko iskustvo i imala temelje za rast.