Mitől lesz gyors a honlapom? – avagy a sebesség optimalizálás művészete

A gyors weboldal jobb, mint a lassú. Egyrészt azért, mert a betöltődési idő rangsorolási faktor a Google-nél – azaz minél gyorsabb a weboldalad, annál jobb helyezésekre számíthat a keresőben.

Másrészt azért, mert egy gyors weboldal jobb felhasználói élményt nyújt: szívesebben várakozunk valaminek a betöltődésére csupán fél másodpercet, mint mondjuk 10-et. Főleg, ha ennek a várakozásnak minden oldalletöltésnél meg kell történnie…

---

Mekkora a weboldalam sebessége?

Amikor egy sebesség-optimalizálási projektet elkezdek, általában a legelső lépés, hogy megállapítsam: mekkora az adott weboldal jelenlegi sebessége. Volt ugyanis már arra is példa, hogy az ügyfél kért egy sebesség-auditot, ahol végül meg kellett állapítanom: tulajdonképpen nagyobb bajok nincsenek az oldalával. Így végül más fejlesztésekre költötte a pénzét.

A jelenlegi sebesség megállapításához 4 eszközt tudok javasolni:

• GTMetrix
• Pingdom Tools
• Google PageSpeed Insights
• A böngészőnk fejlesztői eszközei

Mindegyik arra való, hogy elemzéseket készítsen az oldalunk betöltődéséről: mely elemeknek mennyi időbe telik letöltődni, hol vannak a javítandó területek, stb.

Nézzünk gyorsan egy példát, mondjuk Szolnok város hivatalos oldalát (szolnok.hu) – mit mond róla a GTMetrix:

A fenti, 5.8 másodperces betöltődés kissé megtévesztő lehet, mivel a GTMetrix legközelebbi tesztszervere Londonban van (azaz ennyi idő alatt Londonban töltődik be az oldal), amely számunkra nem eléggé releváns. Viszont egy gyors oldal még onnan is betöltődne 1-2 másodperc alatt.

A valóságban itthonról ennél valamivel gyorsabban törtődik be az oldal, mivel az magyarországi szerveren fut. Ezért a legrelevánsabb adatot akkor kapod, ha a böngésződben az Elem Vizsgálata (Inspect Element) » Hálózat (Network) fülére navigálsz és frissítesz egyet az oldalon.

A szolnok.hu oldal esetében viszont ekkor is nagyon lassú, kb. 3.5-4 másodperces betöltődési sebességet állapíthatunk meg.

Ha megállapítottuk, hogy a weboldalunk lassú, akkor a következő lépés a felgyorsításának irányába a diagnózis felállítása: nézzük meg, miért ilyen lassú. Ebből fogjuk tudni ugyanis, hogy miken érdemes elsősorban változtatni.

1. Túl nagy a weboldal mérete

Továbbra is a fenti példánál maradva, a szolnok.hu weboldalnál az első és legszembetűnőbb dolog számomra az oldal kb. 6 MB-os mérete. Ekkora adatmennyiséget időbe telik letölteni, és ez nagyban hozzájárul az oldal betöltési idejéhez.

Ideális esetben egy weboldal ne legyen nagyobb, mint 1-2 MB. Azzal ugyanis már simán elérhető egy 1 másodperc alatti betöltési idő. Egy 6 MB-os monstrummal már kevésbé.

Érdemes tehát megvizsgálnunk, mely elemek foglalnak sok helyet az oldalunkon. Ezek leggyakrabban a képi és videós tartalmak szoktak lenni.

2. Túl sok lekérdezés történik

Egy weboldal manapság több fájl felhasználásával jelenik meg. Ezek tipikusan a következők:

• HTML fájl: maga a megjelenített dokumentum, amely a szöveges tartalom nagy részét és az oldal struktúráját tartalmazza.
• CSS fájlok: az oldal vizuális megjelenéséért felelősek.
• JavaScript fájlok: a böngészőben futó programkódok, amelyek segítenek az oldal megjelenését és használatát dinamikusabbá és felhasználóbarátabbá tenni.
• Kép- és videófájlok: mint a nevük is mondja, a képes tartalom megjelenítéséért felelősek.
• Emellett előfordulhat, hogy az oldal felhasznál egyéb tartalmakat, pl adatfájlok (pl. XML, JSON), vagy más oldalakról beolvasott adatok (pl. API-k segítségével).

