Hogyan csökkenthető egy weboldal betöltési ideje megfelelő tárhellyel?

A gyors weboldal a szervernél kezdődik

Amikor egy weboldal lassan töltődik be, általában először a túl nagy képekre, a JavaScript-fájlokra vagy valamilyen programozási hibára gyanakszunk. Ezek valóban gyakori problémák, de könnyű megfeledkezni arról, hogy minden dinamikusan előállított oldal mögött szerveroldali folyamatok is dolgoznak.

A böngésző elküldi a kérést, a szerver feldolgozza azt, az alkalmazás gyakran adatbázis-lekérdezéseket hajt végre, majd elkészíti és visszaküldi a választ. Ha már ez a folyamat lassú, a frontend optimalizálás önmagában nem feltétlenül hoz megfelelő eredményt.

A weboldal betöltési idejének csökkentéséhez ezért a tárhely teljesítményét is érdemes megvizsgálni.

Mitől lehet lassú egy tárhely?

Egy tárhelyszolgáltatás teljesítményét nem lehet kizárólag a rendelkezésre álló gigabájtok alapján megítélni. Egy 100 GB-os tárhely például egyáltalán nem biztos, hogy gyorsabb egy 20 GB-osnál.

Sokkal fontosabb lehet:

• a rendelkezésre álló CPU-teljesítmény;
• a memória mennyisége és korlátozása;
• a háttértár teljesítménye;
• az adatbázis sebessége;
• a szerver terheltsége;
• a használt PHP-verzió és konfiguráció;
• a gyorsítótárazási lehetőségek;
• valamint a szerver és a látogatók közötti hálózati kapcsolat.

Különösen osztott tárhelyeknél fordulhat elő, hogy sok weboldal használja ugyanazt a fizikai infrastruktúrát. Egy megfelelően menedzselt szolgáltatásnál ez önmagában nem probléma, de túlzott erőforrás-megosztás esetén a weboldal teljesítménye ingadozhat.

Nem minden lassulást old meg egy erősebb szerver

Fontos azonban a másik végletet is elkerülni. Ha egy webáruház minden oldalbetöltésnél több száz felesleges adatbázis-lekérdezést végez, egy nagyobb szerver csak elfedheti a problémát.

A gyors weboldalhoz a megfelelő tárhely és a megfelelően optimalizált alkalmazás együtt szükséges.

Ezért költözés vagy szerverbővítés előtt érdemes megállapítani, hogy pontosan hol keletkezik a késleltetés. A szerver válaszideje lassú? Az adatbázis a szűk keresztmetszet? Elfogy a memória? Vagy a szerver gyorsan elkészíti az oldalt, csak a böngészőnek kell túl sok képet, CSS-t és JavaScriptet letöltenie?

A válasz alapján egészen más megoldásra lehet szükség. A következőkben végigvesszük, hogyan lehet ezeket a problémákat elkülöníteni, milyen tárhelyparamétereket érdemes vizsgálni, és mikor indokolt valóban gyorsabb infrastruktúrára váltani.

A weboldal betöltési ideje több különálló szakaszból áll

A „lassú a weboldal” önmagában még nem diagnózis. A felhasználó egyetlen várakozásként érzékeli a folyamatot, technikai szempontból azonban több egymást követő lépés történik.

A böngészőnek többek között kapcsolatot kell létrehoznia a kiszolgálóval, a szervernek fel kell dolgoznia a kérést, az alkalmazásnak le kell futnia, szükség esetén adatbázis-lekérdezéseket kell végrehajtania, majd a HTML-dokumentum után további erőforrások érkeznek.

Ez azért fontos, mert a tárhely elsősorban a folyamat szerveroldali részére van közvetlen hatással.

Ha például a szerver 80 milliszekundum alatt elkészíti a választ, de egy 8 MB-os kezdőoldalon több tucat nagy kép és rengeteg JavaScript található, a tárhelycsomag növelésétől nem várható látványos javulás.

Ha viszont már a HTML-válasz elkészítésére is hosszú ideig kell várni, érdemes a szerveroldalon keresni a problémát.

A TTFB fontos jelzés, de nem mond el mindent

A teljesítményelemzés egyik hasznos mérőszáma a Time to First Byte (TTFB). Ez leegyszerűsítve azt mutatja meg, mennyi idő telik el a kérés és az első válaszbájt megérkezése között.

Magas TTFB mögött többféle ok állhat:

• túlterhelt szerver;
• lassú alkalmazáskód;
• lassú adatbázis;
• külső szolgáltatásra várakozó backend;
• nem megfelelő cache-elés;
• hálózati késleltetés;
• erőforrás-korlátozás.

Ezért a TTFB-t sem érdemes automatikusan a tárhelyszolgáltató hibájának tekinteni. Inkább olyan tünetként használható, amely alapján tovább lehet vizsgálni a szerveroldali működést.

CPU és memória: nem csak a mennyiség számít

Egy dinamikus weboldal – például WordPress, WooCommerce vagy egy egyedi PHP-alapú rendszer – minden nem gyorsítótárazott kérésnél számítási feladatokat végez.

