Miért kezdtünk el foglalkozni a Core Web Vitals mutatókkal?

Az elmúlt hónapokban több ügyfelünk oldalán is azt tapasztaltuk, hogy a jó tartalom és a szép design önmagában nem elég: ha az oldal lassan tölt be, vagy a felhasználó kattintás közben „megugrik” a tartalom, azt a látogatók és a Google is megérzi. Ezért végigvittünk egy komplett sebességoptimalizálási kört a szerverinfrastruktúránktól kezdve egészen a frontend renderelésig – és most megmutatjuk, pontosan mit csináltunk, és milyen valós hatása lett a forgalomra.

A kiindulási helyzet

A vizsgált oldalak Debian 12 alapú szerverünkön futottak, jellemzően megosztott erőforrásokon, klasszikus Apache mpm_prefork konfigurációval. Ez a beállítás önmagában nem rossz, de nagy egyidejű terhelésnél és PHP-alapú CMS-eknél (mint amilyeneket mi is weboldal-fejlesztéshez használunk) komoly szűk keresztmetszetet jelentett.

A Google Search Console és a PageSpeed Insights riportjai egyértelműen három problémás mutatóra hívták fel a figyelmet:

LCP (Largest Contentful Paint) – a legnagyobb, látható tartalmi elem betöltési ideje
INP (Interaction to Next Paint) – a felhasználói interakcióra adott válaszidő
CLS (Cumulative Layout Shift) – az oldal vizuális stabilitása betöltés közben

Amit a szerveroldalon változtattunk

Az első és legnagyobb hatású lépés a szerver architektúra átalakítása volt: leváltottuk a hagyományos Apache mpm_prefork modult MPM event + PHP-FPM kombinációra. Ez lehetővé tette, hogy a szerver lényegesen több egyidejű kapcsolatot tudjon kezelni kevesebb memóriaigénnyel, ami közvetlenül a válaszidőt (TTFB) és így az LCP-t is javította.

Emellett finomhangoltuk a Cloudflare cache- és edge-beállításainkat: agresszívabb böngésző- és edge-cache szabályokat vezettünk be a statikus tartalmakra, valamint bot management és rate limiting szabályokkal szűrtük ki a felesleges, teljesítményt romboló crawler-forgalmat. Ez a fajta folyamatos figyelés és finomhangolás a karbantartási szolgáltatásunk részét képezi.

Amit a frontendben javítottunk

A szerveroldali gyorsítás önmagában nem lett volna elég – a frontendben is volt mit tenni:

Képoptimalizálás: WebP formátumra váltottunk a legtöbb terméklistás és blog képnél, ami jelentősen csökkentette a letöltendő adatmennyiséget.
Layout stabilizálás: minden képhez és beágyazott elemhez explicit méretet (width/height) adtunk, hogy a böngésző már betöltés előtt tudja, mekkora helyet kell fenntartania – ez adta a legnagyobb CLS-javulást.
JavaScript késleltetés: a nem kritikus, harmadik féltől származó szkripteket (statisztika, chat widget) késleltetett betöltésre állítottuk, ami az INP értéket javította.

A mérhető eredmények

Az optimalizálás után 4-6 héttel, amikor a Search Console adatai már stabilizálódtak, a következő tendenciákat láttuk:

Az érintett oldalak jelentős része átkerült a „jó” (green) Core Web Vitals sávba mindhárom mutatóban
Az organikus forgalom mobilon érzékelhetően nőtt, különösen a belépési oldalakon
Csökkent a visszafordulási arány a termék- és cikkoldalakon
Javult az átlagos munkamenet-időtartam, ami arra utal, hogy a felhasználók kényelmesebben navigálnak az oldalon

Fontos hangsúlyozni: a Core Web Vitals önmagában nem „varázsgomb”, amitől egyik napról a másikra megugrik a forgalom. Inkább egy hosszabb távú bizalmi jelzés a Google felé – és persze a látogatók felé is –, hogy az oldal gyors, stabil és megbízható élményt nyújt.

Mit javasolunk, ha a te oldalad is lassú?

Ha nem vagy biztos benne, hogy az oldalad hol áll a Core Web Vitals mutatók terén, érdemes elindulni egy gyors technikai auditból. Nálunk ez jellemzően a keresőoptimalizálási szolgáltatásunk első lépése, amit aztán a szerveroldali és a frontend optimalizálás követ.

Ha szeretnéd, hogy megnézzük a te oldaladat is, vedd fel velünk a kapcsolatot – szívesen összeállítunk egy rövid, konkrét javaslatlistát azzal, hogy mit érdemes elsőként javítani.