Ahhoz, hogy megértsük, ez hogyan befolyásolja a weboldal sebességét, előbb meg kell értenünk, milyen folyamatok zajlanak le egy fájl letöltése során. Ehhez válasszunk ki egy tetszőleges fájt a GTMEtrix » Waterfall fülén vagy a Pingdom Tools » File Requests listájáról és álljunk fölé az egérrel.

Azt fogjuk látni, hogy minden egyes fájllekérés a következő lépéseken megy keresztül, mire elkerül hozzánk:

1. DNS: annak beazonosítása a webcím (URL) alapján, hogy az adott fájl mely szerveren helyezkedik el.
2. Connect: kapcsolódás az adott szerverhez.
3. Send: a lekérés elküldése a szervernek, hogy mire van tőle szükségünk.
4. Wait: ennyit kell várni a szerverre, hogy a kért adatot előállítsa a számunkra.
5. Receive: ennyi időbe telik, hogy a kért adat letöltődjön a gépünkre.
6. Blocked: ez idő alatt nem történik semmi – általában azért, mert a böngésző vár más erőforrások letöltésére, mielőtt ezt a letöltést megkezdené.

Ha ránézünk a GTMEtrix-es ábrára fentebb, láthatjuk, hogy a szolnok.hu 125 fájllekérést indít egyetlen weboldal betöltése érdekében. Ez rengeteg.

Még egy 6 MByte-os weboldal is sokkal gyorsabban be tud töltődni, ha csak egyetlen fájlból áll, mintha 125 fájlból állna. Ugyanis 125 fájl esetén minden egyes esetben végig fog menni a böngésző a DNS » Connect » Send » Wait » Receive lépéseken, és sok esetben lesz némi blokkolási idő is. Ha mindez csupán egyetlen nagy fájl lenne, akkor ezeket a lépéseket csak egyszer kellene elvégezni.

Persze egyetlen fájlba tömöríteni egy egész oldalt szinte lehetetlen és legtöbb esetben nem is életszerű. De törekednünk kell arra, hogy minél kevesebb lekérdezéssel meg tudjuk jeleníteni a lapjainkat. Hiszen úgy annyival kevesebbszer kell a böngészőnek végigzongoráznia az összes letöltési lépést.

3. Távoli szerveren van

Lehetőleg a weboldalunkat kiszolgáló szerver legyen abban az országban, mint a célközönségünk. Ha fizikálisan távoli szerveren található, akkor mind a DNS, Connect, Send és Receive értékei meg fognak nőni. Azaz azok a lépések tovább fognak tartani, amelyek során a saját gépünk és a weboldal szervere közötti kommunikáció és adatátvitel történik.

Bár a szolnok.hu magyar szerveren található (nagyon helyesen!), mégis azt láthatjuk, hogy a mindössze 110 kB-os HTML gyökérfájl letöltési (Receive) ideje több, mint 1 másodperc volt. Ez nagyon sok, egy ekkora fájlnak jó esetben 100 milliszekundum alatt bőven ide kellene érnie. Ebben az esetben valószínűsíthető, hogy a szerver oldali kód csinál valamilyen távoli API lekérést, amely lelassítja a betöltődést – vagy pedig van a szerveren valamilyen egyéb blokkoló tényező. Ez egy sebesség-optimalizálási projektnél további vizsgálódást szokott igényelni.

4. Lassú tárhely

Egy tárhely akkor tud lassú lenni, ha maga a szervergép lassú (pl. mert régi a hardver és/vagy nem frissítik rajta a szoftvereket rendszeresen), vagy pedig azért, mert a szolgáltató a profitmaximalizálás érdekében a kelleténél több felhasználót zsúfol rá egy szerverre. Ez utóbbi általában olcsóbb tárhelyeknél szokott előfordulni.

Ahhoz, hogy megállapítsuk lassú-e a tárhelyünk, támpontot adhat a betöltődési grafikon Wait mutatója, ezen belül is magának a HTML oldalnak a wait értéke. Ha a várakozás az adatra sokáig tart, akkor az azt jelenti, hogy a szerver sokáig nyammog rajta. Ilyenkor érdemes tovább vizsgálódnunk:

• Vajon ugyanez az oldal másik szolgáltatóhoz feltelepítve gyorsabb lesz?
• Más oldalak ugyanennél a szolgáltatónál szintén lassúak?
• Mások panaszkodnak-e teljesítménybeli problémákra a szolgáltatónknál?

Ha a fenti kérdések közül legalább kettőre igen a válasz, akkor valószínű, hogy egy költözés egy jobb szolgáltatóhoz sokat tud lendíteni az oldalunk sebességén.

5. Erőforrás-igényes, optimalizálatlan kód

Vannak esetek, amikor az adatra való várakozás nem amiatt tart sokáig, mert a szerverünk lassú, hanem azért, mert a weboldalunk kódja lassú (azaz a hiba a mi készülékünkben van). Ennek oka általában, hogy olyan erőforrás-igényes műveleteket hajt végre, amelyek észrevehetően lelassítják az oldal betöltődését.

Amennyiben meggyőződtünk róla, hogy a tárhelyünk gyors és mégis magas a Wait értéke, akkor gyanús, hogy a kódunkkal van a probléma. Ekkor érdemes egy webfejlesztőnek komolyabban beleásnia magát a kódba.

---

Természetesen léteznek még más egyéb faktorok is, ami miatt lassúvá válhat egy weboldal, de a fentiek a leggyakoribb okok. Most nézzük meg, milyen technikákkal tudjuk ezeket orvosolni…

Most pedig végignézünk néhány olyan technikát, amelyek segítségével egy weboldal betöltődési sebessége jelentősen felgyorsítható.

A) Gondold át, mindenre szükséged van-e az oldalon

A legelső lépés egy optimalizálás előtt álló weboldalnál, hogy átnézzük: nem zsúfoltuk-e túl a tartalmát? Vajon minden elem ami rajta van, szükséges-e, fontos-e a felhasználói élmény szempontjából?

Az alacsony prioritású elemek kidobálása egyes honlapok méretét bizonyos esetekben akár a felére-harmadára is le tudja csökkenteni. Továbbá egyszerre tud segíteni a fentebb (miért lassú a weboldalam?) említett 1. és 2. problémák megoldásában.

Elsősorban a következő elemek tudják jelentősen megnövelni egy weboldal méretét:

• Teljes képernyős slider-ek: már egyetlen jó minőségű, teljes szélességű kép is könnyedén hozzáadhat párszáz kilobyte-ot az oldal méretéhez. Ez jelentősen megnövekszik (akár 2-3 MByte-ra!) akkor, ha 5-6-ot betöltünk belőlük egy slider kedvéért. Bár kétségkívül látványos dolog, gondoljuk végig, szükségünk van-e rá!
• Automatikusan induló videó: ha nem lehetséges az oldalunkat videó nélkül megcsinálni, akkor a gyorsabb betöltődés érdekében intézzük úgy, hogy kezdetben csak a videó borítóképe jelenjen meg és erre kattintva a felhasználó maga indíthassa el azt.
• Kiegészítő / beépülő modulok: ezek általában akkor jelentenek problémát, ha valamilyen CMS-t (pl. WordPress, Joomla, stb.) használunk. Sok bővítmény ugyanis sokkal több funkciót, sokkal több fájlt betölt, mint amire nekünk valóban szükségünk van – ez pedig lelassítja az oldalunkat. Mielőtt feltelepítünk egy plugin-t, vizsgáljuk meg, nem akarunk-e vele ágyúval verébre lőni. Sok esetben ugyanis egy plugin helyettesíthető néhány hozzáadott programsorral.
• Külső szerverekről behívott elemek: ilyen például tipikusan a Facebook Likebox. Régebben divat volt kitenni szinte minden oldalra, ma már, amióta a weboldal sebessége fontos tényező lett, kevés helyen látom. Akár másodpercekkel is le tudja lassítani a betöltődést.
• Túl sok betűtípus: sebesség szempontjából az ideális az, ha az egész oldal egyetlen system font-ot (olyan betűtípus, amely szinte minden számítógépre előre van telepítve) használ – és ennyi. Persze ez nem túl látványos, így hát stílus szempontjából érdemes lehet 1-2 extra betűtípust felhasználni. Arra azonban ügyeljünk, hogy csak olyan variánsokat (pl. normal, bold, italic, light, extended, stb.) töltsünk be, amelyeket ténylegesen használunk. A többi feleslegesen növeli az oldalunk méretét.

