A Google 2024. márciusától hivatalosan is rangsorolási tényezőként használja fel Core Web Vitals mutatók legújabb tagját, az INP-et. A bevezetésétől hónapok óta rettegtek a webfejlesztők. Nem is alaptalanul, de lássuk a miérteket!
Az „Interaction to Next Paint” vagy röviden INP mutató azt hivatott mérni, hogy a felhasználói interakciót, például egy gombra kattintást mennyi idővel követ az erre adott vizuális válasz az oldalon. A törekvés helyén való, hiszen a felhasználó számára nyilvánvalóan az alacsony válaszidőkkel rendelkező, reszponzív oldal a kívánatos.
Mint oly sok esetben, a cél itt is szép, de a megvalósítás meglehetősen gyengére sikerült. A mérhető válaszidő ugyanis erősen függ olyan dolgoktól, amire a weblap tulajdonosainak és a webfejlesztőknek semmiféle befolyásuk nincs.
Miért abszurd az INP mérése?
Az INP-et nagyon sok kritika érte, én most csak néhányat emelnék ki a rengeteg felmerült problémából.
- A mobil teljesítménye, memóriájának mérete nagyban behatárolja a mérés eredményét. Ne felejtsük el, hogy egy 2-3 éves, alsó polcos és egy mai csúcs mobil teljesítménye között esetenként 30-szoros eltérés van.
- A felhasználó eszközének terheltsége is kihat a mérés eredményére. Ha egy frissítés vagy egyéb háttérfolyamat köti le a processzort, akkor nyilván minden egyéb alaposan lelassul. Emiatt extrém magas INP értékek is megjelennek.
- Rengeteg téves mérés történik, amelyeknek az interaktivitáshoz köze sincs. Pl. az alert, a confirm és a prompt függvények által megjelenített panelek képernyőn töltött ideje is hozzáadódik a mért eredményhez. Ha a felhasználó 12 másodpercig gondolkodik, akkor 12 másodperc fölött lesz az INP.
- Nincs olyan lehetőség, amely segítségével az INP problémák egyszerűen azonosíthatóak volnának. Próbálkozhatsz bármilyen eszközzel, egzakt eredményekre nem számíthatsz. A mért eredmények finoman szólva esetlegesek.
A fentiek csak kiragadott példák. A fejlesztők felé sokan és sokszor jelezték ezeket, de úgy tűnik, hogy nem igazán lépték át az ingerküszöbüket visszajelzések. Néha persze változtatnak a méréseken, illetve korrigálják a mért adatokat. Ilyenkor látunk az alábbihoz hasonló furcsaságokat a Search Console grafikonjain.
Ilyen körülmények között abszurd ötlet egy minden weblapra és minden interakcióra vonatkozó határértéket meghatározni. Ennek ellenére meghatároztak egy ilyen mutatót, és jelenleg csak a 200 ms alatti értéket tekintik megfelelőnek.
Tippek az INP érték csökkentéséhez
Bármennyire is abszurd az INP mérése, rangsorolási tényezővé vált, így a fejlesztések során figyelembe kell vennünk. Az alábbiakban néhány tippet adok, ami segíthet az INP értékét a megfelelőségi érték alatt tartani.
- Az INP mérések csak a Chrome böngészőből származnak. Tehát az INP optimalizálása során csak a Chrome böngészőre érdemes koncentrálni.
- Használd ki a CSS contain és content-visibility tulajdonságokat, hogy csökkentsd a böngészőben a layout/paint által kiváltott terhelést!
- Azonnal adj vizuális választ! Amíg egy XMLHttpRequest eredménye megérkezik, addig egy „homokóra” is megfelelő vizuális válasz. A felhasználói élményhez ez nem tesz hozzá sokat, de az INP értéket jelentős mértékben csökkentheti.
- Ne használj alert, confirm, prompt JS függvényeket! Ezek egyszerűek, de a fő szálat lefoglalják, így az INP értékhez hozzáadódik az az idő is, amíg a felhasználó olvas és választ ad.
Ha mindent megteszünk is, sok olyan pont marad, amelyre nem vagy csak minimális mértékben lehetünk befolyással. A különféle hirdetési, analytics, CMP és egyéb készen kapott kódokba például nem sok beleszólásunk van. Pedig a méréseink szerint ezek felelősek a magas INP értékek közel 80%-áért. A legtöbb Consent Management Platform kód, vagy leegyszerűsítve „süti banner” kiemelkedően rosszul teljesít. Márpedig a GDPR és egyéb szabályozások miatt ezek megkerülhetetlené váltak.
Nem véletlenül született meg a vicces felvetés, miszerint az INP problémára az egyetlen biztos megoldás az, ha minden felhasználónak adunk egy vadonatúj iPhone vagy Samsung csúcsmobilt.
További információ:
