Weboldalsebesség: miért fontos, és hogyan javíts rajta? (Frissítve, 2022.11.03.)

A weboldalsebesség rendkívül fontos a felhasználói élmény szempontjából, de jó a keresőoptimalizálás miatt is. Elmondjuk, hogy miért okoz gondot a lassúság, mennyi pénzt buksz ezzel, és arra is adunk tanácsot, hogyan tudsz javítani – objektív és szubjektív módon – a weboldalad sebességén. (2022.11.03. – Egy új fejezettel bővítettünk: Hogyan adj visszajelzést a felhasználóknak?) Szinte biztos, hogy Te is futottál már bele olyan weboldalakba – főleg mobiltelefont használva -, melyeknél hiába vártad a Téged érdeklő információ megjelenését, csak egy fehér oldalt nézhettél másodperceken keresztül, és nem történt semmi.

Milyen érzés volt? Ugye nem volt kedved kivárni, amíg betöltődik, és visszaléptél, hogy egy másik találatot nézzél meg? És talán még azt is megjegyezted, hogy melyik oldal volt ez, hogy legközelebb ne kövesd el azt a hibát, hogy újra rákattintasz.

Oké, de a Te weboldalad mennyire gyors? Azonnal megjelenik a felhasználók számára? Mobilon is? Mit mond a weboldaladról a Google?

Ha neked is van egy weboldalad, annak sebességével kapcsolatban pontosan az előbb említett igények merülnek fel az emberek részéről. A weboldal sebessége rendkívül fontos kérdés, hiszen nagymértékben rontja a felhasználói élményt. De lehet számszerűsíteni is a miatta elszenvedett veszteséget, ahogy arra hamarosan rátérünk majd.

Ezért minél hamarabb, minél gyorsabbá tudod tenni a weboldalad, annál jobb. A céged megítélése múlik azon, hogy mennyire gyors a weboldalad, mennyire bíznak meg a márkádban az emberek. Ráadásul, ha lassú a weboldalad, nem is fognak visszatérni a látogatók, és másoknak sem nagyon fogják ajánlani, sem pedig megosztani az oldalt.

És hiába készíttetsz egy ragyogó designt, ha azt a lassú betöltődés miatt az érdeklődők nagy része soha nem fogja látni. Ezért a webdesignerek számára is elsődleges szempont kell legyen, hogy az a weboldal, amit megterveznek, olyan gyors legyen, amennyire csak lehet.

Sokan a sebességoptimalizálást technikai kérdésnek tartják. És bár ez a feladat nagyobbrészt valóban a programozóké, nem nekik kell aggódniuk a weboldalsebesség miatt. Ezzel neked kell foglalkoznod, majd felkérni egy szakembert a megoldásra.

Mennyivel lettek gyorsabbak a weboldalak az elmúlt években?

A felhasználók egyik leggyakrabban hangoztatott igénye a weboldalakkal kapcsolatban a gyors betöltődés – hívta fel a figyelmet Jakob Nielsen már egy 1997-ben közzétett bejegyzésében. Mint akkor írta, 1994 óta, amióta kutatásokat végez a témában, állandóan felmerülő probléma a weboldalsebesség.

Az emberek ugyanis azt várják el a weboldalaktól, hogy azok egy másodpercen belül “válaszoljanak”, amikor egyik oldalról a másikra érkeznek. A válaszidőkkel kapcsolatos vizsgálatok szintén azt mutatják, hogy egy másodpercnél gyorsabb reakciókat várnak a felhasználók.

Az IBM 1970-es és ‘80-as években a témában végzett kutatásai is már arról szóltak, hogy a felhasználók akkor voltak a leghatékonyabbak, amikor egy másodpercen belül reakció érkezett a kérésükre.

Sajnos azonban a weben az egy másodperc alatti válaszidők nem léteznek, így abból indulhatunk ki, hogy a betöltési idő már önmagában rontja a felhasználói élményt – írta Nielsen. A helyzet pedig az, hogy eltelt azóta 23 év, és bár az internet sokkal gyorsabb lett, a weboldalakról ez már nem mondható el – hívta fel a figyelmet egy mostani bejegyzésében az NNG.

Azt gondolhatnánk, hogy az emberek egyszerűen nem veszik észre, hogy a weboldalak is felgyorsultak, mivel az igényeik, elvárásaik is megnőttek a sebességgel kapcsolatban. A helyzet azonban nem ez, miközben persze az is elmondható, hogy a felhasználók elvárásai a sebességgel kapcsolatban néha irreálisak.

A tény az, hogy az elmúlt 10 évben egyáltalán nem nőtt a weboldalak betöltési ideje – legalábbis ez derül ki a Httparchive.org adataiból, mely 6 millió népszerű weboldal betöltési idejét regisztrálja. Ráadásul a helyzet mobileszközökön még rosszabb, hiszen bár a kapcsolati sebesség sokat javult, ennek ellenére a mobilos weboldalak betöltési ideje is nőtt.

Úgy tűnik tehát, hogy az internet sebességének javulása nem oldja meg a lassú weboldalak problémáját. Hiszen a hálózati sebesség csak egyetlen tényező, mely meghatározza a sebességet. Mint Nielsen is írta egykor: fontos tényező a weboldalsebesség szempontjából, hogy azt mindig a leggyengébb láncszem határozza meg a szervertől a böngészőig tartó folyamatban.

Ide tartozik tehát a szerver kapacitása, annak kapcsolódása az internethez, a net maga (gondolj a földrészeken átívelő kapcsolódásra, különösen csúcsidőben), a felhasználó kapcsolódása az internethez, és a böngésző, illetve az eszköz megjelenítési sebessége.

Ezen tényezők mindegyike rontja a weboldalsebességet, ráadásul a késések összeadódnak, és nem igazán számíthatunk jelentős gyorsulásra attól, hogy a lánc egy-egy szemét feljavítjuk.

Persze felvethetjük, hogy az előbb említett adatok talán nem pontosak, mivel a teljesítményt és a sebességet különböző módokon lehet mérni, ugyanakkor mivel a Httpacrchive.org adatait ugyanazzal a módszerrel gyűjti 10 éve, így az mindenképpen látható, hogy nem következett be jelentős javulás a sebességben.

Mindezt figyelembe véve azonban nem mondhatunk mást, mint 23 évvel ezelőtt Nielsen mondott, azaz hogy a weboldalakat úgy kell megtervezni, hogy a sebesség legyen az elsődleges szempont. Ehhez Jakob Nielsen szerint az kell, hogy

• a weboldal mérete kicsi legyen
• a grafika minimális
• multimédia effekteket pedig csak akkor használjunk, ha feltétlenül szükségesek.

A szakértő azt is megjegyezte annak idején, hogy a legfontosabb a válaszidők kapcsán, hogy a felhasználó számára mikor jelenik meg az első kijelzőnyi hasznos információ. Az kevesebbet számít, hogy a teljes oldal betöltődése mennyi időt vesz igénybe, vagy hogy valamennyi illusztráció mikor jelenik meg, ha a felhasználó már lát némi információt, melyek révén elkezdhet cselekedni.

Mindenesetre a különböző kutatási adatokból az nem derül ki, hogy mi az a szám, aminél a weboldalad már elég gyors, vagy aminél még túl lassú. És az sem igazán elegendő, hogy az átlagnál jobb legyen a weboldalad, ha minden más weboldal sebessége frusztrálóan lassú. Az ideális persze az 1 másodperc alatti betöltési idő lenne, ezt azonban a gyakorlatban nem igazán lehet kivitelezni, ha valóban hasznos és jó tartalmat akarsz átadni a felhasználóknak.

Azt ugyanakkor a fenti kutatási számokból látni lehet, hogy minden sebességbeli javulás a weboldal hatékonyságát és eredményességét tekintve sokat számít. Tehát ahelyett, hogy arra törekednél, hogy “elég gyors” legyen a weboldalad, inkább azt kellene szem előtt tartani, hogy mennyivel lehet eredményesebb az oldal, ha egy másodperccel gyorsabban töltődne be. Hiszen minden másodperccel javuló konverziós arányokat érsz el.

Milyen gyorsnak kellene lennie a weboldaladnak?

Mint már az előbb is szó volt róla, akár egy másodperces késés is elég ahhoz, hogy megzavarja a felhasználó gondolkodási folyamatát, és azt fogja érezni, hogy várnia kell a rendszerre, nem pedig azt, hogy közvetlenül irányítja azt. Az ilyen késések pedig rontják a konverziót.

Ezt számos vizsgálat megállapított, így 2009-ben a Google és a Bing is azt jelezte, hogy akár fél másodperces késés a betöltési időben mérhetően csökkenti a konverziós számokat.

A Mozilla 2010-ben azt találta, hogy az oldalbetöltési idő két másodperces csökkentése 15 százalékkal javuló konverziós arányt jelent.

A Gomez 2011-es adatai szerint azokat az oldalakat, melyek 6 másodperc alatt töltődnek be, 25 százalékkal nagyobb eséllyel hagyják ott a látogatók, mint a 2 másodperc alatt betöltődő oldalakt.