B) Optimalizáld a képeidet

Erről a témáról már írtam egy külön cikket is (igaz, annak csak egy része szólt a méretbeli optimalizálásról). A lényeg, hogy ha betartjuk a következő szabályokat, akkor a képeink mérete jelentősen le fog csökkenni, ezáltal az 1. számú probléma (oldal mérete) megoldása felé egy jelentős lépést tehetünk.

• A kép mérete maximum akkora legyen, mint amekkorában látható. Azaz egy 1000×400 pixeles dobozban ne akarjunk egy 8000×5000-es képet megjeleníteni, mert felesleges, fájlméretben pedig akár 20-szoros különbség is lehet!
• Ahol nem fontos a kép élessége, ott rontsd le a minőségét. Ezt elsősorban JPG képeknél lehet eljátszani. Egy háttérképnek általában bőven megteszi egy 80% minőség is, szabad szemmel egy átlagember nem szokta látni a különbséget.
• Eleve a webre optimalizált verziót tölts fel: sok grafikai programnak léteznek ilyen beállításai, sok-sok kilobyte-ot meg lehet velük spórolni.
• Ha több helyen is használod ugyanazt a képet, ahhoz elég egyetlen fájlt feltölteni. Ne töltsd fel ugyanazt többször!

C) Használj cache-t

A cache-t magyarul gyorsítótárra szokás lefordítani. A cache-elés célja az, hogy azokat a honlap-elemeket, amelyeket többször is megnézünk ugyanabban a formában, lehetőleg minél kisebb erőforrás-igénnyel tudjuk elérni.

Működési elv szerint kétfajta gyorsítótárra lesz szükségünk a honlapunk sebesség-optimalizálása során:

• Böngésző oldali cache: ez azt jelenti, hogy a weboldalunk ritkán változó tartozékait (pl. képek, CSS, JS fájlok, betűtípusok, PDF dokumentumok) első megtekintéskor a böngésző lementi a felhasználó gépére és bizonyos ideig (pl. 1 hónap) ott tárolja azokat. Ennek értelme, hogy pl. a honlap CSS fájljait csak egyszer töltsük le a távoli szerverről, utána használjuk fel újra a már letöltött verziót – megspórolva ezzel sok-sok sávszélességet.
• Szerver oldali cache: erre akkor lehet szükség, ha valamilyen CMS-t (tartalomkezelő rendszert) használunk. A tartalomkezelő rendszerek ugyanis általában úgy hozzák létre az oldalainkat, hogy egy szerver oldali script (jellemzően PHP) valós időben lekér adatokat egy adatbázisból, majd egy HTML sablon segítségével ezeket megjeleníti. Ez egy eléggé erőforrás-igényes feladat, így érdemes a ritkán változó oldalak esetén ezekről egy gyorsan elérhető, statikus másolatot készíteni. Így nem kell minden egyes lekérésnél újra lefuttatni az oldalt összeállító kódot, hanem elég annak a statikus lenyomatát elküldenünk a felhasználónak.

TIPP: Ha ez túl szakmainak hangzott, akkor elég annyit megjegyezned, hogy érdemes beállítani mind a szerver, mind a böngészőoldali cache-t.

D) Válassz egy jó tárhely-szolgáltatót

Erről már írtam korábban bővebben, ezért itt csak dióhéjban nézzük át, hogy mikre érdemes odafigyelnünk a tárhely kiválasztásánál, ha jó gyors oldalt szeretnénk:

• Legyen közel a szerver a célközönségedhez. Lehetőleg ugyanabban az országban.
• Legyen gyors a szerver. Modern alkatrészek, SSD tárhely, legújabb PHP, NGINX, stb… Ezek mind olyan tényezők, amelyek segítenek.
• Relatíve kicsi szerverenkénti felhasználószám. Az erőforrásokat minél kevesebb más felhasználóval kell megosztanod, annál kevésbé áll fenn a veszélye, hogy mások oldalai miatt lassuljon le a tiéd.

Ha további részletekre is kíváncsi vagy, ajánlom figyelmedbe a Kinsta átfogó cikkét a témában.

