Magento 2 sebességoptimalizálás: így lesz tényleg gyors az áruház
A Magento nem lassú. A rosszul összerakott Magento az. Ez az oldal végigveszi, hol keletkezik a lassulás a szervertől a frontendig és melyik beavatkozás mennyit hoz a gyakorlatban.
Mire lőjünk?
Jól beállított Magento áruháznál ezek a szerver oldali értékek reálisak. Ami ennél lényegesen rosszabb, annak oka van és a mérés megtalálja.
- Varnish cache találat10–50 ms
- Kategóriaoldal (PHP)100–300 ms
- Varnish találati arány90% felett
- Core Web Vitalszöld mobilon
- Magento módproduction
A Magento nem lassú. A rosszul összerakott Magento az.
A lassú Magento hírnév abból ered, hogy a platformot sokan úgy üzemeltetik, mint egy WordPresst: megosztott tárhely, alapbeállítások, találomra felrakott modulok. A Magento 2 nagyvállalati architektúra: ha a hozzá tervezett gyorsítótár rétegeket kihagyod, az árát másodpercekben fizeted meg.
A sebesség nem öncél: a konverzióra, a hirdetési minőségi mutatókra és a keresőoptimalizálásra is közvetlenül hat. Utóbbiról a Magento SEO cikkünkben írunk részletesen.
Először mérj
Optimalizálást soha nem kezdünk vaktában. A mérés mutatja meg, hogy a szűk keresztmetszet a szerverben, az alkalmazásban vagy a frontendben van; a három teljesen más beavatkozást kíván.
- TTFB oldaltípusonként: főoldal, kategória, termék, kosár, checkout
- Core Web Vitals valós felhasználói adatból: LCP, INP, CLS
- Varnish és Redis találati arány
- MariaDB lassú lekérdezések
- Indexer és cron futásidők
Hol keletkezik a lassulás?
A Magento gyorsítása architektúra kérdés. Egyetlen csodamodul nincs, sőt a felesleges modul gyakran maga a probléma.
Az alap, amin minden múlik
Megosztott tárhelyen a Magento esélytelen. NVMe SSD, elegendő RAM és dedikált CPU kell alá, méretezett OPcache-sel és jól beállított PHP-FPM worker számmal.
A MariaDB hangolása (buffer pool, lassú query log alapján index-javítások) további tartalékot ad. Magában a friss PHP verzióra váltás is mérhető gyorsulást hoz.
Cache mindenhol
Meglepően sok élő áruház fut developer vagy default módban: ez önmagában több száz ezredmásodperc büntetés. A Redis adja a konfigurációs és blokk cache-t meg a session tárat, a Varnish a teljes oldal cache-t.
Minden indexer update by schedule módban, a cron futása monitorozva. A rosszul időzített reindex csúcsidőben padlóra küldi az áruházat.
Itt dől el a Core Web Vitals
A gyári Luma téma JavaScript öröksége miatt a mobilos pontszámok csak fájdalmasan javíthatók. Tartós megoldást a Hyvä témára váltás ad.
Ha a témaváltás nem fér bele, akkor is sokat hoz: kritikus CSS, JS bundle karcsúsítás, képek WebP és AVIF formátumban, lazy load, CDN és a betűtípusok önkiszolgálása.
Mit hoz ez a gyakorlatban?
Rossz alapokról indulva a szerver-válaszidőben ötös és tízes szorzó is reális. Jó alapoknál a frontend finomhangolása hozza a mérhető különbséget, főleg mobilon.
Minden optimalizálás méréssel indul és méréssel zárul: a beavatkozások előtt és után is dokumentált összehasonlítást adunk, hogy lásd, miért fizettél.
Tipikus lassítók, amiket találni szoktunk
- Nincs Varnish az áruház előtt
- Alulméretezett vagy megosztott szerver
- Developer vagy default mód élesben
- Rossz minőségű harmadik feles modulok
- Luma téma nehéz JavaScriptje mobilon
- Csúcsidőben futó reindex és import
Gyakran ismételt kérdések a Magento sebességről
Miért lassú a Magento 2 webshopom?
Mennyit lehet gyorsítani egy Magento áruházon?
A Hyvä téma tényleg megéri?
Elég egy cache modul a Marketplace-ről?
Flat catalog bekapcsolása gyorsít?
Mérés nélkül vállaltok gyorsítást?
Kapcsolódó cikkek
Mérjük meg az áruházadat
Az ingyenes állapotfelmérés megmutatja a TTFB értékeket oldaltípusonként, a cache találati arányt és azt, melyik rétegben van a legnagyobb tartalék.