2016-ban a Google azt állapította meg, hogy ha egy mobil weboldal 3 másodpercnél lassabban töltődik be, akkor a látogatók 53 százaléka azt meg sem várja. Szintén 2016-os tanulmányukból kiderül, hogy a találati oldaluk fél másodperccel lassabb betöltése esetében 20 százalékkal nő a visszafordulási arány.

Az Akamai 2017-es vizsgálata szerint a konverziós arány azoknál a weboldalaknál a legjobb, melyek kevesebb mint 2 másodperc alatt töltődnek be. A BBC 2018-ban azt állapította meg, hogy minden plusz másodperc a betöltési időben 10 százalékos lemorzsolódást okoz a felhasználóknál.

A Google egyik webmestereknek készült, teljesítményoptimalizálásról szóló videójából az derül ki, hogy ők egy webáruház esetében a 2 másodpercen belüli értéket tartják elfogadhatónak. Ez a számok tehát meg is adják a választ a fejezet címében feltett kérdésre. A weboldaladnak ideális esetben 0,5-2 másodperc közötti értéket kellene hoznia.

John Mueller, a Google szakembere is hasonlóképpen nyilatkozott 2016 decemberében, amikor egy kérdésre válaszolva jelezte, hogy a HTTP betöltési sebességnek 2-3 másodperc alatt kellene maradnia. Azt is hozzátette, hogy ajánlása szerint ezt a webpagetest.org-gal érdemes lemérni.

A Google nem nagyon szokott weboldalsebességgel kapcsolatban konkrétumokat közölni, ezért is fontos John Mueller kijelentése. Ez tehát a viszonyítási alap, melyet érdemes figyelembe venni. Habár, mint a későbbiekben kiderül, a századmásodpercekért felesleges küzdeni. Itt nyilatkozik John Mueller a Twitteren:

@vivek_seo There’s no limit per page. Make sure they load fast, for your users. I often check https://t.co/s55K8Lrdmo and aim for <2-3 secs

— John ☆.o(≧▽≦)o.☆ (@JohnMu) 2016. november 26.

A valóság persze kicsit más. A Pingdom sebességtesztelő eszköz statisztikája szerint 2015-ben az átlagos betöltési idő 5 másodperc volt. Ez azt mutatja, hogy a Pingdom által tesztelt weboldalaknál még nincs teljes mértékben optimalizálva a sebesség. Ezt visszaigazolják a Google mérései, akik elsősorban a mobil weboldalak sebességével foglalkoztak 2016-ban.

Figyelmeztetést küld a Search Console, ha túl lassú az oldalad

Habár eddig nem lehetett pontosan tudni, hogy mit tart a Google túl lassú oldalnak – mely már a találati oldali helyezést is befolyásolja -, most úgy tűnik, hogy lesz mibe kapaszkodni. 2018. október 23-án ugyanis egy felhasználó jelzése szerint a Google figyelmeztetést küldött számára a Search Console-on keresztül a weboldalsebességre vonatkozóan. Az üzenetben azt jelezte a Google, hogy javítania kellene a túl lassú oldalát. Az üzenet itt olvasható angol nyelven: Az üzenetben a Google azt jelezte, hogy a weboldal betöltési sebesség lényegesen alacsonyabb az átlagosnál. Ezt a megállapítást a valós felhasználói mérési adatokra alapozzák, mely a Chrome felhasználói élmény jelentéséből származik. Itt persze ismét felmerül az a probléma, ami a frissített PageSpeed Insightsnál is, hogy a kisebb weboldalak esetében a sebességnél ez mindössze azt jelzi, hogy “unavailable”. Ennek oka, hogy ha nem áll rendelkezésére elegendő adat, akkor abból következtetést sem tud levonni a Google. Mindebből az következik, hogy ha neked nem küld figyelmeztetést a Google, az nem csak abból adódhat, hogy minden rendben van a weboldalad sebességével, hanem abból is, hogy nincsenek meg a megfelelő adatok az értékeléshez. A Google mindenesetre a figyelmeztetésben arra is kitér, hogy a weboldalsebesség rangsorolási tényező, és hogy mit kell figyelembe venni a weboldalunk sebességének meghatározásakor. Ezen túl pedig javaslatokat tesz a megoldásra, többek között a Lighthouse eszköz használatára is utalva (a Lighthouse használatáról itt írtunk bővebben).

Mennyivel növeli a visszafordulási arányt, ha lassú a weboldalad?

A Google azonban nem elégedett meg ennyi vizsgálattal. 2017-ben nekifutott egy másik kutatásnak, melyben azt próbálták meghatározni, hogy a visszafordulási arány milyen mértékben változik az oldal betöltési sebességének függvényében. Az általuk közzétett grafikon rendkívül világosan mutatja be a helyzetet:

Weboldalsebesség és visszafordulási arány a Google kutatása szerint

Ebben a vizsgálatban ismét kiemelik, hogy egy átlagos mobil landing oldal betöltési ideje jelenleg 22 másodperc, miközben a látogatók 53 százaléka nem várja meg azoknak az oldalaknak a betöltődését, melyeknél ez az idő több mint 3 másodperc.

Nem véletlen, hogy a miközben a web-forgalomnak már több mint fele érkezik mobilról, a konverziós arány rosszabb, mint desktopon. Ennek pedig a mobil-weboldalak lassúsága az oka. Ebben a kutatásban a Google 900 ezer mobil hirdetés landing oldalát vizsgálta 126 országból.

Mint kiderült, a weboldalak 70 százalékának csak a hajtás feletti része közel 7 másodperc alatt töltődött be. Ahhoz pedig további 10 másodpercre volt szükség, hogy a teljes weboldal vizuális tartalma megjelenjen.

Azt is megállapították, hogy amikor a betöltési idő 1 másodpercről 7 másodpercre kúszik, a valószínűsége a látogatók visszafordulásának 113 százalékkal nő. És ahogy a weboldalon megjelenő elemek – szövegek, címek, képek – száma 400-ről 6 ezerre nő, a konverzió valószínűsége 95 százalékkal esik.  

Weboldalsebesség és SEO

A weboldalak sebességére érdemes SEO-szempontból is némi figyelmet fordítani, ugyanis a Google számára 2010 óta rangsorolási tényező. De nem olyan értelemben, hogy minél gyorsabb egy oldal, annál előrébb jut a találati listán. Ezzel kapcsolatban további részleteket a rangsorolási tényezőkről szóló bejegyzésünkben találtok.

Mennyit buksz azon, hogy lassú a weboldalad?

Mindjárt kérdezheted is, hogy mégis hogyan függ össze egy weboldal gyorsasága a pénzzel? Pedig egyszerű a képlet, különösen ha a webshopokra gondolunk. Kell még magyarázni? Rendben, megtesszük. Ki lehet ugyanis számolni, hogy mennyi pénzt veszítenek havonta, évente a lassú weboldalak tulajdonosai. Nem árt, ha tudod, hogy a Google SEO szempontból a 1,5 másodpercnél rövidebb betöltési időt díjazza. De ha ez még nem elég, akkor azt is megemlítjük, hogy látogatószámban mennyit veszítesz egy-két másodperceken az Akamai vizsgálata szerint:

• a látogatók 40 százaléka hagyja ott a weboldalad, ha az több mint három másodperc alatt töltődik be
• egy látogató átlagosan mindössze 2,078 másodpercet hajlandó várni az oldaladra
• ha viszont az oldalad egy-két másodperc alatt betöltődik, az már önmagában kétszázalékos látogatószámnövekedést eredményez
• ha leszorítanád egy másodperc alá, akkor 4,6 százalékkal nőne a látogatószám

Ha ez nem elég, akkor hozzátesszük, hogy az Amazon tanulmánya szerint minden egy másodpercnyi lassulás a konverzió 7 százalékos romlását eredményezi, míg a Walmart szerint minden 100 milliszekundumos gyorsítás egy százalékos bevételnövekedést hozott. Az persze jó dolog, ha legalább szép a weboldalad, logikus a navigáció, csodálatosak a hatalmas, faltól-falig képek, lenyűgözőek az animációk, de kérdés, hogy az igen kíméletlen másodpercekkel szembeni küzdelemben elvérzik-e vagy talpon marad? Vagy még csak nem is igazán szép, nem reszponzív, hanem régi, nehéz és lassú?

Weboldalsebesség és konverzió (Forrás: Semrush.com)

És nem csak látogatókat veszítesz folyamatosan egy lassú weboldallal, hanem ebből következően pénzt is. De közelítsük meg a dolgot pozitív oldalról:

minél gyorsabb a weboldalad annál több pénzt hoz neked

Ha sikerül egy másodperccel gyorsabbá tenni, az átlagosan hét százalékos növekedést jelent a konverzióban a Tagman vizsgálata és a legalul látható infografika szerint. Ha webshopod van, akkor ez közvetlenül, összegszerűen jelentkezik. Mint mondtuk, az Amazon és a Walmart már rájöttek, hogy akár 100 millisecundumos lassulás is egy százalékos csökkenést eredményez az eladásaikban (náluk tehát tíz százalékot tesz ki a konverzióváltozás egy másodpercnél). Ez az ő esetükben több millió dollárt jelent évente. De feltesszük egyetlen webshop-tulajdonos sem szereti kidobni a pénzt az ablakon, akármennyiről is van szó. Nézzük akkor, hogy webshopok esetében mit mutatnak a statisztikák egészen pontosan!

