Ügyfelünk egy mintegy 3000 terméket kezelő, WordPress-alapú ipari webáruház katalógust üzemeltet. A felület áttervezésekor egy több fejlesztési réteget, számos egyedi kódot és körülbelül 40 000 képfájlt tartalmazó rendszert vettünk át.
A weboldalon lassú első megjelenés, későn betöltődő képek, ugráló elemek, nehézkes mobilos használat és gyenge termékkatalógus-teljesítmény jelentkezett. Mivel a tüneteket nem egyetlen hiba okozta, a teljes technikai környezetet lépésről lépésre kellett átvizsgálnunk.
Felülvizsgáltuk a bővítményeket, az egyedi kódokat, a konfigurációs fájlokat, az adatbázist és a médiatárat. Optimalizáltuk a képeket, a CSS- és JavaScript-fájlokat, majd Cloudflare CDN-t és lemezes gyorsítótárazást állítottunk be.
A rendelkezésre álló asztali GTmetrix-mérésekben a kezdőlap teljesítménypontszáma 46–54%-ról 90–99%-ra, az LCP pedig 10,7–11,8 másodpercről jellemzően 1 másodperc alá javult.
A legfontosabb eredmények
| Mérőszám | Optimalizálás előtt | Optimalizálás után |
| GTmetrix osztályzat | D–E | jellemzően A |
| Teljesítménypontszám | 46–54% | 90–99% |
| Struktúrapontszám | 77–78% | 92–93% |
| LCP | 10,7–11,8 mp | 0,55–0,99 mp |
| TBT | 106–239 ms | 0–131 ms |
| Legutóbbi kezdőlapi mérés | 46%, 11,1 mp LCP | 98%, 554 ms LCP |
Az LCP több mérésen keresztül 1 másodperc alatt maradt, ami a korábbi állapothoz képest több mint 90%-os csökkenést jelent.
A bemutatott értékek asztali GTmetrix laboratóriumi mérésekből származnak. Nem valós felhasználói Chrome- vagy CrUX-adatok.
Az ügyfél és a kiindulási helyzet
Ügyfelünk weboldala egy ipari és műhelytechnikai termékeket kínáló webáruház, amely megközelítőleg 3000 termék adatlapját kezeli.
A projekt a meglévő weboldal áttervezésével és részleges újraépítésével indult. A rendszer korábbi fejlesztése során párhuzamos staging- és éles környezetek, adatbázis-másolások és egyedi funkciók alakultak ki.
A WordPress alapokra számos saját kódrészlet épült. Egyedi módosítások kerültek a konfigurációs fájlokba, a témába és a funkciókat kezelő állományokba is, miközben több bővítmény részben átfedő feladatokat végzett.
A médiatárban a különböző méretváltozatokkal együtt körülbelül 40 000 képfájl halmozódott fel. Ez nemcsak a betöltési sebességet, hanem a tárhelyhasználatot és a karbantarthatóságot is kedvezőtlenül érintette.
A kihívás
A weboldal teljesítménye fokozatosan romlott. A felhasználók lassú első megjelenést, későn betöltődő képeket, elmozduló felületi elemeket és nehézkes mobilos használatot tapasztalhattak.
A problémát az tette összetetté, hogy nem lehetett egyetlen hibás bővítményre vagy beállításra visszavezetni. Ugyanazt a tünetet okozhatta egy felesleges JavaScript-fájl, egy túlméretezett kép, egy rossz gyorsítótár-beállítás vagy egy korábban hozzáadott egyedi kódrészlet.
Egy gyorsítótárazó bővítmény telepítése ezért önmagában nem jelentett volna tartós megoldást. Először meg kellett értenünk, hogyan épül fel a rendszer, és mely elemek szükségesek ténylegesen a webáruház működéséhez.
A projekt célja
A cél nem kizárólag egy magasabb mérési pontszám elérése volt. Olyan weboldalt kellett kialakítanunk, amely:
- gyorsabban jeleníti meg a kezdő- és termékoldalakat;
- stabilabban tölti be a képeket és a felületi elemeket;
- mobilon is könnyebben használható;
- megtartja a 3000 termékes katalógus működését;
- egyszerűbben karbantartható;
- kevesebb felesleges kódot és bővítményt futtat.
A meglévő termékadatokat és üzleti funkciókat meg kellett őriznünk, miközben a háttérben fokozatosan tisztább technikai alapot alakítottunk ki.
A stratégia és a megvalósítás
1. Kiindulási mérések és technikai audit
GTmetrix-mérésekkel rögzítettük a kiindulási állapotot, majd átvizsgáltuk a WordPress telepítést, az aktív bővítményeket, az egyedi funkciókat és a konfigurációs fájlokat.
Nemcsak azt vizsgáltuk, mi lassítja az oldalt, hanem azt is, hogy mely elemek távolíthatók el a működés veszélyeztetése nélkül.
2. A bővítmények és az egyedi kódok felülvizsgálata
Azonosítottuk a már nem használt, egymással átfedő vagy indokolatlanul sok erőforrást betöltő bővítményeket.
Átnéztük a saját kódrészleteket, a témához kapcsolódó funkciókat és a konfigurációs módosításokat. A felesleges elemeket eltávolítottuk, a szükséges funkciókat pedig megtartottuk vagy átszerveztük.
3. CSS- és JavaScript-optimalizálás
Tömörítettük a CSS- és JavaScript-fájlokat, valamint csökkentettük a nem használt kód mennyiségét.
Azokat a fájlokat, amelyekre egy adott oldalon nem volt szükség, nem töltöttük be automatikusan minden látogatáskor. A kevésbé fontos szkriptek betöltését késleltettük, hogy ne akadályozzák az oldal első megjelenését.
4. A képállomány rendezése
Felülvizsgáltuk a több méretben tárolt, körülbelül 40 000 képfájlt. Eltávolítottuk a bizonyíthatóan felesleges médiafájlokat, a szükséges képeket pedig tömörítettük és korszerű WebP- vagy AVIF-formátumban tettük elérhetővé.
Beállítottuk a késleltetett képbetöltést is, így a böngészőnek nem kell azonnal letöltenie az oldal képernyőn kívüli képeit.
5. Adatbázis-tisztítás
Eltávolítottuk a már nem használt bővítményekhez, korábbi verziókhoz és ideiglenes folyamatokhoz kapcsolódó felesleges adatokat.
A tisztítás célja nem az adatbázis méretének öncélú csökkentése volt, hanem a lekérdezések és a karbantartás egyszerűsítése.
6. Cloudflare és többszintű gyorsítótárazás
Cloudflare CDN-t állítottunk be, hogy a statikus fájlokat a látogatókhoz közelebbi kiszolgálók továbbítsák.
Ezt lemezes gyorsítótárazással egészítettük ki, így a rendszernek nem kellett minden oldalmegnyitáskor teljesen újra előállítania ugyanazt a tartalmat.
7. Folyamatos mérés és finomhangolás
Nem egyetlen mérésből vontunk le következtetést. A kezdőlapot és egy termékoldalt is több napon keresztül monitoroztuk.
A gyorsítótár, a képek és az erőforrás-betöltés beállításait a mérési eredmények és a tényleges működés alapján finomítottuk.
A legnagyobb technikai kihívás
A projekt legösszetettebb része az okok elkülönítése volt. Egy több éven keresztül bővített WordPress rendszerben a teljesítményromlást ritkán egyetlen elem okozza.
Minden módosításnál ellenőriznünk kellett, hogy a sebességjavulás nem jár-e valamely termékoldali, keresési vagy adminisztrációs funkció elvesztésével. Ez lényegesen több időt igényelt, mint egy tiszta technikai alapra épített rendszer optimalizálása.
Alternatív megoldásként felmerült a teljes weboldal tiszta alapokról történő újraépítése. A meglévő termékkatalógus és egyedi funkciók miatt kezdetben az inkrementális tisztítást választottuk, ezzel csökkentve az egyszeri migráció kockázatát.
A projekt végére ugyanakkor világossá vált, hogy az örökölt rendszer feltárására és „gyomlálására” fordított munkaórák miatt egy teljes újraépítés gazdaságosabb is lehetett volna. Ezt azonban csak részletes audit után lehet felelősen eldönteni.
Hogyan működik most a weboldal?
- A látogató megnyitja a kezdőlapot, egy kategóriaoldalt vagy egy termékoldalt.
- A Cloudflare a gyorsítótárazható fájlokat a látogatóhoz közeli kiszolgálóról továbbítja.
- A lemezes gyorsítótár csökkenti a WordPress és az adatbázis terhelését.
- Az oldal csak a ténylegesen szükséges CSS- és JavaScript-fájlokat tölti be.
- A képek tömörített, modern formátumban érkeznek, a képernyőn kívüli elemek pedig késleltetve töltődnek be.
- A rendszeres GTmetrix-monitorozás jelzi, ha egy frissítés vagy új funkció ismét rontani kezdi a teljesítményt.
Az eredmények
11,1 másodpercről 554 milliszekundumra csökkent az LCP
A 2026. május 28-i mérésben a kezdőlap legnagyobb tartalmi eleme 11,1 másodperc alatt jelent meg. A július 16-i mérésben ugyanez 554 milliszekundum volt, ami körülbelül 95%-os javulás.
A többnapos mérési sorozat alapján az LCP a korábbi 10,7–11,8 másodperces tartományból jellemzően 1 másodperc alá csökkent.
46%-ról 98%-ra javult a teljesítménypontszám
A kiindulási időszakban a GTmetrix teljesítménypontszáma 46 és 54% között mozgott. Az optimalizálás után a napi eredmények 90 és 99% közé kerültek.
A weboldal korábbi D–E osztályzata ezzel jellemzően A minősítésre javult.
93%-ra emelkedett a struktúrapontszám
A kezdőlap struktúrapontszáma a korábbi 77–78%-ról 92–93%-ra emelkedett.
Ez azt jelzi, hogy nemcsak a kiszolgálás gyorsult, hanem a böngésző számára átadott oldal felépítése és erőforrás-kezelése is hatékonyabb lett.
A javulás nem csak a kezdőlapon jelent meg
A monitorozott termékoldal teljesítménypontszáma 90–99% között, LCP-értéke pedig 0,74–1,1 másodperc között alakult.
A termékoldal CLS-értéke a bemutatott mérésekben 0 volt, vagyis a tesztek nem észleltek számottevő elrendezés-elmozdulást.
Gyorsabb és kiszámíthatóbb használat
A projekt után a kezdőlap, a termékoldalak és a katalógus érezhetően gyorsabban használható.
A magasabb pontszám önmagában nem üzleti eredmény, de a gyorsabb első megjelenés és a stabilabb felület csökkenti annak esélyét, hogy a látogatók még a termékek megtekintése előtt elhagyják az oldalt.
Konverziós vagy árbevételi növekedést külön mérési adatok hiányában nem kapcsolunk közvetlenül az optimalizáláshoz.
Ügyféloldali tapasztalat
Az ügyfél számára a legfontosabb változást nem önmagában a GTmetrix-pontszám jelentette, hanem az, hogy a több ezer terméket kezelő weboldal gyorsabbá, stabilabbá és könnyebben használhatóvá vált.
A rendszer átláthatóbb technikai alapot kapott, így a későbbi fejlesztések és hibakeresések is kevesebb bizonytalansággal végezhetők.
A projekt legfontosabb tanulsága
Egy régi WordPress weboldalnál nem mindig az optimalizálás a leggazdaságosabb megoldás.
A meglévő rendszer megtartása elsőre kisebb befektetésnek tűnhet, de a dokumentálatlan egyedi kódok, az egymásra épülő bővítmények és a felhalmozott médiaállomány feltárása jelentős munkaórát igényelhet.
Ezért a sebességoptimalizálás első lépése nem egy újabb gyorsító bővítmény telepítése, hanem annak eldöntése, hogy a meglévő rendszer tisztítható-e gazdaságosan, vagy célszerűbb tiszta alapokról újraépíteni.
Összegzés
A weboldal teljesítményét nem egyetlen beállítással, hanem a teljes WordPress rendszer átvizsgálásával javítottuk.
A GTmetrix teljesítménypontszáma 46–54%-ról 90–99%-ra emelkedett, az LCP pedig 11 másodperc körüli értékről jellemzően 1 másodperc alá csökkent. Közben megtartottuk a körülbelül 3000 terméket kezelő katalógust és a szükséges egyedi funkciókat.
A projekt legfontosabb eredménye egy gyorsabb, stabilabb és karbantarthatóbb weboldal lett, de egyben azt is megmutatta, hogy az optimalizálás és a teljes újraépítés költségeit már a munka elején érdemes összehasonlítani.
Régóta stagnál a weboldalad teljesítménye?
Ha a weboldalad egyre lassabb, miközben újabb bővítményekkel és gyorsítótár-beállításokkal sem sikerül tartós javulást elérni, először a probléma valódi okát kell feltárni.
Átvizsgáljuk a technikai felépítést, az egyedi kódokat, a bővítményeket, a képeket és a gyorsítótárazást. Ezután megmutatjuk, hogy a meglévő rendszer optimalizálása vagy a tiszta alapokról történő újraépítés jelenti-e a gazdaságosabb megoldást.
