Miért lassú a webhelye (és hogyan javítsa ki még ma)

A webhely sebessége nem hiúsági mutató, közvetlen bevételi tényező. A Google saját kutatása szerint a mobiloldal betöltési idejének egy másodperces késleltetése akár 20%-kal csökkenti a konverziókat. Az Amazon híresen kiszámolta, hogy minden 100 milliszekundumnyi késleltetés 1%-ba került az eladásaikban. Egy webhelyén keresztül évente 500 000 €-t termelő vállalkozás számára egy fél másodperces sebességjavulás évi 50 000 €-t vagy többet érhet. A sebesség pénz, és minden lassú oldal szivárgás a bevételi folyamatában.

A konverziókon túl az oldalsebesség közvetlenül befolyásolja a keresőmotoros rangsorolását. A Google 2010 óta használja az oldalsebességet rangsorolási tényezőként, a Core Web Vitals pedig, amely olyan felhasználói élménymutatókat foglal magában, mint a Largest Contentful Paint (LCP), a Cumulative Layout Shift (CLS) és az Interaction to Next Paint (INP), 2021-ben vált hivatalos rangsorolási jellé. Az ezeken a benchmarkokon elbukó webhelyeket aktívan sújtják a keresési eredményekben, és elveszítik a láthatóságot a gyorsabb versenytársakkal szemben, függetlenül a tartalom minőségétől.

A GRADAX-nál minden ügyfélprojekt részeként auditáljuk a webhely teljesítményét. Az eredmények figyelemre méltóan következetesek: a legtöbb webhely jelentősen lassabb a szükségesnél, és az okok szinte mindig javíthatók. Az optimalizálatlan képek, a felduzzadt JavaScript-csomagok, a gyenge tárhely és a hiányzó gyorsítótárazás a diagnosztizált teljesítményproblémák több mint 80%-át teszik ki. Az alábbiakban egy rendszerezett útmutató következik e szűk keresztmetszetek azonosításához és megszüntetéséhez.

Mielőtt bármit optimalizálna, állítson fel egy megbízható kiindulási alapot. A Google PageSpeed Insights a legkönnyebben elérhető kiindulópont: adja meg az URL-t, és kapjon részletes jelentést a Core Web Vitals értékekről, a teljesítménypontszámokról és a konkrét optimalizálási javaslatokról. Futtassa le a kezdőlapján és a leglátogatottabb céloldalain is, mert a teljesítmény jelentősen eltér a különböző oldaltípusok között. Egy könnyű kezdőlap 95-öt érhet el, míg egy több tucat képet tartalmazó terméklistázó oldal 45-öt.

Mélyebb elemzéshez használja a Google Lighthouse-t a Chrome DevTools-ban, hálózati korlátozással. Állítsa a kapcsolatot "Slow 4G"-re és a CPU-t "4x slowdown"-ra, hogy szimulálja azokat a körülményeket, amelyeket látogatóinak jelentős része tapasztal mobilkészülékeken. A teljesítménymutatók ezeken a korlátozott körülmények között feltárják azokat a szűk keresztmetszeteket, amelyek a nagy sebességű fejlesztői gépén láthatatlanok. Fordítson különös figyelmet a Time to First Byte (TTFB) értékre, amely a szerver válaszidejét méri, és gyakran ez a korlátozó tényező a megosztott tárhelyen futó webhelyeknél.

A WebPageTest.org nyújtja a legátfogóbb elemzést, beleértve a vízesésdiagramokat, amelyek pontosan megmutatják, mikor töltődik be az egyes erőforrások, és hogyan blokkolják egymást. Futtasson teszteket több helyszínről és különböző kapcsolati sebességeken, hogy megértse, hogyan teljesít a webhelye a világ minden tájáról érkező látogatók számára. A filmcsík nézet különösen értékes: képkockáról képkockára mutatja az oldal renderelésének folyamatát, így azonnal nyilvánvalóvá válik, amikor a nagy erőforrások látható késleltetést okoznak a betöltési élményben.

A képek a legnagyobb egyedi hozzájárulók az oldal súlyához az átlagos webhelyen, az átvitt összes bájt körülbelül 50%-át teszik ki. Egy optimalizálatlan hero kép könnyen elérheti a 3–5 MB-ot, ami önmagában meghaladja a Google által javasolt 1,5 MB-os teljes oldalkeretet. A megoldás egyszerű: konvertálja a képeket modern formátumokba, tömörítse megfelelően, méretezze helyesen, és töltse be lustán.

