Fénysebességű weboldalak?

Az elmúlt időszakok Google frissítései egy új szempontot hoztak be a weboldal üzemeltetők, készítők és a SEO területtel foglalkozók figyelmének a középpontjába: milyen gyors az oldalunk, és miért fontos, hogy gyors legyen?

Azt tudjuk már régóta, hogy az oldalunk látogatói nem szeretnek várni a manapság már rendkívül gyorsnak mondható internet elérési sebességükkel – ezért ez (reméljük) idáig is szempont volt. Ennek az alapvető emberi szempontnak (felhasználhatóság, felhasználói élmény – User eXperience, röviden UX) a figyelmen kívül hagyása már vélhetően rengeteg olyan látogatót tántorított el az oldalunkról, akik potenciális vevővé vagy érdeklődővé tudtak volna válni. Ám a fenti említett kereső oldali algoritmus frissítések alapvetően megváltoztatták ezt a helyzetet azzal, hogy az oldalunk sebessége, reakció ideje, valamint mobil képességei bekerültek súlyos pontszámokkal a Google értékelési módszerébe, kalkulációjába.

Ebben a cikkben az emberi résszel (UX) csak érintőlegesen fogunk foglalkozni – ez, a Weboldal Sebesség Optimalizáláshoz hasonlóan – egy önálló szakterület, és most csak a keresőmotorok szempontjai szerint igyekszünk tanácsot nyújtani ahhoz, hogy jobb eredményeket érjen el a találati listákon – de legalább is a sebességbeli problémák ne csökkentsék a végső pontszámot. Ugyanis ez a részterület csak egy részét fedi le a kereső optimalizálás teljes egészének, nem csodafegyver, de kihagyása veszélyes lehet.

Háttér

Néhány szóban összefoglaljuk, mely elemeket kell figyelembe venni, és melyekkel érdemes foglalkozni, amikor egy weboldal sebességéről beszélünk.
Weboldalunk sebesség indexének összetevői
A fenti ábrán látható, hogy a sebesség index (Site Speed Index – SSI) nagyon sok összetevőtől függ, és akármelyiket kihagyjuk az optimalizálás során, azonnal értékes pontszámokat fogunk veszíteni, és ennek megfelelően hátrébb kerülünk a találati listákon is.

  • A szerver internet elérési sebessége: A weboldalunk egy webszerveren fut egy szolgáltatónál, kérdés, hogy az az adott webszerver milyen internet elérési sebességgel rendelkezik?
  • Szerver erőforrások rendelkezésre állása: Ugyanazon a szerveren általában több weboldal fut egyszerre, kérdés az az, hogy hány weboldallal közösen használjuk ugyanazt a szervert – valamint milyen erős az a szerver amely kiszolgálja a megtekintési kéréseket?
  • Szerver konfiguráció az optimális kiszolgálás érdekében: nagyon sok komponensből áll ez a terület. Milyen típusú webkiszolgáló alkalmazás végzi az oldalunk alatt a munkáját, és az mily módon van konfigurálva – ezek csak az alapok.
  • Tartalom kezelő rendszer feldolgozási és kiszolgálási képességei: az általunk vásárolt rendszer milyen nyelven íródott, és főleg milyen minőségben? Ha egy egyedileg készített tartalom menedzsment rendszert vásároltunk, akkor annak a készítője mennyi tudásnak volt a birtokában, illetve a fejlesztés során ügyelt-e a gyors működésre, az optimális kódok kialakítására?
  • Megjelenített tartalom mérete: ismét komplex terület, de a kérdések nagyjából az egyszerre letöltendő és megjelenítendő tartalom méretére vonatkoznak. Mennyi tartalmat szeretnénk egyszerre átadni a felhasználónak, és vajon szüksége van-e rá?
  • Vizuális tartalom ideális megjelenítése: oldalunk felhasználói élményét különböző stílus elemek, és egyéb összetevők teszik még jobbá. Kérdés az, hogy ezeket a megfelelő sorrendben töltjük-e be, illetve nem akadályozzák-e egymást?
  • Felhasznált média tartalmak optimális rendelkezésre állása: weboldalunk képekkel, videókkal és egyéb nagyméretű tartalmakkal van teletűzdelve. Ha jól optimalizált az oldalunk, akkor ezek „ideális” méretűek, és a böngészőknek nem kell átméretezéssel tölteni az időt.
  • Gyorsító tárak rendelkezésre állása: számos technika áll rendelkezésre arra, hogy a ritkán változó tartalom (képek, szövegek, stb.) eléréséhez ne kelljen mindig kéréseket intézni a weboldalunkhoz – ezeket ki lehet szolgálni saját, vagy felhasználói gyorsító tárakból is.
  • Mindez mobilon is: az optimális pontszám elérése érdekében ugyanolyan sebességűnek kell lennie az oldalunknak asztali számítógépen és mobil eszközön (iPad, Tablet, okostelefon) egyaránt.