Ha ehhez nem áll rendelkezésre elegendő processzorkapacitás, a kérések feldolgozása lelassulhat. Nagyobb forgalomnál pedig több kérés várhat egyszerre végrehajtásra.

Hasonló probléma jelentkezhet kevés memória esetén.

Ezért tárhelyek összehasonlításakor érdemes megvizsgálni, hogy a szolgáltató milyen erőforrás-korlátokat alkalmaz. Különösen osztott tárhely esetén fontos lehet, hogy egy ügyfél mekkora CPU- és memória-erőforrást használhat.

Egy VPS-nél általában jobban átlátható a rendelkezésre álló kapacitás, ugyanakkor annak megfelelő konfigurálása már az üzemeltetés részét képezi.

A háttértár sebessége is számít

Webes környezetben rengeteg kisebb fájlhoz és adatbázis-adathoz kell gyorsan hozzáférni. Emiatt nem csak az számít, hogy SSD vagy NVMe háttértárról beszélünk.

A háttértár I/O-teljesítménye és a szolgáltató által alkalmazott korlátozások szintén befolyásolhatják a valós sebességet.

Ez különösen adatbázis-intenzív alkalmazásoknál válhat látványossá. Egy statikus bemutatkozó oldal erőforrásigénye egészen más, mint egy több tízezer terméket kezelő webáruházé vagy egy folyamatosan használt vállalati rendszeré.

Az adatbázis gyakran rejtett szűk keresztmetszet

Dinamikus weboldalaknál az adatbázis teljesítménye legalább olyan fontos lehet, mint maga a webszerver.

Egy rosszul optimalizált lekérdezés nagy adatmennyiségnél jelentős terhelést okozhat. Ugyanez igaz akkor, ha hiányoznak a megfelelő indexek, vagy egy oldal megjelenítéséhez indokolatlanul sok lekérdezés szükséges.

Ilyen esetben egy erősebb szerver átmenetileg javíthatja a sebességet, de a valódi megoldás sokszor az adatbázis és az alkalmazás optimalizálása.

Érdemes megvizsgálni például:

• mely lekérdezések futnak lassan;
• mennyi adatot olvasnak be;
• megfelelőek-e az indexek;
• hány adatbázis-kérés szükséges egy oldal előállításához;
• lehet-e bizonyos eredményeket cache-elni.

Egy nagyobb webáruháznál vagy egyedi ügyviteli rendszernél már az adatbázis külön szerverre helyezése is szóba kerülhet, de erre csak tényleges terhelési adatok alapján érdemes költeni.

A cache sokszor többet ér, mint a nagyobb szerver

Ha egy weboldal minden látogatónál ugyanazt a tartalmat állítja elő újra és újra, feleslegesen használ processzort és adatbázist.

Itt jelentős szerepet kap a gyorsítótárazás.

Több szinten is alkalmazható cache. Teljes HTML-oldalak tárolásával bizonyos kéréseknél akár az alkalmazás jelentős része megkerülhető. Objektum-cache használatával gyakran használt adatok tárolhatók gyorsabban elérhető memóriában. A böngészőoldali cache pedig csökkentheti az ismételten letöltendő statikus állományok mennyiségét.

Egy jól megtervezett cache-elési stratégia ezért gyakran gazdaságosabb és hatékonyabb, mint pusztán újabb processzormagok hozzáadása.

Arra ugyanakkor ügyelni kell, hogy nem minden tartalom gyorsítótárazható ugyanúgy. Egy személyre szabott ügyfélfiók vagy egy webáruház kosara más kezelést igényel, mint egy nyilvános blogbejegyzés.

PHP-verzió és szerverkonfiguráció

PHP-alapú weboldalak esetében fontos, hogy támogatott, az alkalmazással kompatibilis PHP-verziót használjunk. Egy régi rendszer frissítését azonban nem érdemes ellenőrzés nélkül elvégezni: előfordulhat, hogy egy korábbi bővítmény vagy saját fejlesztés nem kompatibilis az újabb környezettel.

A PHP működését gyorsító OPcache használata szintén alapvető lehet. Ennek segítségével a PHP-nak nem kell minden kérésnél újra feldolgoznia a programkódot ugyanarról a kiindulási pontról.

Saját VPS vagy dedikált szerver esetén további optimalizálási lehetőséget jelent a webszerver, a PHP processzek, az adatbázis és a memóriahasználat megfelelő összehangolása.

Itt azonban fontos szabály, hogy az internetről kimásolt „optimális konfiguráció” nem feltétlenül optimális a saját rendszerünkhöz. A beállításokat mérés és tényleges terhelés alapján érdemes módosítani.

Mikor segít a CDN?

A CDN (Content Delivery Network) elsősorban a statikus tartalmak – például képek, CSS- és JavaScript-fájlok – gyorsabb eljuttatásában lehet hasznos.

Ha a szerver Magyarországon található, és a látogatók túlnyomó része is Magyarországról érkezik, a földrajzi távolság önmagában valószínűleg kisebb probléma. Nemzetközi közönségnél viszont már jelentősebb lehet a különbség.

