Mi a gond a lassú weboldallal?
Az elmúlt években a gyors oldalbetöltődési idő a legtöbb webes project megvalósításakor megkerülhetetlen szemponttá vált.
A sebesség nem az informatikusok hóbortja, sokkal inkább egy "kézzel fogható" felhasználói élmény. A gyorsaság befolyással van a Google helyezésre is, tehát olyan alapvető technikai tényező, mely a weboldal célját, funkcióját tekintve elkerülhetetlen.
Dióhéjban a történet
A lassú, más néven optimalizálatlan weboldal sok olyan adatot, illetve számítási feladatot tartalmaz, mely felesleges, ezzel akadályozva a látogatót a tartalom gyors, kényelmes fogyasztásában.
Például olyan, mintha kapna egy nagy kosarat, tele széttört dióhéj darabokkal, de lenne benne 8 db töretlen dió. A feladata az volna, hogy csak a dióbélt (a megpucolt diót) adja vissza nekem.
Ha a kosárban csak a 8 db töretlen dió lenne, akkor a feladatot sokkal gyorsabban el tudná végezni, mint így. Tehát, ha kizárólag a töretlen diókat kapná meg, akkor az egy optimalizált "számítási" feladat lenne az eredeti feladathoz képest, hiszen nem kell kiválogatnia a diókat a törés előtt.
Valahogy így működnek a böngészőben megjelenített weboldalak is. Ha összecsomagolva, kevés felesleges adatot kapnak, akkor a munkát hamarabb fejezik be, hamarabb renderelik ki az oldal tartalmát, tehát gyorsabban lesz olvasható, nézhető az oldal.
Mi számít optimalizáltnak?
Ez egy picit szubjektív dolog, ugyanis az informatikában tulajdonképpen mindig van mit optimalizálni. A példát tovább gondolva a 8 db töretlen dióhoz képest optimalizáltabb az az állapot, ha mind a 8 meg van törve és csak ki kell szedegetni a belet belőlük.
Amikor sebességre optimalizálunk egy weboldalt, még ott is tudnék találni olyan kódokat, amik feleslegesek, olyan kijelző méretet, ahol lenne még 10-20 százaléknyi adatmennyiség csökkentésnyi lehetőség. A cél nem ez, hiszen az nagyon drága volna és az az erőforrás nem biztos, hogy megtérülne egy közepes forgalmú webáruháznál. Azonban vannak olyan sztenderdek, melyeknek illik megfelelni. Az egyik ilyen például az oldal responsivitása.
A mobilbarát oldal félsiker
Ha mobilbarát a portál, akkor az már félsiker. Akkor végül is elmondható, hogy az oldal optimalizálva van a kis méretű kijelzőkre. Azonban ettől még, ha nincs sebességre optimalizálva, az okozhat problémákat. Tegyük fel, hogy van egy új csili-vili weblapja animációkkal, és jön az okostelefonos látogatója, aki a metrón utazva böngészgeti a Google találati listáját és rátalál a szolgáltatásaira, termékeire. Rábök a találatra és vár.
Az oldala nincs sebességre optimalizálva, annyi (felesleges) scriptet, képet tartalmaz, hogy a mobileszköz csak lassan fogja feldolgozni és megjeleníteni az oldalt. Legyen a böngészett oldal mérete mondjuk 3 MB. (Az optimális méret kb. 1,5 MB alatt van) Ezt az adathalmazt a tárhelye elküldi az okostelefonnak, melyet az eszköz letölt, és elkezd feldolgozni. Telnek a másodpercek és a látogató még mindig nem látja az oldal tartalmát.
Így történhet meg, hogy a látványos, fancy weboldal elhasal, ha éppen egy gyengébb teljesítményű okostelefonnal nyitják meg. Még csak gyenge telefon sem kell, hiszen az is megtörténhet, hogy fut a háttérben 6-7 app és meg van nyitva 4-5 db Chrome tab. Az eszköznek az optimalizálatlan weblapon feleslegesen nagy számításokat kell majd elvégeznie, mely növeli a várakozási időt, és feleslegesen leterheli a telefont is.
Apropó várakozási idő: A várakozási időről és a sebesség illúziójáról egy érdekes cikk: A gyors működés illúziója
Optimalizálni, de mit?
Sok lehetőség van, lehet a (Joomla) frontend html, css és a script fájljait összefűzni, tömöríteni és egy szálon elküldeni (minify, combine). Lehet beküldeni a html kód head részében a hajtás feletti tartalom css-eit.
Nem szeretnék mélyebben belemenni ezekbe a (sztenderd) optimalizálási beállításokba, inkább nézzünk egy egyszerűbb, elképzelhetőbb példát, egy fejléc képet.
Miért küldi a weboldala ugyanazt a fejlécet (header) az okostelefonnak, mint amit egy 24 colos asztali HD kijelzőnek? Itt bizony lehet spórolni (optimalizálni) 130-300 kB-nyi feleslegesen mozgatott és feldolgozásra váró adatot.
Külső kényszer
Ha a fentebb részletezett érvek nem győzik meg, akkor bizony itt van a felhasználók önkéntes érdekvédelmi szervezeteként viselkedő Google, hogy meggyőzze.
Tegyük fel, hogy a metrón ülő látogatója nem várja meg ezt az 5-6 másodpercet, mielőtt betöltene az oldala a telefonján. Ekkor azt csinálja, mint mindenki: visszamegy a találati listába, hogy egy másik találatot is megnézzen. Ez ügye alapból nem jó Önnek, hiszen most ment el a konkurens weboldalra a látogató.
Ami még rosszabb ennél, hogy ezt a mintát figyeli a Google és azt a következtetést vonja le, hogy az oldala nem volt hasznos a látogató számára. Ha belegondolunk, akkor tényleg nem, hiszen meg sem tudta nézni. Ha az oldal lassú, nincs sebességre optimalizálva, vagy csak nem jól van beállítva, akkor több ilyen minta rajzolódhat ki, melyet a Google rögzít és elemez.
Ezeket az adatokat a keresőrobot algoritmusa felhasználja, amikor egy-egy kulcsszó keresési eredményének a sorrendjén dolgozik. Ezek az adatok azt sugallják, hogy az oldal nem hasznos a látogatók számára, ergo lejjebb helyezi a (lassú) találatot a listában.
Ellenőrizze le a webfejlesztő munkáját!
Szerencsére számos eszköz van arra, hogy az oldalbetöltődési időt megmérjük. Javaslom a Google PageSpeed Insights ingyenes szolgáltatást, mely ajánlásokat is ad, hogy mi akadályozhatja a weboldal gyors betöltődését. Ezzel az eszközzel elég jól lehet mérni egy-egy webfejlesztő cég munkáját, referenciáit, illetve, akár a saját oldalát. Egy mérés nem mérés, hiszen elképzelhető, hogy egy-egy sebesség teszt alkalmával a kiszolgáló sok klienssel kommunikál, azaz leterhelt. Lehetséges, hogy épp backup-ol a szerver vagy cache ürítés után lassabban tölt be a weboldal. Számos oka lehet annak, ha a szerver lassú, ezért ajánlatos többször mérni. Az átlag számít.
Ha a tesztek folyamán olyan ajánlásokat (nevezném inkább sztenderdeknek) kapunk a Google sebességtesztjétől, hogy:
- Használja ki a böngésző gyorsítótárazását
- Kicsinyítse le a CSS-t
- HTML lekicsinyítése
- JavaScript csökkentése
- Engedélyezze a tömörítést
- Optimalizálja a képeket
.. akkor inkább keressünk másik webfejlesztő céget. A fent felsorolt ajánlások implementálása egy weboldalon kb. 5-10 perc ráfordítást igényel egy tapasztalt on site SEO-val foglalkozó webfejlesztőnek. Ha ezek hiányoznak, érdemes elgondolkodni, hogy megfelelő szakértelemmel rendelkező fejlesztőt bíztunk-e meg.
Ha lassú Joomla weboldalát szeretné felgyorsítani, esetleg elakadt benne és segítség kell, állunk rendelkezésére, írjon nekünk!