Ezekre a területekre a későbbiekben részletesen is kitérünk majd – de mint már említettük egyszerre kell foglalkozni velük ahhoz, hogy megfelelő legyen az oldalunk működése.

Analízis és mérés

Ahogy minden egyes ilyen típusú feladat esetében az első és legfontosabb lépés az az, hogy tisztában legyünk azzal, hogy honnan indulunk el, mi az oldalunk jelenlegi teljesítménye, sebessége. Ezt meg kell mérnünk, analizálni kell, és ez alapján kell egy egyfajta feladatlistát készítenünk, hogy hogyan is fogjuk a weboldalunkat gyorsítani.

Kiemelt terült a már meglévő analitikák (Google Analytics), amiben oldalra pontos számot kapunk arról, hogy mennyi időbe telik az, míg valaki beírja a címet és ENTER-t nyom, vagy rákattint egy hivatkozásra addig, amíg a teljes tartalmat láthatja maga előtt.

Ezt a fajta analízist több oldalról kell elvégezni (amennyiben az eszközök rendelkezésre állnak):

  • helyi asztali és mobil böngészőből (böngészőkből) történő ellenőrzés és mérés,
  • külső szolgáltatótól történő ellenőrzés és mérés ( célországból történő ellenőrzés és mérés, amennyiben külföldön is szolgáltatunk),
  • Analytics-ben és Webmaster Tools-ban lévő historikus adatok elemzése.

Fontos, hogy a méréseket legalább két időpontban hajtsuk végre: csúcsidőben (10:00 óra és 16:00 óra között), és valamikor csúcsidőn kívül (éjjel vagy hajnalban) – hiszen így kaphatunk képet arról, hogy a szolgáltatónk szervere mennyire leterhelt. Természetesen a csúcsidő és a csúcsidőn kívüli időpontok igazodjanak az oldalunk profiljához.

Mit jelent egy ilyen mérés, és hogyan kell azt végrehajtani?

A legbővebb információkat saját böngészőnkből tudjuk megszerezni – természetesen megfelelő böngésző, vagy böngésző kiegészítő használatával. Az alapból az egyik legtöbb szolgáltatást és ilyen típusú eszközt szolgáltató böngésző a Google Chrome. A fejlesztői eszközök (CTRL+SHIFT+I) segítségével teljes képet kaphatunk az oldalunk sebességéről (Network fül):

 
Weboldalunk sebessége
A pirossal jelzett terület mutatja az egyes elemek betöltési sebességét, és hogy hogyan épülnek egymásra (mi a betöltési sorrend), a narancs terület az adott elem méretét, a zöld területen pedig összefoglaló statisztikát láthatunk.

Egy másik eszköz ugyanitt első kézből tanácsot is tud adni (Audit fül), mi az, amin célszerű lenne változtatni:

 
Chrome javaslatok optimalizáláshoz
Azért javasoljuk a több böngészőből történő mérést (Firefox, Opera, Internet Explorer), mivel az egyes böngészők máshogy működnek, más és más (de azért nagyjából azonos) eredményeket adhatnak. Ezek a mérések egyfajta szempontrendszer alapján mérnek, azaz mindig a kiszolgáló szerver, és ami gépünk között történik a mérés – de vajon a világ hogyan látja a mi weboldalunkat? Erre valók a külső szolgáltatói eszközök.

Külső szolgáltatói eszközök

A külső eszközök nagy többségében olyan eredményekkel térnek vissza, ahogy például a Google is látja az oldalunkat – sőt, szinte minden esetben kapunk javaslatokat arra, hogy hogyan tudjuk az oldalunkat még gyorsabbá, sebesség szempontjából optimálissá tenni.

Az általunk is használt eszközök az alábbiak lehetnek, de fontos az is, hogy mely országból végezzük az oldalunk sebesség analízisét, hiszen egy magyarországi weboldalt egy külföldön (ne adj Isten tengeren túlról) üzemeltetett mérőeszköz sokkal lassabbnak fog látni:

Ezen eszközök egészen egzakt eredményeket és javaslatokat tesznek a részünkre, és ha betartjuk egy adott szolgáltató „feladatlistáját”, akkor vélhetően az eredményeink sokkal jobbak lesznek a kereső motorok szempontjából és a felhasználók szempontjából egyaránt.

