A Need for speed egy méltán népszerű videójáték volt, sokunkat ültette a 2000-es évek elején a virtuális volán elé. Az nyert benne értelemszerűen, aki a legnagyobb sebességet tudta kisajtolni az általa virtuálisan vezetett autóból és így elsőként tudta átszakítani a célszalagot. A sebesség iránti igényünk webes szempontból 2020 jelszava is lehetne. 2020-ban a járvány hatására a világ internetes sávszélessége soha nem látott terheléssel szembesült, a cégek futólépésben menekítik a szolgáltatásaikat és termékeiket az internetre, a weboldal fejlesztőknek rekordgyorsasággal kell indulniuk a weboldal készítés projektekkel és felhasználóként villámgyors weboldalakat akarunk használni. Ez a bejegyzés a weboldal sebesség miértjét és megoldásait járja körül. 2020 olyan, mint a KRESZ kevésbé ismert része, miszerint az utakon is megbüntetnek a kötelező legkisebb sebesség alatt haladva. Ezzel párhuzamosan a Google és a felhasználók is kíméletlenül megbüntetnek, ha túl lassú a weboldalad.

Ebben a cikkben 7 gyakorlati technikát mutatok be a weboldal optimalizálásra, hogy a felhasználók és a Google is csak elismerően csettintsen, ha a weboldaladat megnyitja.

A weben a gyorshajtást jutalmazzák

Korábban egy menedzseri könyvben olvastam egy fizikai szemléltetést, ami szerint azok a cégek vannak előnyben, ahol gyorsan tudnak dönteni. A természetből vett példa pedig elég húsbavágóan hívta fel a sebesség és gyorsaság fontosságára a figyelmet. A fejezet azzal kezdődött, hogy megfelelő sebesség nélkül a föld beleesne a napba és mind megégnénk. Az internet farkastörvényei, ha nem is ennyire drasztikus és visszafordíthatatlan csapást tudnak mérni egy cégre a sebesség hiánya miatt, de az a kutatásokból kiderül, hogy minden egyes másodperc alatt, amíg egy weboldal töltődik, az érdeklődők 7%-a lemorzsolódik. Ez brutális szám, ha megnézünk egy számolási példát valós sebességi adatokkal.

A felhasználóid 30%-át már a betöltődés előtt elveszíted

2020-ban az átlagos weboldal betöltődési sebesség asztali gépeken 4,7 másodperc és mobilon 11,4 másodperc. A 7% lemorzsolódással számolva tehát egy átlagos weboldal az asztali gépes látogatói 30%-át, a mobilos látogatóinak pedig 55%-át veszíti el. Ehhez jön még hozzá az a tény, hogy a Google 2017 óta a mobil látogatókra nagyobb hangsúlyt fektet (logikus, hiszen többen vannak már).

A fenti veszteséghez jön még hozzá az, hogy egy lassú weboldalra a vásárlók 79%-a kisebb valószínűséggel tér csak vissza. A felhasználók fele pedig 2 másodperces weboldal betöltődést akar. A Google szerint 3 másodperc alatt állunk jól a sebességgel.

Weboldal sebesség teszt

Adott tehát a nem is annyira egyszerű feladat. Mérnökként nagyon sokszor hallgattam az egyetemen azt a mondást, hogy ami mérhető, az javítható is. Tehát a javítás folyamatát kezdjük a méréssel. A weboldal mérésre nagyon egyszerűen használható eszközök állnak rendelkezésre.

Google Pageinsights: mivel a „kaliforniai Nagy Testvért” úgy sem tudja senki kihagyni a webes sikerreceptből, így kézenfekvő az ő sebességtesztjüknek a használata. Előnye, hogy a többi weboldalhoz képest meg is mutatja, hogy hogy állunk, magyarázatot és fejlesztési javaslatokat is ad. Hátránya, hogy nem tudjuk, honnan is tesztelik a weboldalunkat. Egy csak Magyarországon üzletelő weboldalnak a felhasználói élményéhez nem biztos, hogy a legfontosabb, hogy a Mountain View-i szerverekről mennyi idő a betöltődése a weboldalnak. Mindenesetre ad egy jó közelítést asztali gépen és mobilon is:

