Webhelysebesség

Milyen technikák léteznek a webhelyek gyorsítására, a weblap megjelenítéséhez szükséges idő csökkentésére? Némi ízelítő arról, hogy hányféle módon gyorsíthatjuk weboldalunk betöltődését.

Nagy sávszélességű kapcsolat

A weblapok betöltődésének első lépése, hogy minél nagyobb sávszélességgel kommunikáljunk egy hozzánk fizikailag is minél közelebb levő szerverrel. Ehhez a tárhelyszolgáltató részéről is fontos a jó sávszélesség és a jó lokáció. Ez a gyakorlatban annyit jelent, hogy nem feltétlenül jó, ha pl. Új-Zélandban vagy más, Magyarország felé relatív keskeny sávszélességel vagy nagy távolságra levő helyekről hosztoljuk az oldalunkat, de pl. ezért nem feltétlenül jó otthonról hosztolni weboldalunk.

CDN (Content distribution network)

Az CDN hálózatok lényege, hogy a kérdéses információ egyszerre több, fizikailag a Föld különböző pontjain elérhető szerverről is lekérhető, a felhasználókat pedig mindig a legközelebbi, leggyorsabb választ produkáló szerver szolgálja ki. A weboldalak esetében a gyakorlatban kétféle megoldás létezik: vagy az egész weboldalt — a HTML fájlt és az összes egyéb fájlt — a CDN szerverei szolgálják ki (mint például ennél a weboldalnál), vagy pedig a html fájlt a saját szerverünk, míg az ún. statikus elemeket – mint a CSS, Javascript és képfájlok – egy másik, a CDN szolgáltatóhoz tartozó aldomain szolgálja ki, mint pl. oldalgazdahu.tarhelyszolgaltato.netdna-cdn.com.

A több szerver között eloszló forgalom sokat segít a globális közönség kiszolgálásában, hiszen mind Ázsiából, mind Dél-Amerikából ugyanolyan sebességű webhelyet érzékelhetnek látogatóink. Hasznos lehet továbbá az időszakos forgalmi csúcsok kiszolgálásában, hiszen a több gépből álló rendszer jobban kezeli a hirtelen jött nagyszámú lekérést, mint egyetlen egy, tárhelyszolgáltatónál található gép.

Webhely komplexitása

Annál semmi sem lesz gyorsabb, mintha „kézzel” kódolnánk és töltenénk fel html fájlokat egy statikus tárhelyre. Sajnos azonban efölött a technika fölött már jócskán eljárt az idő, így ez az út nem járható. Bármilyen tartalomkezelő rendszert is válasszunk – netán saját rendszert fejlesszünk –, ha nem teszünk a sebesség gyorsítása érdekében, biztosan jóval lassabb lesz, mintha statikus html fájlokból álló oldalról beszélnénk, ahol a szervernek „semmit sem kell számolnia”, csak elküldeni a lekért fájlt úgy, ahogy anno feltöltöttük.

Kisebb, néhány tucat weblapból álló, tartalomkezelők által hajtott weboldal esetében a tartalomkezelők általában nem elviselhetetlenül lassúak, azonban egy  többezer tartalmi egységből (oldalból, bejegyzésből, stb.) álló nagyobbacska weboldal esetén további komponenseket kell beállítsunk annak érdekében, hogy elviselhető legyen az oldal sebessége. Ilyenkor például azt is tüzetesebben meg kell vizsgáljuk, mely adatbázis-lekérések, funkciók a leglassabbak, és vajon ki tudjuk-e váltani őket valami egyszerűbb, gyorsabb hívással, funkcióval — azaz mennyivel csökkenthetjük a weboldal kódjának komplexitását.

Tartalomkezelő rendszer