Folyamatos mérés

A második lépés, hogy az egyes műveletek után mérni tudjuk a változásokat, tehát rendelkeznünk kell olyan analitikai eszközzel, amely az egyszeri méréseken felül, folyamatos támogatást nyújt (például a már említett Google Analytics és a Webmaster Tools).

Ha egy kördiagramban szeretném ábrázolni ezen területek sorrendjét az Analízis és a Mérés az alfája és omegája a területnek, hiszen tudnunk kell, mi a javítandó még, és hova tudunk eljutni.

Sebesség szempontjából meghatározó elemek

A háttér áttekintésénél felsoroltuk nagyjából az összes összetevőt már, amivel foglalkoznunk kell – ezek egyenként is tudnak szűk keresztmetszetet szolgálni. Az előzőleg elkészített analízis során javaslatokat kaptunk arra, mit kell változtatni, nézzük át ezeket most egy kicsit részletesebben.

A szerver internet elérési sebessége

A jelenlegi technológia szint nagy többségében azt jelenti, hogy weboldalunk egyetlen szerveren kerül elhelyezésre, és onnan történik a látogatók kiszolgálása. Előre törőben van végre a felhő (Cloud) alapú infrastruktúra is már (itt több szerver erőforrásai összeadódnak, és egy stabilabb és gyorsabb rendszer alakul ki), de még 1-2 évet várnunk kell vele, mire ténylegesen használni tudjuk majd (persze csak ha van értelme számunkra).

Mivel egy szervert használunk, a legfőbb kérdés az az, hogy annak a szervernek mekkora az internet elérési sebessége. Az esetek nagy többségében itt már 100Mbit/s-ról beszélünk (esetenként ennél is nagyobbról), de még nagyon sok helyen fordul elő 10Mbit/s-os sebesség, sőt olyan is előfordul, amikor egy ilyen 10Mbit/s-os csatlakozási sebességet 2-3 szerver között osztanak el.

Miért fontos ez? Ha a felhasználó szempontjából nézzük, Ő otthon ül, vagy az irodában egy 40-50 Mbit/s-os internetkapcsolattal, tehát ha egyedül nézi az oldalt, akkor a 10Mbit/s esetében is a mi szerverünk a lassúbb, ellenben a 100Mbit/s esetében a kiszolgálás normális marad. De mi van, ha egyszerre 4-5 (esetleg több felhasználó) nézi az oldalunkat, plusz a Google is éppen akkor indexeli az oldalunkat? Kiszámítható: 10 egyidejű felhasználó simán felemészti még a 100Mbit/s-os szerver oldali internet kapcsolatunkat egy bizonyos időpillanatra (hiszen nem folyamatosan állnak kapcsolatban a szerverünkkel).

Mondjuk azt, hogy törekedjünk arra, hogy legalább 100Mbit/s legyen a szerverünk internet kapcsolata, mert a többi technikával ezen a sebességen akár egyszerre 100-150 felhasználót is ki tudunk szolgálni.

Szerver erőforrások rendelkezésre állása

Tételezzük fel, hogy a szerverünk már rendelkezik megfelelő internet elérési sebességgel – de itt egy kicsit vissza kell kanyarodni az alapokhoz. Mennyire megbízható az a szerver, amit használunk? Mi történik áramszünet esetén? Van szünetmentes tápegysége, vagy adott esetben több, egymástól független áramforrásból tudunk áramot nyerni? Előfordulhat-e, hogy megszűnik valamiért az internet kapcsolata, vagy esetleg (hasonlóan az áramhoz), többfajta internet csatlakozással rendelkezik? Maga a szerver mennyire minőségi? Előfordulhat-e meghibásodás, vagy esetleg ezzel járó adatvesztés? Van adatmentésünk?

Amennyiben egy erre szakosodott céggel végezzük a szerverünk üzemeltetését, és a szerverünk egy szerverteremben van, akkor a fenti kérdések 90%-a rendben van. Itt szeretnék mindenkit eltanácsolni attól, hogy ebben gondolkozzon: „Van egy 120 Mbit/s-os UPC előfizetésem, miért nem tudnám az irodából üzemeltetni a szervert?”. Ha nem szerverterem biztonságában van a szerverünk, akkor a fenti kérdésekre mindenkinek magának kell a válaszokat megadnia, és az sokkal drágább, mint akármilyen más szolgáltatáscsomag.

