- A Core Web Vitals három mutatóját (LCP, INP, CLS) mindig mobil nézetben nézd először, mert egy miskolci kisvállalkozás forgalma jellemzően onnan érkezik.
- Mérj a beavatkozás előtt is: PageSpeed Insights és Search Console nélkül nem tudod, mit javítottál.
- A képek optimalizálása adja általában a leggyorsabb, legnagyobb javulást a legkisebb kockázattal.
- A gyorsítótár és a felesleges szkriptek visszavágása a második és harmadik lépés, a tárhely csak akkor kritikus, ha a szerver válaszideje magas.
- A hatást éles adaton, néhány hét múlva ellenőrizd, ne csak a laboratóriumi pontszámon.
A weboldal gyorsítás Miskolc témája nem elvont technikai kérdés: egy helyi vállalkozásnál konkrét bevételi tétel. Ha az oldal lassan tölt, a látogató nagyobb eséllyel lép vissza, mielőtt egyáltalán elolvasná, mit kínálsz. Az alábbiakban sorrendbe tett, gyakorlati lépéseket kapsz, és azt is, hogyan méred le, hogy tényleg gyorsabb lett-e.
Mit jelent a Core Web Vitals, és miért fontos Miskolcon?
A Core Web Vitals a Google három felhasználói élmény-mutatója: mennyi idő alatt jelenik meg a fő tartalom (LCP), mennyire reagál gyorsan az oldal a kattintásra vagy koppintásra (INP), és mennyire ugrál betöltés közben a tartalom (CLS). (Hivatalosan igazolt: a Google 2024 tavaszán az INP mutatót tette a korábbi FID helyére, és a hivatalosan javasolt küszöbök: LCP 2,5 másodperc alatt, INP 200 ezredmásodperc alatt, CLS 0,1 alatt.)
Miskolc hagyományos ipari múltú, egyetemi háttérrel átalakuló gazdaságú város, ahol a régi ipari cégek digitális jelenléte sokszor elmaradt a szolgáltatókétól. (Saját tapasztalat: a helyi keresésekben a látogatók túlnyomó része mobilról érkezik, gyakran útközben, gyengébb hálózaton.) Ezért a mérést és a javítást is mobil nézetben érdemes kezdeni, nem asztali gépen, ahol minden gyorsabbnak tűnik.
Hogyan mérd le a kiindulási állapotot?
Előbb mérj, csak utána nyúlj bele bármihez. Beavatkozás előtti alapérték nélkül nem fogod tudni, hogy a munkád használt-e. Három ingyenes eszköz elég a kiinduláshoz:
- PageSpeed Insights: beírod az URL-t, és külön kapsz laboratóriumi (szimulált) és éles, felhasználói mezőadatot. A mobil fület nézd először.
- Google Search Console Core Web Vitals jelentése: ez valós látogatók adatait mutatja, oldalcsoportokra bontva. Ez a leghitelesebb forrás, mert a te tényleges közönséged élményét méri.
- Chrome DevTools (F12, Lighthouse fül): fejlesztői részletekhez, ha mélyebbre ásol.
Írd fel a három mutató kiindulási értékét, és jegyezd meg a dátumot. Az éles mezőadat 28 napos gördülő ablakot használ, tehát a változás nem azonnal látszik.
Melyik lépéssel kezdd a gyorsítást?
A sorrend a legnagyobb hatás és a legkisebb kockázat felől indul. Egy tipikus lassú oldalnál ez a logikus haladási irány:
- Képek optimalizálása (rendszerint a legnehezebb tartalom).
- Gyorsítótár (cache) bekapcsolása és beállítása.
- Felesleges vagy blokkoló szkriptek visszavágása.
- Tárhely és szerver válaszidő ellenőrzése.
Egyszerre egy dolgot állíts, és mérj utána. Ha öt változtatást tolsz ki egyben, és romlik valami, nem tudod, melyik okozta.
Hogyan gyorsítsd a képeket?
A képek a legtöbb oldalon a betöltési idő nagy részéért felelnek, ezért itt éred el a leggyorsabb javulást. Négy dolgot csinálj végig:
- Méretezd a valós megjelenítéshez: ne tölts fel 4000 pixel széles fotót oda, ahol 800 pixelen jelenik meg. A böngésző a nagy fájlt tölti le, majd kicsinyíti, feleslegesen.
- Használj modern formátumot: a WebP vagy AVReplaceP formátum jellemzően jóval kisebb, mint a régi JPEG vagy PNG, észrevehető minőségromlás nélkül.
- Tömöríts: egy jó tömörítő eszközzel a fájlméret gyakran a felére vagy annál is kisebbre csökken.
- Halaszd a képernyőn kívüli képek betöltését (lazy loading). A modern böngészők ezt egy attribútummal is tudják:
<img src="..." loading="lazy">. A hero, vagyis a legfelső, azonnal látható képen viszont NE használd, mert az rontja az LCP-t.
(Saját tapasztalat: WordPress-alapú helyi oldalaknál a képek rendbetétele önmagában is sokat lendít a mobil pontszámon, mert sok régebbi sablon kezeletlen, nagy méretű fotókkal dolgozik.)
Mit tegyél a gyorsítótárral?
A gyorsítótár arról szól, hogy a böngésző és a szerver ne építse fel újra ugyanazt a tartalmat minden egyes látogatásnál. Két rétegre gondolj:
- Böngésző-oldali cache: a statikus fájlok (kép, CSS, JavaScript) egy ideig a látogató gépén maradnak, így a visszatérő látogatónál nem töltődnek le újra. Ezt a szerver fejlécei szabályozzák.
- Szerver-oldali cache: a rendszer előre elkészített oldalakat szolgál ki a folyamatos újragenerálás helyett. WordPressen ezt bővítmény intézi, sok tárhelyszolgáltató szerver szinten is kínálja.
Ha CDN-t (tartalomelosztó hálózatot) is bekapcsolsz, a fájlok földrajzilag közelebbi szerverről érkeznek. Egy magyar közönségű oldalnál ez kisebb nyereség, mint a képek rendbetétele, de a stabilitáshoz hozzátesz.
Hogyan kezeld a szkripteket?
Minden szkript, amit betöltesz, versenyben áll a fő tartalom megjelenéséért. A leggyakoribb lassító a sok külső, harmadik féltől származó szkript: elemzők, csevegőablak, betűtípusok, közösségi beágyazások. Ellenőrizd:
- Mire van tényleg szükség? A régen bekötött, de már nem használt eszközök szkriptjeit vedd ki.
- Halaszd vagy tedd aszinkronná a nem kritikus szkripteket a
defervagyasyncattribútummal, hogy ne blokkolják a megjelenítést. - A betűtípusokat töltsd okosan: a
font-display: swapbeállítás megakadályozza, hogy a szöveg láthatatlan maradjon a webfont letöltése alatt. - Kerüld a felesleges elrendezés-ugrálást: a képeknek és beágyazásoknak adj fix méretet, így nem lökik szét a tartalmat betöltés közben. Ez közvetlenül a CLS mutatót javítja.
Számít a tárhely a sebességnél?
A tárhely akkor válik szűk keresztmetszetté, ha a szerver válaszideje magas, hiába rendezted a képeket és a szkripteket. A PageSpeed Insights külön kiírja a szerver kezdeti válaszidejét (TTFB). Ha ez tartósan magas, a legjobb képoptimalizálás sem elég.
(Szakmai feltételezés: egy olcsó, túlterhelt osztott tárhelyen sok oldal osztozik ugyanazon a gépen, ezért csúcsidőben belassul. Erre nincs mindig előzetes bizonyítékod, ezért érdemes a TTFB-t hosszabb időn át figyelni, mielőtt tárhelyet váltasz.) A PHP-verzió frissítése és a szerver-oldali cache bekapcsolása gyakran előbb hoz eredményt, mint egy teljes költözés.
Milyen ellenőrzőlistán haladj végig?
Rövid, kipipálható lista, amivel egy fordulóban végigmehetsz:
- Megvan a kiindulási LCP, INP, CLS mobilon, dátummal.
- A képek a megjelenítési méretre vannak vágva.
- Modern (WebP vagy AVIF) formátum és tömörítés bekapcsolva.
- Lazy loading a képernyőn kívüli képeken, a hero képen NEM.
- Böngésző- és szerver-oldali cache aktív.
- Használaton kívüli külső szkriptek eltávolítva.
- Nem kritikus szkripteken
defervagyasync. - Képek és beágyazások fix mérettel (CLS ellen).
- Szerver válaszidő (TTFB) ellenőrizve.
Hogyan mérd le a hatást?
A hatást két szinten nézd: azonnal a laboratóriumi pontszámon, néhány hét múlva pedig az éles felhasználói adaton. A PageSpeed Insights laboradata rögtön mutatja, hogy technikailag gyorsult-e az oldal. A valódi bizonyíték viszont a Search Console Core Web Vitals jelentése és a mezőadat, amely a tényleges látogatók élményét összesíti, jellemzően heteken át gyűlő adatból.
Érdemes a Google Analytics visszafordulási és oldalon töltött idő mutatóit is figyelni ugyanabban az időszakban. Ezek nem sebességmérők, de segíthetnek meglátni, hogy a gyorsabb oldalon tovább maradnak-e a látogatók. Fontos: a sebesség javítása önmagában nem garantia semmilyen pozícióra, csak az egyik olyan tényező, amely a felhasználói élményt és a keresési láthatóságot is támogathatja.
Források és további olvasnivalók
- Google Search Central: Core Web Vitals és Page Experience dokumentáció
- web.dev (Google): Learn Performance és a Web Vitals mutatók magyarázata
- Google PageSpeed Insights hivatalos súgó
- Chrome for Developers: Lighthouse és DevTools Performance útmutatók
- W3C: Web Performance Working Group specifikációk
Gyakori kérdések
Mennyi idő alatt gyorsul be egy lassú oldal?
A képek és a cache rendbetétele sok esetben néhány óra alatt kész, és a laboratóriumi pontszámon azonnal látszik. Az éles Core Web Vitals adat viszont 28 napos gördülő ablakból számol, ezért a valós javulás jellemzően néhány hét múlva olvasható ki tisztán a Search Console-ban.
Miért a mobil nézetet nézzem először?
Mert egy helyi, miskolci közönségnél a látogatók nagy része mobilról érkezik, gyakran gyengébb hálózaton. Az asztali nézet szinte mindig gyorsabbnak tűnik, így megtévesztő képet ad arról, mit tapasztal a tényleges látogató.
Elég csak a képeket optimalizálni?
A képek adják általában a legnagyobb és leggyorsabb javulást, de önmagukban ritkán elegendők. Ha a szerver válaszideje magas, vagy sok felesleges szkript blokkolja a megjelenítést, azok is behúzzák a mutatókat, ezért érdemes a teljes sorrenden végigmenni.
Kell CDN egy magyar közönségű oldalhoz?
Egy döntően hazai látogatottságú oldalnál a CDN kisebb nyereség, mint a képek és a cache rendbetétele, mert a szerver földrajzilag amúgy is közel van. Stabilitáshoz és forgalmi csúcsok kezeléséhez hozzátesz, de nem ez az első lépés.
Javítja a gyorsítás a Google-helyezésemet?
A sebesség az egyik felhasználói élmény-tényező, amelyet a Google figyelembe vesz, így segítheti a láthatóságot, de önmagában nem határozza meg a pozíciót. A tartalom minősége és relevanciája legalább annyit számít, ezért a gyorsítást ezekkel együtt érdemes kezelni.
Honnan tudom, hogy a tárhelyem a szűk keresztmetszet?
A PageSpeed Insights kiírja a szerver kezdeti válaszidejét (TTFB). Ha ez tartósan magas azután is, hogy a képeket és a szkripteket rendbe tetted, akkor jó eséllyel a tárhely a korlát. Előbb a PHP-verzió frissítése és a szerver-oldali cache bekapcsolása segíthet, mielőtt költözésen gondolkodsz.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.