E) Csökkentsd le a letöltendő fájlok számát

E cikk első felében található 2. pontban már elmagyaráztam, miért nem jó, ha sok apró fájlból áll a weboldalunk. Nézzük, ezen a problémán hogyan tudunk enyhíteni:

• Egyesítsük a JS fájljainkat egyetlen nagy fájlba. Erre egyes WordPress pluginek (pl. WP Rocket) automatikusan is képesek. Ha nem használunk CMS-t, akkor pedig egyszerűen fűzzük egybe a fájlokat, lehetőleg abban a sorrendben, ahogyan egyébként is betöltődnének.
• Egyesítsük a CSS fájljainkat is. Így a végén optimális esetben lesz 1-1 JS és CSS fájlunk összesen.
• Sok kis képfájl esetén gondolkozzunk el azon, hogy fűzzük őket egybe egyetlen file-ba és jelenítsük meg mindig azt a részt (ún. sprite-okat), amelyekre szükség van. Alternatív megoldás lehet a kis képfájlokat belehelyezni magába a CSS-be vagy HTML-be base64 kódolással.
• Ha sok kis ikonra van szükségünk, érdemes lehet olyan ikon fontot használnunk képek helyett, amilyen pl. a Font Awesome.
• Amit meg tudunk oldani HTML és CSS segítségével arra ne használjunk képet. Pl. gradienseket, nyilakat, háromszögeket, köröket nagyon szépen lehet ma már tiszta CSS-el is rajzolni. Sőt, egyesek már művészi szintre is emelték a CSS grafikákat 🙂

F) Tömöríts!

Egy weboldal fizikai méretét jelentősen lecsökkenthetjük, ha az adatainkat tömörítjük. A tömörítés egy olyan eljárás, amely során az adatokat lekódoljuk egy kisebb helyet foglaló formátumba (ilyen eljárással készülnek például a népszerű ZIP fájlok is). Ennek hatására jóval kisebb adatcsomagot kell továbbítani a szervertől a felhasználó gépéig, megspórolva ezzel némi letöltési időt.

Nézzük hát a weboldal-optimalizálásban leginkább használatos tömörítési technológiákat:

• GZip: amikor lekérünk egy oldalt a szerverről, akkor azt a szerver küldés előtt betömöríti (bezippeli), majd letöltés után a felhasználó gépe automatikusan kitömöríti. Így a két végponton ugyanazt a fájlt látjuk, de a hálózaton keresztül tömörítve utazik, spórolva az igénybevett sávszélességen.
• Minifikálás: abból indul ki, hogy a szöveges HTML, CSS és JS fájljaink sok olyan karaktert tartalmaznak, amelyeknek a végrehajtás szempontjából nincs jelentőségük. Ilyenek például a szóközök, az új sor és a tabulátor karakterek, valamint a kódközi kommentek. Ha ezeket elhagyjuk, az eredetinél jóval kisebb fájlokat kapunk, amelyek a böngésző számára ugyanazzal a tartalommal rendelkeznek.
  • JavaScript fájloknál ennél még tovább is megy a minifikáció: ott a változó és függvényneveket – ahol csak lehet – lerövidíti 1-2 betűs elnevezésekre. Így gyakran találkozhatunk olyannal, hogy egy “myLittleVariable = 1;” kifejezésből a minifikált verzióban ennyi marad: “a=1;“. Ez a számítógépünk számára ugyanazt jelenti, de lényegesen kevesebb helyet foglal.
  • Azt érdemes figyelembe venni, hogy a minifikált verziók emberi szem számára nehezen olvashatók, így érdemes ezeket csak a végső felhasználóknak szánt (production) környezetben használnunk. Ha változtatni akarunk a kódon, azt végezzük az eredeti fájlokon, és használjunk olyan röp-tömörítő programot a minifikáláshoz, amilyen pl. a Prepros (de WordPress alatt a WP Rocket is automatikusan meg tudja ezt oldani).

G) Lazy loading

Mivel a weboldalak méretének jelentős részét (egyes mérések szerint átlagosan 2/3 át) a képeink teszik ki, ezért ez az a terület, ahol a legtöbbet nyerhetünk. Egy része a megoldásnak az volt, hogy optimalizáltuk a képeink méretét.