• A felhasználók 83 százaléka arra számít, hogy egy webshop 3 másodpercnél gyorsabban betöltődik.
• Ha ez nem történik meg, akkor a látogatók 44 százalékánál ez rossz benyomást kelt,
• 79 százalék esetében csökken a valószínűsége, hogy az oldalon legközelebb megint vásárolni fog
• 46 százalék pedig még panaszkodik is a lassú weboldal miatt az ismerőseinek.

Ha elfogadjuk, hogy egy egymásodperces javulás átlagosan 7 százalékos növekedést eredményez a konverzióban, illetve 1 másodperces lassulás 7 százalékos romlást, akkor egy naponta 10 ezer forint bevételt hozó weboldal esetében az éves veszteség 255 ezer forint lesz (10 000x365x0,07) egyetlen másodperc miatt. Persze, ha a bevétel már 100 ezer forint naponta, akkor a veszteség is eléri forintban a 2,55 milliót. Ha 3-4 másodperccel lassabb, mint lehetne, akkor három-négyszer 2,55 millió, azaz 8-10 millió forint a bukás évente.

Weboldalsebesség és konverzió (Forrás: Tagman)

De pozitív irányból megközelítve: a sebesség ugyanennyivel növelheti is az eredményt, csak gyorsítani kell a weboldalt. Ha napi százezres bevétellel számolunk, akkor egy 1 másodperces sebességjavulással már 2,5 milliós bevételnövekedést érhet el a webshop évente, míg 3-4 másodperces javulással 8-10 millióval növelheti a bevételét.

Gyakorlati példák

Ez egy nagyon szintetikus számítás, a valóság nem feltétlenül így alakul, de vannak példák arra, hogy valós esetekben mit eredményezett egy-egy weboldal gyorsítása vagy éppen lassulása. Már említettük az Amazont és Walmartot, melyeknél minden 100 ms lassulás egyszázalékos csökkenés eredményezett a bevételben, ugyanakkor minden egymásodperces gyorsulás kétszázalékos konverziójavulást hozott.

Egy további szereplő, a Shopzilla 25 százalékkal emelte látogatószámát és 12 százalékkal növelte meg bevételét, amikor a 7 másodperces betöltési időt 2 másodpercre mérsékelte. Barack Obama amerikai elnök kampányában oldalának betöltési sebességét 5 másodpercről két másodpercre javították. Ez 14 százalékkal emelte a konverziót, és plusz 34 millió dollárt jelentett a számára. A Mozilla esetében 2,2 másodperces sebességjavulás 15,4 százalékkal emelkedő konverziót eredményezett, mivel 60 millióval nőtt a letöltések száma éves szinten.

Egyértelmű tehát, hogy mi a feladat. A gyakorlatban a felhasználók által elvárt 3 másodperc alá viszonylag könnyen le lehet szorítani egy weboldal betöltési idejét. A programozót és a pénztárcát nem kímélő munka azonban leginkább ezután kezdődik. Amikor 2, majd esetleg a Google által ajánlott 1,5 másodpercnél gyorsabb betöltődést akarunk elérni. De érdemes és egyre inkább szükséges végrehajtani ezt a fejlesztést. Ha a felhasználó a konkurenciánál várakozás nélkül kapja meg, amit szeretne, akkor azt az oldalt fogja használni, ott fog vásárolni, és oda fog legközelebb is visszatérni, nem pedig hozzád.

Hogyan mérd a weboldalad sebességét?

Habár eddig gyakran elhangzott, hogy hány másodperces betöltési idő számít jónak vagy elfogadhatónak, nem ennyire egyszerű a dolog. Az általában használt és általunk is preferált sebességmérő weboldalak ugyan mutatnak egy számot másodpercben, ez azonban nem árul el mindent a weboldalad sebességéről. Gondolj csak arra, amikor betöltődik a weboldalad. Ennek sok különböző állomása, több különböző része van, melyeket mérni lehet. Lehet, hogy az adatátvitel a lassú, miközben a képek gyorsan töltődnének be. Ebben az esetben milyen gyors a weboldalad?

Persze leegyszerűsíthetjük az egészet egyetlen számra: amíg teljesen be nem töltődik az oldal. A kapott szám nem árul el sok mindent. Az is lehetséges, hogy olyan a weboldal, mely ugyan hosszú ideig nem töltődik be, de a felhasználónak már erre az időre is kínál egy egyszerűsített verziót. Akkor ez az oldal lassabb vagy gyorsabb, mint egy olyan, mely teljes egészében ugyan gyorsabban betöltődik, de a felhasználónak ki kell várnia a teljes betöltődést, mert addig semmit nem lát az oldalon.

A betöltődés folyamata

Attól a pillanattól kezdve, hogy rákattintasz egy weboldal linkjére, vagy beírod a böngészőbe az URL-t és lenyomod az entert, megkezdődik a betöltés folyamata. Ez a folyamat több lépésből áll, melyet néhány nagyobb szakaszra oszthatunk fel. A Google egyik tudásanyagában így mutatja ezt be: Az időket tekintve persze a valósághoz képest túl szép a helyzet, de a lényeget megmutatja. Azaz a folyamat alapvetően három részből áll.

1. Hálózat

Először is a hardverednek kapcsolódnia kell az internethez. Ennek érdekében adatok áramlanak kábeleken és/vagy a levegőben. Ez korlátokat jelent, és meghatározza, hogy az eszközöd milyen gyorsan tudja feldolgozni az információkat. A folyamatnak ez a szakasza meglehetősen nehezen mérhető és nehezen is változtatható meg.

2. Szerver

Aztán ott van a szerver kérdése: az eszközöd lekéri a weboldalt a szerverről, a szerver pedig felkészül és válaszol. A lényeg ebben a szakaszban a szerver hardverének, az adatbázisnak és a szkripteknek a teljesítménye. A szerver teljesítménye olyan eszközökkel mérhető, mint a NewRelic vagy a DataDog. Az adataik alapján kiderülhet, hogy mi a helyzet a weboldalad hostingjánál, és hogy kell-e változtatni téma, a pluginek vagy a szkriptek esetében.

A WordPress esetében találsz olyan plugineket, melyek elvégzik ezt az elemzést. Ilyen például a Query Monitor, mely rámutat arra, hogy mely elemek miatt lassú a WordPress oldalad, hogy a téma, a pluginek vagy a környezet a bűnös.

3. Böngésző

Ez az a szakasz, ahol felépítésre és megjelenítésre kerül a weboldal. Az, hogy miként töltődnek be a képek, a JavaScriptek, miként zajlik a CSS és a HTML címkék feldolgozása, mind meghatározza, milyen gyorsan jelenik meg a weboldalad a felhasználó számára. Ennek vizsgálatára számos eszköz létezik: ilyen a WebPageTest, a Google PageSpeed Insights, a Lighthouse, vagy a Chrome Developer Console, mely pontosan megmutatja, hogy mi történik az oldalad betöltése során a gépeden és a böngésződben. Ezek az eszközök jól megmutatják, hogy milyen elemek azok, melyeket érdemes lenne optimalizálni, milyen CSS vagy JavaScript túl lassú, vagy hogy mikor kell arra várni, hogy más domainről betöltődjenek elemek.

Általános mutatók

Akad néhány olyan általános mutató, melyeket érdemes vizsgálni és optimalizálni minden egyes weboldal esetében. Ilyen az

• első byte letöltéséig eltelt idő, mely azt mutatja meg, hogy mennyi idő kell a szervernek a válaszra. Még ha a weboldalad front-endje rendkívül gyors is, ez alaposan lelassítja az oldalt. Mérhető a Query Monitor vagy a NewRelic segítségével.
• az első fontos kép megjelenítéséig eltelt idő, mely azt mutatja meg, hogy az első kulcsfontosságú vizuális tartalom megjelenítéséhez mennyi idő szükséges. Mérhető a  Lighthouse segítségével.
• mennyi idő kell az interakcióhoz, ami arról szól, hogy mikor lesz látható az élmény és reagál a felhasználóra. Szintén mérhető a  Lighthouse segítségével.

Ezek a mutatók némileg kifinomultabbak, mint az, hogy “mennyi idő alatt töltődik be a weboldal”, és ami talán ennél is fontosabb sokkal inkább a felhasználót helyezik a középpontba. Ezeknek a számoknak a javítása közvetlenül befolyásolja a felhasználói elégedettséget, ami rendkívül fontos SEO szempontból.

A mérés folyamata

Miként nézhet ki tehát a mérés folyamata?

