Amikor egy weboldal sebességéről beszélünk, legtöbbször arra gondolunk, milyen gyorsan töltődik be. A jó felhasználói élményhez azonban ez már nem elég. Az is számít, mi történik azután, hogy az oldal megjelent: milyen gyorsan nyílik meg egy menü, reagál egy gomb, működik egy szűrő vagy kerül egy termék a kosárba.
Ezt a válaszkészséget méri az Interaction to Next Paint (INP), amely 2024 márciusában vált a Google Core Web Vitals mutatóinak egyikévé, a korábbi First Input Delay (FID) helyét átvéve.
Az INP segítségével arról kaphatunk képet, hogy a weboldal használat közben mennyire gyorsan reagál a látogató műveleteire. Ez különösen fontos a webáruházaknál, ahol egyetlen munkamenet során számos interakció történhet.
A Google által meghatározott értékek alapján:
- 200 ms vagy kevesebb: jó
- 200–500 ms: fejlesztésre szorul
- 500 ms felett: gyenge
A cél tehát nem pusztán az, hogy a webshop gyorsan betöltődjön. A keresésnek, a szűrésnek, a menüknek, a kosárnak és az űrlapoknak is gyorsan és kiszámíthatóan kell reagálniuk.
Miért fontos az INP egy webáruháznál?
Egy modern webshop kifejezetten interaktív felület. Termékszűrők, lenyíló menük, keresők, képgalériák, kosárfunkciók, kuponmezők és fizetési folyamatok követik egymást.
Ha a látogató rákattint egy gombra, de látszólag semmi nem történik, könnyen újra kattint. Ha egy szűrő alkalmazása után hosszú ideig várnia kell, megszakadhat a böngészés lendülete. Ha pedig a kosár vagy a fizetési folyamat reagál lassan, az már közvetlenül a vásárlási folyamatot érinti.
Az INP azért különösen hasznos teljesítménymutató, mert nem kizárólag az első felhasználói interakcióra koncentrál. A látogatás során bekövetkező interakciókat figyelembe véve próbál képet adni arról, mennyire reszponzív az oldal használat közben.
Fontos ugyanakkor különbséget tenni a jó felhasználói élmény és a Google-rangsorolás között. A Core Web Vitals értékei hasznos jelzést adnak egy oldal technikai felhasználói élményéről, de önmagában egy kiváló INP-érték nem garantál jobb pozíciót a Google találati listáján.
Hogyan mérheted az INP-t?
Mielőtt optimalizálni kezdenél, érdemes pontosan megállapítani, hol van a probléma.
Ehhez több eszköz is rendelkezésre áll:
- PageSpeed Insights
- Google Search Console Core Web Vitals jelentés
- Chrome UX Report (CrUX)
- Chrome DevTools
Különösen értékesek a valós felhasználói adatok, hiszen egy fejlesztő nagy teljesítményű számítógépén és gyors internetkapcsolatán egészen más eredmény születhet, mint egy régebbi mobiltelefonon.
Érdemes a mobil- és asztali eredményeket külön vizsgálni, illetve megnézni az egyes oldaltípusokat is.
Egy webáruháznál például külön figyelmet érdemelhetnek a kategória- és termékoldalak, a kereső, a termékszűrők, a kosár, valamint a fizetési folyamat.
A JavaScript gyakran az INP egyik legnagyobb ellensége
Az INP-optimalizálás során az egyik legfontosabb vizsgálandó terület a JavaScript.
A böngészőnek számos feladatot kell elvégeznie: JavaScriptet futtat, frissíti az oldal tartalmát, kezeli az interakciókat és előkészíti a megjelenítést. Ha a fő szálat hosszú ideig egy nagy számítás vagy túl sok JavaScript-feladat foglalja le, a felhasználói interakciók feldolgozása is késhet.
A látogató ebből csak annyit érzékel, hogy kattintott – az oldal azonban nem reagált azonnal.
Vizsgáld felül a felesleges scripteket
Webáruházaknál az évek során könnyen felhalmozódhatnak a különböző JavaScript-kódok: analitikai eszközök, marketingtagek, chatmodulok, remarketingkódok, közösségimédia-integrációk és különböző bővítmények.
Érdemes időnként felülvizsgálni, hogy ezek közül valóban mindegyikre szükség van-e.
Ne tölts be mindent minden oldalon
A code splitting segítségével a JavaScript kisebb részekre bontható, így nem feltétlenül kell a teljes alkalmazáskódot minden oldalbetöltéskor elküldeni a böngészőnek.
Ha egy funkcióra csak a pénztár oldalon van szükség, nem biztos, hogy annak kódját már a főoldalon is be kell tölteni.
Bontsd fel a hosszú feladatokat
Ha egy összetett JavaScript-feladat hosszú ideig lefoglalja a fő szálat, érdemes kisebb részekre bontani, hogy a böngészőnek közben legyen lehetősége kezelni a felhasználói interakciókat.
Bizonyos számítások akár Web Worker segítségével is áthelyezhetők a fő szálról, míg a nem kritikus feladatok későbbi végrehajtása szintén segíthet a felület válaszkészségének megőrzésében.
Nem minden lassúság INP-probléma
Fontos megérteni, hogy az INP elsősorban a böngészőben érzékelt interakciós válaszkészséget vizsgálja. Nem ugyanaz, mint a szerver válaszideje vagy a weboldal teljes betöltési ideje.
Ez azonban nem jelenti azt, hogy a backend teljesítménye lényegtelen.
Egy webáruház számos interakciója hálózati vagy szerveroldali műveletet is elindíthat. Ilyen lehet például egy AJAX-alapú keresés, dinamikus termékszűrés, készletinformáció lekérése vagy bizonyos kosárműveletek.
A látogató szempontjából végül az számít, hogy az egész folyamat gyorsnak és folyamatosnak érződik-e.
TTFB: amikor a szerver válaszára várunk
A szerveroldali teljesítmény egyik ismert mérőszáma a TTFB (Time to First Byte). Ez azt mutatja meg, mennyi idő telik el addig, amíg a böngésző megkapja a válasz első bájtját.
A magas TTFB mögött több ok is állhat:
- lassú vagy túl sok adatbázis-lekérdezés,
- nagy szerverterhelés,
- nem megfelelő gyorsítótárazás,
- erőforrásigényes alkalmazáskód,
- vagy az adott weboldal számára szűkös szerverkapacitás.
Éppen ezért a frontend optimalizálása mellett a backend teljesítményét is érdemes rendszeresen ellenőrizni.
A cache nemcsak gyorsít, hanem tehermentesít is
A gyorsítótárazás – vagyis a caching – segítségével bizonyos tartalmakat és számítási eredményeket nem kell minden alkalommal újra előállítani.
Ez több szinten is megvalósítható.
A böngésző cache-elheti a statikus fájlokat, a szerver tárolhatja az elkészített oldalakat vagy egyes objektumokat, egy CDN pedig a felhasználóhoz földrajzilag közelebbi pontokról szolgálhat ki statikus tartalmakat.
Dinamikus webáruházaknál az adatbázis és az alkalmazás szintjén alkalmazott megfelelő cache-stratégia szintén jelentősen csökkentheti a háttérrendszer terhelését.
A lényeg azonban nem az, hogy „kapcsoljunk be minden cache-t”, hanem hogy az adott weboldal működéséhez megfelelő gyorsítótárazási stratégiát alakítsunk ki. Egy webshop kosara vagy személyre szabott tartalma például más megközelítést igényel, mint egy ritkán változó bemutatkozó oldal.
A megfelelő infrastruktúra is része a teljesítménynek
Egy optimalizált frontend és backend mellett a weboldalt kiszolgáló infrastruktúra teljesítménye is számít.
Nagyobb forgalmú vagy adatbázis-intenzív webáruházaknál fontos lehet a megfelelő CPU-teljesítmény, a rendelkezésre álló memória, a gyors háttértár és az elegendő hálózati kapacitás.
Az NVMe SSD technológia például nagy I/O-teljesítményt és alacsony késleltetést kínálhat, ami megfelelő környezetben előnyt jelenthet adatintenzív alkalmazások és weboldalak számára.
Ugyanakkor fontos hangsúlyozni: egy gyorsabb szerver önmagában nem javít meg egy rosszul optimalizált weboldalt.
Ha a böngésző fő szálát több száz milliszekundumig blokkolja egy JavaScript-feladat, azt egy erősebb VPS sem fogja megszüntetni. Ugyanígy egy kiválóan optimalizált frontend mögött is kialakulhat lassulás, ha a háttérrendszer túlterhelt vagy az adatbázis nem képes megfelelő sebességgel kiszolgálni a kéréseket.
A jó teljesítmény ezért mindig frontend, backend és infrastruktúra együttműködésének eredménye.
Stabil háttér a gyors weboldalakhoz
Ahogy egy weboldal forgalma és erőforrásigénye növekszik, egyre fontosabbá válhat a megfelelő infrastruktúra kiválasztása.
A FORPSI tárhely-, VPS– és dedikált szervermegoldásai különböző erőforrásigényű weboldalak számára biztosíthatnak technikai alapot. Nagyobb vagy speciális igényű projektek esetén a VPS és a dedikált szerver nagyobb szabadságot adhat az alkalmazáskörnyezet, a rendelkezésre álló erőforrások és a szerveroldali optimalizálás kialakításában.
A megfelelő infrastruktúrát cachinggel, optimalizált adatbázissal és jól felépített alkalmazással kombinálva csökkenthető a háttérrendszer terhelése, és kiszámíthatóbbá tehető a weboldal működése.
Összegzés: a gyors oldal nemcsak betöltődik, hanem reagál is
A weboldal sebessége ma már jóval többet jelent annál, hogy hány másodperc alatt jelenik meg a kezdőképernyő.
A látogató folyamatosan kapcsolatba lép az oldallal: kattint, görget, keres, szűr, terméket helyez a kosárba vagy adatokat ad meg. A jó felhasználói élményhez ezeknek a műveleteknek is gyorsnak és gördülékenynek kell érződniük.
Az INP optimalizálásához ezért érdemes:
- valós felhasználói adatok alapján mérni a teljesítményt,
- csökkenteni a felesleges JavaScriptet,
- felbontani a hosszú főszálas feladatokat,
- átgondolni a harmadik féltől származó scriptek használatát,
- optimalizálni az adatbázist és a backend működését,
- megfelelő cache-stratégiát kialakítani,
- és az oldal erőforrásigényéhez illeszkedő infrastruktúrát választani.
A cél végső soron nem egyetlen PageSpeed-pontszám maximalizálása. A valódi cél az, hogy a látogató gyorsnak érezze az oldalt – a megnyitástól egészen a vásárlás befejezéséig.
Források:
- https://web.dev/articles/inp
- https://developers.google.com/search/docs/appearance/core-web-vitals
- https://developer.chrome.com/docs/crux/
- https://developer.chrome.com/docs/crux/release-notes
- https://developer.chrome.com/docs/performance/
- https://commercev3.com/resources/blog/ultimate-site-speed-optimization-guide-for-ecommerce-development
- https://www.linkgraph.com/blog/interaction-to-next-paint-optimization/
- https://www.inmotionhosting.com/blog/what-is-ssd-hosting/
- https://www.forpsi.hu/webhosting/
- https://www.forpsi.hu/virtual/
