Már nagyon szeretnéd látni a képernyőn az infót, amire rákerestél, de másodpercek óta csak tölt az oldal. Kattintasz még egyet, és ugyanez történik. Ha ezek után nem hagyod el a felületet, akkor te vagy az a végtelenül türelmes látogató, akire egy weboldal tulajdonosa nem építheti a stratégiáját.
A weboldal sebessége a felhasználói élmény egyik alapvető része. A lassú betöltés vagy késve reagáló felület megakasztja a böngészést, megnehezítheti a vásárlást, az ajánlatkérést vagy akár egy egyszerű információ megtalálását. A teljesítmény ráadásul a keresőoptimalizálással is összefügg: a Google a Core Web Vitals mutatókat is felhasználja a rangsorolási rendszereiben, bár a jó teljesítmény önmagában természetesen nem garantál jó helyezést.
A sebesség kérdése ezért nem intézhető el annyival, hogy „gyorsan betölt-e az oldal”. Számít az is, mikor jelenik meg a fontos tartalom, milyen gyorsan reagál a felület a felhasználó műveleteire, és mennyire stabil a megjelenés betöltés közben.
Lassú oldal = elveszett ügyfelek?
Akár igen. Ha egy látogató egy terméket, szolgáltatást vagy információt keres, jellemzően nem azért érkezik a weboldalra, hogy annak betöltésére várjon. Minél több akadály kerül a kívánt művelet elé, annál nagyobb az esély arra, hogy félbehagyja a folyamatot. Ez különösen látványos lehet egy webáruháznál. A lassulás nem feltétlenül a kezdőlapon jelentkezik: előfordulhat, hogy a terméklista gyors, de a kereső, a szűrés, a kosár vagy a fizetési folyamat reagál lassan. A felhasználó számára azonban mindegy, hogy a háttérben szerveroldali lekérdezés, túl sok JavaScript vagy egy külső szolgáltatás okozza a várakozást. Ő egyszerűen azt érzékeli, hogy az oldal nem reagál megfelelően.
Ugyanez igaz egy céges weboldalra is. Ha az érdeklődő az első látogatáskor lassú, akadozó felülettel találkozik, az befolyásolhatja az oldalról és közvetve a vállalkozásról kialakuló benyomását. Ezért a teljesítmény a felhasználói élmény része, nem pusztán fejlesztői technikai kérdés.
A gyors oldal azonban önmagában még nem lesz jó weboldal. A használhatóság, a tartalom, a navigáció, a vizuális hierarchia és a megfelelő technikai háttér együtt számítanak. Egy modern webdesign kialakításánál ezért a teljesítményt már a tervezés és fejlesztés során célszerű figyelembe venni, nem csak akkor, amikor az elkészült oldalról kiderül, hogy lassú.
A weboldal sebessége a Google számára is számít
A „Google a gyorsabb oldalt mindig előrébb sorolja” állítás túlzott leegyszerűsítés. A kereső elsődleges célja továbbra is az, hogy a keresésre releváns és hasznos találatokat adjon. A Google dokumentációja szerint ugyanakkor a Core Web Vitals mutatókat használják a rangsorolási rendszerek, és a jó oldalélmény hozzájárulhat a keresési teljesítményhez. A jó Core Web Vitals eredmény viszont nem helyettesíti a releváns, hasznos tartalmat, és egy tökéletes PageSpeed-pontszám sem jelent automatikusan jobb helyezést.
A sebesség SEO-szempontból tehát fontos, de nem érdemes kizárólag egyetlen mérőszámra optimalizálni. Sokkal jobb cél egy olyan oldal létrehozása, amely a valódi látogatóknál is gyorsan jelenik meg és gyorsan reagál.
Mit jelent valójában az, hogy gyors egy weboldal?
Régebben gyakran egyszerűen a teljes oldal betöltési idejéről beszéltünk. Ez azonban nem írja le pontosan a felhasználói élményt.
Képzelj el két oldalt. Az egyik három másodperc alatt tölt be teljesen, de a fontos tartalma már egy másodperc után látható és használható. A másik szintén három másodperc alatt készül el, de addig szinte üres képernyőt mutat. A technikai „teljes betöltési idő” hasonló lehet, a felhasználói élmény mégis egészen más.
Ezért használ a Google is több mutatót a Core Web Vitals rendszerében.
LCP: mikor jelenik meg a fő tartalom?
A Largest Contentful Paint (LCP) azt méri, mennyi idő alatt jelenik meg a látható területen található legnagyobb releváns kép- vagy szövegelem. Ez gyakran egy nagyméretű nyitókép, banner vagy nagy szövegblokk. A Google jelenlegi ajánlása szerint jó felhasználói élményhez az LCP-nek 2,5 másodpercen belül kell megtörténnie. A minősítésnél nem egyetlen tesztet néznek: a valós látogatások 75. percentilise az irányadó. Ha például a nyitóképet túl nagy fájlként tölti le a böngésző, vagy a szerver lassan kezdi el kiszolgálni az oldalt, az LCP könnyen romolhat.
INP: milyen gyorsan reagál az oldal?
Az Interaction to Next Paint (INP) a felület válaszkészségét méri. Vagyis azt vizsgálja, mennyi idő telik el egy felhasználói interakció – például kattintás vagy koppintás – és az azt követő vizuális visszajelzés között. Jó értéknek jelenleg a 200 milliszekundum vagy annál alacsonyabb INP számít.
Ez azért lényeges, mert egy oldal akár gyorsan meg is jelenhet, mégis érezhetjük lassúnak. Ha megnyomunk egy gombot, de látszólag nem történik semmi, ösztönösen újra kattintunk, vagy egyszerűen azt feltételezzük, hogy valami elromlott. Az INP problémák hátterében gyakran túl sok vagy túl hosszú ideig futó JavaScript-feladat áll. Ilyenkor a böngésző fő szála annyira elfoglalt, hogy nem tud időben reagálni a felhasználóra.
CLS: ugrál-e a tartalom betöltés közben?
A Cumulative Layout Shift (CLS) nem klasszikus sebességmutató, mégis szorosan kapcsolódik az oldalélményhez. Azt méri, mennyire változik váratlanul az oldal elrendezése. Ismerős helyzet, amikor már éppen rákattintanál valamire, de betöltődik fölötte egy kép vagy hirdetés, az egész tartalom lejjebb ugrik, és végül teljesen más elemre kattintasz. Pontosan ezt a jelenséget segít mérni a CLS.
Jó eredménynek 0,1 vagy annál alacsonyabb CLS számít. A problémát okozhatják például méretmegadás nélkül beillesztett képek, utólag megjelenő tartalmi blokkok vagy nem megfelelően kezelt webfontok.
Hogyan mérheted meg a weboldalad sebességét?
A sebességoptimalizálást mérés nélkül nem érdemes elkezdeni. Attól, hogy egy oldal a saját laptopodon és internetkapcsolatodon gyorsnak tűnik, egy régebbi mobiltelefonról vagy lassabb mobilhálózatról még lehet problémás.
Az egyik legismertebb eszköz a Google PageSpeed Insights, amely laboratóriumi mérési eredményeket és – ha elegendő adat áll rendelkezésre – valós Chrome-felhasználóktól származó adatokat is meg tud jeleníteni. A Google Search Console Core Web Vitals jelentése pedig abban segít, hogy webhelyszinten azonosítsd a problémás oldalcsoportokat.
A laboradat és a valós felhasználói adat között fontos különbség van. A laboratóriumi teszt kontrollált körülmények között vizsgálja az oldalt, ezért jól használható hibakeresésre. A valós mérési adatok viszont azt mutatják meg, mit tapasztalnak ténylegesen a látogatók különböző eszközökön és hálózatokon. Ezért egyetlen teszt eredményéből nem érdemes messzemenő következtetést levonni. A teljesítményt célszerű mobilon és asztali környezetben is vizsgálni, majd a konkrét lassulás okát megkeresni.
Milyen tényezők lassíthatják a weboldalt?
A lassú oldalnak ritkán van egyetlen oka. A böngészőnek a HTML mellett képeket, stíluslapokat, JavaScript-fájlokat, betűkészleteket és gyakran külső szolgáltatások erőforrásait is le kell töltenie és fel kell dolgoznia. Közben a szervernek is elő kell állítania vagy ki kell szolgálnia a kért tartalmat. Éppen ezért a teljesítményprobléma lehet frontend-, backend-, hálózati vagy infrastrukturális eredetű.
Túl nagy képek és videók
A nagy felbontású képek jelentős adatforgalmat okozhatnak. Különösen pazarló, ha a weboldal például egy több ezer pixel széles képet tölt le azért, hogy azt végül néhány száz pixeles méretben jelenítse meg. A képoptimalizálás nem egyszerűen erősebb tömörítést jelent. Számít:
a megfelelő képméret;
a megfelelő fájlformátum;
a tömörítés;
a különböző képernyőméretekhez igazodó reszponzív kép;
és az is, hogy mikor kezdi el betölteni a böngésző az adott képet.
A modern képformátumok, például a WebP vagy az AVIF sok esetben kisebb fájlméretet tesznek lehetővé megfelelő képminőség mellett. A képernyő alsóbb részén található képeknél használható úgynevezett lazy loading, vagyis késleltetett betöltés is. Ilyenkor a böngésző nem feltétlenül tölti le azonnal azokat a képeket, amelyeket a felhasználó még nem lát. Ezt azonban nem szabad mechanikusan minden képre alkalmazni. Ha például a lap tetején lévő fő kép adja az LCP-elemet, annak késleltetése éppen ronthatja a teljesítményt.
Túl sok JavaScript
A JavaScript teszi lehetővé a modern weboldalak számos interaktív funkcióját, de a túl sok JavaScript komoly teljesítményproblémát is okozhat. A fájlt ugyanis nem elég letölteni. A böngészőnek fel is kell dolgoznia és végre kell hajtania a kódot. Ez különösen gyengébb mobileszközökön válhat érezhetővé.
A megoldás nem az, hogy „ne használjunk JavaScriptet”, hanem hogy csak annyi kód jusson el a felhasználóhoz, amennyire ténylegesen szükség van. Segíthet például a felesleges kód eltávolítása, a fájlok megfelelő felosztása, bizonyos funkciók késleltetett betöltése és a külső scriptek felülvizsgálata.
Felesleges bővítmények és külső szolgáltatások
Tartalomkezelő rendszereknél gyakori, hogy az évek során egyre több bővítmény kerül az oldalra. Ezek újabb CSS- és JavaScript-fájlokat, adatbázis-lekérdezéseket vagy külső kéréseket hozhatnak magukkal. Hasonló hatása lehet az analitikai, marketing-, chat-, videó-, térkép- vagy közösségimédia-szolgáltatásoknak is. Nem minden plugin vagy külső script probléma. A kérdés inkább az, hogy ad-e annyi értéket az adott funkció, amekkora teljesítményköltséggel jár.
Lassú szerver és magas válaszidő
Hiába optimalizált a böngészőben futó kód, ha maga a szerver lassan reagál. A háttérben állhat kevés szerverkapacitás, rosszul optimalizált adatbázis-lekérdezés, túl sok dinamikus művelet, nem megfelelő cache-elés vagy egyszerűen az adott rendszerhez gyenge infrastruktúra.
Összetettebb webes rendszereknél ezért a sebességoptimalizálás nem mindig frontendfeladat. Előfordulhat, hogy a backend működését, az adatbázist vagy az alkalmazás architektúráját kell megvizsgálni. Ez az egyik oka annak is, hogy egy egyedi webfejlesztésnél a teljesítményt már a technikai tervezés során célszerű figyelembe venni.
Nem megfelelő gyorsítótárazás
A gyorsítótárazás, vagyis a cache lényege, hogy ne kelljen minden alkalommal ugyanazt a tartalmat teljes egészében újra előállítani vagy letölteni. A cache több szinten működhet. A böngésző például helyben megőrizhet olyan statikus fájlokat, amelyeket a következő oldal megnyitásakor nem kell újra letölteni. Szerveroldali cache esetén pedig bizonyos eredmények előre eltárolhatók, így a szervernek nem kell minden kérésnél ugyanazt a számítást vagy adatbázis-műveletet újra végrehajtania. A jó cache-stratégia tehát nem egyszerűen egy kapcsoló bekapcsolását jelenti. Meg kell határozni, mi tárolható, mennyi ideig, és mikor kell a gyorsítótár tartalmát frissíteni.
Hiányzó vagy rosszul használt CDN
A CDN, vagyis Content Delivery Network olyan elosztott kiszolgálóhálózat, amely bizonyos tartalmakat a felhasználóhoz földrajzilag vagy hálózatilag közelebbi pontról tud továbbítani.
Ez különösen akkor lehet hasznos, ha egy weboldal látogatói több országból vagy régióból érkeznek, illetve sok statikus erőforrást – például képet, CSS-t vagy JavaScriptet – kell kiszolgálni. A CDN ugyanakkor nem varázsszer. Egy lassú adatbázis-lekérdezést vagy rosszul megírt alkalmazáslogikát önmagában nem javít meg. Először azt kell megérteni, hol keletkezik a késleltetés, és ehhez választani megfelelő megoldást.
CSS, webfontok és a megjelenítés kritikus útvonala
A böngészőnek nemcsak le kell töltenie az oldal erőforrásait, hanem azt is el kell döntenie, hogyan jelenítse meg őket. Bizonyos CSS- és JavaScript-erőforrások késleltethetik az első tartalom kirajzolását. A webfontok szintén okozhatnak késést vagy vizuális ugrást, ha a betűkészletek betöltése nincs megfelelően kezelve.
Ezért a fájlok egyszerű „kicsinyítése” mellett az is számít, milyen sorrendben és milyen prioritással tölti le őket a böngésző.
Hogyan gyorsítható fel egy weboldal?
A jó optimalizálási sorrend nem az, hogy találomra bekapcsolunk néhány gyorsító funkciót. Először mérni kell, utána azonosítani a legnagyobb problémát, majd ellenőrizni, hogy a módosítás valóban javított-e a helyzeten.
Egy tipikus folyamat így nézhet ki:
Mérd meg a jelenlegi állapotot. Vizsgáld meg a Core Web Vitals mutatókat és a betöltési folyamatot mobilon is.
Keresd meg a szűk keresztmetszetet. Más megoldás kell egy lassú szerverhez, egy túl nagy nyitóképhez és egy JavaScript miatt késve reagáló felülethez.
Először a legnagyobb hatású hibákat javítsd. Nincs sok értelme apró fájlokon spórolni néhány kilobájtot, ha közben egy több megabájtos kép tölti be a fél képernyőt.
Mérj újra. A módosítás hatását ellenőrizni kell, lehetőleg nemcsak laboratóriumi, hanem idővel valós felhasználói adatok alapján is.
Figyeld hosszabb távon a teljesítményt. Egy weboldal változik: új tartalmak, képek, bővítmények és külső szolgáltatások kerülnek rá, ezért a teljesítmény is romolhat később.
Ha a probléma már nem néhány különálló hibából ered, hanem az oldal technikai alapjai nehezítik a továbbfejlesztést, érdemes azt is mérlegelni, hogy optimalizálás, továbbfejlesztés vagy teljes újratervezés jelent-e jobb megoldást.
Mikor elég néhány optimalizálás, és mikor van szükség komolyabb fejlesztésre?
Nem minden lassú weboldalt kell újraépíteni. Ha a problémát néhány túlméretezett kép, rosszul konfigurált cache vagy feleslegesen betöltődő script okozza, viszonylag célzott beavatkozással is sokat lehet javítani. Egy jól felépített oldalnál az optimalizálás gyakran inkább finomhangolás.
Más a helyzet, ha a teljes rendszer technikai adósságot halmozott fel. Régi vagy nehezen karbantartható kód, egymásra épülő bővítmények, lassú adatbázis-műveletek vagy rosszul skálázható architektúra esetén a sebességprobléma csak egy tünet lehet a sok közül.
Ilyenkor már nem az a fő kérdés, hogyan lehet még néhány tizedmásodpercet lefaragni, hanem az, hogy milyen technikai alapokon érdemes tovább működtetni az oldalt. Egy weboldalfejlesztő feladata ilyen helyzetben nem pusztán a fájlok tömörítése, hanem a lassulás valódi okának feltárása.
Mobilon különösen könnyen előjönnek a teljesítményproblémák
Egy erős irodai számítógép gyors internetkapcsolattal könnyen elfedheti a problémákat. A látogatók azonban eltérő eszközöket és hálózatokat használnak. Egy nagy JavaScript-csomag például nemcsak a letöltés miatt lehet lassú. Egy gyengébb telefon processzorának a kód feldolgozása is tovább tarthat. Ugyanez igaz a nagy képekre: gyors vezetékes kapcsolaton alig észrevehető különbség mobilhálózaton már komoly várakozást jelenthet.
Ezért a weboldal sebességét nem érdemes kizárólag saját gépen ellenőrizni. A weboldal tervezése során már az eltérő képernyőméretekkel, eszközökkel és használati körülményekkel is számolni kell.
Nem a 100-as PageSpeed-pontszám a cél
Könnyű beleesni abba a hibába, hogy a teljes optimalizálás egyetlen szám hajszolásává válik. A PageSpeed Insights és más teljesítménymérő eszközök nagyon hasznosak, de az eredményeiket diagnosztikai segítségként érdemes kezelni. Egy 100-as pontszám nem tesz automatikusan jóvá egy weboldalt, ahogy egy gyengébb laboreredmény sem jelenti feltétlenül azt, hogy minden felhasználó rossz élményt kap.
A valódi cél az, hogy az oldal:
gyorsan mutassa meg a fontos tartalmat;
időben reagáljon a felhasználó műveleteire;
ne ugráljon betöltés közben;
különböző eszközökön és hálózatokon is használható maradjon;
és a teljesítmény a weboldal fejlődésével se romoljon észrevétlenül.
A sebesség tehát az ideális weboldal egyik fontos tulajdonsága, de mindig a teljes felhasználói élmény részeként érdemes kezelni.
Mit érdemes tenni, ha lassú a weboldalad?
Ha lassúnak érzed az oldaladat, első lépésként ne találomra telepíts újabb optimalizáló bővítményeket. Előbb derítsd ki, mi okozza ténylegesen a lassulást.
Lehet, hogy néhány kép optimalizálása és a cache megfelelő beállítása elegendő. Más esetben a szerver, az adatbázis, a JavaScript, egy külső szolgáltatás vagy maga az alkalmazás felépítése okozza a problémát. Minél összetettebb a rendszer, annál fontosabb, hogy a teljesítményt ne különálló trükkök, hanem mérések alapján javítsd.
Ha fejlesztői segítséggel történik az optimalizálás, a munka célszerűen a jelenlegi állapot elemzésével indul. Ezután lehet javítani a lassulást okozó hibákat, optimalizálni a nagy fájlokat, átnézni a cache- és CDN-beállításokat, illetve szükség esetén a szerveroldali működést. Az eredményt pedig újra meg kell mérni.
Ne hagyd, hogy a lassú betöltési idő vagy a késve reagáló felület álljon a látogató és a célja közé. A jó weboldal-sebesség nem önmagáért fontos: azért dolgozunk rajta, hogy az oldal használata gyors, kiszámítható és kényelmes legyen.