1. Valamilyen eszközzel, például a WebPageTest segítségével elkészítesz egy vízesés-diagramot, ami megmutatja, miként töltődik be a weboldalad.
2. Ez alapján meghatározod a szűk keresztmetszeteket a szervert és a back-end részt illetően. Ehhez használható a már említett Query Monitor vagy a NewRelic, melyek megmutatják, hogy hol akad meg a betöltés.
3. Ezután vizsgáld meg a front-end problémákat: a képek, szkriptek, CSS betöltésével kapcsolatosan. Ehhez használható a Google PageSpeed Insights or , melyek javaslatokat tesznek az optimalizálásra.
4. Végül a kulcsfontosságú mutatók mérésére is igénybe veheted a Lighthouse for Chrome-ot.

Hogyan gyorsítsd fel a weboldalad?

Nézzük meg azt, hogy az előbbiek alapján általában hol lehet a weboldalad áramvonalasítani. Alapvetően a méretet kell mérsékelned, és  arra kell törekedned, hogy kevesebb legyen a HTTP-lekérésed, hiszen ez jelzi, hogy hány elemet kell letölteni. A kevesebb jobb, vagy legalábbis gyorsabb.

Hogyan csökkentsd a HTTP-lekérések számát?

Amikor valaki meglátogatja a weboldalad, akkor a böngésző elküld egy kérést a szerver számára. Ez a kérés a HTTP-lekérés. A szerver válaszol, és készen áll arra, hogy megmutassa a felhasználónak a weboldalad.

A böngésző azonban nem tudja egyszerre az egész weboldalt megmutatni, mivel különféle fájlokra, pluginekre, képekre van szüksége ehhez. Attól függően, hogy hány ilyen alkotóelemből áll össze a weboldalad, a lekérések száma igencsak nagyra nőhet. Ez pedig gondot jelent a sebesség szempontjából. Hiszen minél több HTTP-lekérésre van szükség a weboldalad megjelenítéséhez, annál hosszabb ideig tart a folyamat. 

Először tehát érdemes megnézni, hogy hány HTTP-lekérést küld a weboldalad. Ezt az adatot bármely weboldal-ellenőrző eszközzel megvizsgálhatod, például ezzel. De ha Chrome-böngészőt használsz, akkor a vizsgálat funkcióval szintén meg tudod nézni, a “Network” füre kattintasz.

Az ellenőrző eszközök azt is meg szokták olykor mondani, hogy a lekérések száma soknak számít-e vagy nem. Ha igen, akkor érdemes nekiállni csökkenteni. De hogyan csökkentsd lekérések számát? Itt van néhány lehetőség, melyeket a későbbiekben még bővebben is kibontunk:

• Távolítsd el a felesleges plugineket!
• Ha mindenképpen szükséged van valamely plugin által kínált funkcióra, akkor keress egy kevésbé nehézsúlyú példányt.
• Távolítsd el a felesleges képeket! Hiszen minden kép egy HTTP-lekérést jelent.
• Használj “lazy loading”-ot! Amiről mindjárt részletesebben is lesz szó. A lényeg, hogy ha egy médiaelem nem kerül egyből betöltésre, akkor azzal megspórolsz egy HTTP-lekérést.
• Használj tartalmi gyorsítótárazást! Ez ugyanis azt jelenti, hogy a látogató böngészője tárolja azoknak a szkripteknek a másolatát, melyek szükségesek a weboldalad megjelenítéséhez. Így, ha a felhasználó visszaér, akkor nincs szükség újra minden lekérésre.
• Csökkentsd a külső lekéréseket! Ilyen például, ha a weboldalad megjelenítéséhez kell YouTube vagy Google Analytics. A weboldalad megjelenítése ezeknél attól függ, hogy a szervereik milyen gyorsan reagálnak.
• Érdemes használni a CSS Sprites-t, amely egyetlen lekéréssel megoldja valamennyi kép betöltését, ha sok grafikához tartozó állandó elemet, jellemzően ikonokat, gombokat kell betölteni egy weboldalon, hiszen ez sok http-lekérést jelent.

Dobd ki a felesleges plugineket!

Akadnak olyan pluginek a weboldaladon, melyek nem is használsz? Annak ellenére, hogy ezeket nem használod, lassítják a weboldalad. Ez különösen igaz akkor, ha olyan rendszered van, mint a WordPress. Még azon pluginek használatán is el kellene gondolkodnod, melyeket valójában használsz. Gondold végig, hogy tényleg szükséged van-e rájuk, hozzájárulnak-e a felhasználói élmény javításához? A pluginek száma mellett fontos kérdés a minőségük is. Ne adjál hozzá mindenféle elavult, rossz plugint a weboldaladhoz, keress olyanokat, melyek valóban értékesek és ez az értékeléseknél is tükröződik! A régi, lejárt szavatosságú pluginek lerontják a weboldalad.

Csak szükséges közösségi média elemeket tartsd meg!

Hány közösségi média megosztási gombot használsz a weboldaladon? És ezzel szemben hányra van szükséged? Bár marketing szempontból javasolt ezek használata, az emberek nem használnak túl sokat ezek közül a megosztásoknál, vagy legalábbis nincs minden lehetőségre szükségük. Ugyanakkor ezek az elemek lassítják a weboldalad, növelik a betöltési időt.

Ez különösen igaz az olyan közösségi média elemeknél, melyek még azt is mutatják, hogy hány kedvelésnél, megosztásnál jár az adott oldal, hiszen mindkét irányba le kell futtatnia egy lekérést. Úgyhogy válassz ki csak egy vagy két platformot, melyeken igazán aktív vagy, fontosnak találod őket, melyeken keresztül az emberek kapcsolatba kerülnek veled rendszeresen. Ezeknek a gombjait tedd ki az oldaladra, a többit pedig felejtsd el, mert ezek csak útban vannak.

Mit tehetsz a képekkel?

Videók, illusztrációk, fotók, animációk. Persze, szeretjük őket, javíthatnak is a felhasználói élményen, mindezt azonban a sebesség kárára teszik. Úgyhogy mielőtt hozzáadnál bármilyen képet a weboldaladhoz, mérlegeld a fontosságát a többi elemhez viszonyítva. Kínál valami pluszt a felhasználóknak, vagy csak a helyet töltöd ki vele? Ha igen, akkor tartsd meg, ha viszont nem, akkor minek erőlteted?

Emellett minden képet optimalizálnod kellene a webre, vagyis olyan kicsinek kellene lenniük a fájlméretet tekintve, amennyire csak lehetséges. Ne kezdj el feltölteni teljes méretű fotókat a weboldaladra, még akkor sem, ha így tűnik tökéletesnek a minőségük. Ez persze némi munkát igényel, de megéri, különösen ha folyamatosan növekszik a weboldalad.

Ha csak egyvalamit teszel rendbe a weboldaladon a sebesség érdekében, akkor azok legyenek a képek. Ez igaz a desktop megjelenésre, de különösen igaz a mobilos verzióra. Míg néhány évvel ezelőtt még átlagosan 1,5 MB méretű volt egy weboldal, addig ez a méret mára 2,1 MB-ra nőtt. Ennek egyik oka, hogy nőtt a kép- és videótartalmak mennyisége a weboldalakon. Az alábbi grafikonon pontosan látható, hogy általában mi is adja egy-egy weboldal méretét.

Méretek tartalomtípusok szerint (Forrás: The Fiscal Times)

A képek közel 63 százalékát teszik ki a weboldalak méretének, míg a videók 10 százalékát. A képek felelősek tehát elsősorban egy weboldal sebességéért, illetve azok nagy méretéért. Hiszen minél nagyobb méretű egy weboldal, annál több idő a megjelenítése.

És a Google is ezt mondja

Nem alaptalanul. A Google részéről a legnagyobb gondnak azt találják a weboldalaknál, hogy a képek nincsenek megfelelően mobilra optimalizálva. Ez egészen pontosan azt jelenti, hogy amikor mobilra betöltődik egy weboldal, akkor ugyanúgy a teljes felbontású képet kell megjelenítenie a böngészőnek, mint az asztali verziónál. A felhasználók tehát a legtöbb esetben ugyanazt kapják nagykijelzős asztali gépen, mint egy kisméretű mobilon. A képek nem igazodnak az adott eszközhöz, azaz nincs megfelelően optimalizálva az oldal mérete és sebessége. A videó itt látható minderről: Ökölszabályként elmondható, hogy el kell felejteni a a több száz kb-os méreteket a képeknél. Arra kell törekedni, hogy egy kép mérete ne haladja meg a 70 kb-ot.

Hogyan csökkentsd a képek méretét?