Ha a weboldalunk üzemeltetését egy szolgáltatóra bíztuk, még mindig számos szolgáltatáscsomag közül válogathatunk. Ezek árban, szolgáltatás minőségben, és a biztosított erőforrások területén különböznek egymástól. Manapság az alábbi csomagok érhetőek el:

  • Weboldal hoszting: a weboldalunk egy bizonyos szerveren kap egy bizonyos könyvtárat, ahova fel tudjuk tölteni a fájltartalmat, meg egy adatbázist, ami a tartalmak kiszolgálására szolgál. Olyan, mintha albérletet keresnénk, és csak egy szobát bérelünk ki egy lakásban – együtt kell élni minden más ott lakóval együtt. A legolcsóbb megoldás, alacsony látogatottságú weboldal esetén alkalmazható is, de figyeljünk oda arra, hogy a mi oldalunkkal párhuzamosan hány másik oldal üzemel ugyanazon a szerveren! Láttunk már rémálomba illő „több száz oldal ugyanazon a szerveren” megoldásokat, amiknek nem volt jó eredménye.
  • VPS – virtuális szerver: Tulajdonképpen a panelház esete. Egy nagyobb teljesítményű szerveren készítenek nekünk egy saját elkerített részt (a lakás a nagy panelházban), és bizonyos mennyiségű erőforrás fölött korlátozott hatáskörünk van. De ha a panelház liftjének szempontjából nézzük az egészet, akkor látható a szűk keresztmetszet, hiszen nagyon gyakori technika a szolgáltatók részéről, hogy a hosztinghoz hasonlóan „túltöltik” az erőforrásokat, és mivel a mi virtuális szerverünk versenyzik a többi virtuális szerverrel az erőforrásokért, előfordulhat, hogy sokat várakozik a rendszer. Közepes árszintű megoldás, közepes forgalmú weboldalakhoz – annak összes előnyével és hátrányával, hiszen itt már saját szerverünk van (nagyjából), és például biztonsági kérdésekről is nekünk kell rendelkeznünk.
  • Dedikált szerver: Az előbbi analógiát figyelembe véve ez már egy családi ház. Minden erőforrás felett mi rendelkezünk, mi osztjuk be, mely szolgáltatás mekkora részt kap ezekből, egy nagyobb forgalmú oldal esetében mindenképpen ezt javasoljuk. Vélhetően szerverünk egy szerverteremben van elhelyezve (házunk a lakóparkban), vannak erőforrások, amiken továbbra is osztozni kell, és együtt kell élni a többiekkel. A legdrágább csomag, de mindenképpen megéri annak, aki ebből él, vagy a látogatói számából, hiszen innentől már oszthatóak az erőforrások egy második szerver beállításával, szolgáltatások kiszervezéséből is – negatív oldala meg pont ugyanannyi, mint a VPS esetén van.

Látható, hogy számos lehetőségünk van a válogatásra, alacsony forgalmú oldal esetén is tudunk olyan weboldal hoszting megoldást keresni, amely kielégítő sebességgel rendelkezik számunkra – lényeg az, hogy a számunkra (pénztárcánknak) megfelelőt találjuk meg.

Szerver konfiguráció az optimális kiszolgálás érdekében

Ez az egyik legbonyolultabb és legtechnikaibb része az egésznek. Attól függően, hogy előző pontban milyen megoldást választottunk, annál több dolog fölött tudunk rendelkezni. Többfajta webkiszolgáló alkalmazás közül válogathatunk, ha a VPS, vagy a Dedikált szerver megoldásokat nézzük, míg a Hoszting esetében az van, amit a szolgáltató ad.

Rettenetes mértékben testre tudjuk szabni a webszerverünket, tudjuk működését optimalizálni, finomhangolni ami azért fontos, hiszen egységnyi havi pénzráfordításból jelentősen nagyobb teljesítményt tudunk kihozni, HA mi vagyunk a szerverünk teljes urai.

Olyan beállítások fölött tudunk rendelkezni megfelelő minőségű szolgáltatás esetén, amelyek alapjaiban befolyásolják az oldalunk sebesség indexét:

  • Be tudjuk állítani, hogy a felhasználó tömörített tartalmat kapjon, amivel kb. 25-50%-nyi adatmennyiséget tudunk megspórolni (ha a szolgáltató ezt nem engedi bekapcsolni, akkor érdemes a költözésen gondolkozni, hiszen ez emeli a processzorok használatát minden oldal esetében – ha sok van egy helyen, kiderülhet, hogy az adott szerver túlzsúfolt).
  • Meg tudjuk adni a ritkán változó tartalmainkhoz kapcsolódóan (képek, videók, szöveges), hogy mikor, és mennyi időre kerüljenek a felhasználói, vagy egyéb közös gyorsítótárakba (cache).
  • Mi tudjuk szabályozni az átirányításokat, illetve számos olyan komponenst tudunk beállítani, amivel az általunk átadott tartalom mérete csökken, így az elérési idő is (felesleges külső lekérdezések, átirányítások) csökken.
  • Egyedileg tudjuk azonosítani az oldalunk minden egyes tartalmi elemét, így a közös gyorsítótárak (cache) könnyebben és biztonságosabban azonosítja az egyes elemeket, és magasabb megbízhatósági indexet tudunk elérni a sebesség növelése mellett.