Viszont mi van akkor, ha mondjuk van 10 fotónk egy oldalon, de az átlag felhasználó csak kb. a harmadik képig szokott legörgetni?

Ekkor kár lenne előre letölteni az összes képet. Hiszen ha mondjuk mindegyikük 200 kByte méretű, akkor ez összesen 2 MByte-nyi letöltést tesz szükségessé. Ha viszont csak azokat a fotókat tölti le böngészőnk, amelyek a felhasználó látómezőjébe kerülnek, akkor megússzuk átlagosan 600 kByte letöltéssel.

Erre ad megoldást a Lazy Loading módszer, amely figyeli, hogy épp hol jár a user az oldalon belüli görgetéssel és akkor tölti le a következő képet, ha már elért odáig.

H) Adatbázis optimalizálás

Általában régebbi, gyakran frisülő és esetlegesen sok felhasználós weboldalak betegsége szokott lenni, hogy az adatbázis-lekérdezések elkezdenek túl sokáig tartani.

Dobd ki a felesleges adatokat!

Ennek egyik oka, hogy túl sok a szemét az adatbázisban. Könnyen meglehet, hogy több ezer inaktív felhasználó adata ott csücsül az adatbázisunkban, olyan tartalmakkal karöltve, amelyeket soha senki nem fog már elolvasni. Ezek általában feleslegesen lassítják az adatbázis-lekérdezéseinket, így érdemes 1-2 évente némi tisztogatást végeznünk.

CMS-ek használatánál további bonyodalmakat tud okozni, ha a bővítmények uninstallere nincs megfelelően megírva és felesleges adatokat hagy az adatbázisodban, miután eltávolítottad. Pl. felraksz egy WordPress plugin-t, csak hogy kipróbáld. Nem tetszik, eltávolítod. Igen ám, de közben a bővítmény elhelyezett jó néhány bejegyzést az adatbázisodban, amit eltávolításkor „elfelejtett” letörölni. Ez sajnos egy sokkal általánosabb probléma, mint gondolnád!

Indexelj!

Az adatbázis lekérdezéseink sebességén tovább tud javítani a megfelelő indexelés. Ezt legkönnyebben úgy lehet elképzelni, mint a nagy, vastag könyvek végén a szó- és névjegyzéket. Ha ezek nincsenek ott, akkor egy fogalom megtalálásához lehet, hogy át kell böngészned az egész könyvet. Ha ott vannak akkor például találsz egy ilyet a jegyzékben, hogy: „Reneszánsz, 93., 102-104. o.”, és tudni fogod, hogy mely oldalakon olvashatsz utána.

Az adatbázis indexek is hasonlóan működnek. Ilyenkor egy segédtáblában (amit indexnek hívunk) előre összegyűjtjük a leggyakrabban keresett adatatokat, illetve hogy ezek merrefelé találhatók az adatbázisban. Így bizonyos kereséseket rendkívül felgyorsíthatunk a segítségükkel.

Összefoglalva

Manapság már több okból is rendkívül fontos lett, hogy a weboldalunk minél gyorsabb legyen. Bár ez egy induló weboldalnál általában nem jelent nagy problémát, ahogy növekszik az oldalunk tartalma és felhasználóinak száma, azt tapasztalhatjuk, hogy a korábban fürge honlapunk egyre csak lassabb lett.

Ekkor kell elővenni a sebesség-optimalizálás eszköztárát. Egyes esetekben e módszerekkel akár töredékére is csökkenthető a weboldal betöltődési ideje. Gyakorlatilag e cikkben említett 3 pontot kell végigjárnunk:

1. Megnéznünk, mekkora a honlapunk tényleges sebessége. Ha nincsenek vele különösebb gondok, akkor nincs több teendőnk – dőljünk hátra!
2. Ha az oldal lassú, akkor mélyebbre kell ásnunk az elemzési adatokban – hogy megállapítsuk, mi okozza a lassúságát.
3. Ha ez megvan, alkalmazzuk a megfelelő optimalizálási technikákat.

Érdemes lementenünk a sebességtesztek eredményeit az optimalizálás előtt és után is, hogy megbizonyosodjunk róla: amit tettünk, valóban gyorsított a honlapunkon.

Kérdésed, észrevételed van? Várom a kommentedet!