A WebP és az AVIF a modern képfájlok, amelyeket használnia kell. A WebP 25-35%-kal kisebb fájlméretet biztosít, mint a JPEG azonos vizuális minőség mellett, és minden jelentős böngésző támogatja. Az AVIF még tovább növeli a tömörítést: 50-60%-kal kisebb, mint a JPEG, de a kódolás lassabb, a böngészőtámogatás pedig, bár növekszik, még nem általános. Az AVIF-et ott szolgáljuk ki, ahol támogatott, egyébként WebP-re váltunk vissza; a formátumválasztást automatikusan az HTML picture elem vagy a szerveroldali tartalomtárgyalás kezeli.

A reszponzív képek ugyanilyen fontosak. Egy 2400 pixel széles hero kép kiszolgálása egy 375 pixel széles nézetablakkal rendelkező mobil eszköznek sávszélesség- és erőforrás-pazarlás. Használja a srcset attribútumot több képméret biztosításához, és hagyja, hogy a böngésző válassza ki a megfelelőt. A legtöbb webhely esetében a 640px, 1024px, 1440px és 1920px szélességű képek biztosítása lefedi a nézetablak-méretek teljes skáláját. A lazy loading-gal (a natív loading="lazy" attribútummal) kombinálva a képernyőn látható terület alatti képek csak akkor töltődnek le, amikor a felhasználó közelükbe görget, ami drasztikusan javítja az oldal első betöltési idejét.

A tárhelykörnyezet határozza meg a teljesítmény alsó határát, amelyet semmilyen front-end optimalizálás nem tud felülmúlni. Ha a szervere 800 milliszekundumot vesz igénybe egy HTML-válasz előállításához, az oldala nem tölthető be másodperc alatt, függetlenül attól, hogy mennyire jól optimalizálja a képeket és a szkripteket. A Time to First Byte (TTFB) értéknek a legtöbb oldal esetében 200 milliszekundum alatt kell lennie. Ha az értéke következetesen meghaladja a 400 milliszekundumot, a tárhelye a szűk keresztmetszet.

A megosztott tárhely a leggyakoribb ok. Egy megosztott szerveren a webhelye több tucat vagy több száz másik webhellyel verseng a CPU-, memória- és I/O-sávszélesség-erőforrásokért. Amikor egy szomszédos webhely forgalmi csúcsot tapasztal, vagy erőforrás-igényes szkriptet futtat, a teljesítménye romlik. A VPS-re vagy dedikált felhőszerverre való frissítés kiküszöböli ezt a versengést azáltal, hogy garantálja az erőforrás-kiosztását. Kifejezetten WordPress webhelyek esetében egy menedzselt WordPress tárhely, amely szerver szintű gyorsítótárazást, PHP opcode gyorsítótárazást és adatbázis-lekérdezés-optimalizálást tartalmaz, 60-80%-kal csökkentheti a TTFB-t az általános megosztott tárhelyhez képest.

A szerver helye is fontosabb, mint azt sokan gondolnák. A fizika minimális késleltetést ír elő az optikai kábelen keresztüli fénysebesség alapján, körülbelül 1 milliszekundumot 100 kilométerenként. Egy Egyesült Államokban lévő szerver, amely egy Németországban lévő felhasználónak válaszol, legalább 60-80 milliszekundumos oda-vissza késleltetést ad hozzá, mielőtt bármilyen feldolgozás elkezdődne. Ha a közönsége többsége egy adott régióban található, helyezze el a szerverét abban a régióban. Globális közönség esetén a CDN a szerver helyétől függetlenül közelebb hozza a tartalmat a felhasználókhoz.

A modern webhelyek hatalmas mennyiségű JavaScriptet és CSS-t szállítanak, amelyek nagy részére a felhasználó böngészőjének soha nincs szüksége. A medián webhely 2025-ben több mint 500 KB JavaScriptet visz át, és a nehéz keretrendszerekkel épített vagy harmadik féltől származó szkriptekkel megrakott oldalak gyakran meghaladják a 2 MB-ot. A JavaScript minden kilobájtját le kell tölteni, elemezni, lefordítani és végrehajtani, mielőtt az oldal teljesen interaktívvá válna. Ez az oka annak, hogy egy oldal vizuálisan késznek tűnhet, de több másodpercig nem reagál a kattintásokra és a görgetésre.