A szerverek és kapcsolódó területei itt le is zárulnak, persze az eddigiek csak a felszínt mutatják, hogy legyen egy összefoglaló képünk arról mennyiben számít az, hogy honnan működik az oldalunk. A felhasználói kérések kezelését innentől a tartalomkezelő rendszerek veszik át – ott is van mivel foglalkozni.

Tartalomkezelő rendszer feldolgozási és kiszolgálási képességei

Manapság már ritkák az úgynevezett egyedi rendszerek, amelyek alapján működik a rendszerünk. Ha valamely „nagyszerű” cég azzal érvvel, hogy így egyedibb lehet az oldalunk – nagyon gyorsan álljunk tovább, hiszen XY Kft. által fejlesztett rendszerhez csak XY Kft. embere ért addig, amíg ott dolgozik.

Nagyon sok közösség által készített tartalomkezelő rendszer (Content Management System – CMS) érhető már ingyenesen, amelyek mögött emberek tízezrei állnak: WordPress, Drupal, Joomla!, és még sorolhatnánk őket. Ezekbe inkább érdemes energiát fektetni, mivel több millió helyen telepítették őket, és ezen visszajelzések alapján tudták a rendszer kódját optimalizálni. Ugyanis ebben a pontban a legfőbb kérdés az az, hogy általunk használt rendszer mennyire kiforrott, mennyire van olyan képességek birtokában, aminek kihatása van a sebességre.

Egy egyedileg készített tartalomkezelő rendszerben, vagy manuális épített weboldalban nincs (vagy nem biztos hogy van – fejlesztő, készítő kérdése) tartalom és sebesség optimalizálás. Számos dologra kell odafigyelni, amelyek nagymértékben befolyásolják az oldalunk sebességét, ilyenek mint:

  • egy oldal betöltéséhez kapcsolódó kérések mennyisége: minél kevesebb annál jobb,
  • az oldalunk minden egyes elemének meg kell felelni a standardoknak (HTML, CSS),
  • nem szabad túl sok, vagy túl kevés külső hívást intézni stíluslapok, vagy felhasználói élményt fokozó eljárások meghívása érdekében,
  • gondoskodnunk kell arról, hogy ezen eljárások csak egyszer kerüljenek meghívásra, mégpedig akkor, amikor szükségesek: ne legyen duplikáció, vagy felesleges eljáráshívás, mert csak a méretet növeli,
  • nem lehet hibás hivatkozás a rendszerünkben, vagy ha mégis, akkor azt megfelelő módon kell kezelnünk,
  • a működés során használt eljárások biztonságosak legyenek, és számunkra átláthatók, hiszen az sem mindegy, saját oldalunk hogyan kommunikál önmagával.

A tartalomkezelőnk lesz az, ami az általunk készített szövegeket, képeket és egyéb dolgokat a felhasználó elé prezentálja, valamint segíti a mi munkánkat azzal, hogy eszközöket biztosít a folyamatos tartalombővüléshez. Válasszuk meg gondosan, ne higgyünk az „egyediség” címszavával eladott termékben, mivel az egyediséget a tartalomkezelő által használt design / stílus fogja adni, nem pedig maga a tartalomkezelő.

A tartalomkezelő az általunk megadott tartalmat fogja a felhasználó / látogató elé prezentálni, de nem mindegy, ennek mekkora a mérete.

Megjelenített tartalom mérete

Akármelyik pont elé odaírhatnám, hogy ez a legfontosabb az összes közül, de a tartalom mérete valóban pályázik erre a címre. Gondoljuk el, ha mondjuk az oldalunk háttere egy 14 megapixeles fényképezővel készített, 6500 x 5200 pixel felbontású, 14 MB-os fénykép, amin egy szép zöld táj van. Ezt minden egyes alkalommal, minden felhasználó számára le kell töltenünk, amikor megnézi az oldalunkat. Ha lassú a szerverünk, akkor ez majdnem esélytelen, ha pedig gyors a szerver, akkor előbb utóbb a sok egyidejű látogató lesz az, aki miatt bedugul az oldal (emlékeznek? 100Mbit/s sebességen osztozik mondjuk 10 felhasználó, aki egyszerre akarja a fenti képet letölteni. Ez azt jelenti, hogy felhasználóként 5 és 10 másodperc lesz az, amíg csak a háttérképet megkapja!).

