A lassú oldal még a jó tartalmat is elrejti: a látogatók egy része néhány másodperc várakozás után visszalép, mielőtt bármit is látna. Ez a cikk sorrendbe tett, konkrét lépéseket ad ahhoz, hogyan gyorsítsd fel egy egyszerű vállalkozói vagy szolgáltatói oldalt, és hogyan ellenőrizd, hogy tényleg javult-e a helyzet. A hangsúly a gyakorlaton van, nem az elméleten.
Miért számít a sebesség egy salgótarjáni vállalkozás oldalán?
Röviden: mert a helyi látogatók zöme mobilról, gyakran gyengébb kapcsolaton érkezik, és a lassú betöltés miatt elhagyhatja az oldalt, mielőtt a kínálatoddal találkozna. Saját tapasztalat: egy kisebb piacú településen a helyi keresésekből érkező forgalom nagy része okostelefonról jön, ahol a hálózat és a készülék is korlátosabb, mint egy irodai gépnél.
Salgótarján kisebb piacú, átalakuló ipari város, ahol viszonylag kevés helyi versenytárs van jelen komolyan az interneten. Ez egyben lehetőség is: szakmai feltételezés, hogy ahol kevés a jól karbantartott, gyors helyi oldal, ott már egy rendezett, gyors weboldal is segítheti, hogy egy salgótarjáni vállalkozás előrébb kerüljön a helyi láthatóságban, viszonylag kis ráfordítással. Ez nem garantál helyezést, de jó alapot ad hozzá, mert a sebesség egyszerre javítja a felhasználói élményt és az egyik keresőoptimalizálási jelzőszámot.
Mit mérnek pontosan a Core Web Vitals mutatók?
Röviden: három mérőszám írja le a valós felhasználói élményt: a fő tartalom betöltésének sebessége, az interakciók válaszideje és a vizuális stabilitás. Hivatalosan igazolt (Google Search Central alapján) a három mutató és a javasolt küszöb:
- LCP (Largest Contentful Paint): a legnagyobb tartalmi elem megjelenése. Jó, ha
2,5 másodpercalatt marad. - INP (Interaction to Next Paint): mennyire gyorsan reagál az oldal a kattintásra, koppintásra. Jó, ha
200 ezredmásodpercalatt van. Ez a mutató váltotta le a korábbi FID-et. - CLS (Cumulative Layout Shift): mennyire ugrál a tartalom betöltés közben. Jó, ha
0,1alatt marad.
Ezek a mutatók a keresőben megjelenő oldalélmény-jelzések részei. Nem az egyetlen rangsorolási tényezők, de a rossz értékek rontják az élményt, és így közvetve a helyi láthatóságot is.
Hogyan kezdj neki a képekkel?
Röviden: a képek a legtöbb kis vállalkozói oldalon a legnagyobb fékek, ezért itt éri meg elsőként rendet tenni. Egy nagy, tömörítetlen fotó önmagában másodperceket adhat a betöltéshez.
Menj végig ezeken lépésről lépésre:
- Használj modern formátumot. A WebP vagy az AVIF általában lényegesen kisebb, mint ugyanaz a kép JPG vagy PNG formában, észrevehető minőségromlás nélkül.
- Méretezd a képet a valós megjelenési méretre. Ne tölts fel 4000 pixel széles fotót oda, ahol a helye 800 pixel. A böngésző így is letölti a teljes fájlt.
- Add meg a szélességet és a magasságot, hogy a böngésző előre lefoglalja a helyet, és ne ugráljon a tartalom (ez a CLS-t javítja).
- Késleltesd a képernyőn kívüli képek betöltését a
loading="lazy"attribútummal, hogy csak akkor töltsenek be, amikor a látogató odagörget.
Egy jól felszerelt kép nagyjából így néz ki a kódban:
<img src="uzlet.webp" width="800" height="600" loading="lazy" alt="Salgotarjani uzlet bejarata">
Saját tapasztalat: a legtöbb magyar kkv-oldalon a képek rendbetétele hozza a legnagyobb, azonnal érezhető gyorsulást, ezért érdemes ezzel kezdeni. A hero-kép (a legfelső, legnagyobb kép) az egyik legfontosabb, mert gyakran ez maga az LCP-elem.
Mit állíts be a gyorsítótárban és a tárhelyen?
Röviden: a gyorsítótár azt éri el, hogy a visszatérő látogató ne töltse le újra ugyanazt, a jó tárhely pedig azt, hogy a szerver gyorsan válaszoljon. A kettő együtt dolgozik.
- Böngésző-cache. Állíts be hosszú lejáratot a ritkán változó fájlokra (képek, betűtípusok, CSS, JavaScript). Egy tipikus fejléc erre:
Cache-Control: public, max-age=31536000, immutable. - Tömörítés. Kapcsold be a Brotli vagy legalább a GZIP tömörítést a szöveges fájlokra. Ez sok esetben a méret jelentős részét levágja.
- Tárhely és PHP-verzió. Egy elavult, túlterhelt tárhelyen minden más optimalizálás keveset ér. WordPress esetén a friss, támogatott PHP-verzió és egy jól konfigurált szerveroldali cache érezhetően gyorsítja a válaszidőt.
- CDN, ha van értelme. Ha a látogatóid nagyobb területről érkeznek, a tartalomszóró hálózat (CDN) közelebb viszi a fájlokat hozzájuk. Egy kizárólag helyi közönségnél ez kevésbé kritikus.
Szakmai feltételezés: egy sűrűn frissülő oldalon a túl agresszív gyorsítótárazás elavult tartalmat mutathat, ezért a cache-szabályokat mindig a fájl típusához igazítsd, és teszteld egy privát böngészőablakban.
Hogyan szelídítsd meg a szkripteket és a betűtípusokat?
Röviden: a felesleges JavaScript és a sok külső szkript blokkolhatja a megjelenítést, és rontja a válaszidőt (az INP-et). Kevesebb és okosabban betöltött szkript gyorsabb oldalt ad.
- Halaszd vagy tedd aszinkronná a szkripteket a
defervagy azasyncattribútummal, hogy ne állítsák meg az oldal felépítését. - Ritkítsd a bővítményeket. WordPressen minden aktív plugin súlyt ad. Ami nincs használatban, azt kapcsold ki és távolítsd el.
- Nézd meg a külső beágyazásokat. Egy beágyazott térkép, videó vagy csevegőablak sok kilobájtot hozhat magával. Töltsd be ezeket csak akkor, amikor tényleg kellenek.
- A betűtípusnál használj
font-display: swapbeállítást, hogy a szöveg azonnal olvasható legyen a saját betűtípus letöltése közben is.
Saját tapasztalat: egy sablonos oldalon gyakran több analitikai és marketingszkript fut, mint amennyire valóban szükség van. Érdemes átnézni, melyik ad tényleg értéket, és a többit levenni.
Hogyan mérd le, hogy tényleg gyorsult-e?
Röviden: mérj a javítás előtt és után, ugyanazzal az eszközzel, mobil profilban, és külön figyeld a laborból és a valós felhasználóktól származó adatot.
Ezekkel az eszközökkel dolgozz:
- PageSpeed Insights. Egyszerre mutat labormérést (Lighthouse) és valós felhasználói mezőadatot (CrUX). A mezőadat a fontos, mert a tényleges látogatók élményét tükrözi, jellemzően egy nagyjából 28 napos ablakból.
- Lighthouse a böngésző fejlesztői eszközeiből: gyors, ismételhető labormérés fejlesztés közben.
- Google Search Console Core Web Vitals jelentése: itt látod, hogy a valós forgalomban mely oldalcsoportok gyengék, és a javítás után követheted a változást.
Fontos: a mezőadat késleltetve frissül, mert több hét látogatásából áll össze. Ezért egy javítás hatása nem azonnal, hanem napok-hetek alatt jelenik meg a valós számokban. A labormérés viszont azonnal visszajelez, ezért fejlesztés közben azzal dolgozz, ellenőrzésre pedig a mezőadatot nézd.
Gyors ellenőrzőlista a nekifutáshoz
- Mérj most, mobil profilban, és jegyezd fel a kiindulási LCP, INP és CLS értéket.
- Cseréld a nagy képeket modern formátumra, méretezd le, adj nekik szélességet és magasságot.
- Kapcsold be a böngésző-cache-t és a Brotli tömörítést.
- Ellenőrizd a tárhelyet és a PHP-verziót, kapcsold ki a felesleges bővítményeket.
- Halaszd a szkripteket, nézd át a külső beágyazásokat, állíts be
font-display: swapbeállítást. - Mérj újra, és pár hét múlva ellenőrizd a Search Console valós adatait is.
Ez a sorrend nem véletlen: a lista elején állnak azok a lépések, amelyek jellemzően a legnagyobb gyorsulást adják a legkisebb kockázattal. Ha csak az első két-három pontot végzed el rendesen, az oldalak nagy részén már érezhető a javulás.
Források és további olvasnivalók
- Google Search Central: Core Web Vitals és az oldalélmény dokumentáció
- web.dev: LCP, INP és CLS útmutatók
- Google PageSpeed Insights és a Lighthouse dokumentáció
- Chrome User Experience Report (CrUX) leírás
- MDN Web Docs: Cache-Control, loading és font-display referencia
- A legtöbb helyi keresés mobilról érkezik, ezért a mobil sebességet állítsd az első helyre.
- A képek optimalizálása hozza jellemzően a legnagyobb gyorsulást a legkisebb ráfordítással.
- A böngésző- és szervercache, valamint a Brotli tömörítés a visszatérő látogatóknál érezhető.
- A felesleges szkriptek és pluginek blokkolják a megjelenítést, ezeket érdemes ritkítani.
- Mindig mérj a javítás előtt és után ugyanazzal az eszközzel, mobil profilban.
Gyakori kérdések
Melyik lépéssel érdemes kezdeni a gyorsítást?
Jellemzően a képekkel, mert egy kis vállalkozói oldalon ez hozza a legnagyobb, azonnal érezhető gyorsulást. Modern formátum, valós méretre skálázás, megadott szélesség és magasság, valamint a képernyőn kívüli képek késleltetett betöltése a leggyorsabb nyereség.
Miből tudom, hogy tényleg lassú az oldalam?
Mérd meg a PageSpeed Insights eszközzel mobil profilban, és nézd a valós felhasználói mezőadatot. Ha az LCP 2,5 másodperc felett, az INP 200 ezredmásodperc felett vagy a CLS 0,1 felett van, van mit javítani.
Mennyi idő alatt látszik a javítás hatása?
A labormérésben azonnal, a valós felhasználói adatban viszont csak napok-hetek alatt, mert a mezőadat több hét látogatásából áll össze, jellemzően egy nagyjából 28 napos ablakból. Ezért érdemes fejlesztés közben laborral, ellenőrzésre pedig a Search Console valós adataival dolgozni.
Számít a Core Web Vitals a helyi keresésben?
A jó oldalélmény az egyik jelzés a kereső számára, de nem az egyetlen rangsorolási tényező. Egy gyors oldal segítheti a helyi láthatóságot és a látogatók megtartását, de önmagában nem garantál helyezést.
Kell drága tárhely a gyors oldalhoz?
Nem feltétlenül, de a tárhely minősége határt szab a többi optimalizálásnak. Egy elavult vagy túlterhelt szerveren a képek és a cache rendbetétele is keveset ér, ezért érdemes friss, támogatott környezetet és jól beállított szerveroldali gyorsítótárat használni.
Miért fontos külön a mobil sebesség?
Mert a helyi keresések nagy része okostelefonról érkezik, gyakran gyengébb hálózaton és lassabb készüléken. Egy asztali gépen gyorsnak tűnő oldal mobilon még lehet lassú, ezért mindig mobil profilban is mérj.
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.