Gyors honlapokat akarok

Régi hitvallásom, hogy egy weboldal sebessége kritikus szempont. Mindig. Versenyelőnyhöz juthat az a cég, amelyik gyors weboldallal rendelkezik. Miért? Mert szívesebben kattintunk, ha tudjuk, hogy azonnal rendelkezésre fog állni az információ. Ha szívsebben kattintunk, gyakrabban is tesszük ezt, azaz több oldalletöltést hozunk létre böngészés közben. Viszont, ha várni kell egy oldal letöltődésére, akár csak néhány másodpercet, közben megnyithatnak egy új fület a böngészőben a látogatók, és fennáll a veszély, hogy el is feledkeznek az előző honlapról.

A fentiek ékes bizonyítéka a Google legújabb álláspontja: a weboldal sebessége is szerepet játszik a rangsorolásnál a Google kereső találati oldalán. Aminek viszont közvetlen hatása szokott lenni a cég pénzügyeire. A döntés egyébként érhető a Google részéről, hiszen nekik az a céljuk, hogy jó minőségű találatokat adjanak. És úgy tűnik szerintük is a gyorsabb weblap jobb.

Mit is jelent a weblap sebessége. Annyit, hogy látogató a cím beírást követően, vagy linkre kattintás után, mennyi időt kell várjon hogy az adott oldal teljes egészében megjelenjen a képernyőjén. Minél kevesebbet kell várnia, annál jobb. A várakozással eltöltött idő sok komponensből áll, amelyek két nagy részre bonthatóak: szerver oldali várakozás és kliens oldali várakozás. Mindkettő egyaránt fontos, de teljesen különböző technikák és eszközök szükségesek az optimalizációhoz.

Optimalizálás a szerver oldalon.

Ma már ritkán beszélünk statikus html oldalakról. Általában adatbázis alapú weboldalunkat egy program állítja össze, amelyet majd a webszerve szolgál ki. Az adatbázis például lehet MySQL vagy Postgres, a programnyelv pedig lehet PHP, Python vagy ASP.NET. Webszerverre példa az Apache vagy IIS. Ma már nem ritka, hogy nem egyedi program állítja össze az adatbázisból a weboldal HTML kimenetét, hanem valamilyen tartalomkezelő rendszert vagy keretrendszert használunk. Én a Drupal tartalomkezelő keretrendszert használom, de sok hasonló célú eszköz létezik, amelyeket szintén széles körben használnak. Általános célúak közül a Drupal mellett a Joomla népszerű még, de speciális célokra ott vannak a különböző blogmotorok, fórummotorok vagy wiki szoftverek is.

Bár technikailag a program része, mégis a tartalomkezelőt tekinthetjük egy negyedik komponensnek. Ezt a 4 komponenst (webszerver, adatbázis, keretrendszer, program) érdemes külön-külön megvizsgálni és elvégezni a szükséges finomhangolásokat, hogy a legkevesebb késlekedést okozzanak a weboldal megjelenítése során. A szerver operációs rendszert tekinthetjük egy ötödik komponensnek, de ennek a finomhangolása nem annyira a weboldal sebességénél számít, hanem nagy forgalmú oldalak skálázhatóságánál, ami egy egészen más dolog.

A beállításokra általános tanácsot adni nem lehet, mert az mindig a használt eszköztől függ. A fenti négyesből én az Apache + MySQL + PHP + Drupal kombinációt használom a leggyakrabban, ezeknek a beállításairól szeretnék majd később többet is írni.

Optimalizálás a kliens oldalon.