Ez a terület szorosan épül az előző pontra, a tartalomkezelő rendszerre, hiszen itt olyan dolgokról kell gondoskodni, mint:

  • a felhasznált stíluslapok és külső eljárások minimalizált, tömörített tárolása,
  • az oldalunkon lévő elemek túl nagy számának kerülése,
  • saját tartalmunk méretének megfelelő minimalizálása (nem egyezik meg a tömörítéssel, de mondjuk a felesleges SPACE és ENTER karakterek kivétele a kódból, nagyjából ezt jelenti),
  • szerverünk által közölt azonosító elemek kis mérete.

Ezeket megoldhatja a már említett tartalomkezelő rendszer is, de tudunk egy kis optimalizálással mi is ebbe az irányba haladni – csak ismernünk kell a megfelelő szűk keresztmetszeteket, és akkor javíthatók (analízis, analízis, analízis).

A tartalom mérete mellett az is egy nagyon fontos dolog, hogy az egyes elemeket milyen sorrendben emeljük be az oldalunkba, ez már a vizuális tartalom ideális megjelenítése területhez kapcsolódik.

Vizuális tartalom ideális megjelenítése

Kiemelt fontosságú, hogy az oldalunk felépítésénél használt stíluslapok, és külső eljárásoknak milyen a beolvasási sorrendje. Ahogy az a 2. ábrán látható feljebb, bizonyos elemek betöltése párhuzamosan hajtódik végre, de más elemek betöltéséhez meg kell várni a korábbiak betöltését. Gondoljuk bele, ha egyszerre betöltjük azokat a dolgokat, amiket lehet párhuzamosan használni, majd utána szépen sorban azokat, amiket egyesével kell, akkor gyorsabban fog az oldalunk életre kelni, mintha nem a megfelelő sorrendben betöltve minden egyes rész a másikra vár. Ezt is általában meg szokták oldani a tartalomkezelő rendszerek, de van amikor érdemes belenyúlni és rendet csinálni közöttük. Célszerű a stíluslapok a betöltés elejére venni, és a külső eljárásokat pedig a végére venni.

Még egy dolgot kell itt még kiemelni – bár már kifelé megy az aktuális trendből szerencsére: az ideális megjelenés nem giccses, hanem letisztult, csak szükséges elemeket tartalmazó vizuális élményből áll. Az oldalunk nem attól lesz látogatott (sőt), hogyha mindenféle csicsa-micsa villog, ugrál, énekel, zenél, és ha rengeteg képpel, meg animációval teletűzdeljük. Válasszunk olyan designert, aki tud olyan minimalista design-t készíteni nekünk, amivel saját professzionalitásunkat tudjuk mutatni, és ne pedig egy kezdő weboldal készítő „mennyi minden technológiát ismerek” megoldását. Nagyon sokat tudunk rontani az oldalunkon felesleges vizuális elemekkel, amik lehet, hogy jól néznek ki, de valójában a betöltési időt növelik kizárólag – vagy alkalmazzunk okos megoldásokat, és fejlesztőket, akik aránylag kis erőforrás befektetéssel meg tudják ezeket alkotni a számunkra. Nem hiszen, hogy szükséges dolog az oldal hátterét változtatni attól függően, hogy reggel, vagy este van, vagy tél vagy nyár.

De fényképekre, és más vizuális elemekre szükségünk van, akkor mégis hogyan lehet megoldani itt a sebesség kérdését? Úgy, hogy a kép mindig a megfelelő méretben áll a rendelkezésünkre.

Felhasznált média tartalmak optimális rendelkezésre állása

A Megjelenített tartalom mérete résznél már leírtam az egyik legtipikusabb hibát, hogy egy nagyon nagyméretű képet teszünk be háttérnek 6500 x 5200 pixel felbontásban, ami szép. De tudjuk azt, hogy a jelenleg legelterjedtebb képernyő felbontás a 1680×1050 pixel? Ilyenkor a böngészőnk, amikor letöltjük a képet, rengeteg erőforrást felhasználnak arra, hogy képet lekicsinyítsék látható méretűre, és bizony addig semmi más nem töltődik, de legalább is nem jelenik meg a számunkra.