Önmagában azt állítani, hogy az egyik tartalomkezleő rendszer pl. a Joomla gyorsabb vagy lassabb pl. a WordPress-nél vagy másik CMS-nél, meglehetős csacskaság, hiszen ez ennél egy jóval összetettebb, és több paramétertől függő kérdés. Hasonlóan, egy kevésbé átgondolt saját fejlesztésű rendszer is lehet olyan lassú, mint egy olyan általános célú CMS, ami a mi adott funkciójú weboldalunk esetén nagy valószínűséggel sok fölösleges funkciót is lefuttat.

A CMS-ek esetében például az oldalak betöltődésének sebességét gyakran nem is az alaprendszer, hanem a rosszul vagy rossz koncepció alapján megírt kiegészítők, vagy az összetett funkcionalitást nem kellően optimalizált módon implementáló témák, sablonok okozzák. Ráadásul a látogatók zömének bármilyen tartalomkezelő rendszer esetén elsősorban a gyorsítótárazott tartalmakkal kellene találkoznia, nem pedig a CMS-ek  vagy az egyedi webalkalmazásunk által kiszámolt weblapokkal.

Szerver oldali gyorsítótárazás

Az ún. szerver oldali gyorsítótárazás (cache) lényege, hogy a webszerver nem számol végig mindent minden egyes lekérdezés alkalmával, hanem csak bizonyos időintervallumonként. A köztes időszakban pedig egy jóval kevesebb „energiával” előhívható, korábban már kiszámolt végeredményt ad vissza a látogatóknak. Ha például én lehívom az index.hu nyitólapját, meg utánam pár másodperccel lehívja valaki más, akkor nem valószínű, hogy kettőnk lekérdezése között változott az oldal tartalma, ezért neki nem kell újból  kiszámolnia a szervernek, mit is jelenítsen meg a másik látogatónak, csak elővenni a gyorsítótárból azt a fájlt, amit nekem már kész végeredményként elküldött.

Lehetséges, hogy az egész weblap kódját teszi el a szerver konzervként a gyorsítótárba, és azt szolgálja fel villámgyorsan a látogatóknak, de vonatkozhat ez a weblap ritkábban változó részeire (lábléc, és egyéb nem tartalmi elemek), de akár egyes adatbázis-lekérések eredményeinek eltárolására is. A weboldal előállításának több szintjén is élhetünk e gyorsító technikával.

A gyorsítótárazással tehát szinte olyan lesz minden, mintha egy statikus oldalunk lenne, csak itt a statikus html fájlokat nem mi töltöttük fel tavaly, hanem egy dinamikus háttérrendszer által került legenerálásra. Beállítástól függően csak akkor kell újból kiszámolni és letárolni ezt a fájlt, ha a következő lekérés alkalmával már változna az aktuálisan visszaadandó tartalom. Ha például új bejegyzést írunk a blogunkba, akkor optimális esetben törlődik a nyitólapunk gyorsítótárazott fájlja, hiszen ezzel megváltozott a webhely nyitólapja is. Gondot okozhat azonban, ha például a nyitólap legenerálásáért felelős kódon változtattunk, hiszen ebben az esetben elképzelhető, hogy kézzel kell töröljünk a gyorsítótárban található fájlokat annak érdekében, hogy a kódban történt változtatások megjelenjenek a weblapon.

A tartalomkezelő rendszerek gyorsítása történhet egy tőle nagyrészt független rendszerrel: ha például egy előtétet, egy ún. proxy szervert teszünk a dinamikus tartalmat előállító webszerver elé, ami csak akkor fordul a mögötte levő webalkalmazás-szerverhez, ha nála nem található érvényes lementett, gyorsítótárazott verzió, így tehermentesíti a számításigényes folyamatokat.

A másik lehetőség, hogy a tartalomkezelő rendszeren belül, vagy saját fejlesztésű webalkalmazásunk részeként implementálunk gyorsítótárazó megoldásokat. A fejlett tartalomkezelő rendszerekhez általában elérhetőek olyan kiegészítők, melyek a gyorsítótárazás mellett egyéb, weboldalak sebességnövelését eredményező technikákat is implementálnak.

