A Google még 2020-ban mutatta be az oldalélmény mérésére szolgáló Core Web Vitals mutatókat. Mivel a jó oldalélmény beleszámít a rangsorba, így fontos, hogy ezekre a tényezőkre is figyeljünk. Azonban 2024 márciusában az FID mutatószám lecserélésre kerül, helyette az INP (Interaction to Next Paint) kerül.
Ha egy felhasználó végrehajt egy interakciót az oldalon, pl. rákattint egy lenyíló menüre, akkor “elvárja”, hogy az oldal egyből reagáljon, és megjelenjenek az almenük.
Ha sokáig nem reagál az oldal, akkor mint a fenti képen is látszik, sokszor újból rákattintunk a menüre, így mire betöltődne, már be is csukódott. Ez pedig rossz felhasználói élményt eredményez.
Mit jelent az INP?
Az INP egy olyan mérőszám, amely felméri az oldal felhasználói interakciókra adott általános reakcióidejét azáltal, hogy megfigyeli az összes kattintás, koppintás és billentyűzet interakciójának késleltetését. A végső INP érték a leghosszabb megfigyelt interakció, figyelmen kívül hagyva a kiugró értékeket.
Az alacsony INP azt jelenti, hogy az oldal folyamatosan képes volt gyorsan reagálni a felhasználói interakciók összességére – vagy túlnyomó többségére. A jó válaszkészség azt jelenti, hogy az oldal gyorsan reagál a vele végzett interakciókra. Nagyobb oldalaknál, ahol sok interakciót végeznek, az esetleges véletlenszerű akadozások miatt a rendszer minden 50. interakció után figyelmen kívül hagyja a legnagyobb reagálási időt.
Milyen interakciók számítanak bele az INP-be?
Ami az INP-t illeti, csak a következő interakció-típusokat figyeli:
- Kattintás egérrel
- Érintőképernyős eszköz érintése
- Egy billentyű lenyomása a fizikai vagy a képernyő-billentyűzeten.
A hovering és a scrolling (görgetés) nem számít bele az INP-be.
Mi számít jó INP értéknek?
Akkor számít jó értéknek az INP, ha az nem haladja meg a 200 ms értéket.
A 200 ezredmásodperc feletti és az 500 ezredmásodperc alatti vagy kisebb INP azt jelenti, hogy az oldal reagálóképességét javítani kell. Az 500 ezredmásodperc feletti INP azt jelenti, hogy az oldal gyenge reakcióképességű. Összességében akkor tekintjük az INP-t megfelelőnek, ha az oldalmegtekintések 75%-ánál 200 ms alatt volt az INP. Ezt le lehet kérni a Google adatbázisából domain és aloldalak szintjén is.
Miben különbözik az INP az FID-től?
Az INP figyelembe veszi az oldalon töltött valamennyi interakciót, míg az FID csak az első interakciót figyeli. Ezenkívül az FID csak az első interakció bemeneti késleltetését méri, az eseménykezelők futtatásához szükséges időt vagy a következő képkocka megjelenítésének késleltetését nem.
Tapasztalatom szerint az FID vizsgálaton az összes eddigi ügyfelem megfelelt, hiszen annak eredményeképpen, hogy csak az első interakciót figyelte (annak is csak egy részét), FID tekintetében általában jól teljesítettek az oldalak. Ezzel szemben az INP mélyebben vizsgálja az interakciókat és válaszidejüket, illetve átfogó képet ad a teljes weboldalról. Ez az oka annak, hogy az INP tekintetében számos oldal gyengébben teljesít, így célszerű ezeken a paramétereken minél előbb, de legkésőbb 2024 márciusáig javítani.
Hogyan mérhető az INP?
Az FID-hoz hasonlóan az INP is valós felhasználói interakciók alapján számolódik, így ha látni akarjuk az oldal teljesítményét, célszerű az alábbi szoftverek valamelyikét használni:
Google Search Console
Az “alapvető webes vitals-mutatók” nézetben, mind a mobil, mind az asztali jelentést megnyitva látható, hogy ha ezen a téren probléma van az oldallal:
Belekattintva a “Javításra szorul” vagy “Gyenge” súlyozású hibákba, a Search Console kiad néhány minta URL-t, és a hozzá tartozó mért INP értékeket. Érdemes ezeket az oldalakat alaposabban megvizsgálni.
PageSpeed
A https://pagespeed.web.dev/ oldalon bárki letesztelhet egy adott URL-t, mely során láthatja, hogy az utóbbi 28 napban a Chrome felhasználóknál hogyan teljesített az oldal. Amennyiben jobb oldalt átkattintunk az “Eredet”-re, úgy domain szinten is megnézhetjük az eredményeket.
CrUX adatbázis
Amennyiben a weboldal szerepel a Chrome felhasználói élmény jelentésében (CrUX), úgy gyorsan lekérhetjük az INP-re vonatkozó valós adatokat, akár hónapokra lebontva is. Itt látszik az is, hogy például egy esetleges weboldal csere miként módosította az oldalélményt. A https://developer.chrome.com/docs/crux/dashboard/ címen adjuk meg a vizsgálandó domaint (akár versenytársat is):
Ezt követően látjuk, hogy az egyes mutatókban hogyan teljesít a weboldal:
A vizsgált domain jelen esetben rosszul teljesít, az oldallátogatások csupán 19,98%-ában volt megfelelő az INP érték 2023 májusában. Akkor számít jónak az INP érték, ha az oldallátogatások legalább 75%-ában jól teljesít (külön vizsgálva asztali és mobil eszközön).
Mitől lehet az, hogy nincs INP érték?
- Túl kevés volt a látogató az adott aloldalon/domain címen, így még nem áll rendelkezésre elegendő adat.
- Az oldal betöltődött, de a felhasználók nem kattintottak, nem hajtottak végre elég interakciót az oldalon (a görgetés itt nem számít).
Miért nehéz elemezni az INP-t?
- SemRush, Ahrefs, ScreamingFrog és a többi hasonló szoftver nem tudja részletesen elemezni, mert ehhez valós felhasználói interakciók kellenek.
- Mivel az INP valós felhasználói interakciókon alapul, így ha nincs elég adat. ez esetben sem a PageSpeed, sem a Search Console nem fogja visszaadni az INP értékét.
- Ha már van elég adat, és azt látjuk, hogy javítani kell rajta, akkor sem fogjuk tudni, hogy pontosan melyik interakciónál lassul be.
- PageSpeed és Lighthouse elemzésénél legfeljebb a Total Blocking Time (TBT) javítására kaphatunk javaslatokat, amelynek fejlesztése javíthatja az FID és INP értékeket is, mert azok korrelálnak egymással. De attól még, hogy betöltéskor milyen folyamatok tartanak túl sokáig, még nem fogjuk látni, hogy melyek azok az interakciók, amelyek komolyabban befolyásolhatják az INP-t.
INP elemzési lehetőségek
Több eszköz is rendelkezésre áll ahhoz, hogy a valós interakciókat ki tudjuk elemezni, így megállapíthatjuk, az oldal mely területével vannak problémák.
Chrome bővítmény – Web Vitals
A bővítmény telepítését követően minden interakciónál, amit a weboldalon végzünk, megkaphatjuk az aktuális Core Web Vitals értékeket:
Alapesetben az INP érték a leghosszabb interakciós válaszidőt fogja mutatni, így egyben láthatjuk a Core Web Vitals mutatókat. Azonban ha a beállításokban megadjuk, hogy a konzolba is írja ki az adatokat, úgy minden egyes interakciónál megkapjuk, hogy mennyi volt az interakció válaszideje:
A konzol Chrome böngészőben F12-vel érhető el, és látszik, hogy a legutóbbi interakció 24ms ideig tartott (200 alatt megfelelő). Azt is megmutatja, hogy hol és milyen interakciót hajtottunk végre. Így, ha valahol hosszú lenne a várakozási idő, pontosan vissza lehet követni, hogy azt melyik interakció váltotta ki. Lentebb részletesen bemutatásra kerül a 3 részfolyamat.
A bővítmény itt tölthető le: https://chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma
Használati utasítás: https://web.dev/debug-cwvs-with-web-vitals-extension/
Chrome Developer Tools
Amennyiben nincs lehetőségünk, vagy nem szeretnénk bővítményt telepíteni, használhatjuk a Chrome Developer Tools (F12) felületén belül a Lighthouse-t:
A Lighthouse indítása előtt át kell váltani a módot Timespan-re. Néhány másodpercig használjuk a Lighthouse-t, ezalatt a weboldalon különböző interakciókat végzünk. Így mikor leállítjuk a programot, az kiértékeli.
A példában látszik, hogy a menüre kattintva 100ms alatt reagált az oldal, ami jónak számít. Emellett hasznos információkkat szolgáltat a fejlesztők számára. Aki részletesebben is bele akar mélyedni, az a “Performance” fülön az egyes alfeladatokat is tudja elemezni.
Problémás esetek az elemzésben
Vannak olyan helyzetek, amikor a fenti módszerrel nem tudjuk elemezni az oldalt. Ezek közül 2 olyat emelnénk ki, amely érintette valamely ügyfelünket:
Iframe az oldalban
Mikor a Google elemzi az INP értékét, akkor a teljes oldal interakcióját figyeli, beleértve az Iframe-ben lévő interakciókat is (Chrome böngészőn keresztül). Azonban az IFRAME-eket a böngésző külön szálon kezeli, tehát hiába próbáljuk elemezni pl. Web Vitals bővítménnyel az INP-t, sajnos (vagy biztonsági okból inkább szerencsére) az oldalon futtatott Javascript-tel nem érjük el az iframe adatait, így mérni sem tudjuk azt. Ilyen esetben az Iframe keretet közvetlenül is meg kellett hívni a böngészőben, hogy elemezni tudjuk azt.
Dinamikus kiszolgálás – mobil nézet
Vannak olyan weboldalak, ahol a szerver teljesen más kódot küld el a böngészőnek, ha asztali gépen nézik, mint ha mobilon. És hiába próbáltuk a Developer Tools-ban szimulálni a mobilnézetet, nem működött. Szerencsére erre is van egy alternatív megoldás:
Minden mobiltelefonban van egy fejlesztői felület, amely alapesetben rejtve van, de speciális módon elő lehet hívni. Xiaomi telefonok esetében a telefon beállításainál az MIUI-verzióra kell legalább 6-7x egymás után kattintani, hogy ez aktiválódjon.
Innentől elérjük a fejlesztői felületet (nálunk a további beállítások között található), ahol be tudjuk kapcsolni az USB-hibakeresést.
- A telefonon megnyitjuk a Chrome böngészőt és beírjuk a vizsgálandó oldalt
- USB-vel összekötjük a telefont a számítógéppel
- A számítógépen megnyitjuk a Chrome böngészőt, és beírjuk: chrome://inspect/#devices
Ha nem lenne bepipálva a “Discover USB devices”, akkor tegyük meg. Ezt követően másodperceken belül felismeri a böngésző a csatlakoztatott eszközt és a megnyitott oldalakat. Ha az intren.hu oldalnál az “inspect” linkre kattintunk, akkor külön ablakban betölti a developer tools-t:
Ezen a felületen bal oldalt azt látjuk, amit a mobiltelefonunkon is. Jobb oldalt pedig bekapcsoltuk a “Performance” fülön a rögzítést, hogy minden interakciót, mechanizmust rögzítsen, ami segít az elemzésben. Ha nem tudjuk előhozni a felületet, vagy a böngésző nem látja a telefonunkat, itt további megoldási javaslatokat is kapunk: https://developer.chrome.com/docs/devtools/remote-debugging/
Az eddigi vizsgálatok eredményeképp meg tudjuk állapítani, hogy milyen oldalaknál és melyik interakcióknál vannak a problémák.
Az INP részei
Miután megállapítottuk, hogy melyik interakció okoz problémát, lehetőségünk van azt további részekre bontani, és ezáltal még pontosabb képet kapunk arról, hol szükséges a fejlesztőknek beavatkozni. Az interakciónak 3 fázisa van:
- Input delay: Ez ott kezdődik, amikor a felhasználó interakciót kezdeményez az oldallal, és akkor ér véget, amikor a böngésző elkezdi feldolgozni az interakciót
- Processing time: az interakció feldolgozásához tartozó idő
- Presentation delay: Az interakció feldolgozása után mennyi idő kell, hogy ezt vizuálisan elkezdje megjeleníteni.
Nézzük meg újra a menüre kattintás válaszidejét:
Mikor a menüre kattintottunk, a weboldal 1 ms alatt reagált, tehát nem voltak olyan folyamatok, ami miatt várakoznunk kellett volna arra, hogy a böngésző elkezdje feldolgozni a kérésünket. Mivel itt nem kellett semmit elmenteni az adatbázisba, sem bármilyen adatot lekérni szerverről, így a kérés gyorsan feldolgozásra került.
Végül pedig a menüsor baloldalról behúzásra került, amit egy Javascript függvény végzett el. A megjelenítés elkezdéséhez mindössze 23 ms kellett, ami így tökéletes.
Interakciók optimalizálása
A fenti három fázis összideje adja ki az INP értékét.. Az interakció minden egyes fázisa hozzájárul bizonyos ideig a teljes interakciós késleltetéshez, ezért fontos tudni, hogyan optimalizálhatjuk az interakció egyes részeit, hogy azok a lehető legrövidebb ideig fussanak.
The Input delay
Minden esetben van egy kis késleltetés, mire a rendszer elküldi a kérést a böngészőnek, de ezt az értéket a lehető legminimálisabbra kell szorítani.
Az FID érték csak ezt méri, és csak az első interakciónál.
A fenti kép a Developer Tools “Performance” füléről készült, ahol látszik, hogy egy Task már előbb kezdett el dolgozni, mint hogy valamilyen interakciót csináltunk az oldalon. Ebből kifolyólag, amíg a böngésző nem végzett azzal a feladattal, addig blokkolta az interakciónkat, ez az Input delay. Csíkozottan mutatja azt az időt, ahol már túl sokat kellett várni a folyamatra.
Néhány javaslat az Input delay csökkentéséhez:
- Csökkentsük a hosszú folyamatokat, valamint bontsuk több kisebb részre őket. A Processing Time fejezetben konkrét példával is illusztráljuk a folyamatot.
- Bizonyos esetekben előfordul, hogy túl gyorsan több interakciót is végzünk az oldalon. Például termékkereső esetén a keresőkifejezés beírásakor, minden leütés után ad javaslatokat. Ilyenkor előfordulhat, hogy az előző interakciót még nem fejezte be az oldal (azaz még gyűjti a szerver a javaslatokat), de már újabb interakció történt. Ilyenkor javasolt az előző interakciót megszakítani: https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort
- Az animációk szintén sok erőforrást igényelnek, így ahol szükséges, érdemes JS helyett CSS-t alkalmazni.
The Processing Time
Képzeljünk el egy grafikus szerkesztőt, amely gépelés közben formázza a szöveget, kiírja a szavak számát, kiemeli a helyesírási hibákat, és közben folyamatosan elmenti a szöveget, például amikor megszakad az internet kapcsolat.
Ebben a példában a következő négy dolognak kell megtörténnie a felhasználó által beírt karakterek hatására. A következő képkocka megjelenítése előtt azonban csak az első elemet kell elvégezni.
- Frissíti a szövegmezőt a felhasználó által beírt szöveggel, és alkalmazza a szükséges formázást.
- Frissíti a felhasználói felület azon részét, amely megjeleníti az aktuális szavak számát.
- Futtatja a helyesírási ellenőrzést.
- Menti a változtatásokat.
Ha minden billentyűleütésnél el kell végeznie ezt a négy feladatot a böngészőnek, ráadásul egyetlen “nagy” feladatként, ez sok időbe telik, tehát hosszú lesz a processing time:
Épp ezért javasolt, hogy mind a négy feladat legyen szétdarabolva különálló kis funkciókra. Így csak az elsőnek kell lefutnia egyből, a többit pedig lehet a háttérben futtatni (pl. setTimeout függvénnyel):
Ennek köszönhetően a feldolgozási idő lerövidül, gyorsabban megjeleníti a formázott szöveget a képernyőn, illetve a következő billentyű leütésére is gyorsabban tud reagálni.
The presentation delay
Miután a böngésző feldolgozta a folyamatokat, elkezdi megjeleníteni vizuálisan is az eredményt. Azonban ehhez sokszor módosítja az oldal egyes részeit, animál, ami szintén időt vesz igénybe. Néhány terület, ami késleltetheti a megjelenítést:
- Nagy DOM (Document Object Model) méret
Az oldal túl összetett struktúrájú, nagyon sok elemből épül fel. Így a módosítás, újragenerálás is sok időbe telik. Így ezt is érdemes minimalizálni: https://web.dev/dom-size-and-interactivity/ - Nagy oldalaknál lehet lényeges a content-visibility CSS parancs, ami arra szolgál, hogy ami nem látszik a képernyőn, azt ne renderelje a böngésző, ezzel is gyorsítva a folyamatot: https://web.dev/content-visibility/
- Animációk erőforrásigénye
A Javascript-es animációk sok erőforrást igényelhetnek, így javasolt ezt is minimalizálni, illetve CSS-sel elkészíteni.
A fenti képen látható, hogy egy interakció során az oldalon nagyon sok változás történt, amely 2559 elemet érintett.
Összefoglalás
Amint látható, nagyon sok tényező befolyásolja az INP értékét, és a javítása is bonyolult fejlesztői folyamatokat igényelhet, melyet egyedileg kell felülvizsgálni. A cikkben bemutattunk néhány tipikus példát erre, de ezeken kívül még számos további optimalizálási lehetőség van, amelyeket a lenti forrásmegjelölések tovább részleteznek.
Források:
https://web.dev/diagnose-slow-interactions-in-the-lab/
https://developer.chrome.com/docs/devtools/remote-debugging/