Egy másik érdekes adat az, hogy az átlagos képméret egy weboldalon maximum 900 pixel széles szokott lenni. De hogy érhető el akkor az, a több különböző méretű kép mégis mindig abban a méretben jelenjen meg, amire nekünk szükségünk van? Az egyes számú segítség megintcsak a tartalomkezelő rendszer – ezeket automatizáltan végzik, azaz sok méretben legenerálják a képeket és egyéb tartalmakat, és mindig a megfelelőt veszik elő. Ezen felül ráadásul nincs szükség 100%-os minőségű képekre – hiszen egy kisebb méretű kép, a minőség 70%-on tartása mellett pontosan ugyanazt a vizuális élményt adja, mint nagyobb.

Ezen felül a stíluslapok megfelelő alkalmazása is segítség lehet – vannak megfelelő technikák arra, hogy a képeket az igénynek megfelelő méretben tudjuk prezentálni akkor, amikor szükség van rá. Fontos ezekre odafigyelni, hiszen már akár egy rossz, vagy egy felesleges kép is jelentős mértékben le tudja lassítani oldalunk működését.

Külön ki kell itt emelni (de később még lesz róla szó), hogy a mobiltelefonon / tableten meg még kisebbek a képek (maximum 720 pixel szélesek, de inkább kevesebb) – ezekre külön technikákat kell alkalmazni, hogy ott is normálisan jelenjenek meg – vagy meg se jelenjenek meg, mert nem is kivehető már olyan méretben.

De még mindig vannak képek, és grafikai elemek, amelyeket le kell tölteni, ráadásul sokszor. Ilyenkor jön képbe az az elem, amellyel a sebességért még tehetünk valamit: a gyorsítótárak, vagyis a cache.

Gyorsító tárak rendelkezésre állása

Amikor gyorsítótárakról beszélünk több technológiai megoldást vonunk össze egy név alá. Olyan eszközök állnak rendelkezésre, amelyekkel legalább annyit tehetünk a sebesség érdekében, mint az összes eddig felsorolt elemmel.

Tartalomszolgáltatás – (CDN – Content Delivery Network)

Rengeteg statikus (ritkán változó) vagy nagyméretű fájl az, amivel valójában dolgozunk, amit a felhasználók elé tárunk nap mint nap – ráadásul már beszéltünk a párhuzamos betöltés lehetőségéről, amely esetén bizonyos tartalmakat a felhasználók egyszerre tudnak elérni a szerverünkről.

Mi lenne, ha ezek a tartalmak nemcsak a mi szerverünkön, hanem a világban mindenhol szétszórva, mégis nagy biztonságban lennének? A szerverünknek kevesebb kérést kellene kidolgoznia, hiszen egyszerre több helyről tudja letölteni a dolgainkat, ráadásul párhuzamosan egymás mellett: nő a sebesség. Sőt, ha nemzetközi szinten gondolkozunk, akkor még jobb a helyzet, hiszen a felhasználó a hozzá legközelebbi szerverről tudja letölteni azt, amire szükséges van, így még a felhasználói élmény is jobb lesz.

A CDN-ek működése nagyon egyszerű: a szolgáltató biztosít a számunkra egy tárhelyet, ahova mi fel tudjuk tölteni a fájljainkat, és ezeket használjuk fel az oldalunknál. A legegyszerűbb ilyen CDN szolgáltató a YouTube, aki videómegosztással segíti a munkánkat. Gondoljuk el, milyen lenne, ha 5-10 darab, 400-500Mb-os videót nézegetne egyszerre 3-4 felhasználó? Rövid időn belül „bedugulna” a forgalmunk.

Valódi gyorsítótárak: a CACHE

A ritkán változó tartalmak (főleg a kisebb méretűek esetében) egy másik eljárás a CACHE, vagy a gyorsítótár alkalmazása. Ennek több fajtája van:

  • felhasználói: ilyenkor a felhasználó gépén tárolódnak a képek, és egyéb anyagok, és ha felmegy az oldalunkra, akkor valójában csak egy ellenőrzést folytat, hogy változott-e a tartalom, és ha nem, akkor a gépéről veszi elő a tartalmakat, nem terheli a szerverünket. Megvan az a hátránya, hogyha a felhasználó törli a böngésző gyorsítótárát, akkor újra le kell töltenie a tartalmakat.
  • tartalom menedzsment rendszerből származó: az okosabb rendszerek úgy működnek, hogy az adatbázis lekérdezést igénylő dinamikus oldalakból (bizony beállítások, és felhasználási szám alapján) statikus oldalakat képeznek, így gyorsabb lesz a kiszolgálás.
  • szerver oldali: ez egy általunk kialakított, és épített gyorsítótár. Bizonyos szabályok alapján működő rendszer ez (ugyanazon a szerveren, ahol a weboldalunk is fut), amely gyorsabb, és kisebb terhelést jelent magára a szerverünkre nézve, az innen származó tartalmak gyorsabban érnek el a felhasználóhoz, mint a tartalomkezelő rendszerünkből.
  • központi: az interneten számos publikus és automatikus gyorsítótár működik a nagyobb forgalmú weboldalak miatt, ahova a mi tartalmaink is bekerülhetnek – hiszen ezzel a teljes internet sebességét növelni lehet. Ilyenkor nagyon nagyon oda kell figyelni, milyen a webszerverünk konfigurációja, milyen elévülési időket állítottunk be az egyes elemekhez, mert ennek lehet „csúnya” vége is.