A CDN ezen kívül tehermentesítheti az eredeti szervert, és a szolgáltatástól függően további gyorsítótárazási, forgalomkezelési vagy biztonsági funkciókat is biztosíthat.

Fontos viszont, hogy a CDN sem javít meg automatikusan egy lassú backendet. Ha minden kérésnél meg kell várni egy több másodpercig dolgozó alkalmazásszervert, a problémát elsősorban ott kell kezelni.

Osztott tárhely, VPS vagy saját szerverkörnyezet?

Kisebb céges weboldalaknál egy jó minőségű osztott tárhely teljesen megfelelő lehet. Nem indokolt VPS-t üzemeltetni pusztán azért, mert technikailag nagyobb szabadságot biztosít.

A VPS akkor válhat előnyössé, ha:

• garantálhatóbb erőforrásokra van szükség;
• egyedi szerverkonfiguráció kell;
• több alkalmazást üzemeltetünk;
• saját cache- vagy háttérszolgáltatásokat használunk;
• az osztott tárhely korlátai rendszeresen problémát okoznak.

Nagy terhelésnél dedikált vagy több szerverből álló infrastruktúra is indokolt lehet.

A lényeg azonban ugyanaz: mérés nélkül ne váltsunk infrastruktúrát.

Egy havi néhány ezer látogatót kiszolgáló honlap problémáját nem biztos, hogy egy többszörösen drágább szerver oldja meg. Elképzelhető, hogy egyetlen hibás bővítmény vagy optimalizálatlan adatbázis-lekérdezés okozza a lassulást.

Hogyan vizsgáljuk meg, hogy valóban a tárhely lassú?

Érdemes lépésenként haladni.

Elsőként mérjük meg különböző időpontokban a weboldal teljesítményét. Ha az oldal hajnalban gyors, munkaidőben pedig jelentősen lassabb, az például erőforrás-problémára is utalhat.

Ezután különítsük el a frontend és backend problémákat. Vizsgáljuk meg, milyen gyorsan érkezik meg az első HTML-válasz, majd mennyi idő szükséges a teljes oldal megjelenítéséhez.

Szerverhozzáférés esetén ellenőrizzük:

• a CPU terhelését;
• a memóriahasználatot;
• a háttértár I/O-terhelését;
• az adatbázis teljesítményét;
• a webszerver és PHP naplóit;
• az esetleges hibákat és időtúllépéseket.

Ezután érdemes terhelés alatt is mérést végezni. Egy szerver ugyanis lehet rendkívül gyors egyetlen látogatóval, miközben néhány tucat párhuzamos kérésnél már jelentősen nő a válaszidő.

Gyakori hiba: mérés helyett azonnali szerverbővítés

A legegyszerűbb reakció egy lassú oldalra az, hogy „vegyünk nagyobb szervert”. Ez bizonyos esetekben valóban szükséges, de nem jó kiindulópont.

Jobb sorrend:

1. mérjük meg a jelenlegi teljesítményt;
2. azonosítsuk a szűk keresztmetszetet;
3. javítsuk az alkalmazás- vagy konfigurációs hibákat;
4. vezessünk be megfelelő cache-elést;
5. mérjünk újra;
6. és csak ezután döntsünk az infrastruktúra bővítéséről.

Ezzel nemcsak pénzt takaríthatunk meg. Egy rosszul optimalizált rendszer ugyanis az erősebb szervert is képes idővel kinőni.

Gyors tárhely választása: gyakorlati ellenőrzőlista

Tárhely vagy szerver kiválasztásakor ne kizárólag a tárhelyméretet és a havi díjat hasonlítsuk össze. Érdemes választ keresni arra is, hogy milyen CPU- és memóriakorlátok vannak, milyen háttértárat használ a szolgáltatás, illetve rendelkezésre áll-e megfelelő cache-elési lehetőség.

Nézzük meg továbbá:

• választható-e megfelelő PHP-verzió;
• van-e OPcache;
• milyen adatbázis-környezetet kapunk;
• készül-e rendszeres biztonsági mentés;
• mennyire egyszerű később nagyobb csomagra váltani;
• milyen technikai támogatást biztosít a szolgáltató;
• és hol található az infrastruktúra.

Növekedő vállalkozásnál különösen értékes, ha a tárhely később úgy bővíthető, hogy ehhez ne kelljen minden alkalommal teljes rendszerköltözést végrehajtani.

A gyorsaságot nem egyetlen komponens adja

A megfelelő tárhely jelentősen hozzájárulhat a weboldal betöltési idejének csökkentéséhez, de önmagában nem helyettesíti az optimalizált weboldalt.

A jó eredményhez a szervernek, az adatbázisnak, az alkalmazásnak, a cache-nek és a frontendnek együtt kell hatékonyan működnie.

Ezért egy lassú weboldal esetében a legjobb első lépés nem feltétlenül a szolgáltatóváltás. Először mérni kell, majd megkeresni a tényleges szűk keresztmetszetet. Ha a vizsgálat azt mutatja, hogy valóban a tárhely erőforrásai korlátozzák a rendszert, akkor már pontosan meghatározható, milyen infrastruktúrára érdemes továbblépni.