Ellenőrizze a JavaScript-csomagjait a Chrome DevTools Coverage fülével, amely megmutatja a letöltött kód ténylegesen végrehajtott százalékos arányát az oldal betöltése során. Gyakori, hogy egy adott oldalon a JavaScript 50-70%-a kihasználatlan marad. A tree-shaking, a kódfelosztás és a dinamikus importok drasztikusan csökkenthetik a kezdeti csomagméreteket. Ha olyan keretrendszert használ, mint a Next.js vagy a React, győződjön meg arról, hogy kihasználja a beépített kódfelosztást, amely csak az aktuális oldalhoz szükséges JavaScriptet tölti be, ahelyett, hogy a teljes alkalmazást előre szállítaná.

A harmadik féltől származó szkriptek gyakran a legnagyobb bűnösök. Az analitika, a chat widgetek, a közösségi média beágyazások, az A/B tesztelő eszközök és a hirdetési pixelek mindegyik saját JavaScript terhet, hálózati kéréseket és feldolgozási többletet ad hozzá. Láttunk olyan ügyféloldalakat, amelyek tizenkettő vagy több harmadik féltől származó szkriptet töltenek be, összesen több mint 1,5 MB méretben. Vizsgálja felül minden harmadik féltől származó szkript szükségességét és hatását. A nem kritikus szkripteket töltse be aszinkron módon a defer attribútummal, és fontolja meg azok eltávolítását, amelyek nem hoznak mérhető üzleti értéket. A technikai SEO audit pontosan megmutatja, mely szkriptek húzzák a Core Web Vitals értékeit a küszöbértékek alá.

A gyorsítótárazás a leghatékonyabb teljesítményoptimalizálás, amelyet megvalósíthat, mert teljesen megszünteti a munkát. Ahelyett, hogy minden kérésnél újragenerálná az oldalt vagy újra letöltené az erőforrást, a gyorsítótár a tárolt másolatot szolgálja ki a töredék idő alatt. A hatékony gyorsítótárazás több szinten működik: böngésző gyorsítótár, szerveroldali gyorsítótár, alkalmazásszintű gyorsítótár és CDN gyorsítótár. Minden szint csökkenti a következő terhelését, és együtt akár 90%-kal vagy annál is nagyobb mértékben csökkenthetik a szerver erőforrás-felhasználását.

A böngésző gyorsítótár HTTP fejléceken keresztül szabályozható. Állítsa be a Cache-Control fejléceket megfelelő max-age értékekkel minden erőforrástípushoz: a statikus erőforrások, például képek, betűtípusok és verziózott CSS/JS fájlok egy évig gyorsítótárazhatók (max-age=31536000) immutable és public direktívákkal. A HTML oldalakat rövidebb ideig vagy egyáltalán nem szabad gyorsítótárazni, attól függően, milyen gyakran változik a tartalom. A service workerek egy további szintet adnak hozzá azáltal, hogy alkalmazásszinten gyorsítótárazzák az erőforrásokat, lehetővé téve a visszatérő látogatók számára az azonnali oldalbetöltést és akár az offline működést is.

A szerveroldali gyorsítótár a teljesen renderelt HTML kimenetet tárolja, így a későbbi kérések kihagyják a teljes renderelési folyamatot. WordPress esetén az olyan bővítmények, mint a WP Super Cache vagy a W3 Total Cache, statikus HTML fájlokat generálnak, amelyeket az Apache vagy az Nginx közvetlenül szolgál ki anélkül, hogy egyáltalán meghívná a PHP-t. Egyedi alkalmazások esetén a Redis vagy a Memcached gyorsítótárazhatja az adatbázis-lekérdezéseket, az API válaszokat és a számított eredményeket. Az alapelv az, hogy a lehető legmagasabb szinten gyorsítótárazzunk: egy gyorsítótárazott HTML oldal gyorsabb, mint egy gyorsítótárazott adatbázis-lekérdezés, amely gyorsabb, mint egy nem gyorsítótárazott adatbázis-lekérdezés.