Fontos felhívni a figyelmet rá, hogy tippjei néha olyanok, mint a Sport szeletes csávó, aki csak segíteni akart, de csak nagyobb bajt okozott a helyzet mélyebb ismerete nélkül …

GTmetrix: több sebességtesztet kombinál, amit én szeretek benne, hogy ki lehet választani, hogy a tesztelést végző szerver melyik városból viszi el egy tesztkörre a weboldalt.

Itt Kanadából teszteltem:

Itt pedig Londonból és majdnem 1 másodperccel jobb eredményt kapok így:

Think with Google: ez az eszköz kifejezetten a mobileszközök szempontjából méri a sebességet 3G vagy 4G mobilhálózaton keresztül. Ami nagyon hasznos, hogy a konkurenciával össze lehet hasonlítani magunkat.
Itt ugyan cipőkanállal becsúsztam 3 másodperc alá, viszont a már Google 2.5-et szeretne (eléggé meg kell izzadni a kegyeiért).

Ami még hasznos megoldás itt, hogy a konkurenciával össze tudjuk hasonlítani az eredményünket.

Weboldal sebesség optimalizálás 

Kevés tartalom: minimalizmus

Michalangelo mondta a Dávid szobor művének készítése kapcsán, hogy „akkor volt kész, mikor már nincs mit elvenni belőle.” Minél kevesebb tartalom és minél kisebb mérettel legyen a weboldalon. Volt egy időszak, amikor a weboldalak főoldalai tele voltak a háttérben automatán lejátszott videókkal asztali gépen és mobilon egyaránt. Mikor azzal szembesültek a weboldal készítők, hogy ezzel eléggé kellemetlen helyzetbe hozzák a korlátos mobilinternetről böngésző gyanútlan felhasználókat, akkor jöttek a csak asztali gépnél a videók, mobil nézetben egy kép helyettesítette ezt. Manapság azonban az látszódik, hogy a főoldali háttérvideók a legtöbb helyről eltűntek.

Tartalom optimalizálás

Van egy nagy amerikai építészeti szektorban dolgozó ügyfelünk, nekik nagyjából 500 MB-nyi kép került fel a weboldalukra, olyan, mint egy építészeti magazin. A képek tömörítésével 380 MB-ra csökkent ez méret, ami azt jelenti, hogy 30%-al azonnal áramvonalasabb az oldal bármikor. Ez 4 másodpercről azonnal a vágyott 3 másodperc alá viszi betöltődést ugyanazon internetes sebesség mellett.
Fontos, hogy a képeken ne legyen látható minőségi romlás. A Photoshopban is webes kép formátum ajánlás, de a weboldal tartalomkezelő rendszerekben is gyakran van képotimalizáló lehetőség. WordPress esetén pl. a TinyPNG plugin lehet jó megoldás, ezzel azonnal növekedni fog a weboldal sebesség.
 

Kód optimalizálás

A HTML, CSS és JavaScript kódot is érdemes optimalizálni, minél áramvonalasabb legyen. Lehetőleg, amit össze lehet csoportosítani, az egyszerre töltődjön be, azok az elemek amelyek nem láthatóak azonnal, azok ráérnek később is betöltődni. Minél kevesebb HTTP kérés legyen a weboldalon.
Fontos, hogy minden ilyen tömörítési hadművelet után a weboldalt tesztelni kell, hiszen okozhat problémát bőven. Nekünk például legutóbb minden működött tökéletesen kivéve a mobil menürendszert, amely elveszítette a funkcióját. A megoldás a JavaScript optimalizálásból a menü elemeinek kizárása volt.
 

Lazy loading

A „lusta betöltéseknél” nem minden elem egyszerre töltődik be egy weboldal megnyitásánál, hogy minél gyorsabban jelenjen meg az értelmezhető tartalom. Hanem azok az elemek töltődnek be, amelyekre szükség van, görgetés vagy klikkelés esetén pedig a következő elemek és így tovább. Lehet ezzel is bőven gyorsítani a weboldalt, hiszen, ha 250 Facebook komment tartozik az adott blogbejegyzéshez, akkor ezek közül nem tölti be mindet, hanem fokozatosan.
 

Első byte-ig eltelt idő leszorítása

