Weboldal gyorsítás: 7 tipp a weboldal betöltési sebesség növelésére

A weboldal gyorsítás 7 lépése. Mégis milyen tényezőkön múlik a weboldal betöltési sebesség?
Rontja a lassú weboldal a felhasználói élményt és a Google helyezéseket?

Egy honlap betöltési sebessége meglehetősen sok dologtól függ. A rosszul optimalizált, lassú weblap hátránnyal indulhat a versenypiacon.
Miért?

A versenytárs elemzésnél nemcsak szolgáltatásokat és árakat néztem, hanem a weboldalkészítők saját honlapjának a technikai és SEO beállításait is megnéztem.
Kíváncsi voltam arra, hogy akik ilyen szolgáltatást nyújtanak, mennyire igényesek a saját oldalukkal kapcsolatban.
Vegyesek a tapasztalataim, egy kirívó példát mutatok majd, de most folytassuk az első bekezdésben feltett “Miért?” kérdéssel.

A Google már 2010-ben bejelentette, hogy a weboldal betöltési sebességet beemeli a rangsorolási tényezői közé. Miközben ezt a blogot írtam, forrásokat kerestem hozzá, mert nem szerettem volna kizárólag a Google bejelentésére hagyatkozni.
Eközben olvastam egy rendkívül érdekes felmérést. Ebben csaknem 12 millió Google keresést elemeztek különböző szempontok alapján, és egy elég megdöbbentő állítás is szerepel benne:
“We found no correlation between page loading speed and first page Google rankings”
Azaz nem találtak egyértelmű kapcsolatot a weboldal betöltési sebessége és aközött, hogy a weboldal szerepel-e a Google találati listájának első oldalán.

Az dologhoz hozzátartozik, hogy a Google bevallása szerint csak az extrém lassú weboldalak számíthatnak visszaesésre a helyezésben és ebben a felmérésben az átlagos weboldal betöltési sebesség 1,65 mp. volt, ami meglehetősen gyorsnak mondható.
Mivel nekem nincsenek erőforrásaim, hogy hasonló felmérést készítsek, fogadjuk el, hogy ennek a tanulmánynak a készítői valóban erre a megállapításra jutottak.

Két dolgot biztosan tudok mondani erre.
Az egyik az, hogy a Google nem teszi közzé részletesen a rangsorolási algoritmusait, azaz, hogy milyen módszerek szerint dönti el, hogy milyen helyezést ér el a weboldalad a találati listán.
Útmutatásokat igen, de pontos leírást, azt például, hogy az adott rangsorolási faktorokat pontosan hogyan súlyozza, nem. Ezen kívül az algoritmusok is folyamatosan változnak, tehát nem lehetsz biztos benne, hogy nem azért nem kerülsz előrébb a keresőkben, mert egy leszedált csiga sebességével töltődik az oldalad.

A másik oldalát a történetnek úgy hívják, hogy felhasználói élmény. Ez a keresőmotoroktól függetlenül is hatással lesz a weboldalad teljesítményére.

Mielőtt rátérnénk arra, hogy milyen technikai részletek és hogyan befolyásolják a honlapod sebességét, és ezekkel mit lehet kezdeni, felteszek egy kérdést:
Te mennyit vársz egy weboldal betöltődésére, mielőtt elnavigálsz onnét, mert nincs türelmed kivárni?
Erre a kérdésre természetesen csak te tudhatod a választ, de a statisztikák viszont beszédesek: 

Forrás: Pingdom

Eszerint, ha 5 másodpercre emelkedik a weboldal betöltési idő, 38% lesz a visszafordulási arány. Nyomják a “Vissza” gombot, mintha nem lenne holnap.

Ebből a 38-53%-ból lehet, hogy 1-2% pedig potenciális ügyfél lett volna. Már itt veszteséged keletkezhetett.

A Google azt mondja, hogy nem tekinti tényezőnek például a visszafordulási-arányt, vagy az oldalon eltöltött időt. Az előző bekezdésben leírtak alapján ez lehet, hogy így van, lehet, hogy nem, de ha másért nem is, ez az a terület, ami miatt mindenképp foglalkozni kell a honlapod gyorsításával.

Weboldal gyorsítás: mire figyelj?

Tárhely választás

