- A legtöbb sebességprobléma a túl nagy képekből és a hiányzó gyorsítótárazásból ered, ezeket érdemes először javítani.
- A Core Web Vitals mobilon dönt: egy siófoki vendéglátó oldalt a nyári forgalom nagy része telefonról nyit meg.
- Minden módosítás előtt és után mérj ugyanazon az URL-en, mobil nézetben, hogy a hatás elkülönüljön a többi tényezőtől.
- A szkriptek (chat, pixel, betűtípus) halasztása gyakran többet hoz, mint a tárhelyváltás.
- A sebesség jó eséllyel segíti a felhasználói élményt és a keresési láthatóságot, de önmagában nem garantál helyezést.
A weboldal gyorsítás Siófokon a legtöbb kisvállalkozásnál ugyanott dől el: a mobilon betöltő képeknél, a gyorsítótárazásnál és a fölösleges szkripteknél. A Balaton legnagyobb városában a keresések nagy része telefonról, gyakran gyenge nyári térerővel érkezik, ezért a mobil sebesség nem műszaki hobbi, hanem a foglalás vagy a telefonhívás előfeltétele. Ez a cikk sorrendbe tett lépésekben mutatja meg, mit érdemes javítani és hogyan mérd le a hatást.
Miért pont Siófokon számít ennyire a mobil sebesség?
Röviden: mert a forgalom szezonális és túlnyomórészt mobilról jön, így a lassú oldal pont a legdrágább pillanatban veszít látogatót.
Hivatalosan igazolt: Siófok a Balaton legnagyobb városa, erősen szezonális turizmussal és vendéglátással, ahol a keresési kereslet a nyári hónapokban sokszorosa a télinek. Saját tapasztalat: egy éttermet, apartmant vagy szolgáltatót kereső látogató jellemzően úton, telefonon nézi meg az oldalt, és ha az lassan nyílik, egyszerűen visszalép a találati listához. Szakmai feltételezés: a szezonális csúcsban ez a néhány másodperc arányaiban több elveszett érdeklődőt jelent, mint télen, mert egyszerre sokan keresnek ugyanarra.
Mik azok a Core Web Vitals, és melyiket kell figyelned?
Röviden: három mérőszám a betöltésről, a válaszkészségről és a stabilitásról, ezeket a Google is figyeli.
Hivatalosan igazolt: a Core Web Vitals három fő mutatóból áll. Az LCP (Largest Contentful Paint) a legnagyobb tartalmi elem megjelenését méri, az INP (Interaction to Next Paint) a felhasználói interakcióra adott válasz gyorsaságát, a CLS (Cumulative Layout Shift) pedig azt, mennyire ugrál be a tartalom betöltés közben. A Google szerint ezek a felhasználói élmény jelei, és a keresési rangsorolás egyik tényezőjét is jelentik. Szakmai feltételezés: kisvállalkozói oldalon a leggyakoribb bűnös az LCP (nagy hero-kép) és a CLS (utólag betöltődő betűtípus vagy cookie-sáv), az INP inkább a sok szkriptet futtató oldalakon romlik el.
Melyik lépéssel kezdd, ha lassú az oldal?
Röviden: a képekkel, mert ott a legnagyobb a nyereség a legkevesebb kockázattal.
A gyakorlatban ez a sorrend válik be a legtöbbször:
- Képek: méretezés, modern formátum, lazy load.
- Gyorsítótárazás (cache): böngésző- és szerveroldali cache, ahol van, CDN.
- Szkriptek: fölösleges bővítmények, chat, pixelek, betűtípusok halasztása.
- Tárhely: csak akkor, ha a fentiek után is lassú a szerverválasz.
Saját tapasztalat: sokan rögtön tárhelyet váltanának, pedig a sebességprobléma nagy része az első három lépésben megoldódik, olcsóbban és kockázatmentesebben.
Hogyan gyorsítsd fel a képeket anélkül, hogy csúnya lenne?
Röviden: töltsd fel a képet akkora méretben, amekkorán megjelenik, konvertáld modern formátumra, és a hajtás alatti képeket töltsd be késleltetve.
A képek jellemzően a letöltött adat többségét adják, ezért itt a legnagyobb a tér. Ellenőrzőlista:
- Ne tölts fel 4000 pixel széles fényképet oda, ahol 800 pixelen jelenik meg. Méretezd át feltöltés előtt.
- Használj WebP vagy AVIF formátumot, ezek jellemzően kisebbek azonos minőség mellett.
- A hajtás alatti (görgetéssel elérhető) képekre tegyél lazy loadot, hogy csak akkor töltsenek be, amikor kellenek.
- A hero-képnek (a legnagyobb, felül látható képnek) viszont NE adj lazy loadot, mert az rontja az LCP-t.
HTML-szinten a lazy load egyszerű:
<img src="strand-800.webp" width="800" height="533" loading="lazy" alt="...">
Szakmai feltételezés: a width és height megadása azért fontos, mert így a böngésző előre lefoglalja a képnek a helyet, és nem ugrik be a tartalom (jobb CLS).
Mit ér a gyorsítótárazás, és hogyan állítsd be?
Röviden: a cache azt jelenti, hogy a visszatérő látogatónak és a szervernek nem kell mindent újra legyártania, így gyorsabb az oldal.
Kétféle gyorsítótárazás számít. A böngésző-cache a látogató gépén tárolja a képeket, betűtípusokat, stíluslapokat, hogy második alkalommal ne töltse le újra. A szerveroldali cache (például WordPressnél egy gyorsítótárazó bővítmény) előre elkészített HTML-t szolgál ki, hogy ne kelljen minden kérésnél újra összeállítani az oldalt. Saját tapasztalat: egy egyszerű, jól beállított cache-bővítmény sokszor érezhetőbb gyorsulást hoz, mint bármi más, és a beállítása egyszeri munka. Ha az oldalt sok, egymástól távoli helyről nézik, egy CDN (tartalomkiszolgáló hálózat) tovább gyorsíthat, mert földrajzilag közelebbről szolgálja ki a fájlokat.
Miért lassítanak a szkriptek, és mit lehet velük tenni?
Röviden: minden beépülő szkript külön letöltés és külön futás, ezért csak azt tartsd meg, ami tényleg kell, a többit halaszd.
Az oldalra rákerülő chat-widget, közösségimédia-beágyazás, hőtérkép, több pixel és néhány betűtípus együtt komolyan visszafoghatja a betöltést és az INP-t. Teendők:
- Nézd végig a bővítményeket, és kapcsold ki, amit nem használsz. A kevesebb szkript kevesebb kockázat is.
- A nem kritikus szkripteket töltsd be
defervagyasyncattribútummal, hogy ne blokkolják a megjelenítést. - A betűtípusokat töltsd önhostolt módon, és használj
font-display: swapbeállítást, hogy a szöveg azonnal olvasható legyen. - A követőkódokat (analitika, pixel) fontold meg címkekezelőn keresztül, késleltetve.
Szakmai feltételezés: egy tipikus vendéglátó oldalon a szkriptek megszelídítése gyakran többet javít a mobil élményen, mint a drágább tárhely.
Mikor a tárhely a szűk keresztmetszet?
Röviden: akkor, ha a kép, cache és szkript rendben van, de a szerver első válasza (TTFB) még mindig lassú.
A TTFB (Time to First Byte) azt méri, mennyi idő alatt kezd válaszolni a szerver. Ha ez tartósan magas, miközben a többi lépést már megtetted, akkor lehet szó tárhelyproblémáról: túlterhelt megosztott szerver, régi PHP-verzió vagy távoli adatközpont. Saját tapasztalat: hazai közönségnél jó eséllyel segít a magyar vagy közeli európai szerver, a friss PHP-verzió és egy nem túlzsúfolt csomag. Szakmai feltételezés: a tárhelyváltás önmagában ritkán csodaszer, de a többi lépéssel együtt stabilabbá teszi a szezonális csúcsban a válaszidőt.
Hogyan mérd le, hogy tényleg gyorsult-e?
Röviden: ugyanazt az URL-t mérd mobil nézetben módosítás előtt és után, és nézd a valós felhasználói adatot is, ne csak a laborteszt-pontszámot.
Két adattípus van. A labormérés (például PageSpeed Insights, Lighthouse) ellenőrzött körülmények között tesztel, gyors visszajelzést ad egy-egy módosításra. A terepadat (a Chrome valós felhasználóktól gyűjtött mérése, a Search Console Core Web Vitals jelentésében) azt mutatja, mit tapasztalnak ténylegesen a látogatók, de lassabban frissül. Mérési ellenőrzőlista:
- Mindig mobil nézetben mérj először, mert a siófoki forgalom nagy része onnan jön.
- Jegyezd fel a kiindulási LCP, INP és CLS értéket, mielőtt bármit módosítanál.
- Egyszerre lehetőleg egy dolgot változtass, hogy a hatás elkülönüljön.
- A terepadatnál számolj heteket, mire a javulás megjelenik, ne ess pánikba az első napokban.
Szakmai feltételezés: a sebesség javulása jó eséllyel segíti a felhasználói élményt és közvetve a keresési láthatóságot, de a rangsorolás sok tényezőből áll, így önmagában a gyorsítás nem garantál helyezést vagy több foglalást.
Milyen sorrendet kövess a következő hónapban?
Röviden: mérj, javíts egy réteget, mérj újra, és csak utána lépj a következőre.
Egy reális, siófoki kisvállalkozásra szabott menetrend: első héten mérés és képoptimalizálás, második héten cache és betűtípusok, harmadik héten a szkriptek átnézése, és csak ezután, ha indokolt, a tárhely. Ez a haladás átlátható marad, és minden lépés hatását külön látod. Saját tapasztalat: a szezon előtt néhány héttel érdemes nekiállni, hogy a csúcsforgalom már a gyorsabb oldalt találja.
Források és további olvasnivalók
- Google Search Central: Core Web Vitals és oldalminőség útmutatók
- web.dev (Google): Learn Performance, LCP, INP, CLS dokumentáció
- Google PageSpeed Insights és Lighthouse dokumentáció
- Chrome User Experience Report (CrUX) dokumentáció
- MDN Web Docs: képoptimalizálás, lazy loading, font-display
- Google Search Console súgó: Core Web Vitals jelentés
Gyakori kérdések
Melyik javítson elsőként egy siófoki kisvállalkozás, ha lassú a mobil oldala?
A képekkel érdemes kezdeni: méretezés a tényleges megjelenítéshez, WebP vagy AVIF formátum és lazy load a hajtás alatti képekre. Ez hozza a legnagyobb gyorsulást a legkisebb kockázattal, és jellemzően közvetlenül javítja az LCP-t mobilon.
Mi az a Core Web Vitals, és miért fontos?
Három mérőszám a felhasználói élményről: az LCP a betöltési sebességet, az INP a válaszkészséget, a CLS a vizuális stabilitást méri. A Google szerint ezek a keresési rangsorolás egyik tényezőjét is jelentik, ezért érdemes mindhármat figyelni, elsősorban mobil nézetben.
Kell-e tárhelyet váltanom, hogy gyorsabb legyen az oldal?
Nem feltétlenül. A tárhelyváltás csak akkor indokolt, ha a képeket, a cache-t és a szkripteket már rendbe tetted, de a szerver első válasza (TTFB) még mindig lassú. A sebességprobléma nagy része a tárhely érintése nélkül is megoldható.
Hogyan mérem le, hogy tényleg gyorsult-e az oldal?
Ugyanazt az URL-t mérd mobil nézetben a módosítás előtt és után, például PageSpeed Insightsban, és jegyezd fel az LCP, INP és CLS értékeket. Emellett nézd a Search Console valós felhasználói (terep) adatait is, ami néhány hét alatt frissül.
Számít-e egyáltalán a sebesség a szezonon kívül?
Igen, de nyáron a tét nagyobb. Siófokon a keresési kereslet a nyári hónapokban sokszorosa a télinek, és ez a forgalom nagyrészt mobilról érkezik, gyakran úton. A csúcs előtt néhány héttel érdemes optimalizálni, hogy a legtöbb érdeklődő már a gyors oldalt találja.
A sok bővítmény lassítja az oldalt?
A fölösleges szkriptek (chat, beágyazások, több pixel, betűtípusok) igen, mert külön letöltést és futást jelentenek, és ronthatják az INP-t. Kapcsold ki, amit nem használsz, a maradékot pedig töltsd be defer vagy async attribútummal, hogy ne blokkolják a megjelenítést.
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.