Ezek (mind a 4 fajta) egyidejű felhasználásával még a leglassabb, legterheltebb weboldal esetében is csodákat lehet tenni – használatuk nélkülözhetetlen.

Mindez mobilon is

Ez itt a jéghegy csúcsa, hiszen eddig mindent úgy készítettünk, hogy asztali számítógépen, vagy notebook-on megfelelő módon (gyorsan, optimálisan) jelenjenek meg az oldalaink. Egy jól átgondolt weboldal építése során, már a legelejétől tudunk erre figyelni, és nem kell a munkánkat duplán végezni.

Erre is léteznek technológiai megoldások, amiket reszponzív, agy adaptív weboldalaknak nevezünk: attól függően, milyen eszközről nézzük az adott oldalt, és az milyen állapotban van (álló vagy elforgatott).

Ezen felül arra is külön figyelmet kell fordítanunk, hogy bizony külső eljárásokhoz kapcsolódó funkciók nem is érhetőek el külön mobilon – tehát a mellett, hogy a vizuális megjelenésre is oda kell figyelni, még bizonyos funkcionális korlátozásokat is be kell vezetni.

Összefoglalás

Az eddig leírtakon felül legalább háromszor ennyit lehetett volna írni szakmai szavakkal még jobban teletűzdelve – de a cél az az volt, hogy egy olyan területről beszéljünk, amit ideje elővenni, amire oda kell figyelni mostantól.

Borzasztóan komplex területről van szó, amely csak egy pici része a még komplexebb SEO területnek, de mivel itt egy versenyről van szó, minden egyes területre oda kell figyelni – így a webhelyünk sebességére is.

Ha már az elején be tudunk kapcsolódni egy projektbe, számos tanáccsal, ötlettel, megoldással tudunk szolgálni annak érdekében, hogy egy komplex, de egyértelmű szabályrendszernek megfeleljen az elkészülő weboldal.

Akkor is van értelme a területtel foglalkozni, ha már elkészült a weboldal, hiszen semmi sem megváltoztathatatlan. Számos esetben kaptunk már megkeresést meglévő weboldal gyorsítására, amelyeket egytől-egyig sikerrel vittünk – bár ilyenkor sokkal több a kötött pont (például tartalomkezelői rendszerek).

Bízunk benne, hogy ezzel a rövid leírással sikerült képet adnunk arról, miért fontos a webhely sebesség index, és milyen eszközöknek köszönhetjük azt ha az éppen lassú, vagy gyors. Az már egy sokkal mélyebb szakmai tudást igényel, hogy az aktuális állapoton változtatni tudjunk, de rendelkezünk a megfelelő tapasztalattal a területen már.

Sári Csaba, 2013. október 17.
clausewitz45@gmail.com
+36 (30) 977-0179

 

6 hozzászólás érkezett ehhez a poszthoz

  1. Profile photo of abissus

    Nagyon jó cikk, érthető volt még egy szakmán kívüli ember számára is,olyan közérthetően adtad elő és ez nagy erény egy szakmáját profi szinten űző embertől! Gratula! 😉

    Tetszik (0)
  2. Profile photo of Taki

    Figyelemre mélto modon összeállitott cikk!
    Valoban könnyen érthetö, preciz munka!
    Nagyon szépen köszönjük!

    Tetszik (0)
  3. Profile photo of Virágos Péter

    Jó kis írás, bár én hiányolom belőle a hálózatról szóló fejezetet!
    Ugyanis a hálózat fizikai és logikai kialakítása alapvetően határozza meg a sebességet!

    Tetszik (0)
  4. Profile photo of bigblog

    Nagyon tetszik ez a cikk! Gratulálok érte 😉

    Tetszik (0)

Szólj hozzá a cikkhez