Az első lépés mindig ez. És a legelső szempont soha ne a tárhely ára legyen. Meg az utolsó sem, mert egy lassú, leterhelt tárhely agyon fogja verni az egész projektedet, onnantól bűvészkedhetsz akármit az oldaladon, használhatsz feketemágiát is, jó eredményt nem fogsz elérni.
Nem arról van szó, hogy minden weboldal alá dedikált szervert kell üzembe helyezni, vagy csak a legdrágább csomagok a megfelelőek. Nagyon széles a paletta, és itt is sok szempontot kell figyelembe venni.
Körültekintően járj el, mert ha nem megfelelő szolgáltatót választasz, és az oldaladat költöztetni kell emiatt, az költségekkel fog járni. Ezen kívül az addigi rossz teljesítmény miatt keletkezett bevétel-kieséssel is számolj.
Ha bizonytalan vagy ebben a témakörben, mindenképp kérj tanácsot.

A honlap felépítése

A kis- és középvállalkozások weboldalai jellemzően nem egyedi fejlesztéssel készülnek, hanem valamilyen tartalomkezelő rendszerrel, mint például a Joomla vagy a Wordpress, stb. Ha ilyen megoldásban gondolkodsz te is, nagyon fontos, hogy megfelelő sablont válassz.
Itt pont nem arra gondolok, hogy csicsásabb legyen, mint a riói karnevál és bele legyen integrálva minden marha fontosnak gondolt, ám halál-felesleges funkció, a névnapok megjelenítésétől kezdve az időjárás előrejelzésen keresztül az aktuális holdfázis magyarázatiáig.
A weboldalad költségeit ne a sablonon akard faragni, sokkal jobban jársz, ha pár 10 euróért vásárolsz olyat, ami megbízható forrásból származik, javítják és fejlesztik.

A számodra felesleges funkciókkal telepakolt, ne adj’ Isten rossz minőségű, esetleg ingyenes sablonnál sanszos, hogy a kódolása sem lesz optimalizált, cserébe baromi lassú, ezen felül egy halom biztonsági kockázatot is a nyakadba veszel, magyarul duplán jársz rosszul.
A tartalomkezelők egy keret-rendszert adnak neked, alapból is sok feladat elvégezhető velük, de szükség lesz kiegészítő modulokra is. A kiegészítők kiválasztására ugyanaz igaz, mint amit feljebb írtam, csak megbízható kiegészítőket használj.
Ezen felül kerüld ezek halmozását, gondold át, hogy mi az, amire valóban szükséged van, mert nem lehet, hanem tuti, hogy növelni fogják a weboldal betöltési idejét.

Összefoglalva, a kevesebbel itt is jobban jársz. Nem arról akarlak meggyőzni, hogy mindent dobj ki, és legyen egy fehér honlapod egy űrlappal, hogy “Most vedd meg!”, hanem arról, hogy józan ésszel mérlegelj.
És minőségi, megbízható alapanyagból dolgozz!

Amennyiben pedig valóban egyedi kódolású weboldalt készíttetsz, ott abszolút elvárás, hogy a honlap kódolása optimalizált legyen.
A weboldalak kódja alapvetően 3 összetevőből áll, a HTML, a CSS és a szkriptek, ezekre később visszatérünk. 

A gyorsítótár, avagy a "cache"

A lényegre szorítkozva írom ezt a részt, mert ez egy sokszereplős játék, benne van a tartalomkezelő (CMS) rendszer, az azt kiszolgáló szerver, valamint a látogató böngészője is, és a téma sokkal összetettebb, mint egy bekezdés.

De a rövid történet a következő:
A CMS-ek működési elve - elnagyolva - az, hogy amikor látogató érkezik az oldalra, ezek a rendszerek dinamikusan építik fel a weboldalt, minden egyes alkalommal.
Ez erőforrás és időigényes művelet.
Itt jön a képbe a cache, avagy a gyorsítótár. Ez azt jelenti - megint csak elnagyolva -, hogy statikusan tároljuk az oldal tartalmát, és a CMS-nek nem kell minden egyes alkalommal dinamikusan felépíteni, hanem a tárolt, statikus “másolatot” jeleníti meg a böngészőkben. Léteznek olyan rendszerek, amelyek alapfunkciói között ott van a gyorsítótárazás lehetősége, illetve olyanok is, amelyekhez külön kiegészítő kell, hogy erre képesek legyenek.