1. Használd a megfelelő felbontást! – A képeid semmiképpen ne legyenek nagyobbak, mint ami végül meg fog jelenni a felhasználóknak. Ez azt jelenti, hogy felesleges 2000×1000 px-es képeket feltölteni, ha a böngészőben 400×200 px-esként jelennek meg. De még ha a teljes kijelzőt ki akarod tölteni a fotóval, mert egy háttérképről van szó, akkor sem nagyon kell 1200-1500 px-esnél nagyobb felbontás, legalábbis, ha nem tartalmaznak apró részleteket. De erre mindjárt visszatérünk.
2. Használd az optimális formátumot! – Sokan követik el azt a hibát, hogy fotókat PNG-ben jelenítenek meg. A minőséggel ugyan valóban nem lesz gond, azonban a mérete többszöröse lehet egy JPG-nek. A PNG-t tartogassuk a néhány színt tartalmazó grafikákra, vagy amikor szükséges az átlátszóság. A JPG fotóknál használandó formátum, míg a GIF a mozgóképeknél. Ezeknél azonban akad most már jobb választás.
3. Használj hatékonyabb, modern képformátumokat! – Alakítsd át a képeidet a korszerűbb WebP és JPEG-XR formátumba. Ez persze azzal jár, hogy a különböző böngészőknek különböző formátumokat kell szolgáltatni, de a méret határozottan kisebb lesz. A WebP-t a Chrome támogatja (a Google fejlesztése), míg a JPEG-XR-t a legtöbb Internet Explorer verzió és az Edge. Egy pluginnal viszont megoldható, hogy Chrome-ba a WebP-t töltse be a böngésző, míg más böngészők a JPG-t használják.
4. Felejtsd el a GIF-et! – A GIF ugyan menő és kényelmes, azonban nem egy hatékony megoldás. Óriási a fájlméret és erősen terheli a processzort, ami különösen mobilon okozhat gondot. Helyette használható az animált WebP a Chrome böngészőknél, esetleg MP4 vagy WebM videók. A legtöbb modern böngésző számára ezek megjelenítése már nem okoz gondot.
5. Nem kell mindenkinek 2X-es (retina kijelzős) kép! – Akadnak még olyan felhasználók, akik normál kijelzőket használva böngésznek. Számukra felesleges a retina minőségű kijelzőkre kínált képfelbontás, elég nekik ennek csak a fele. A megoldás az, hogy kétféle felbontásban tárolod a képeket, és attól függően jeleníted meg őket, hogy milyen eszközzel érkezik a felhasználó.
6. Tömörítsd a képeket feltöltés előtt! – A PNG képek akár 50 százalékkal is tömöríthetők, anélkül, hogy észlelhető lenne a minőségbeli visszaesés. Itt van például egy weben is használható megoldás PNG-k tömörítésére. A tömörítő kodekek sokféle technikát használnak arra, hogy csökkentsék az adatmennyiséget, mely leír egy képet. Elég lehet persze annyi is, hogy Photoshopban a “save to web” opciót használod, így nem kell másik szoftverhez nyúlni külön a tömörítésért. Általában a 60 százalékos tömörítés még elfogadható eredményt ad.
7. Eleve olyan képet válassz, melyen kevesebb a részlet! – A legjobb megoldás, hogy kis méretű legyen egy kép, és ne kelljen rontani rajta a tömörítéssel, ha kevés részletet tartalmaz. Az apró részletek ugyanis azok, melyek a méret nagy részét kiteszik. Itt jól látható a különbség, mindkettő fű, az egyik mérete mégis több mint háromszorosa a másikénak:
   

   134kb

   

   40kb

   Ugyanez igaz egyébként videóknál is. Biztos találkoztál már azzal, hogy amikor egyszerre sok apró részlet, például hullámok, flitterek, levelek jelennek meg egy videóban az elkezdi növelni a méretet.
8. Használj zajcsökkentést vagy elhomályosítást! – Ha egy sötétben készült kép nagyon szemcsés, akkor a mérete is nagy lesz. Ha ezt a szemcsésséget vagy zajt eltávolítod egy szoftverrel, akkor az csökkenti a fájlméretet. De akár az is elég lehet, ha egy kicsit elmosod a képet, legalábbis a méretet jelentősen befolyásolja.
9. Csökkentsd a dinamikatartományt! – A kép sötétítésével érheted el ezt, ami a méretet is módosítja. De ugyanezt a hatást éred el, ha ráhúzol egy szín layert, ezzel ráadásul a márkád imidzséhez is igazítod a képet. Ez különösen jól alkalmazható háttérképeknél, mivel kevésbé zavarja a rá kerülő szövegek vagy grafikák megjelenését.
   

   42 kb

   

   36 kb

10. Ne használj böngésző-oldali méretezést! – Ehelyett szerver-oldalon kellene méretezni a képeket, mert ezzel elkerülhető, hogy feleslegesen nagyméretű képeket kelljen letölteni. Még akkor is megéri előre méretezni a képeket, ha mindez azt jelenti, hogy sokféle méretben létre kell hoznod egy-egy képet.
11. Nincs mindig szükség magas minőségű JPG-re! – Ne félj gyengébb minőségű JPG-fájlokkal kísérletezni, ugyanis sokszor nem látszik a különbség a weben. Természetesen a jobb minőségű JPG kép mindig jobban néz ki, de ez a minőségbeli javulás gyakran túl nagy áldozatot követelhet a sebesség tekintetében.
12. Töröld a meta-adatokat! – Különösen akkor figyelj erre, ha vannak felhasználók által feltöltött fotók a weboldaladon. A metaadatok, azaz Exif infók törlésével gyorsíthatod a fotók megjelenítését, egyedül a megfelelő tájolásra kell figyelni.
13. Mindig add meg a kép kiterjedésének paramétereit, azaz a szélességét és a magasságát a kódban. Ugyanígy az alt attribútumnak, vagyis az alt tagnek is szerepelni kell minden képnél. Ebben kaphatnak helyet a kulcskifejezések.
14. Ne a kódban add meg a kisebb kiterjedést, amennyiben kisebb helyre akarod beilleszteni a képet. Mert ilyenkor feleslegesen tölt le a böngésző egy nagyméretű képet. Ehelyett a képméretet csökkentsd.
15. Háttereket és kereteket CSS-ben formázd meg, mert azok is az oldal betöltési idejét növelik, hiszen méretet jelentenek. Persze egy CSS-t is túl lehet komplikálni, így a CSS fájl betöltési ideje is nőhet.
16. Használhatsz CSS filtereket – a filterek jelzik a böngészőnek, hogy milyen telítettséget, kontrasztot, elmosást, stb. szeretnél látni a képeknél. Csökkenthető tehát mondjuk a telítettség és a kontraszt, ezáltal pedig a méret is, majd a CSS-ben meghatározható egy nagyobb telítettség és kontraszt. Problémát okozhat, hogy nem minden szín telítettsége növekszik azonos mértékben, így egy kicsit furcsává válnak a színek, ha jelentősebb mértékben CSS-en a telítettségen. A másik gond, hogy ha a képeket letöltik a felhasználók, vagy megjelenik a Google képkeresésben, akkor ott a csökkentett telítettségű és kontrasztú verzióval találkoznak.
17. Érdemes használni a CSS Sprites-t, amely egyetlen lekéréssel megoldja valamennyi kép betöltését, ha sok grafikához tartozó állandó elemet, jellemzően ikonokat, gombokat kell betölteni egy weboldalon, hiszen ez sok http-lekérést jelent.

Máshol is el lehet érni csökkentéseket, például az ikonoknál: ikon-fontok használatával a kép-alapú ikonok helyett. Konvertáld át az elemeket SVG-be, azaz vektor formátumba, ha egy ikon-font nem használható. A képek helyett próbálj megoldani mindent, amit lehet HTML-lel és CSS-el. Ne nehezítsd az oldalad olyan elemekkel, melyeket fotóként kell betölteni, például gombok, nyilak.

Dobd ki a felesleges média-fájlokat!

Ez gyakran elkerüli a weboldaltulajdonosok figyelmét, pedig javíthat a betöltési időn. A szerveren tárolsz egy rakás olyan képet, melyeket már nem használsz. Ha ezeket eltávolítod, akkor helyet szabadítasz fel. WordPressben ehhez lépj be a Médiakönyvtárba, és a legördülőben válaszd ki a “Különálló” opciót, mely listázza neked a nem csatolt képeket. Ezeket törölheted is, mert nem használod őket a bejegyzéseidnél.

Kicsinyíts, tömöríts!

A sebességhez a kulcsot tehát a kis méretű fájlok jelentik, és nem csak a képeknél. Ehhez rendkívül sok eszköz a rendelkezésedre áll, például:

• A WP Smush képtömörítésre a WordPress-használóknak.
• A Kraken szintén képtömörítésre bárkinek.
• A TinyPNG ugyancsak sok formátum esetében további csökkenést eredményez.
• A Gzip becsomagolja a fájlokat.
• A CSS-t lekicsinyítheted ezzel az eszközzel.
• A SpriteMe a háttérképeket CSS sprite-okba rendezi, hogy csökkentse a HTTP-lekérések számát.
• A CSS Compressor pedig a kód méretét csökkenti.

A CSS legyen felül, a JavaScript alul

A CSS fájl mindig legyen a weboldal tetején, mert ez sok erőforrást megtakarít. Így: <!DOCTYPE html> <html> <head> <link rel=”stylesheet” href=”yourstylesheet.css” /> </head> <body> Your main content </body> </html> Ugyanakkor a Javascript kódot a weboldal alján helyezd el, közvetlenül a záró body tag után.