Böngésző oldali gyorsítótárazás

Nem csak a webmesterek és a tárhelyszolgáltatók igyekeznek élni a gyorsítótárazás lehetőségével, hanem a böngészők is meglehetősen agresszívan igyekeznek gyorsítani a weboldalak betöltését azzal, hogy nem kérnek le olyan fájlokat, amelyeket már korábban letöltöttek. Ha például délelőtt már letöltöttem az index.hu nyitólapját, akkor már nem feltétlenül szükséges újból letölteni az index logójának képfájlját délutáni látogatásom alkalmával is. Annál ugyanis semmi sem lesz gyorsabb, mint a saját gépünk merevlemezéről elővenni egy már korábban letöltött fájlt.

A folyamatot a szerver oldalról is befolyásolhatjuk: az úgynevezett HTTP header-ben, azaz a HTTP fejlécben utasításokat adhatunk a böngészőknek atekintetben, hogy milyen fájlokat miképpen gyorsítótárazzanak, vagy egyáltalán gyorsítótárazzanak-e.

A gyorsítótárazás azonban nem csak előnyöket, de problémákat is okozhat. Ha ugyanis éppen szerkesztünk valamit a weboldal tartalmán vagy kódján, akkor akár a szerver oldali, akár a böngésző oldali cache-lés miatt is előfordulhat, hogy nem a legutóbbi módosításunk szerinti állapotot látjuk majd, hanem egy régebbi, megtévesztő állapotot: emiatt pedig gyakran kell akár „kézzel” is törölni a szerver oldali vagy a böngésző oldali gyorsítótárat.

Lekérdezések számának csökkentése

Minden lekérdezésnek, bármilyen kis fáljról is van szó, meg kell járnia a szerver és a látogató közötti távolságot, ez pedig a sok kicsi sokra megy alapon már számottevő időt jelenthet. Gyakran előfordul, hogy különböző funkciók implementációja céljából sok kis JavaScript fájlok letöltése szükséges. Ha például külön-külön JS fájlban van a slideshow-unk mozgatásáért felelős, a képeket nagy méretben megnyitó, vagy a navigációs menüt animáló funkció, az sokkal kevésbé előnyös, mintha ezeket a fájlokat egyetlen JS fájlba egyesítve csupán egyszer kellene lekérnünk, és megkapjunk.

Ugyanez érvényes a CSS fájlokra is, bár az pl., hogy milyen sorrendben fűzzük össze ezeket a fájlokat, akár komoly galibákat is okozhat azáltal, hogy rossz sorrendben kerülnek felülírásra az ugyanazokra az elemekre vonatkozó szabályok. Hasonlóan kevesebb lekérés, ezáltal kevesebb idő szükséges ahhoz, ha az oldalon használt ikonokat nem sok külön kis képpel, hanem mind egyetlen nagyobb kép letöltésével, ún. CSS sprite technikával állítjuk elő.

Fájlméretek csökkentése

A különböző fájltípusok esetén más és más módszerek állnak rendelkezésünkre annak érdekében, hogy minél kisebb méretű fájlokat kelljen letölteni egy weblap előállításához:

• Az egyik ilyen általános technika, hogy a webszerver minden fájlt tömörítve küld el a böngészőnek, legyen az kép vagy html kód.
• A képek esetén sokat segít, hamindig csak pont akkora – és egy pixellel sem nagyobb – képet illesztünk be az oldalba, mint amekkora méretben az meg fog jelenni
• A már feltöltött képek esetében még alkalmazhatunk pluszban olyan tömörítési eljárásokat, melyek nem eredményeznek minőségromlást, azonban csökkentik a képfájl méretét
• A html, css, js kódok (tehát szöveges fájlok) esetében pedig egyrészt eltávolíthatjuk a megjelenítés szempontjából felesleges sortörés, szóköz és tabulátor karaktereket, másrészt pedig kitörölhetjük a kódokba illesztett kommenteket. (ún. HTML, CSS, JS minification).