Akárhogy is van, ezt a funkciót erősen ajánlott használni, jelentős szerepet játszik a weboldal gyorsításban, hiszen így nem kell minden oldal-lekérésnél dinamikusan előállítani a tartalmat.
Itt vissza kell kanyarodnom a tárhely kérdésére. Vannak olyan szolgáltatók, akik ezt a gyorsítótárazást a szerver-oldalon lehetővé teszik, és nem a CMS-re bízzák ezt a feladatot. Amennyiben lehetőség van rá, ezt a megoldást válaszd.

A gyorsítótár alkalmazásával tehát növelheted a weboldal betöltési sebességét, általában ezek alapbeállításai nem nehezek. Viszont ahogy említettem, több szereplős történetről beszélünk, emiatt a cache finomhangolása nem mindig egyszerű. 

CDN használata (Content Delivery Network)

A CDN egy olyan, földrajzilag egymástól távol lévő szerverekből álló hálózat, amely fő funkciója szerint replikálja a weboldalon lévő tartalmakat, pl. képeket, videókat.
Ennek eredményeként amikor a látogató a weboldalra érkezik, a földrajzilag hozzá legközelebb eső szerverről töltődik le a látogató böngészőjébe a tartalom, csökkentve ezzel a weboldal betöltési idejét és az azt tároló szerver terhelését.

A CDN-ek további funkciókkal is rendelkezhetnek, túlterheléses támadások elleni védelem, tűzfal funkciók.
Azt tudnod kell, hogy ez a szolgáltatás növeli a weboldalad üzemeltetési költségeit.
Viszont a CDN szükségességét mérlegelni kell. Például egy média-tartalmakkal bőven rendelkező, nagy nemzetközi forgalmat bonyolító honlap esetében indokolt a használata, de amennyiben lokális (akár egy országon belüli) a célközönséged, nem feltétlenül éri meg a plusz költség.

HTTP lekérések száma

A HTTP rövidítés valószínűleg nem ismeretlen számodra, láthattad már ezerszer. Annyit érdemes tudni róla, hogy egy információátviteli protokollról van szó, amely az interneten egy kérés-válasz alapú kommunikációt tesz lehetővé a kliens és a kiszolgáló között. Ezen a protokollon keresztül jelenítette meg a böngésződ ezt az oldalt is, amit most olvasol.

Minden elem, ami megjelenik egy weboldalon, képek, betűtípusok, stíluslapok, szkriptek egy-egy lekérés eredménye. Nem nehéz kitalálni, hogy minél kevesebb ilyen van, annál gyorsabban töltődik be az oldal.
Első körben itt is a józan ész segíthet eldönteni, hogy mi az, amire szükség van, és mi az, ami nyugodtan mehet a kukába. Például nagyon praktikusnak hathat egy működő óra megjelenítése a weboldalon, mai napig látni ilyen csodákat. Amit amúgy is lát a felhasználó az operációs rendszer tálcáján. Ezt javascript-tel megoldani nem ördöngösség, viszont máris generáltál egy plusz lekérést tökfeleslegesen.

Hogyan gyorsíthatod a weboldaladat a lekérések számának optimalizálásával?

• A fent említett józan ész
• Vizsgáld át a sablonodat és a kiegészítőket, hogy csak az elengedhetetlen funkciók legyenek használatban egy oldalon
• Dobd ki a felesleges képeket
• Használd az úgynevezett “lazy loading”-ot a képeknél, ami arra való, hogy a képek csak akkor kerüljenek betöltésre, amikor szükség van rájuk
• Ha teheted, csökkentsd a stíluslapok számát azzal, hogy kombinálod őket
• Hajítsd ki a felesleges szkripteket az oldaladról
• Csak a szükséges mennyiségű betűtípust használd (amúgy is borzasztóan néz ki egy weboldal 8-10 különböző betűtípussal)
• Óvatosan bánj a külső forrásokkal, értem ezalatt például a beágyazott videókat, vagy a közösségi médiás elemeket

Ezzel már rengeteget tettél ezért, hogy növeld a weboldal betöltési sebességét a HTTP lekérések számának redukálásával.

És ha már szkriptek és stíluslapok

Mindkettő fontos része egy weboldal működésének, ez nem kérdés, a “hogyan”-on van a lényeg.
A weboldal gyorsítás nagyban múlik azon, hogy ezeket megfelelően használjuk. Sokat ezek közül készen kapsz egy CMS-sel, némi szakértelemmel ezeket is lehet módosítani, eltávolítani belőlük a felesleges elemeket. De erre nem mindig van lehetőség, nézzük mi az, amit mégis megtehetsz, hogy gyors weboldalt mondhass magadénak.