Ahhoz hogy a felhasználónál megjelenjen a weboldal a következőknek kell megtörténni:

  1. a böngésző kapcsolatot épít ki a kiszolgálóval
  2. letölti a html forrást
  3. letölti a szükséges egyéb komponenseket, úgymint képek, css stíluslapok, javascript-ek, és egyéb beépülő komponensek (mérőkódok, Videómegosztók, reklám zónák, stb...
  4. a böngésző lefuttatja a Javascript kódokat, amelynek eredményeként sokszor újabb komponensek letöltése szükséges

Amikor a fentiek mind befejeződtek, akkor mondhatjuk hogy a weboldal megjelent a látogató oldalán. Ez általában nagyon sokáig tart, leginkább a külső beépülő komponensek és reklámok miatt. A felhasználók pedig türelmetlenek, úgyhogy ezt sokszor meg sem várják, már továbbkattintanak. Ezt célszerű elkerülni, törekedni kell arra, hogy minél gyorsabban teljes egészében összeálljon a látogató képernyőjén az oldalunk. Itt egy kicsit könnyebb tippeket adni, nézzük sorban:

Az első lépés tulajdonképpen maga a szerver oldali teljesítmény optimalizáció. Annyi kiegészítéssel, hogy számít a böngésző és a kiszolgáló közötti fizikai távolság is. Ha a magyarországi olvasók a célcsoport akkor célszerű Magyarországon üzemeltetett szerveren futtatni a weboldalt.

A második lépénél túl sokat nem lehet variálni, de annyit igen, hogy a html-t Gzip tömörítéssel szolgáljuk ki.

A megjelenítéshez használt belső komponensek (képek, stíluslapok, JS fájlok) és külső komponensek (reklámok, web statisztika mérőkódok, videók) okozzák a lassulás legnagyobb részét. Ennek az optimalizálásával tudunk a legtöbbet nyerni.

Tulajdonképpen az alapszabály egyszerű, minél kevesebb komponenst használjunk, és ezek minél kisebb méretűek legyenek. A belső komponenseket csoportonként össze lehet vonni, és tömöríteni. Erre vannak speciális eszközök amelyek ezt a két lépést egyszerre elvégzik helyettünk. A külső komponenseknél egyszerű a helyzet: minél kevesebbet használjunk. Sokszor látni mérőkódokkal telepakolt weboldalakat: bekerül a medián webaudit, a gemius és a google analytics is. Miért ne, hisz "nem árthat" ha még több adatunk van. De bizony árthat, nem az adat, hanem az hogy a sok méregetés közben a látogatót fenntartjuk abban, hogy hozzáférjen az oldalunkhoz.

És ott vannak még a reklám zónák, amelyen nyilván üzleti szempontból kerültek oda. A gond az, hogy a Magyarországon legelterjedtebb reklámkiszolgáló szerverei néha annyira lassúak, hogy néha teljesen megakasztják az oldal letöltődését. Próbáljunk olyan reklámkiszolgálót használni, amelyik gyors.

A beépülő Youtube és Indavideók is jól meg szokták akasztani az oldalak használatát. Soha ne tegyünk be egyetlen oldalra egy lejátszható videónál többet. Ezt a Youtube is betartja a saját oldalain belül.

Az utolsó tennivalónk a kliens oldalon a Javascript-ek gyors futtatása. Ez erősen függ a webalkalmazástól, de általános tanácsot adni nem lehet. De érdemes minél kevesebb dolgot bízni a Javascriptre, amit csak lehet váltsunk ki CSS stílusokkal, ugyanis az sokkal gyorsabb.

Persze ne kifejezetten keresőoptimalizálási szándékkal vágjunk bele a fentiekbe, a Google-nél ez csak egy kis szempont. Inkább a látogatók általános megelégedettsége legyen a cél, és ezen is próbáljuk meg mérni az eredményeinket.

4 hozzászólás

Kár hogy pont az Apacheot

Kár hogy pont az Apacheot említed mert az az egyik legnagyobb lassító tényező (ami a forrását megnézve nem is csoda). Lecseréltem LigHTTPd-re, tettem föl egy Django telepítést és láss csodát, 2-5 ms alatt bejött az alapoldal. Mindezt egy 600-as celeronnak megfelelő VPS-ben 256 MB RAM-mal.

A lighy-ra sokan panaszkodtak

A lighy-ra sokan panaszkodtak régebben, hogy csorog a memória, emiatt felzabálja az erőforrásokat. Ezt nem tapasztaltad? Az nginx népszerű még apache alternatívaként.

Nem tapasztaltam ilyet. Az

Nem tapasztaltam ilyet. Az Apachenál biztos nem csorgatja jobban, ma láttam 20 perc alatt fölzabálni 1 giga memóriát. Az nginx-nek meg kicsit impresszionista a confja de tényleg gyors. A Lighty az arany középút.