Amikor az oldalsebesség üzleti kérdés lett
Egy webshop, ahol a mobilos betöltési idő és a konverziós arány között −0,81-es összefüggést mértünk. Ez elég volt ahhoz, hogy a sebesség javítása előrébb kerüljön a feladatok között.
Az oldalsebesség nem csak technikai kérdés. Ezen az oldalon a lassabb betöltés mérhetően alacsonyabb vásárlási aránnyal járt együtt, és ez csak akkor derült ki, amikor két adatforrást összekötöttünk.
Saját mérés, GA4 → BigQuery.
| kb. 5 mp → kb. 3 mp | Átlagos mobilos betöltési idő | körülbelül 40%-kal rövidebb |
|---|---|---|
| 2,60% → 2,73% | Konverziós arány | +0,13 százalékpont, relatív értelemben +5% |
| r = −0,81 | Összefüggés a mobilos betöltési idő és a konverziós arány között | negatív: a hosszabb betöltéshez alacsonyabb arány társult |
Saját mérés · GA4 → BigQuery, mobilos munkamenetek, hat hónap · anonimizált ügyfélprojekt.
A helyzet
Egy nagy forgalmú magyar barkács- és vasáru-webshop keresőoptimalizálásán és használhatóságának javításán dolgoztam. A márkát nem nevezem meg, de a helyzet sok webshopnál ismerős lehet: jelentős organikus forgalom, sok termékoldal és sok mobilról érkező látogató. A cél az volt, hogy a látogatásokból több vásárlás legyen.
Több területen is volt tennivaló. Foglalkozhattunk volna a tartalommal, a belső linkekkel, a kategóriaoldalakkal, a strukturált adatokkal vagy más technikai javításokkal. Azt kellett eldönteni, melyik feladattól várható érdemi üzleti eredmény.
Az oldalsebesség is felmerült, de először meg akartuk érteni, hogyan függ össze a vásárlásokkal. Ezért a méréssel kezdtünk.
Miért maradt háttérben a sebesség?
Az oldal működött, lehetett rajta böngészni és vásárolni. Első ránézésre nem tűnt feltűnően lassúnak, ezért nem volt egyértelmű, mennyire sürgős a gyorsítása.
Egy látványos hibánál könnyebb dönteni: ha nem működik a kosár, meg kell javítani. A kisebb lassulások viszont könnyen háttérbe szorulnak a kampányok, az akciós oldalak és a termékadatok frissítése mellett. Különösen akkor, ha nem tudjuk megmutatni, milyen üzleti következményük lehet.
Arra kerestünk választ, hogy a hosszabb várakozás együtt jár-e alacsonyabb vásárlási aránnyal.
Hogyan mértük?
A Google Tag Manager segítségével teljesítményadatokat gyűjtöttünk, és elküldtük őket a GA4-be. Mértük többek között az oldal és a tartalom betöltéséhez szükséges időt, a dokumentum feldolgozásának egyik időpontját, valamint a szerver válaszidejét.
A GA4 adatait BigQueryben elemeztük. Az adattisztítás és a szélsőséges értékek kezelése után betöltési idő szerint csoportosítottuk a munkameneteket, majd összehasonlítottuk a csoportok konverziós arányát.
Hat hónap mobilos adatait vizsgáltuk. A kérdés egyszerű volt: kisebb arányban vásároltak-e azok, akiknél lassabban töltődött be az oldal?
Az elemzés erős negatív összefüggést mutatott: r = −0,81. A hosszabb betöltési időhöz jellemzően alacsonyabb konverziós arány társult.
Ez önmagában nem bizonyítja, hogy a lassulás okozta a különbséget. A vásárlási arányt a forgalom összetétele, a használt eszközök és más tényezők is befolyásolhatják. Az eredmény azonban elég erős jelzés volt ahhoz, hogy a sebesség javítását előrébb vegyük a feladatok között.
Mi volt a kiinduló állapot?
Az átlagos mobilos betöltési idő nagyjából 5 másodperc volt. Egy webshopban a látogató egymás után több kategória- és termékoldalt is megnyithat, így a várakozás minden újabb oldalnál megismétlődik.
A kiinduló konverziós arány 2,60% volt. A rövidebb betöltési idejű munkamenetek csoportjaiban jellemzően magasabb vásárlási arányt láttunk. Voltak eltérések az egyes csoportok között, de az összefüggés jól kirajzolódott.
Min változtattunk?
A gyorsításhoz több területen kellett hozzányúlni az oldalhoz.
Képek kiszolgálása
Sok kép a szükségesnél nagyobb méretben vagy kevésbé hatékony formátumban töltődött be. A feltöltött képekből több méretváltozatot készítettünk, hogy az oldal a megjelenítéshez megfelelő méretet tudja betölteni.
WebP- és AVIF-formátumot használtunk, és gondoskodtunk az ezeket nem támogató böngészők kiszolgálásáról is. Így mobilon kevesebb képadatot kellett letölteni.
Gyorsítótárazás
A webshop egyedi fejlesztésű rendszerben működött, ezért a gyorsítótárazást a platformhoz kellett igazítani.
Az erőforrás-igényes lekérdezések eredményeit alkalmazásszinten tároltuk el újrafelhasználásra. A szerveren OPcache-t és APCu-t is használtunk, a statikus fájlokat CDN szolgálta ki, és rendeztük a böngésző gyorsítótárazási beállításait.
Külön figyelmet igényelt, hogy mindez ne okozzon elavult árakat, készletinformációkat vagy hibás kosártartalmat. Meg kellett határozni, mely adatokat lehet újrafelhasználni, meddig, és milyen változás esetén kell frissíteni őket.
A megjelenítést késleltető kód
Csökkentettük a feleslegesen betöltött CSS mennyiségét. Az oldal kezdeti használatához nem szükséges JavaScriptet később vagy csak akkor töltöttük be, amikor valóban szükség volt rá.
A kód tömörítése is része volt a munkának. A fő feladat azonban az volt, hogy kevesebb erőforrás letöltésére és feldolgozására kelljen várni az oldal megjelenése előtt.
Folyamatos ellenőrzés
A gyorsítás után is figyeltük a teljesítményt. Egy új banner, külső szkript vagy követőkód ismét lassíthatja az oldalt, ezért ezek hatását is ellenőrizni kell.
Az elért eredmény megtartásához ez ugyanúgy hozzátartozik, mint az első javítások.
Milyen eredményt láttunk?
Az átlagos mobilos betöltési idő nagyjából 5 másodpercről 3 másodpercre csökkent. Ez körülbelül 40%-kal rövidebb betöltési idő.
A konverziós arány 2,60%-ról 2,73%-ra nőtt. A különbség 0,13 százalékpont, ami a kiinduló értékhez képest 5%-os növekedés.
Nagy forgalomnál ekkora változásnak is jelentős üzleti értéke lehet. Havi 500 000 munkamenettel és 35 000 Ft-os átlagos kosárértékkel számolva:
- 2,60%-os konverziós aránynál 13 000 rendelés keletkezik.
- 2,73%-os konverziós aránynál 13 650 rendelés keletkezik.
- A különbség 650 rendelés, ami 35 000 Ft-os átlagos kosárértékkel havi 22,75 millió Ft bevételi különbségnek felel meg.
Ez feltételes számítás. Azt mutatja meg, mekkora bevételi különbséget jelentene a mért konverzióváltozás ekkora forgalom és változatlan átlagos kosárérték mellett. Mobilos konverziós arány esetén a számításban szereplő forgalomnak is mobilos munkamenetekből kell állnia.
A becslés nem igazolja, hogy ennyi többletbevételt kizárólag a gyorsítás hozott. A javítások után mért konverziónövekedésből önmagában nem választható le minden más hatás. Arra viszont alkalmas, hogy érzékeltesse, miért érdemes üzleti szempontból is foglalkozni a sebességgel.
Mit tanultam belőle?
A sebességről könnyű technikai mutatókban beszélni. A vásárló ebből azt érzékeli, hogy várnia kell a terméklistára, későn jelenik meg egy kép, koppintás közben elmozdul egy gomb, vagy az oldal nem reagál azonnal. Ezek a problémák különböző teljesítménymutatókhoz tartoznak, de használat közben egyetlen élménnyé állnak össze.
Ebben a projektben a mérés segített megmutatni, hogy a lassabb betöltés alacsonyabb vásárlási aránnyal járt együtt. Így már konkrét adatok alapján tudtunk beszélni arról, miért kapjon időt a gyorsítás a fejlesztési tervben.
A munkát a belső fejlesztőcsapattal közösen végeztük. Az én feladatom az volt, hogy a SEO- és UX-szempontokat összevessem a mérési eredményekkel, és ezek alapján javaslatot tegyek a fejlesztések sorrendjére.
A megvalósításhoz szükség volt a fejlesztők rendszerismeretére. Ők tudták feltárni, hogyan működnek a lekérdezések, mikor frissülnek az adatok, és mely változtatások érinthetik az árakat, a készletet vagy a kosarat. Ezeket a részleteket közösen kellett végigvennünk.
A projekt számomra azt mutatta meg, mennyivel könnyebb jó fejlesztési döntést hozni, ha a mérés, a SEO, a használhatóság és a fejlesztés szempontjai egyaránt megjelennek benne. Az oldalsebesség így konkrét üzleti célhoz és ellenőrizhető eredményekhez kapcsolódott.
Mit érdemes ellenőrizni a saját oldaladon?
- Vannak adataid arról, milyen gyorsan töltődik be az oldal a valódi látogatóknál?
- Össze tudod kapcsolni a betöltési adatokat a vásárlásokkal, és össze tudod hasonlítani a különböző sebességű munkamenetek konverziós arányát?
- A képekből a megjelenítéshez megfelelő méretű és formátumú változat töltődik be?
- Vannak olyan szkriptek vagy stíluslapok, amelyek késleltetik az oldal megjelenését, pedig kezdetben nincs rájuk szükség?
- Van felelőse annak, hogy az új tartalmak és funkciók bevezetése után is ellenőrizzétek az oldal sebességét?