Elméletben kézenfekvő megoldás lehet az a fájlméretek csökkentésére, ha kevesebb tartalmat jelenítünk meg egy weblapon (pl. rövidebb listákat), kevesebb funkciót implementálunk a weblapon, vagy kevesebb képfájlt használunk akár a webdesign létrehozásához, akár a tartalom illusztrálásához. Ezek azonban mind olyan nemkívánatos változtatások, melyek nagy valószínűséggel csökkentik weboldalunk használhatóságát.

Teljes megjelenítéshez szükséges idő

Ahhoz, hogy egy weboldal olvasható tartalommal megjelenjen a látogató böngészőjében, egyáltalán nem szükséges minden, a HTML fájlban meghatározott kiegészítő fájlnak (képnek, JS és CSS fájlnak) betöltődnie. Például a Google Analytics követőkód letöltődésére igazán felesleges várnia a látogatónak, hiszen az nem befolyásolja, hogy mi is látható az adott weblapon.

Ezért ezt a kódot úgynevezett aszinkron megoldással tölti be a böngésző: gyakorlatilag ráér azután is betölteni, hogy a webhely további, feltétlenül szükséges elemei már láthatóak. Problémás lehet ez a megoldás akkor, ha bizonyos tartalmi elemeket később töltünk be a weblapba az aszinkron (AJAX) megoldással, hiszen ebben az esetben a kérdéses tartalmi elem nem képezi a weblap html kódjának részét, így a keresők számára nehézséget okoz az ilyen tartalmak beindexelése és feldolgozása.

Az aszinkron megoldások mellett másik technika az ún. lazy load: ebben az esetben először csak azok a képek kerülnek letöltésre, melyek látszanak a betöltődéskor a látogató böngészőjében. Ahogy pedig a látogató szkrollozik lefelé az oldalon, úgy töltődnek be a további, a görgetés miatt a böngésző ún. viewport-jában megjelenő képek az oldalba.

Webszerver gyorsasága

Végül pedig számít az is, hogy mennyire gyors az adott webalkalmazás-szerver, ami kiszámolja, hogy milyen fájlokat is kellen elküldeni a látogatóknak: ha például egy gyenge gépen található az oldalunk, vagy például egy osztott tárhelyen a sok egyéb weboldal nagyon túlterheli a szervert, akkor bármennyit is tettünk a webhely gyorsítása érdekében, a legkisebb keresztmetszet akkor is a webszerver lesz. Hacsak nem valami szörnyen gagyi tárhelyszolgáltatót választottunk, akkor elsősorban a fenti technikák implementálásával érdemes foglalkozni, mintsem új tárhelyszolgáltatóra költözéssel.

Összefoglalás

Ahhoz, hogy egy napjaink igényeinek megfelelő funkcionalitású weboldal gyorsan töltődjék be, számtalan különböző technikával élhetünk. Ezek egy része bizonyos tartalomkezelő rendszerek alapvető részét képezi (a Plone például magától összerakja egybe a JS fájlokat), vagy egy-egy kiegészítő nyújtotta funkcionalitással érhető el (például a fentiek közül számtalan technikát egyszerre alkalmazó W3 Total Cache, vagy a képek kicsinyítését végző WP Smush.it), netán a tárhelyszolgáltató nyújtja számunkra (pl. CDN integráció vagy speciális gyorsítótárazó rendszerek).

E technikák sokféleségéből következik, hogy egy mintaszerűen gyorsított, pl. a PageSpeed szolgáltatás által ajánlott összes technikát használó weboldal esetén nem kis munka mindent összerakni és jól beállítani. Ráadásul a komplexebb rendszer több hibaforrást is tartogathat: emiatt pedig e gyorsító technikákat széles körben csak nagyobbacska szájtoknál érdemes használni, hiszen a kicsi oldalak esetén a befektetett relatív sok munka nem fog akkora érzékelhető gyorsulással járni.