Gyorsítótárazz!

Engedélyezd a gyorsítótárazást a weboldaladon! Ha nem teszed, akkor a felhasználók fizetik meg az árát. Van persze, aki ennek használatát vitatja, de a felhasználók és a sebesség fontosabb a vitáknál. A cache révén létrehozol egy ideiglenes fájlt a weboldalaidról, vagyis a felhasználók böngészője emlékszik azokra az oldalakra, melyeket korábban meglátogatott. Így kevesebb adat átvitelére van szükség, csökken a szerver terhelése. A felhasználók pedig megköszönik Neked, különösen abban az esetben, ha már jelentős méretű a weboldalad.

Ne használj beágyazott táblázatot!

Akad még jó pár olyan weboldal, ahol beágyazott táblázatokat használnak, ami felesleges terhelést jelent a böngésző számára és rontja a betöltési időt. <table> <table> <table> … </table> </table> </table> Érdemes tehát nem-beágyazott táblázatokat használni: <table>…</table> <table>…</table> <table>…</table> De még jobban jársz, ha használod a float elemet, és rács-alapú designt alkalmazol, mivel ezek javítják a HTML betöltési sebességet.

Ha sok a hozzászólásod, tördeld fel több oldalra!

Egy-egy nagy forgalmú weboldalon előfordul, hogy akár több 100 komment megjelenítése is terheli az oldalt. Annak érdekében, hogy ezt kiküszöböld, érdemes több lapra tördelni őket. WordPress esetében ez egyszerű: a beállítások résznél keresd meg a hozzászólásokra vonatkozó menüpontot, majd azon belül tedd ki a pipát a “hozzászólások oldalakra bontása” sorhoz:

Frissítsd a PHP-verziót!

Nyilván nem könnyű mindig frissíteni a weboldalt, amikor kijön egy új verzió, viszont hasznos. A sebesség szempontjából is. Az újabb verziók ugyanis sokkal gyorsabbak, mint a korábbiak. Hogy mennyivel, az itt látható (illetve az eredeti vizsgálat ezen az oldalon érhető el):

Használd a WP Rocket pugint!

Ha a weboldalad WordPress alapú, akkor érdemes lehet telepítened a WP Rocket plugint. Ez a plugin automatikusan tömöríti a HTML, JavaScript és CSS fájlokat. Emellett lehetővé teszi a böngésző gyorsítótárazást, az oldal gyorsítótárazást, az adatbázis optimalizálását és a lazy loadot.

A weboldaladra mutató linkek végén is használj perjelet!

Az oka egyszerű: ha egy weboldaladra mutató link végéről elhagyod a perjelet, akkor a szerver a megadott nevű fájlt kezdi el keresni, ami egy teljesen felesleges 301-es átirányítást jelent, hiszen amikor nem találja, akkor néz utána a könyvtárnak. Ez tehát egy többletterhelést jelent a szerver számára, ami rontja a teljesítményt. Vagyis a https://weboldalam.hu URL helyett célszerű a https://weboldalam.hu/ URL-t használni.

Ne engedélyezd a hotlinkinget!

Hotlinkelésről akkor beszélünk, amikor egy másik weboldal úgy használ egy képet, hogy azt a Te szervered szolgáltatja számára. Ez természetesen szűkíti a sávszélességet és rontja a betöltési időt, mivel a szervert leterheli a lekérés. A hotlinkelés blokkolásához a .htaccess fájlhoz kell hozzáadnod egy kódrészletet. Itt egy példa rá: RewriteEngine onRewriteCond %{HTTP_REFERER} !^$RewriteCond %{HTTP_REFERER} !^http://(www\.)pelda.hu/.*$ [NC]RewriteRule \.(gif|jpg|jpeg|bmp|zip|rar|mp3|flv|swf|xml|php|png|css|pdf)$ – [F] A saját kódod attól függ, hogy mely domainek számára engedélyezed a hotlinkelést. Ezzel a htaccess eszközzel létrehozhatod a saját kódodat az igényeidnek megfelelően.

Takaríts rendszeresen!

Ahogy otthon is rendet kell rakni időnként, ugyanúgy a weboldalad adatbázisában, linkjeinél, fájljai között is. Ezeket az elemeket írd fel a takarítási listádra:

• Az adatbázis optimalizálása – egy idő után az adatbázisban túl sok lesz a változtatás, a nem használt fotók, a mentett adatok. Ezeket nem kell mind megtartani. Takarítsd ki azokat az elemeket, melyekre már nincs szükség a weboldaladhoz!
• Javítsd a linkeket – a törött linkek ugyan nem lassítják le a weboldalad, ugyanakkor megnehezítik azt, hogy a felhasználók eljussanak az egyik oldalról a másikra. Ez pedig ugyanolyan rossz. Rendszeresen ellenőrizd, hogy vannak-e törött linkek a weboldaladon, és távolítsd el őket!
• Mindent frissíts – főleg, ha olyan platformot használsz, mint amilyen a WordPress is. A frissítések tartalmazzák a javításokat, melyek hozzájárulnak a sebesség növekedéséhez, valamint védik a weboldalad a különféle veszélyektől. És semmi sincs annál lassabb, mint egy weboldal, amit meghekkelnek vagy megfertőződik.

Optimalizáld a szervereidet!

Ezek után fussunk neki röviden annak a kérdésnek, hogy mit is tehetsz a weboldalad gyorsítása érdekében. Először is sok múlik a hosting-szolgáltatódon: egy minőségi szolgáltatása nem csak jobb támogatást, de nagyobb sebességet is kapsz. Érdemes tehát alaposan körülnézni és utánajárni, amikor hosting-szolgáltatót választasz magadnak.

Az, hogy miként kezeled a szervereidet, rendkívül fontos tényező a weboldalad sebessége szempontjából. Különösen fontos az, hogy milyen a szerver válaszideje. Ez arról szól, hogy mennyi időbe telik, mire a szerver válaszol a felhasználó böngészőjének lekéréseire.

Máshogy fogalmazva, optimalizálhatod a weboldalaidat annyit, amennyit akarod, ha a szervereid nem elég gyorsak, akkor a weboldalad sebessége nem lesz megfelelő. Ezért vannak különböző technikák, melyeket érdemes bevetni, annak érdekében, hogy a válaszidők jócskán lerövidüljenek:

• Használj kevesebb forrást minden aloldaladon (késleltetett képeket, külső CSS és JS fájlokat).
• CDN, vagyis content delivery network használata (erre mindjárt részletesebben is kitérünk).
• Gyorsítótárazás.
• A szerver szoftver-konfigurációjának optimalizálása.

A Webshark weboldalának sebessége a Pingdom tesztje szerint

Használj CDN-t!

Az előbb már említettük a CDN használatát, most lássuk részletesebben, hogy miről is van szó! Röviden: a content delivery network különböző földrajzi pontokon elhelyezett szerverek hálózata, melyek együtt dolgoznak annak érdekében, hogy gyorsabban töltsék be a weboldalaid azon felhasználók számára, akik fizikailag közel vannak valamely hálózatban lévő szerverhez.

A CDN gyorsítótárazza az olyan statikus tartalmakat, mint a HTML, a CSS, a JavaScript és a képfájlok, melyek minden felhasználó számára azonosak. Ezeket a fájlokat nem kell dinamikusan generálni, mint a dinamikus tartalmak esetében. A statikus fájlok csak jelen vannak, és mindenki ezeket használja. Ezeket a statikus fájlokat lehet aztán elérhetővé tenni a CDN világszerte elhelyezkedő szerverei segítségével. Ezáltal a felhasználóid mindenhol gyorsan elérhetik a weboldalad.

Gyorsan meggyőződhetsz a szükségességéről, ha például a korábban már említett Pingdom segítségével különböző elhelyezkedésű szerverek segítségével vizsgálod meg a weboldalad sebességét. Az a weboldal, ami Stockholmban mondjuk 2 másodperc alatt megjelenik, New Yorkban már csak 6 másodperc alatt fog betöltődni. A lényeg itt az, hogy minél nagyobb a távolság a szerver és a kliens között, annál hosszabb időt vesz igénybe a weboldal betöltése. A szervernek ilyenkor több időbe telik válaszolni egy lekérésre.

Habár a legtöbben a CDN-nek azt a tulajdonságát használják ki, hogy felgyorsítja a felhasználók számára a weboldal megjelenését szerte a világban, ennél többet is tud: segítségével csökkenthetők a sávszélesség költségei, javulhat az elérhetőség és a rendelkezésre állási idő, fokozható a biztonság.

A költségeid azáltal csökkenhetnek a CDN használata révén, hogy statikus tartalmakat szolgáltat a felhasználók számára saját szerverről, nem pedig a Tiédről. Gyakran ugyanis a forgalom hullámokban érkezik, és ha egy ilyen hullám meghaladja a rendelkezésedre álló kereteket, akkor az Neked többletköltséget okozhat, mert nagyobb sávszélességre lesz szükséged.