A Content Delivery Network (tartalomkézbesítő hálózat) a webhely statikus erőforrásait egy globális edge szerverhálózaton osztja el, így a felhasználók a hozzájuk földrajzilag közel lévő szerverről töltik le az erőforrásokat, nem pedig az origin szerverről, amely több ezer kilométerre is lehet. A CDN bevezetése az egyik legnagyobb hatású, legkisebb erőfeszítést igénylő teljesítményjavítás, és az olyan szolgáltatások, mint a Cloudflare, bőkezű ingyenes csomagokat kínálnak, amelyek a legtöbb kis- és közepes webhelyet lefedik.

A CDN nyújtotta teljesítménynövekedés a legdrámaibb az origin szervertől távol lévő felhasználók számára. Egy Frankfurtban hosztolt webhely, amely egy képet szolgál ki egy tokiói felhasználónak, körülbelül 250 milliszekundumról 30 milliszekundum alá csökkenti a oda-vissza késleltetést, amikor a kép egy tokiói edge csomóponton van gyorsítótárazva. Szorozza meg ezt a javulást az oldalon lévő minden képpel, stíluslappal, betűtípussal és szkripttel, és a halmozott hatás átalakító erejű. Mértük, hogy a CDN bevezetése 40-60%-kal csökkentette a teljes oldalbetöltési időt a nemzetközi látogatók számára.

A modern CDN-ek túlmutatnak az egyszerű statikus erőforrás-gyorsítótárazáson. A Cloudflare, a Fastly és az AWS CloudFront edge computing képességeket kínálnak, amelyek teljes HTML oldalakat gyorsítótárazhatnak, A/B tesztelést végezhetnek az edge-en, menet közben optimalizálhatják a képeket, sőt szerver nélküli funkciókat futtathatnak edge helyszíneken. WordPress webhelyek esetén a Cloudflare APO (Automatic Platform Optimization) szolgáltatása teljes oldalakat gyorsítótáraz az edge-en, globálisan 50 milliszekundum alatti TTFB-t érve el, olyan teljesítményt, amelyet kizárólag origin hosztinggal lehetetlen lenne elérni, függetlenül attól, milyen erős a szervere.

Ha azonnali eredményeket szeretne mély technikai belemenetel nélkül, íme öt változtatás, amelyet egy órán belül megvalósíthat. Először telepítsen és konfiguráljon egy gyorsítótárazó bővítményt, ha WordPress-t használ. A WP Super Cache ingyenes, és öt perc alatt beállítható. Másodszor futtassa a képeit egy tömeges optimalizálón, például a ShortPixel vagy az Imagify segítségével, amelyek látható minőségvesztés nélkül 60-80%-kal csökkenthetik a képméreteket. Harmadszor engedélyezze a GZIP vagy Brotli tömörítést a szerverén, amely az átvitel során 70-90%-kal csökkenti a szöveges erőforrások méretét.

Negyedszer halassza el a nem kritikus JavaScriptet a defer attribútum hozzáadásával a script tagekhez, vagy helyezze azokat a HTML body aljára. Ez megakadályozza, hogy a JavaScript blokkolja a kezdeti oldalrenderelést, és több száz milliszekundummal javíthatja az LCP pontszámot. Ötödször engedélyezzen egy CDN-t. A Cloudflare ingyenes csomagja tíz perc alatt beállítható, és azonnal javítja a betöltési időket minden olyan látogató számára, aki nem a szervere közelében található. Ez az öt változtatás önmagában egy webhelyet 40-es PageSpeed pontszámról 75-re vagy magasabbra emelhet.

A gyors győzelmeken túli fejlesztésekhez egy átfogó teljesítményaudit a legköltséghatékonyabb befektetés, amelyet megtehet. A GRADAX-nál a stack minden rétegét elemezzük: a hoszting infrastruktúrát, a szerverkonfigurációt, az alkalmazásarchitektúrát, a front-end erőforrásokat és a harmadik féltől származó függőségeket, majd egy priorizált optimalizálási ütemtervet adunk át, amely a hatás és a megvalósítási erőfeszítés szerint rangsorolja a teendőket. A legtöbb ügyfél az oldalbetöltési idejét a felére csökkenti az ajánlásaink megvalósításának első hetében. Lépjen kapcsolatba velünk, hogy időpontot egyeztessen egy teljesítményauditra a webhelyéhez.