A weboldalak többsége valamilyen CMS megoldáson alapul (Joomla, Drupal, Wordpress, stb.).
Ezek használatával viszonylag gyorsan lehet tetszetős és jól használható honlapokat készíteni. Bár az átlagosnál mélyebb szintű ismereteket követel meg egy ilyen oldal összeállítása, a CMS-eket használó webfejlesztők zöme nem tudja, hogy mi zajlik a háttérben, amikor egy ilyen alkalmazás működik.
Minél egyszerűbb, annál bonyolultabb
Ezek a CMS-ek általában csak egy alapot szolgáltatnak a weboldalhoz. Menük, és a hozzájuk tartozó tartalmak, illetve cikkgyűjtemények, blogok. Ha valaki ennél többet akar, plusz modulokat, plugineket kell letöltenie és beépítenie a CMS rendszerébe.
Így lesznek a viszonylag egyszerű webalkalmazásokból fórumok, webshopok, galériák, hírportálok, stb. Ennek azonban súlyos ára van.
Mint ahogy azt a statikus tartalmakról szóló leírásban is említettem, egy oldal behívásakor valójában a böngésző nem egy, hanem több alkalommal fordul a kiszolgálóhoz.
Egyszer a dinamikus, többször pedig a statikus tartalmakért, és főleg ez utóbbiak számossága képes ugrásszerűen megnőni.
Akkor ugyanis, amikor az alapkiszerelésű kis CMS portálunkat különböző pluginekkel, modulokkal és komponensekkel bővítgetjük, minden egyes alkalommal több és több ilyen statikus tartalommal bővül a kör.
A legtöbb ilyen kiegészítőnek ugyanis szintén vannak statikus részei, amelyek minden egyes oldalbetöltésnél növelik a böngésző és a kiszolgáló közti kérdések-válaszok számát.
Hiába van gyors internetkapcsolata a látogatónak, és hiába van nagy sávszélessége a kiszolgálónak, van egy korlát, amiről érdemes tudni:
Egy böngésző egyszerre csak meghatározott számú (4-10) kérést tud a kiszolgálónak elküldeni.
Amíg ezek a tartalmak nem érkeznek meg a böngészőhöz, az várakozni kényszerül, az idő pedig telik.
Ez ugyan a böngészők konfigurációszerkesztőiben többnyire állítható, de az nem szerencsés. Egyrészt nem kérhetjük meg a felhasználót, hogy a weblapunk böngészéséhez túrja szét a saját beállításait, másrészt nem örülnénk annak, hogy ha 10-15 egyidejű látogató egy kattintással ezres számban küldene kéréseket a szerverünk felé.
A hatékony megoldás a kérések számának a drasztikus csökkentése.
Hogyan?
Vannak olyan kiszolgáló oldali eszközök, amelyeket a webszerveren alkalmazva, analizálják a weboldalunk működését. Ha pl. a CMS-ünk kódja azt követeli meg, hogy egy oldal betöltéséhez el kell küldeni a böngészőnek 27 stíluslap fájlt, 39 javascriptet, emellett még 42 különféle statikus tartalmat (kis ikonok, nagyobb képek, betűk), Az azt jelenti, hogy több, mint 100 különböző kérést kell lekezelni egymás után.
Hiába van a statikus tartalmak kiszolgálására külön gépünk, az oldallekérések számában ez nem segít, további optimalizálás szükséges.
Ezek a fentebb említett eszközök megvizsgálják a statikus fájljaink tulajdonságait, és ennek megfelelően módosítják a weboldal kódját is. A kisebb elemeket képesek a weboldal kódjába illeszteni (ez akár a képfájlokra is igaz), a nagyobbakat pedig összevonni (stíluslapok, java scriptek), egyes képtíposokon pedig úgy optimalizálni, hogy lecsökkentik a felbontását (ha az nagyobb, mint ahogyan a böngészőben megjelenik), vagy újratömörítik (ha az nem megy a minőség rovására).
Sok esetben akár a tizedére is csökkenthető a böngésző és a kiszolgáló közötti kérések száma, és az adatmennyiségen is lehet 5-10%-ot faragni.
Ennek következtében a weboldalunk sokkal reszponzívabbá válik, közel ugyanolyan adatforgalom mellett a betöltődése feljavul, mert a böngésző kevesebbet várakozik.
Kiszolgálói oldalon ez jelent némi plusz erőforrásigényt, de az optimalizált tartalom gyorsítótárazható, és az analizátor modulok nem azonnal állnak neki átalakítani a kódot - az adott oldalnak 5-10 alkalommal kell betöltődnie valahol, hogy a végleges tartalom kialakuljon.
A weboldal kódjának optimalizálása, és a statikus tartalmak külön szálon történő kiszolgálása együtt megvalósítva hihetetlen mértékben képes felgyorsítani egy oldal működését úgy, hogy az eredeti alkalmazáskódhoz hozzá sem kell nyúlni.
Nem csodaszer
Azt azért mindenkinek tudnia kell, hogy nem minden típusú lassúságra gyógyír ez a megoldás sem.
A rosszul megírt alkalmazás, és a rosszul megírt adatbáziskezelés, vagy a túl lassú adatbáziselérés csak úgy szüntethető meg, ha az alkalmazás kódjában a hibákat kijavítják, vagy az adatbáziselérés lassúságának az okát kiderítik, és megszüntetik.
Az optimalizálás csak akkor vezet eredményre, ha a lassú működés nem hibából fakad.
Példa
A GTmetrix alapján ennek az oldalnak, ami viszonylag puritán, nem tartalmaz sok médiaelemet és kiegészítőt, optimalizálás nélkül a teljesítménye az alábbi:

Az optimalizálás után pedig:

Látható, hogy a betöltési idő több, mint a harmadára, a kérések száma pedig a felére csökkent (amellett, hogy a betöltött tartalom több). Ez is bizonyítja azt, hogy a http tartalom feldolgozási sebessége nagyon összefügg az oldal elemeinek optimalizálásával, és a statikus tartalmak más kiszolgálóra terelésével.