Első körben a stíluslapok (CSS).

Feljebb említettem, hogy érdemes kombinálni ezeket, amivel csökken a HTTP lekérések mennyisége.
Ezen kívül rendkívül fontos a méretük, nyilván nem mindegy, hogy egy oldal megjelenítéséhez mekkora adatmennyiséget kell továbbítani az interneten.

Ahhoz, hogy egy stíluslapot emberi módon értelmezni tudjunk, célszerű tagolásokat, behúzásokat és kommenteket használni. Ezekkel viszont jócskán növeljük a méretét, amiktől már érdemes megszabadulni a felhasználás során.
Mutatom:

53% a megtakarítás azzal, hogy eltűntettünk belőle minden felesleget. Ennél a pár sornál nem tűnik jelentősnek, de ezt képzeld el egy 20000 karakteres stíluslap esetén.
A minimalizált változat az emberi szemnek már kusza, de a böngészők ettől ugyanúgy tudják értelmezni.
Ellenőrizd a stíluslapjaidat, hogy optimalizálva vannak-e a weboldaladon. Ha nincsenek, az interneten jó néhány online eszközt találsz arra, hogy ezt elvégezd, a CSS minify kulcsszavakra keress rá.

Ide kívánkozik egy kis kitérő. A CMS-ekhez kínált szövegszerkesztők egy része az úgynevezett “amit látsz, azt kapod” (WYSIWYG) szövegszerkesztő. Ezekkel egyből tudod formázni a szöveget, képeket, betűtípust, méretet, színt és háttérszínt állíthatsz, stb.
És egyből úgy látod a szerkesztőben a stílust, ahogy az a böngészőben is megjelenik majd.

Szuper. Elsőre praktikusnak és egyszerűnek tűnhet ez a megoldás, mégsem ajánlom, hogy mindent így formázz. Több okból sem. Ezzel a módszerrel minden egyes általad formázott elemhez hozzárendeli a szerkesztő a stílust, beágyazva a HTML kódba, és ezzel növeli a kód méretét.

A másik, hogy egy idő után, mondjuk a 30. blogbejegyzés tájékán teljesen átláthatatlan lesz, hogy mikor mit csináltál. Egy példa csak, a H2 címsorok beállításait szeretnéd megváltoztatni, akkor 30 blogbejegyzésben egyesével kell ezt megtenned.
Mind a harmincban így néz ki a kód:
<h2 style=”font-family: Arial; font-size: 26px; line-height: 1.8; color: black;”>Címsor szövege</h2>
Ehelyett használj CSS-t, abban egyszer írod le a stílust, és ha változtatni kell valamin, azt egy helyen meg tudod tenni, és a HTML kód méretével is spórolsz.

A szkriptek

A CSS-nél említett minimalizálás itt is igaz. Amennyiben érzel erőt hozzá, nézd át a szkripteket és optimalizáld őket, ha nincsenek.

Amit ezen felül meg tudsz tenni, az az, hogy a szkripteket lehetőség szerint az oldal kódjának az alján helyezd el, hogy ne blokkolják a futásukkal az oldal betöltését.
Léteznek ezen felül még technikák a szkriptek futásának optimalizálására, az aszinkron és a késleltetett futtatás, de ezek alkalmazása már némi körültekintést és hozzáértést igényelnek.

A honlap képeinek optimalizálása

Csodás témakör. Azért csodás, mert csodálatosan sokan megfeledkeznek erről, ha weboldal gyorsításról van szó.
Szeretnék az elején valamit mutatni anonim módon. Nem célom senkit kritizálni, megszólni, eddig sem tettem, ezután sem fogom, de ez annyira kirívó példa volt, hogy eltettem.

A HTML lekérésekről most nem szólnék, pedig az is elég beszédes, bőven megérne egy misét, hogy miért is fut 26 javascript, de maradjunk a képeknél.
Jól látszik, hogy összesen 23 darab képet tölt be az oldal, összesen 15,5 megabyte méretben. 647 kilobyte átlagban, de a legnagyobb több volt mint 2 megabyte. Sem a képek méretei, sem a képek formátuma nem volt optimalizálva.

