Google Core Web Vitals optimalizálás Magentón 90 pont feletti eredményhez a kép-optimalizálás (WebP vagy AVIF formátumra váltás), a JavaScript és CSS minifikálás, valamint a szerver válaszidő (TTFB) csökkentése együttesen vezet, mert ez a három terület fedi le a legtöbb pontveszteséget okozó technikai problémát. A mi tapasztalatunk szerint a legtöbb cégvezető egyetlen gyors beavatkozástól – például a cache bekapcsolásától – vár csodát, pedig a 90 pont feletti eredmény csak akkor érhető el tartósan, ha mindhárom terület egyszerre, összehangoltan kerül optimalizálásra. Az esetek jelentős részében a Magento webáruházak azért ragadnak 50-70 pont körül, mert egy-egy terület javítása mellett a másik kettő változatlan marad, és ez korlátozza a teljes potenciált. Ez a cikk konkrét, gyakorlati lépéseket ad ahhoz, hogy egy Magento webáruház valóban 90 pont feletti Core Web Vitals eredményt érjen el mobilon és asztali gépen egyaránt.
Kép-optimalizálás – WebP és AVIF formátumra váltás
A kép-optimalizálás az a terület, amely a leggyorsabban, legkisebb kockázattal hoz mérhető javulást a Core Web Vitals pontszámban, mert a termékfotók és a bannerképek jellemzően a teljes oldalméret legnagyobb részét teszik ki egy Magento katalógusoldalon. Tapasztalataink alapján a hagyományos JPEG vagy PNG formátumról WebP vagy AVIF formátumra váltás önmagában is 30-50 százalékos fájlméret-csökkenést eredményez azonos vizuális minőség mellett, ami közvetlenül javítja a Largest Contentful Paint (LCP) mutatót. Az általunk vizsgált esetekben azok a webáruházak, amelyek automatizált, minden feltöltött képre kiterjedő formátumkonverziót vezettek be, jelentősen gyorsabb kategóriaoldal-betöltést értek el, különösen a sok terméket egyszerre megjelenítő listanézeteknél.
Milyen konkrét beállítások szükségesek a képoptimalizáláshoz?
A hatékony képoptimalizáláshoz szükséges a modern formátumra (WebP vagy AVIF) történő automatikus konverzió, a lusta betöltés (lazy loading) bekapcsolása a görgetési terület alatti képeknél, valamint a responsive képméretezés, amely eszközönként eltérő méretű képet szolgál ki. Mikor nem elegendő önmagában a formátumváltás: ha a képek mérete még konvertált formátumban is túl nagy a megjelenítési felülethez képest, mert ilyenkor a responsive méretezés hiánya továbbra is feleslegesen nagy fájlokat küld a böngészőnek, különösen mobil eszközökön.
JavaScript és CSS minifikálás – a renderelést blokkoló terhek csökkentése
A JavaScript és CSS minifikálás közvetlenül befolyásolja az Interaction to Next Paint (INP) és a First Contentful Paint (FCP) mutatókat, mert a tömörítetlen, feleslegesen nagy kódfájlok lassítják a böngésző feldolgozási és renderelési folyamatát. Az esetek jelentős részében azt tapasztaltuk, hogy a natív Magento admin beállításokban elérhető minifikálási és összefűzési (bundling) opciók bekapcsolása önmagában is érzékelhető javulást hoz, de a valódi áttörést a felesleges, nem használt CSS-szabályok és JavaScript-kód eltávolítása adja, amely gyakran felhalmozódott modulok és bővítmények miatt terheli feleslegesen a rendszert.
Miért nem elegendő önmagában a beépített minifikálás bekapcsolása?
A beépített minifikálás önmagában nem elegendő, mert csak a meglévő fájlok méretét csökkenti, de nem szünteti meg a felesleges, nem használt kódrészeket, amelyeket harmadik féltől származó modulok vagy elavult egyedi fejlesztések hagynak a rendszerben. Kinek nem való a minifikálás egyszeri, alkalmi bekapcsolása: azoknak a webáruházaknak, ahol rendszeresen telepítenek új modulokat, mert minden új bővítmény újabb, potenciálisan nem optimalizált kódot ad a rendszerhez, amelyet rendszeresen felül kell vizsgálni.
| Optimalizálási terület | Érintett Core Web Vitals mutató | Tipikus javulás mértéke |
| Kép-optimalizálás (WebP/AVIF) | Largest Contentful Paint (LCP) | 30–50% fájlméret-csökkenés |
| JS/CSS minifikálás | Interaction to Next Paint (INP), FCP | Érzékelhető renderelési gyorsulás |
| TTFB csökkentése | Time to First Byte, közvetve LCP | Másodperces nagyságrendű javulás |
| Varnish cache bevezetése | Teljes oldalbetöltési idő | Másodpercekről milliszekundumokra |
Szerver válaszidő (TTFB) csökkentése – az alapréteg optimalizálása
A szerver válaszidő, azaz a Time to First Byte (TTFB) csökkentése alapvető fontosságú, mert minden más optimalizálás – legyen szó képekről vagy JavaScript-ről – csak azután érvényesül, hogy a böngésző megkapta a szerver első válaszát. A mi tapasztalatunk szerint a legtöbb ügyfél akkor éri el a legnagyobb TTFB-javulást, ha a Varnish cache-t megfelelően konfigurálja, mert a gyorsítótárazott oldalak esetében a szerver PHP-végrehajtás és adatbázis-lekérdezés nélkül, közvetlenül a memóriából szolgálja ki a választ. A hivatalos teljesítmény-benchmark adatok szerint egy vanília Magento 2.4.9 rendszer megfelelő optimalizálás nélkül mobilon 4,2–5,8 másodperces LCP értéket produkál, míg a jó minősítéshez szükséges küszöb 2,5 másodperc alatt van, ami jól mutatja, mekkora szerepe van a szerveroldali alapoknak a végső pontszámban.
Milyen tényezők befolyásolják leginkább a TTFB-t egy Magento rendszernél?
A TTFB-t elsősorban a hosting infrastruktúra minősége, a PHP-verzió frissessége, az adatbázis-lekérdezések optimalizáltsága és a Full Page Cache backend típusa – beépített fájlrendszer vagy Varnish – befolyásolja, mert ezek együtt határozzák meg, mennyi ideig tart, amíg a szerver elkészíti és elküldi az első választ. Érdemes-e a TTFB csökkentését a kép- és kódoptimalizálás előtt elvégezni? Igen, mert egy lassú szerveroldali alapréteg korlátozza a többi optimalizálás hatékonyságát is, ezért mindig érdemes a szerveroldali réteggel kezdeni a Core Web Vitals fejlesztési folyamatot.
Hogyan érhető el fenntarthatóan a 90 pont feletti eredmény
A 90 pont feletti Core Web Vitals eredmény fenntartható eléréséhez nem elegendő egyetlen, alkalmi optimalizálási kör, mert a pontszám idővel visszaeshet, ha új modulok, képek vagy funkciók kerülnek a rendszerbe optimalizálás nélkül. Tapasztalataink alapján a legtöbb sikeres, tartósan magas pontszámot elérő webáruház rendszeres, ismétlődő teljesítményauditot vezet be, amely minden jelentősebb változtatás után újra ellenőrzi a Core Web Vitals mutatókat.
Milyen sorrendben érdemes végrehajtani a teljes optimalizálási folyamatot?
A teljes optimalizálási folyamatot érdemes a szerveroldali réteggel – Varnish cache, TTFB – kezdeni, majd a kép-optimalizálással folytatni, és végül a JavaScript és CSS minifikálással, valamint a felesleges kód eltávolításával lezárni, mert ez a sorrend biztosítja, hogy minden réteg a lehető legjobb alapra épüljön. Mikor nem ajánlott csak egyetlen területre fókuszálni: ha a cél a tartós, 90 pont feletti eredmény, mert a Core Web Vitals mutatók egymással is összefüggnek, és egyetlen elhanyagolt terület korlátozhatja a teljes pontszámot.
A 90 pont feletti Core Web Vitals eredményhez az alábbi lépéseket érdemes sorban végigjárni:
- A Varnish cache megfelelő konfigurálása és a szerveroldali TTFB optimalizálása.
- Minden termékkép automatikus konvertálása WebP vagy AVIF formátumra, lazy loading bekapcsolásával.
- A JavaScript és CSS fájlok minifikálása és összefűzése, felesleges kód eltávolításával.
- A telepített modulok átvizsgálása, a feleslegesen terhelő bővítmények kivezetése.
- Rendszeres, ismétlődő Core Web Vitals mérés minden jelentősebb változtatás után.
Az optimalizálási folyamat megkezdése előtt érdemes az alábbi szempontokat is átgondolni:
- A jelenlegi Magento üzemeltetés és szerverkörnyezet kapacitása a szükséges változtatásokhoz.
- A CDN bevonásának lehetősége a statikus tartalmak – képek, JS, CSS – gyorsabb kiszolgálásához.
- A meglévő modulok és egyedi fejlesztések hatása a jelenlegi teljesítményre.
- A mobil és asztali mérési eredmények közötti eltérés és annak okai.
- A rendszeres monitoring bevezetése a hosszú távú pontszám megőrzéséhez.
Lazy loading és a görgetési terület feletti tartalom kezelése
A lazy loading helyes bevezetése kritikus fontosságú, mert bár a görgetési terület alatti képek késleltetett betöltése javítja a kezdeti oldalbetöltési sebességet, a görgetési terület feletti, azonnal látható elemekre alkalmazott lazy loading pontosan az ellenkező hatást éri el, és ronthatja a Largest Contentful Paint mutatót. Tapasztalataink alapján a leggyakoribb hiba, amikor a fejlesztők egy globális, minden képre kiterjedő lazy loading szabályt vezetnek be, ahelyett hogy megkülönböztetnék a kezdeti nézetben látható és az alatta elhelyezkedő tartalmat. Az általunk vizsgált esetekben azok a webáruházak érték el a legjobb LCP-eredményt, ahol a hero banner és az első néhány terméksor képei kifejezetten prioritást kaptak, míg a további tartalom lazy loading-gal töltődött be.
Hogyan azonosítható helyesen, mely elemek kaphatnak lazy loading kezelést?
A helyes azonosításhoz meg kell határozni, mely elemek jelennek meg a kezdeti, görgetés nélküli nézetben a legjellemzőbb eszközméreteken, mert ezeknek az elemeknek prioritást kell kapniuk a betöltés során, nem pedig lazy loading-ot. Mikor nem ajánlott automatikus, mindenre kiterjedő lazy loading megoldást alkalmazni: ha a webáruház kategóriaoldalain a hero banner vagy a kiemelt termékek a kezdeti nézetben jelennek meg, mert ezeknél a lazy loading éppen a legfontosabb LCP-mutatót rontja.
Third-party szkriptek hatása a Core Web Vitals pontszámra
A harmadik féltől származó szkriptek – analitikai eszközök, marketing pixelek, chat widgetek – gyakran alábecsült, mégis jelentős hatással vannak a Core Web Vitals pontszámra, mert ezek a szkriptek a saját optimalizálási munkánktól függetlenül töltődnek be, és jelentősen megnövelhetik a JavaScript-végrehajtási időt. Az esetek jelentős részében azt tapasztaltuk, hogy egy egyébként jól optimalizált Magento webáruház pontszáma drasztikusan visszaesik, amint 5-10 különböző marketing- és analitikai szkript kerül a rendszerbe kontroll nélkül.
Hogyan kezelhetők a third-party szkriptek a pontszám romlása nélkül?
A third-party szkriptek kezeléséhez érdemes egy tag management megoldást (például Google Tag Manager) alkalmazni, amely lehetővé teszi a szkriptek késleltetett, feltételes betöltését, ahelyett hogy minden eszköz közvetlenül, azonnal töltődne be minden oldalon. Érdemes-e minden marketing- és analitikai eszközt egyszerre, azonnal betölteni minden oldalon? Nem, mert a legtöbb ilyen szkript nem kritikus a kezdeti felhasználói élmény szempontjából, és késleltetett betöltéssel jelentősen csökkenthető a negatív hatásuk a Core Web Vitals mutatókra.
Font-betöltés optimalizálása és a Cumulative Layout Shift csökkentése
A font-betöltés optimalizálása közvetlenül befolyásolja a Cumulative Layout Shift (CLS) mutatót, mert a rosszul kezelt webfontok betöltése közben a szöveg mérete és pozíciója hirtelen megváltozhat, ami vizuális elmozdulást okoz és rontja a felhasználói élményt. A mi tapasztalatunk szerint a legtöbb Magento webáruház alapértelmezett font-betöltési stratégiája nem veszi figyelembe ezt a problémát, és a CLS-mutató éppen emiatt marad a kívánt küszöb felett annak ellenére, hogy a kép- és kódoptimalizálás egyébként rendben van.
Milyen technikai megoldások csökkentik a font-betöltésből eredő elmozdulást?
A font-betöltésből eredő elmozdulás csökkentéséhez érdemes a font-display: swap vagy font-display: optional CSS-tulajdonságot alkalmazni, valamint a kritikus fontokat előre betölteni (preload) a HTML fejlécben, hogy a böngésző minél hamarabb elkezdje letölteni őket. Kinek nem való a webfontok gondolkodás nélküli, közvetlen beillesztése: azoknak a webáruházaknak, ahol a márkaidentitás miatt egyedi, nem rendszer-alapú betűtípusokat használnak, mert náluk a helytelen font-betöltési stratégia különösen nagy CLS-problémát okozhat a lassabb hálózati kapcsolattal rendelkező látogatóknál.
Melyik optimalizálási sorrend a valódi jó választás a 90 pont eléréséhez
A valódi jó választás sosem az, hogy egyetlen, látványos beavatkozásra – például a képek konvertálására – koncentrálunk, hanem az, hogy a szerveroldali réteg, a kép-optimalizálás és a JavaScript/CSS minifikálás egymásra épülő, tudatos sorrendben, összehangoltan kerül fejlesztésre, mert a Core Web Vitals mutatók szorosan összefüggnek egymással. Tapasztalataink alapján a legtöbb tartósan 90 pont feletti eredményt elérő Magento webáruház a szerveroldali TTFB-vel és a Varnish cache konfigurációjával kezdte a munkát, mert egy lassú alapréteg korlátozza a kép- és kódoptimalizálás hatékonyságát is, majd erre épült a WebP vagy AVIF formátumra váltás és a felesleges kód eltávolítása. Az esetek jelentős részében a legnagyobb, mégis leggyakrabban figyelmen kívül hagyott kockázatot a harmadik féltől származó marketing- és analitikai szkriptek jelentik, mert ezek a saját optimalizálási munkától függetlenül drasztikusan visszavethetik a pontszámot, ha nincsenek tag management megoldással, késleltetett betöltéssel kezelve.
A mi tapasztalatunk szerint a lazy loading és a font-betöltés helyes kezelése olyan finomhangolási lépések, amelyek nélkül a Largest Contentful Paint és a Cumulative Layout Shift mutatók nem érik el a kívánt szintet, még akkor sem, ha a nagyobb optimalizálási lépések már megtörténtek. Kinek nem való az egyszeri, alkalmi optimalizálási kör: azoknak a webáruházaknak, ahol rendszeresen telepítenek új modulokat, képeket vagy funkciókat, mert náluk a pontszám idővel visszaesik, ha nincs bevezetve a rendszeres, ismétlődő teljesítményaudit minden jelentősebb változtatás után. A valódi jó választás tehát egy olyan, tudatosan rétegzett és folyamatosan karbantartott optimalizálási gyakorlat, amely a szerveroldali alapoktól a képeken és a kódon át egészen a harmadik féltől származó szkriptek kezeléséig minden réteget lefed – ez a szemlélet biztosítja, hogy a Magento webáruház ne csak egyszer, hanem tartósan is 90 pont feletti Core Web Vitals eredményt érjen el.