Persze a CDN-ért is fizetned kell, tehát túl sokat nem fogsz megspórolni vele. A CDN ugyanakkor fokozza a biztonságot is, mivel a CDN szolgáltató egyfajta tűzfalként jelenik meg, védve a weboldalad például egy DDoS-támadás miatti leállástól. A leggyakoribb fenyegetésekkel szemben hatékony, és bizonyos speciális beállításokkal a WordPress oldaladtól is távol tarthatod a hackereket.

Emellett pedig skálázható, és javítja az elérhetőséget és a rendelkezdésre állási időt. Már csak azért is, mert a CDN révén kiegyensúlyozhatók a nagy forgalmi ugrások. Ráadásul a növekvő sebesség a SEO és a felhasználói élmény szempontjából is előnyös.

A CDN tehát egy jól használható eszköz, amikor javítani akarod a weboldalsebességet és az oldalad felhasználói élményét, miközben használatával a biztonságot is fokozhatod. Ha tehát a látogatóid egy része külföldről, távolabbi országokból éri el a weboldalad, akkor érdemes lehet megfontolnod a használatát.

Gondold át a webdesignt!

Itt nem csak azt kell figyelembe venni, hogy milyen szép a weboldalad, hanem azt is, hogy ez az elemek betöltésével jár, ami időt vesz igénybe. A weboldalsebesség szempontjából a minél egyszerűbb weboldal a nyerő. De nyilván a webdesignban azért sok más szempont is felmerül. Így kompromisszumokat kell kötni, és kihozni egy minden szempontból elfogadható eredményt. Ebbe beletartozik, hogy

• csökkented a JavaScript fájlok méretét,
• minimalizálod a betűtípusok számát,
• optimalizálod a betöltési sorrendet,
• nem egyszerre töltődnek be az elemek, hanem a hajtás felettiek kapnaknagyobb prioritást, és
• kevesebb szerverlekérést használsz, és
• minimalista webdsignra váltasz!

Nem csak azért érdemes minimalista webdesignra törekedni, mert az most olyannyira trendi, hanem azért is, mert gyorsabb weboldalt eredményez. (Talán éppen ezért lett ennyire felkapott a minimalizmus a webdesignban.) Kevesebb ugyanis a betöltendő elem. Sok későbbi problémától kíméled meg magad, ha már eleve úgy állsz hozzá a weboldalad tervezéséhez, hogy elkerülöd azokat a lehetőségeket, melyek a weboldalad lassulását eredményezhetik. De mitől lesz minimalista a weboldalad?

• Például a hamburger menü használatától a sztenderd menüsor helyett.
• Még több whitespace-től.
• Rövidebb űrlapoktól.
• Kisebb képektől.
• Kevesebb betűtípustól.

Ha viszont már nem tudsz tovább gyorsítani a weboldaladon, mert nem akarsz további kompromisszumokat kötni, akkor adunk néhány tanácsot várakozás élményének fokozásához. Hiszen a sebesség esetében nem csak az számít, hogy a teszteken hány másodperces betöltődési időt ér el a weboldalad, hanem az is, hogy

Hogyan tűnhet gyorsabbnak a weboldalad?

Mert a legfontosabb az, hogy milyen gyorsnak érzik az emberek a weboldalad. Ha a felhasználók úgy érzik, hogy az oldalad villámsebes, akkor már nyert ügyed van. Hiszen a felhasználói élménynél nem az adatok számítanak. Ha a weboldal sebességével elégedettek az emberek, akkor jó felhasználói élményről beszélhetünk.

Egy videón Luke Wroblewski elmagyarázza, hogy a sebesség egy kritikus tényező a felhasználói élmény szempontjából. De ahelyett, hogy különféle bonyolult technikai megoldásokon törnéd a fejed annak érdekében, hogy gyorsítsd a válaszidőt, célszerűbb egy jó designt alkalmazni. Tehát összefoglalva, amikor a weboldalad túl lassú, két lehetőséged van:

• Minden áron leszorítod 3-2-1,5 másodperc alá a betöltési időt, mely felhasználói élmény és a SEO szempontjából mindenképpen üdvözítő dolog.
• Ha azonban ez túlságosan nagy kompromisszumokkal járna – például fel kellene adni funkciókat, el kellene távolítani nagyméretű képeket, videókat, grafikákat -, akkor van egy másik megoldás: élvezetessé kell tenni a várakozást a felhasználók számára.

Mert a lényeg mégis csak az, hogy az emberek ottmaradjanak a weboldaladon. És mivel érheted ezt el?

Frissítve, 2022.11.03.:

Hogyan adj visszajelzést a felhasználóknak?

Akinek van gyereke és autója, és még egy-egy utazás erejéig kombinálni is szokta a kettőt, az tudja, hogy a gyerekek szájából rendszeresen elhangzó kérdés az autóban eltöltött első öt perc után: “ott vagyunk már?” De miért is hangzik el ez a kérdés rendszeresen? Mert miközben mi tudjuk, hogy nagyjából – és ha semmi nem jön közbe – mennyi ideig fog tartani az út, addig a gyerekeknek fogalmuk sincs róla. Nem tudják, hogy mennyi ideig kell várniuk.

Pontosan ugyanez a helyzet a weboldalak és a felhasználók viszonylatában. Persze mondhatod, hogy ezért használjuk a progress indicatorokat vagy állapotjelzőket, melyek megmutatják, hogy miközben a felhasználó tétlenül mereng a dolgok lassúságán, addig azért valami mégiscsak történik. A dolog azonban nem ilyen egyszerű.

Jacob Nielsen, a usability királya szerint, ha egy válaszra 0,1 másodpercnél kevesebbet kell várni, akkor azt a felhasználók “azonnalinak” élik meg. Vagyis semmi dolgunk, csak eléjük dobjuk az eredményt. Ha 1 másodpercig kell várniuk, akkor már felfigyelnek a késlekedésre, azonban visszajelzés még ebben az esetben sem szükséges. 10 másodperc után viszont a felhasználók elveszítik az érdeklődésüket. Ezért ilyenkor már pontosan meg kell nekik mondani nekik, hogy mennyit kell még várniuk, így belekezdhetnek egy másik feladatba.

Ennek kapcsán érdemes tudni, hogy két kutató a Carnegie Mellontól folyamatjelzőkkel kísérletezve azt találta, hogy ha egy feladat 5 másodpercnél rövidebb idő alatt lezajlik, akkor a folyamatjelző miatt az emberek hosszabbnak érzik az eltelt időt. A progress bar ugyanis felhívja a figyelmet arra, hogy várni kell. Érdemes tehát a folyamatjelzőt csak abban az esetben bevetni, ha a betöltődés 5 másodpercnél hosszabb időt vesz igénybe.

De milyen legyen egy állapotjelző. Négy típust különböztethetünk meg:

Loading spinner

Ez a legalapvetőbb betöltési jelzés a weboldalakon, ami egyszerűen informálja a felhasználókat arról, hogy a rendszer dolgozik, így várniuk kell. Ugyanakkor nem ad semmilyen konkrét információt arról, hogy mennyi ideig is kell várniuk. Ennek ellenére egy loading spinner még mindig sokkal jobb megoldás az animáció miatt, mint egy statikus felirat, mely jelzi a betöltődést. Ugyanis az, hogy valami mozog a kijelzőn, azt mutatja a felhasználónak, hogy valami történik.

Egy loading spinnert akár 5 másodpercnél rövidebb betöltés esetén is érdemes lehet használni, vagyis 2-10 másodperc között elfogadják az emberek, e fölött azonban nem. Érdemes ugyanakkor a felhasználók számára egy plusz tájékoztatást is kínálni arról, hogy mire is kell várniuk. Ha elmagyarázod nekik, hogy mit csinál a rendszer, azzal nagyban csökkented a bizonytalanságukat. Szintén segít, ha valamennyire egyedi loading spinnert sikerül alkotni, ugyanis akkor inkább arra fognak figyelni az emberek, nem pedig a várakozásra.

Progress bar

Ha 10 másodpercnél hosszabb folyamatokról van szó, akkor már valamilyen százalékos folyamatjelzőt érdemes bevetni. Ebből kiderül az emberek számára, hogy körülbelül mennyi ideig kell várakozniuk. Az is egy lehetőség, hogy “pontosan” megmondd az embereknek a hátralévő időt. Ez elsősorban akkor hasznos, ha egy folyamat hosszabb ideig tart. De ilyenkor is elegendő, ha csak annyit közölsz, hogy még körülbelül hány percig kell várniuk:

Egy kutatás szerint, amikor az embereknek egy hosszú, de gyors sor és egy rövid, de lassú sor között kellett választaniuk – már hogy melyikbe álljanak -, akkor a hosszabb, de gyorsabb sort választották. Miért? Mert látták a folyamatos változást. Ezért van az, hogy azok a progress barok, melyek folyamatos előrehaladást mutatnak, sokkal jobb hatásúak, mint a sokszor megtorpanó és hosszú ideig semmilyen visszajelzést nem adó folyamatjelzők. Lehet, hogy csak illúzió, de a lényeg, hogy gyorsabbnak érzik a betöltési időt az emberek.