Ez a mérőszám egyértelműen a hosting szolgáltató számlájára írható. Ha valaki osztott tárhelyen van és ez a mutató lassú, akkor egyértelmű a hiba. A jelenlegi koronavírusos digitális távoktatásos és Zoom-os időszakban a hosting szerverek fehéren izzanak és nehéz a sok kérést kiszolgálniuk. A Google 200 ms alatti értéket ajánl. Múlt héten az Amerikából hostingolt ügyfelek szerver válaszaideje ez az ajánlást 2-3x-osan is átlépte, ezért csak a szerver válaszidő mindig félmásodperc kérést hozott be a weboldal használatnál, és akkor még a weboldal betöltődése sehol sem volt. Itt a megoldás egy CDN beállítás volt.

Cachelés

Egy weboldal meglátogatása után a weboldal fájljai a számítógéped vagy mobilod tárhelyén fognak tárhely kapacitást foglalni anélkül, hogy mentenéd őket, ezt hívják cachelésnek (gyorsítótárazás). Ez azért va, hogy a legközelebbi látogatásnál már az eszközöd a legtöbb adatot (képek, javascript kód, html, CSS design elemek stb.) gyorsan be tudja tölteni az eszközöd saját tárhelyéről, nem kell a távoli weboldal szervert (annyira) terhelni. Tehát, ezzel a visszatérő látogatók gyorsabb és jobb élményt kapnak. Nemutolsósorban ezzel a megoldással a weboldal látogatói kevésbé terhelik az internetes hálózatot is. Megadható az is, hogy mi legyen cache-elve és mennyi ideig.
Tipp: ha a weboldaladnál valami változtatás van, akkor ürítsd a böngésző cache-ét, mert nem biztos hogy a jelenlegi weboldalt és nem egy régi cache-ben tárolt emlékképet látsz éppen.

CDN

A cikk első felében a Gtmetrix tesztnél látszódott, hogy Londonból egy másodperccel gyorsabban betöltődött a weboldalam, mint Vancouverből. Minél közelebb kellene tehát vinni a felhasználókhoz a weboldalt. A CDN (content delivery network, tartalomtovábbító hálózat) azt jelenti, hogy a weboldal nem csak az eredeti helyszínről (origin szerver), hanem a világban több helyre lemásolásra kerül (edge vagy cache szerverek) és ezekről lesz továbbításra a látogatók felé.

Mindig az az a szerver továbbítja majd a weboldalt, amely a legoptimálisabb földrajzi távolság és leterheltség szempontjából. Ennek a szétosztott hálózatnak az előnye, hogy nehezebben dugul be, gyorsabb és biztonságosabb is, mint az egy telephelyes kiszolgálás. Arra viszont figyelni kell, hogy az eredeti telephelyről lesz a weboldal replikálva, így óvni kell, mint a hímes tojást (Húsvétvasárnap írva a tartalmat meg főleg). Tehát, ha az eredeti telephely kiesik, akkor a weboldal elérhetetlen lesz szintén.

Összefoglaló

A technológiák folyamatosan változnak, ahogy egy jó weboldal tartalma, így a weboldal optimalizálás egy soha véget nem érő versenyfutás. Onnan tudjuk, hogy ideiglenesen révbe értünk, hogy a különböző sebesség teszteken 3 másodperc alatt tudunk szerepelni. Ha ez kész, akkor jöhet a 2 másodperc és így tovább. Nem kell azonban szakmát váltanod és a sebesség megszállottjának lenni, már a fenti technikák sokat tudnak segíteni. Ami fontos, hogy nem javasolt mindent egyszerre beállítani, sokkal jobb fokozatosan áramvonalasítani a honlapunkat. Minden egyes másodperc sokat fog segíteni, mind a felhasználói élményben, mind a konverzióban. Ha minden összeállt még talán egy Need For Speed-ben látott autón is majd elkezdhetsz gondolkodni. Kívánom, hogy így legyen és talán ettől már csak egy weboldalnyira vagy …
Ha tovább olvasnál weboldal projektmenedzsment területen, ami a fenti és még minden szükséges területet összefog: https://www.moonshot.hu/egyeb/weboldal-projektmenedzsment-checklista/
A fenti weboldal sebesség téma szorosan kapcsolódik a korábbi üzemeltetési cikkhez.