Egy nagy forgalmú magyar hardver webshopnak dolgoztam SEO és UX területen. A márkát nem nevezem meg, mert a projekt nem publikus, de a helyzet elég tipikus volt: erős organikus forgalom, sok termékoldal, nagy mobilhasználat, és egy olyan üzleti cél, ami nem a „legyen szebb az oldal” kategória volt.
Nem volt konkrétan meghatározva, hogy milyen SEO-beavatkozással kell eredményt elérni. A cél az organikus teljesítmény javítása volt, a „hogyan” pedig rám volt bízva. Több irány is szóba jöhetett volna: technikai SEO, tartalom, belső linkelés, kategóriaoldalak vagy strukturált adatok. Én viszont olyan területtel akartam kezdeni, amely nemcsak SEO-ban segíthet, hanem bevételi oldalon is nagyobb hozammal kecsegtet. Ezért került fókuszba a site speed. Nem a legkisebb munka, de nagy forgalmú webshopnál az egyik legjobb üzleti megtérülésű SEO/UX-beavatkozás lehet.
A kiinduló feltételezés egyszerű volt: a lassabb oldalak gyengébben konvertálnak. Ez önmagában nem különösebben új gondolat. A Deloitte és Google „Milliseconds Make Millions” kutatása például azt mutatta, hogy már 0,1 másodperc mobil site speed javulás is mérhető hatással lehet a funnel előrehaladására, retail környezetben pedig 8,4%-os konverziós és 9,2%-os átlagos kosárérték-növekedést figyeltek meg. A web.dev összefoglalója szerint a kutatás 37 európai és amerikai márkaoldal, több mint 30 millió user session és 30 napos mérési időszak alapján készült. A kérdés nálunk nem az volt, hogy „általában számít-e a sebesség”. Hanem az, hogy ezen a konkrét webshopon belül látszik-e üzleti hatás.
A probléma
A webshop technikailag működött. Nem volt összeomolva, nem volt használhatatlan, és első ránézésre nem is tűnt tragikusan lassúnak. Ez a gyakorlatban sokszor veszélyesebb helyzet, mint amikor valami nyilvánvalóan rossz. Ha egy oldal egyértelműen törött, könnyű rábólintani a javításra. Ha viszont „csak” lassabb a kelleténél, akkor a site speed könnyen hátrasorolódik a fejlesztési listán. Itt is ez történt. Volt SEO backlog, UX backlog, fejlesztési backlog, kampányos igények, promóciós oldalak, termékoldali módosítások. A site speed egy volt a sok feladat közül. Ezért először nem optimalizálással kezdtünk, hanem méréssel.
Hogyan mértük?
A mérési logika lényege az volt, hogy ne csak oldalszinten nézzük a sebességet, hanem össze tudjuk kapcsolni a felhasználói viselkedéssel és a konverzióval. Google Tag Managerben beállítottunk egy site speed / Core Web Vitals jellegű adatgyűjtést, amely a mért sebességadatokat GA4-be továbbította. Ez hasonló logikára épült, mint amit Matthew Edgar is bemutat: GA4-ben alapból nincs klasszikus site speed riport, de GTM-en keresztül be lehet küldeni például page_load_time, content_load_time, dom_interactive_time, server_response_time, illetve Core Web Vitals jellegű értékeket. A GA4-ből az adatok BigQuery-be kerültek. Ott történt az adattisztítás, a hibás vagy extrém értékek kezelése, majd a sessionök sebesség szerinti csoportosítása. A cél az volt, hogy ne általános PageSpeed-pontszámokról beszéljünk, hanem erről:
Azok a felhasználók, akik lassabb oldalbetöltést kaptak, rosszabb arányban vásároltak-e?
A válasz igen volt.
A lineáris regresszió erős kapcsolatot mutatott a mobil betöltési sebesség és a konverziós arány között. A korreláció -0,81 lett. Az előjel azért negatív, mert itt a magasabb betöltési idő rosszabb érték: minél lassabb volt a felhasználói élmény, annál alacsonyabb volt a konverziós arány.
Fontos: ezt nem úgy kezeltük, hogy „a regresszió mindent bizonyít”. A korreláció nem ok-okozat. A gyakorlatban viszont sokszor nem is erre van szükség az első döntéshez. Arra van szükség, hogy elég erős jel legyen a priorizáláshoz.Itt az volt.
Mit mutattak az adatok?
A mobil átlagos betöltési idő a kiinduló állapotban körülbelül 5 másodperc volt. Ez nem hangzik drámainak, de ecommerce környezetben sok. Főleg mobilon, terméklista-oldalaknál, kategóriaoldalaknál és termékoldalaknál, ahol a felhasználó nem egy oldalt néz meg, hanem sok apró döntést hoz egymás után.
A baseline konverziós arány 2,6% körül volt.
A sebesség szegmensek összehasonlítása alapján az látszott, hogy a gyorsabb élményt kapó felhasználók jobb arányban jutottak el vásárlásig. Nem minden sor volt tökéletesen szép, nem minden bucket viselkedett tankönyvszerűen. Ilyen a valós adat. De az irány egyértelmű volt.
Ezután a feladat már nem az volt, hogy „nézzük még egy hónapig”. Hanem az, hogy csökkentsük a site speed mutatókat.
A megoldás
A javítás több rétegből állt. Tapasztalatom szerint site speednél ritkán egyetlen nagy trükk hozza az eredményt. Inkább sok kisebb, egymást erősítő döntésből áll össze a különbség.
Az első nagy terület a képek optimalizálása volt.
A webshopnál rengeteg termék- és kategóriakép volt, ami természetes egy hardveres ecommerce oldalon. A gond nem az volt, hogy voltak képek, hanem az, hogy sok esetben nem a megfelelő méretben és formátumban jelentek meg, ezek jellemzően erősen befolyásolják az LCP (Legnagyobb vizuális tartalomválasz) eredményét.
Bevezettünk egy olyan képlogikát, ahol feltöltéskor több méret készült ugyanabból a képből. A frontend nem ugyanazt a nagy képet szolgálta ki mindenkinek, hanem a felhasználó kijelzőméretéhez és eszközéhez igazodó verziót. Ahol lehetett, WebP és AVIF formátumot használtunk, fallback megoldással azoknak a böngészőknek, ahol erre szükség volt.
Ez önmagában sokat számított, főleg mobilon.
A második nagy terület a cache-rendszer volt.
Egy egyedi fejlesztésű webshopnál ez ritkán annyit jelent, hogy bekapcsolunk egy gyorsító plugint, és kész. Itt is több réteget kellett összehangolni. Máshogy kellett kezelni a statikus fájlokat, a gyakran ismétlődő adatbázis-lekérdezéseket, és megint máshogy azokat az elemeket, amelyeknek mindig frissnek kellett maradniuk.
Az erőforrásigényes lekérdezéseket alkalmazásszinten cache-eltük, a szerveroldali működésen OPcache és APCu segített, a képek, CSS- és JavaScript-fájlok kiszolgálása pedig CDN/reverse proxy rétegen keresztül gyorsult. Emellett a böngésző cache-szabályokat is rendbe kellett tenni, hogy a felhasználó ne töltsön le újra mindent minden egyes oldalon belüli kattintásnál.
A nehézség nem maga a cache bekapcsolása volt, hanem az, hogy közben a webshop üzleti működése ne sérüljön. Az áraknak, készletadatoknak és kosárinformációknak mindig frissnek kellett maradniuk. Vagyis nem az volt a cél, hogy mindent agresszíven cache-eljünk, hanem hogy pontosan szétválasszuk, mi gyorsítható biztonságosan, és mi az, amihez nem szabad hozzányúlni.
A harmadik terület a JavaScript és CSS refaktorálás volt.
Itt az volt a cél, hogy ami nem kell az első renderhez, az ne blokkolja az első rendert. Kikerültek felesleges kódrészletek, csökkent a nem használt CSS, és a nem kritikus JavaScript késleltetve vagy feltételesen töltődött be. Ez főleg mobilon segített.
A HTML, CSS és JS tömörítés is bekerült, de ezt nem érdemes túlértékelni. A HTML-minify ritkán az a tétel, ami önmagában megváltja a projektet. Hasznos, de a nagyobb javulást inkább a képek, a cache, a render-blokkoló erőforrások csökkentése és a felesleges frontend logika eltávolítása adta.
A negyedik, kevésbé látványos rész a mérési és fejlesztési fegyelem volt.
Nem egyszeri „site speed projektként” kezeltük a feladatot. Be kellett építeni a folyamatba, hogy egy új banner, új script, új tracking pixel vagy új frontend komponens ne rontsa vissza két hét alatt azt, amit korábban megjavítottunk.
Ez a rész kevésbé izgalmas, de a gyakorlatban sokszor itt dől el, hogy a javítás tartós lesz-e.
Az eredmény
| Mutató | Előtte | Utána |
| Mobil betöltési idő | kb. 5 mp | kb. 3 mp |
| Konverziós arány | 2,6% | 2,73% |
| Relatív konverziós javulás | — | kb. 5% |
- A mobil átlagos betöltési idő körülbelül 5 másodpercről 3 másodpercre csökkent. Ez nagyjából 40%-os javulás.
- A konverziós arány 2,6%-ról 2,73%-ra nőtt. Ez relatív értelemben 5% növekedés. Ha 2,72%-kal számolnánk, az körülbelül 4,6%-os relatív növekedés lenne, tehát publikációban a 2,73% tisztább szám.
Első ránézésre a 2,6% → 2,73% nem tűnik látványosnak. Ezért szoktam óvatos lenni azzal, amikor valaki csak százalékpontokban nézi a konverziós javulást. Nagy forgalmú webshopnál ez már más történet.
A mellékelt mintaszámításban havi 500 000 sessionnel és 35 000 Ft-os átlagos kosárértékkel számolva a javulás körülbelül 22,75 millió Ft becsült havi többletbevételt jelentene. Ez természetesen nem könyvelési adat, hanem publikációs célú becslés, hogy mennyit számít a weboldal betöltődésének sebessége egy nagy forgalmú weboldalon.
Mit tanultunk belőle?
A site speedet sokan még mindig technikai SEO-feladatként kezelik. Részben az is. De egy nagy forgalmú webshopnál gyorsan kiderül, hogy ennél többről van szó. SEO oldalról számít a felfedezhetőség, a felhasználói élmény, a landing page-ek teljesítménye, és persze az is, hogy a Google milyen minőségű oldalt lát. De a felhasználót ezek közül egyik sem érdekli így, ebben a formában. Ő nem PageSpeed-pontszámot lát, hanem azt, hogy várnia kell.
- Lassan jön be a terméklista.
- Késik a kép.
- Megmozdul az oldal, mire kattintana.
- A kosárgomb nem akkor reagál, amikor várná.
Ezek külön-külön nem tűnnek nagy hibának. Egy vásárlási folyamatban viszont összeadódnak. Főleg mobilon, ahol eleve türelmetlenebb a felhasználó, és sokszor nem ideális környezetben böngészik.
Számomra ebben a projektben nem az volt a legfontosabb eredmény, hogy a mobil betöltési idő nagyjából 5 másodpercről 3 másodpercre csökkent. Ez fontos volt, de önmagában még mindig csak egy technikai mutató. A nagy különbséget az jelentette, hogy a sebességet sikerült üzleti nyelvre lefordítani. Nem arról beszéltünk, hogy „rossz a PageSpeed score”. Ez önmagában ritkán mozgat meg egy szervezetet. Arról beszéltünk, hogy a lassabb felhasználói élmény mérhetően gyengébb konverziós aránnyal járt együtt. És ha ezen javítunk, annak bevételi hatása lehet. Ez már egészen más beszélgetés. Azt is fontos hozzátenni, hogy ez nem egyszemélyes projekt volt. Az én feladatom elsősorban az volt, hogy összekössem az üzleti problémát, a SEO-szempontokat, a UX-hatásokat és a mérési adatokat. Ebből kellett olyan fejlesztési prioritást csinálni, ami nem csak szakmailag védhető, hanem üzletileg is értelmes. A megvalósítás viszont a belső fejlesztőcsapat nélkül nem ment volna. Ilyen típusú optimalizálásnál nagyon sok apró döntésen múlik az eredmény: mit lehet cache-elni, mit nem, hogyan kezeljük a képeket, mi törhető ki a CSS-ből vagy JavaScriptből, hol van valódi kockázat, és hol csak megszokásból maradt bent valami a rendszerben.
Ezeket nem lehet kívülről, egy auditból „rámondani” az oldalra. Kell hozzá egy jó fejlesztői csapat, amelyik érti a rendszert, tudja, hol vannak a korlátok, és hajlandó a teljesítményt nem külön technikai feladatként, hanem üzleti célként kezelni. Nekem ez volt a projekt egyik legfontosabb tanulsága: a site speed optimalizálás akkor működik igazán, ha az adat, a SEO, a UX és a fejlesztés nem külön témaként fut, hanem ugyanarra a problémára dolgozik.