Ennek megfelelően 37-38 (!) másodperc a weboldal betöltési ideje, és mobil nézetben ezek az értékek ugyanazok, csak a betöltés ideje nőtt meg még jobban.
A legmegdöbbentőbb a történetben, hogy ez egy weboldal-készítéssel foglalkozó cég oldala.

Mit tegyél, hogy te ne járj így?

• Használj megfelelő képformátumot.
  Az általánosságban használt, veszteséges tömörítést alkalmazó képformátum a JPEG. Minél nagyobb a tömörítés mértéke, a kép mérete annál kisebb lesz, viszont ezzel arányban a minősége is romlik.
  A PNG formátum veszteségmentes tömörítést alkalmaz, a képek minősége nem romlik annyira, mint a JPEG esetében, viszont ennek megfelelően a kép fizikai mérete nem csökkenthető olyan mértékben.
  A WEBP egy viszonylag új, a Google által fejlesztett képformátum, használhat veszteséges és veszteségmentes tömörítést is. A leírások szerint 25-35%-kal kisebb fizikai méretet érhetünk el vele a JPEG-gel összehasonlítva minőségromlás nélkül.
  A böngészők újabb verziói támogatják a webp formátumot. Ha teheted, használd ezt.
• Figyelj oda a képek szélességére és magasságára, optimalizáld.
  Ha az oldaladon egy képet 400x300 pixel méretben jelenítesz meg, teljesen felesleges pazarlás forrás-képként egy 1920x1080 pixel méretű képet megadni.
• Ha lehetőséged engedi, használd a CSS ‘srcset’ attribútumát. Ezzel a kijelző méretétől függően tudsz más-más méretű képeket betölteni, például asztali monitoron egy 1920x1080, egy mobil eszközön pedig 480x270 pixel méretű képet.
• A képek szélességét és magasságát add meg mindig:
  <img src="/akarmi.webp" width="480" height="270"> Ezzel elkerülheted a layout shift-nek, csúszkálásnak nevezett jelenséget, a böngésző még a kép megjelenítése előtt lefoglalja a területet a kép számára.

Eszközök a weboldal teljesítményének ellenőrzésére

Elöljáróban annyit szeretnék leszögezni, hogy a 100%-os teljesítményt nehéz elérni, de természetesen törekedni kell a minél jobb eredményre.

A Google ajánlásai szerint ideális lenne a weboldal betöltési idejét 3 másodperc alá szorítani. Ha ezekben az ellenőrző eszközökben 80-85% körüli eredményt ér el az oldalad, akkor már egészen rendben van. Az ellenőrzéseket mobil és asztali nézetben is végezd el.
A tesztek nemcsak a teljesítményt vizsgálják, hanem ajánlásokat is tesznek, mik azok a tényezők, amiken a weboldal gyorsítás múlik vagy elvérzik, segítik optimalizálni a weboldal sebességét és felhasználói élményt.

Mint minden másnál, itt is megoszlanak a vélemények, melyik használhatóbb, melyik felhasználó-barátabb, én nem törnék pálcát egyik felett sem, mind a három használatát javaslom.

Javarészt azokban a témakörökben fogsz tanácsokat kapni, amiket feljebb kitárgyaltunk, ilyenek lehetnek:

• A tartalmak méretének csökkentése: képek optimalizálása, a szkriptek és a CSS fájlok méretének csökkentése.
• Tömörítés: használjunk gzip tömörítést a weboldal tartalmának átviteléhez.
• Cache meglétének és beállításainak ellenőrzése.
• JavaScript és CSS optimalizálás: távolítsuk el a nem használt kódokat, kódrészleteket.
• Blokkoló erőforrások felfedése: kiszűrik a weboldalon található olyan elemeket, amelyek blokkolják a fő tartalom betöltését.
• Egyéb javaslatok: a HTTP kérések csökkentésére, az átirányítások számának csökkentése, a használt betűtípusok számának csökkentése.

PageSpeed Insights: A Google developers eszköze, ingyenes

GTMetrix: Naponta néhány lekérdezés ingyenes. Talán egy kicsit “bőbeszédűbb”, mint a PageSpeed Insight, pl. grafikonon mutatja a HTTP lekéréseket, és a lekért elemek betöltési idejét

WebPageTest: Szintén ingyenes néhány lekérdezés erejéig. Finomhangolhatóak a tesztek, több beállítási lehetőséggel rendelkezik, mint a GTMetrix. Szerintem ez adja a legátfogóbb eredményeket.