Mi az a weboldal redesign? Mikor és miért van rá szükséged? (Frissítve, 2023.09.29.)
Ma már az emberek az első benyomásukat a cégedről az interneten, a..
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. (2023.04.05. – Egy új fejezettel bővítettünk: Hogyan gyorsítsd fel a WordPress-oldaladat?)
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.
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 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.
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.
Az emberek 53 százaléka elhagy egy weboldalt mobilon, ha az nem töltődik be 3 másodperc alatt. Ez a lényege a Google tanulmányának, mely a “The Need for Mobile Speed” címet kapta. A mellékelt linken prezentálták is egy szépen elrendezett formában az összefoglalóját.
Kiemelendő, hogy nem wifi hálózaton kell a 3 másodperces értéket elérni. Hanem bizony a szűkös mobil-adatforgalom mellett elérendő ez a weboldalsebesség. És ez azért is fontos, mert mint a Google már korábban is jelezte: a keresések több mint fele mobilról érkezik.
Ez a 3 másodperces weboldalsebesség-érték némi aggodalomra adhat okot, tekintve, hogy most egy átlagos weboldal mintegy 19 másodpercig töltődik 3G hálózaton, de 4G-n is 14 másodpercig tart a megjelenése. A weboldalak 77 százaléka egyébként 10 másodpercnél hosszabb ideig töltődik.
És ezek a főoldalak. Az aloldalak jellemzően fele olyan gyorsan jelennek meg a felhasználók kijelzőjén. Pedig a felhasználók 46 százaléka a webes böngészésben azt tartja a legidegesítőbbnek, amikor várni kell a weboldal betöltődésére.
A Google szerint a lassúság oka elsősorban a fájlméret, az elemek elrendezése és a szerverlekérések száma. A hirdetések, a képek, a videók és a mérési technológia hatására csökken a weboldalsebesség.
A legnagyobb visszaesést pedig a hirdetések okozzák a weboldalakon. A mobilhirdetések átlagosan 5 másodperc alatt töltődnek be. Ez éppen kétszerese annak, amennyi idő alatt asztali gépen megjelennek. Egy átlagos mobil-weboldal mérete 2,5 Mb. Ami azt jelenti, hogy csak az adatok betöltése 13 másodperc 3G-n. Maga a tartalom ebből 1,49 Mb méretű, míg a reklámok átlagosan 816 Kb méretűek.
A Google tanulmányában egyébként az is szerepel, hogy az emberek fele elvárja, hogy egy mobilos weboldal kevesebb, mint 2 másodperc alatt töltődjön be. A Google ezért felhívta a figyelmet arra, hogy most már nem elég, ha egy weboldal rendben megjelenik mobileszközökön.
A mobiloldalnak ugyanis gyorsnak is kell lennie. A lassú weboldalak frusztrálják az embereket és persze negatív hatással vannak a weboldalra is. Ugyanakkor, ha már sikerül elérni az 5 másodperces weboldalsebesség-értéket, akkor az átlagos 19 másodperces oldalakhoz képest 25 százalékkal jobb lesz a láthatóságod, 70 százalékkal lesz hosszabb az átlagos munkamenet, és 35 százalékkal csökkent a visszapattanási arány.
A tanulmány emellett kitért a weboldalsebesség és a bevételek közti összefüggésekre is. És miközben persze a bevételeket számos tényező határozza meg, azoknál a weboldalaknál, melyek 5 másodperc alatt betöltődtek, kétszeresére nőtt a mobilhirdetésekből befolyó összeg a 19 másodperces oldalakhoz képest.
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.
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.
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.
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:
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:
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!
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.
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.
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.
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.
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.
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.
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.
Akad néhány olyan általános mutató, melyeket érdemes vizsgálni és optimalizálni minden egyes weboldal esetében. Ilyen az
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.
Miként nézhet ki tehát a mérés folyamata?
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.
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:
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.
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.
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.
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.
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.
134kb
40kb
42 kb
36 kb
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.
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.
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 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.
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.
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.
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:
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):
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.
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.
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.
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:
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:
A Webshark weboldalának sebessége a Pingdom tesztje szerint
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.
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
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?
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
Habár egy WordPress-oldal is csak egy weboldal, a lényeget tekintve tehát pont olyan, mint a többi, így a fenti iránymutatás alkalmazható rá, érdemes külön a WP-oldalakhoz tippeket adni, ugyanis vannak kisebb, illetve tipikus eltérések, melyek csak ezekre a weboldalakra jellemzők.
Kezdjük ott, hogy bár elsőre egyszerűnek tűnik a WordPress-platform, azért a motorháztető alatt ez is bonyolult. Akadnak benne olyan elemek, mely különféle adatbázisokból töltik le az adatokat, amikor meg kell jeleníteni egy weboldalt. Ha sok oldalad van a WP-webhelyeden, ráadásul rengeteg média-tartalom kapcsolódik hozzá, valamint különféle plugineket is telepítettél, ezek így együtt elnehezítik az weboldalad.
Ugyanakkor viszont a WordPress azért alapvetően elég rugalmas rendszer, és vannak lehetőségek arra, hogy jelentősebb szakértelem nélkül is javíts a weboldalsebességen.
Természetesen egy WordPress-oldalnál is kiindulópont a jó webhosting, hiszen a fájlok és az adatok a szerveren tárolódnak. Kell tehát egy gyors és stabil szerver, azaz legyen jó az „üzemideje”, vagyis mindig biztosítsa a weboldalad elérhetőségét. Fontos azonban a skálázhatóság, ami azt jelenti, hogy a forgalmi csúcsokat is ki tudja szolgálni. Végül pedig sebesség szempontjából fontos tényező a felhasználóktól való távolság. Hiszen egy távoli szerver lehet ugyan gyors, de a felhasználó számára mégis lassúnak fog tűnni.
Sokan elsiklanak a PHP-verzió frissítése felett, pedig sokat tud javítani a weboldalad sebességén is, ha mindig a legfrissebb verziót használod:
Arra azonban figyelj, hogy egy PHP-frissítésnél kompatibilitási problémák jelentkezhetnek a plugineknél és témáknál. Emiatt pedig le is állhat a weboldalad, vagyis előbb készíts egy mentést és tesztelj!
Remélhetőleg ez egyértelmű, de azért itt is megemlítjük: a WP-verziód mindig legyen a legfrissebb. Ez nem csak a biztonságot tekintve fontos, hanem a sebességre is jó hatással van. A WordPress 6.1 például sokat javít a teljesítményen a jobb adatbázis-teljesítmény és médiakiszolgálás révén. Ráadásul az újabb WP-verzió révén újabb PHP-verziót is használhatsz, ami szintén hozzájárul a teljesítményjavuláshoz. Természetesn az új WordPress verziót is tesztelni kell, hogy ne legyenek gondok egyes pluginokkal.
Egy egyszerű lehetőség arra, hogy elsősorban a visszatérő felhasználók számára gyorsabbá váljon a weboldalad. A gyorsítótárazás révén ugyanis nem kell mindig lekérni az adatokat a szerverről, azok a gyorsítótárból rendelkezésre állnak. Ezt a feladatot a gyorsítótárazó pluginok a WP-ben általában el is végzik. Arra azonban figyelj, hogy amikor több ilyen gyorsítótárazó + optimalizáló plugint is használsz, azok olykor egymást akadályozzák, és lassítják a weboldalad.
A WordPress oldalad által használt téma is befolyással van annak betöltődési sebességére, ugyanis az egyes témák nem egyforma méretűek és nem egyformán jól kódoltak. Egy rossz kód lelassíthatja az oldalad, ahogy az olyan témák is, melyekben sok a kép, a szkript és egyéb elemek. Ezek mind az oldalméretet növelik. Érdemes tehát egyszerű témát választani, azt is gondosan, az értékelések, vélemények figyelembevételével.
A WordPresst a pluginok teszik jól használhatóvá, ugyanakkor ezek hátrányára is válhatnak az oldalnak. Különösen, ha ész nélkül telepítjük őket. Egy-egy pluginnal jobban használható lesz az oldalad, a túl sok viszont rontja a teljesítményt. Minél több funkciót kell ugyanis betölteni, annál lassabb az oldal. Azokat a pluginokat, melyeket nem használsz, minél előbb távolítsd el. Ez nem csak a sebességnek tesz jót, hanem csökkented a kockázatát a kompatibilitási problémáknak is.
A képek jelentős befolyással bírnak egy weboldal teljesítményére. Minél nagyobbak és minél több van belőlük, annál jobban lelassítják az oldalt. Már egy túl nagy és nem optimalizált hajtás feletti nyitókép is jelentős mértékben ronthatja a webes vitals mutatókban szereplő LCP-pontszámot.
Valójában nincs szükséged óriási felbontású képekre. Pont elég egy olyan, ami kellően élesnek néz ki ahhoz, hogy látni lehessen rajta azt, amit ábrázol. Annál is inkább, mert a minél nagyobb felbontás (és méret) nem mindig egyenlő a jobb képminőséggel.
Mindenesetre mielőtt feltöltenéd a képeidet a weboldaladra, csökkentsd a méretüket a lehető legnagyobb mértékben. Ez különösen fontos, ha több képet is megjelenítesz az oldaladon. Erre használhatók pluginek, melyek automatikusan elvégzik ezt a feladatot.
Jelentős hatással van a sebességre az is, hogy miként szolgáltatod a médiatartalmakat a felhasználóknak. Nemsokára részletesebben is ismertetjük például a lazy-loading technikáját, melyet már sok weboldal használ, a WP-be pedig már beépítették. Ennek hatására a weboldal csak akkor tölt be egy képet, amikor arra valóban szükség van.
Ott van még a videók kérdése, melyeket érdemes nem a szerveren tárolni. Ezek sok helyet foglalnak és nagyon lassítják az oldalt. Praktikusabb videómegosztó platformokat használni, aztán beágyazni a videókat az oldalba. Arról azonban győződj meg, hogy ennek során csak egy képet tölt be az oldal, a videó csak interakció hatására töltődik be.
Természetesen itt is előkerül a CDN használata, ami akkor különösen fontos, ha távoli felhasználókat is kiszolgál a szervered. A CDN-ről fentebb már írtunk, lényege, hogy ezzel létrejön a weboldalad statikus tartalmának néhány másolata a hálózathoz tartozó szervereken. Ezért a felhasználót nem az eredeti szerverről közvetlenül kell kiszolgálni például a HTML-fájllal, hanem a hozzá közelebb lévő CDN-szerverről történik ez. Ha WP-hez használsz CDN-t akkor fontos a jó plugin is, amilyet például a Cloudflare kínál.
Ez egy olyan pont, ami nem a kezdőknek vagy a laikusoknak való, tehát, amikor ebben gondolkodsz, akkor érdemes egy gyakorlott fejlesztő segítségét kérni. A lényeg, hogy a szkriptek számát csökkenteni és optimalizálni kell.
Nem csak a képek méretét érdemes csökkenteni, hanem a HTML, CSS vagy JavaScript fájlokét is. Annak ellenére, hogy ezek nem túl nagyméretű fájlok és a csökkentés sem tűnhet óriásinak. Olyan optimalizálási lehetőségek vannak, mint például az ismétlődő sorok megszüntetése a kódban, vagy a több fájl egy fájlban történő összehozása és tömörítése. Ehhez nem kell feltétlenül programozónak lenned, mert akadnak rá pluginok, mint például az Autoptimize vagy a WP Minify.
Mindig, amikor a felhasználó kattint a weboldaladon, a böngésző több HTTP-kérést indít a szerver felé, amivel különböző fájlokat és adatokat kér. A szervernek a kéréseket fel kell dolgoznia, vissza kell küldeni a szükséges fájlokat, így a böngésző meg tudja jeleníteni a weboldalt a felhasználónak.
A HTTP-lekérések számának csökkentése tehát alapvetően azon fájlok számának mérséklését jelenti, melyeket a szervernek el kell küldenie a böngésző számára. Ezáltal kisebb lesz az adatáramlás és a terhelés a szerveren, valamint könnyebbé válik a böngészőnek megjelenítenie a weboldalt.
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:
Mert a lényeg mégis csak az, hogy az emberek ottmaradjanak a weboldaladon. És mivel érheted ezt el?
Frissítve, 2022.11.03.:
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:
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.
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:
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.
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.
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
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.
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.
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.
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.
A Webshark.hu a hozzászólásoknál előzetes moderálást alkalmaz. Moderálási szabályaink itt olvashatók.