Ez az oka annak is, amiért el kell kerülnöd a statikus progress barok használatát. Ezeken csak egy mozdulatlan kép vagy szöveg látszódik, mely azt jelzi az embereknek, hogy várjanak, mert töltődik valami. Természetesen a semminél ez is jobb, a felhasználói élmény szempontjából azonban messze nem beszélhetünk jó megoldásról. Az emberek ugyanis egy statikus progress bar megjelenésével még mindig nem látják, hogy a háttérben valóban zajlanak-e a dolgok.

A jó megoldás tehát, ami világosan mutatja az aktuális helyzetet. Amire figyelni kell:

• A folyamatjelző soha nem álljon le, mert különben a felhasználók azt gondolják, hogy lefagyott az oldal. A legrosszabb, amikor 99 százaléknál megáll a folyamat.
• Kisebb megakadások elrejthetők egy folyamatosan mozgó progress barral.
• Lehetőleg a folyamat elején lassan haladjon a jelző mozgása, majd a vége felé érdemes begyorsítani, mert ennek révén elégedettebbek lesznek a felhasználók, ugyanis gyorsabbnak érzékelik a betöltődést.
• Az is hasznos, ha azt is jelzed, hogy eddig hány feladaton van túl a folyamat, tehát jelzi a rendszer, hogy hány feladatot kell végrehajtani, és abból eddig hányat sikerült.

Jelzi, hogy hány feladatot végzett el, és hány van még hátra

De van egy további, hatékony kialakítás is. Chris Harrington és kollégái kísérleteztek különböző progress bar típusok hatásával. Azt találták, hogy az emberek 11 százalékkal rövidebbnek érezték az eltelt időt, amikor a jelzés “pulzált”: világoskékből sötétbe váltott, majd vissza egyre növekvő ütemben.

Progress ring

Az előbbi két betöltési jelzés kombinációja a betöltési gyűrű, vagy a progress ring, mely egy rendkívül rugalmas, szinte minden helyzetben alkalmazható megoldás. A gyűrű jelezheti konkrétan a hátralévő időt, de idő jelölése nélkül is mutathatja a betöltődést, ráadásul rövid vagy hosszú várakozás esetében is használható. Utóbbinál persze jeleznie kell a betöltés állását.

Univerzális betöltési jelzés

Használható úgy is, hogy induláskor nem jelzi, hogy mennyi van még hátra a folyamatból, ha szükséged van ennek kiszámítására, majd amikor ez megtörtént, akkor átvált, és jelezni kezd, mennyi idő telt el, és mennyi van még hátra.

Arra figyelj, hogy mindig az óramutató járásával megegyező irányba haladjon a jelzés.

Egy ilyen progress ring egyébként még gombokon vagy bármely más elemeken is használható, ezeknél jól jelzi, hogy a cselekvés végrehajtására időre van szükség.

Továbblépve a progress barokon, a weboldalak megjelenésénél is be lehet vetni pár trükköt a jobb felhasználói élmény érdekében. Jó megoldás, ha a weboldalad szakaszosan töltődik be, és látszik a folyamat, ahelyett, hogy csak akkor teszed a felhasználó orra elé az eredményt, amikor már az egész oldal betöltődött. Ezzel a megoldással csökkenthető a felhasználók passzív várakozási ideje. Vagyis az az idő, amíg csak üldögélnek kényelmetlen irodai székükben és a nagy semmire merednek a monitoron. Erre az egyik megoldás az úgynevezett

Skeleton screen

alkalmazása. Ebben az esetben arról van szó, hogy ideiglenes információs konténereket használsz az oldalon addig, amíg a teljes tartalom be nem töltődik. A skeleton screens tulajdonképpen a weboldalad üres verziója, mely fokozatosan töltődik fel. Ilyenkor  nem kell használni folyamatjelzéseket, mert ez már elegendő jelzést nyújt az embereknek: megmutatja, hogy mire számíthatnak a hamarosan betöltődő oldalon. A csontváz-képek gyorsan megjelennek, mivel kis fájméretű képekről, gyakran egyszerű formákról van csak szó. Ha nem tudod, mi ez pontosan, akkor itt láthatod a Facebook-alkalmazás megjelenését iOS-en: A szürke négyzetek és vonalak jelzik a hamarosan megjelenő képeket és szöveget. Amint befejeződik ezek betöltése, a formák helyén megjelennek a valódi képek és mondatok. Ennek alkalmazásával persze nem lesz gyorsabb az oldal betöltődése, de a felhasználók talán gyorsabbnak érzik.

A skeleton screen tulajdonképpen azt az illúziót nyújtja a felhasználónak, mintha gyorsabb lenne a betöltődési idő. Hátránya ugyanakkor, hogy míg a folyamatjelzők egyértelműen mutatják, hogy töltődik a weboldal, addig a skeleton screen ezt nem jelzi egyértelműen. Ennek ellenére számos tech óriás ezt a megoldást választotta: a Google, a Facebook, a Medium vagy a Slack. Ez pedig már elég indok lehet arra, hogy Te is ezt használd, mivel a nagy cégek is ezt használják, így az emberek ismerik a megoldást, és tudják mire számítsanak a megjelenésénél.

Ugyanakkor persze sok esetben az emberek számára még mindig egyértelműbb, megszokottabb megoldás a folyamatjelzők használata. Ilyen például, amikor olyan médiatartalmakat kell betölteni, mint a képek vagy a videók. Emellett az is érdekes kérdés a sceleton screen kapcsán, hogy miként is definiáljuk azt pontosan. Van ugyanis néha különbség például a Google és a Facebook által mutatott és más oldalak által mutatott vázak között. Míg előbbi már jelzi, hogy miként fog felépülni a tartalom, addig sok esetben a weboldalak, csak általános placeholdereket mutatnak, nem pontosan azt a tartalmi szerkezetet, ami azon az oldalon meg fog jelenni. Utóbbi pedig nem igazán jó megoldás. Olyan oldalvázat kellene ugyanis mutatni a látogatóknak, mely a betöltendő felület alapvető formáit tartalmazza, mégpedig olyan pontosan, amennyire lehetséges.

Elmosódott, kisméretű képek

Hasonló megoldás a skeletonhoz, amikor a képek először csak elmosódva jelennek meg, majd ha teljesen betöltődtek, akkor láthatók élesen. Ilyenkor először csak egy thumbnail töltődik be, aminek nagyon kicsi a fájlmérete. Ha ez elmosódottan jelenik meg, akkor az egy jó placeholder.

Lazy loading

A Webshark weboldalán is találkozhatsz ezzel a technikával, mely szintén egy hasznos jelzés a felhasználók számára a betöltődés folyamatáról. Itt az egyes elemek nem azonos időben, hanem folyamatosan, egymás után jelennek meg egy animációba ágyazva. Ez azért kellemes élmény a felhasználóknak, mert azzal foglalkoznak, ami már látható, és nem kell várakozniuk. A lényege, hogy nem jelenik meg minden elem egészen addig, amíg azokra valóban nincs szükség. Például az olyan elemek, melyek a hajtás alatt találhatók, csak akkor kerülnek betöltésre és megjelenítésre a felhasználó számára, ha már a hajtás alá görgetett.

Ez a “csak akkor, amikor szükséges” megközelítés azt jelenti a weboldalad számára, hogy kevesebb forrással is beéri, ezáltal pedig javul a teljesítménye. Azt meg kell jegyezni, hogy kifejezetten rövid, kis oldalakon nem igazán érvényesül a hatása. Ha a weboldaladon sok a tartalom, és ezáltal a felhasználók jellemzően sokat görgetnek lefelé, akkor lesz igazán hatékony a lazy loading használata.

Tehát ha egy igazi hosszú görgetésű weboldalt terveztél, akkor remekül használhatod a lazy loading technikát, mivel ebben az esetben sokat dob a weboldalad sebességén és felhasználói élményén.

Tedd szórakoztatóvá és integráld az élményt!

Minél jobban le tudod kötni a felhasználóidat a betöltődés közben, annál szórakoztatóbbá teszed a várakozást.Erre valók az animációk, melyeket az emberek szívesen néznek, leköti őket, és nem azzal foglalkoznak, hogy mennyit kell még várni, mire folytathatnák a feladatukat. Talán nem is kell tovább magyarázni. Érdekes, megfogja az embereket, és egyedivé teszed egy ilyen megoldással a weboldalad, de még a céged megjelenését is.

Végül pedig, hogy igazán élvezetessé tedd a várakozást, a betöltési képernyőt kombináld össze a megjelenő weboldallal. Vagyis ne két különálló élményt tervezz, hanem az egyiket vezesd át a másikba. A lényeg, hogy a progress barként megjelenő elem végül beépül a kész oldalba. Így a kettő egységet alkot, a felhasználói élmény tökéletesebb lesz. Pedig várni kell a weboldalra, nem is keveset. Ugye, hogy mégis megteszed, és a végén sem leszel csalódott? Végül pedig ejtsünk pár szót külön a mobilos élmény javításáról is.

Címkék: webdesign, weboldal sebesség, weboldalsebesség