A villámgyors oldalbetöltés 5 aranyszabálya

A betöltési idő a modern webfejlesztés egyik legfontosabb, mégis egyik legelhanyagoltabb témája. Nemcsak felhasználói élmény, hanem SEO szempontjából is jelentős fontossággal bír.

 

Nem kell mindent betölteni

Elsősorban csakis azokat az állományokat töltsük be, amelyek létfontosságúak az oldal megjelenítéséhez (pl. CSS fájlok). A JavaScript betöltését próbáljuk meg minél későbbre halasztani, async és defer használatával. A lényeg az, hogy a felhasználó minél hamarabb eljusson a "látható" részig.

Ebben segíthet rengeteget a lazy loading, amivel csak akkor fognak betöltődni az adott állományok, ha odagörgetünk.

 

Tömörítés, tömörítés és még több tömörítés

CSS/JS
Ha megoldható, használjunk "minified" CSS és JS állományokat. Ezek rövidebb elnevezéseket használnak, illetve nem tartalmaznak whitespacet vagy kommenteket, ezáltal kisebb fájlmérettel rendelkeznek.

Képek
A képekről készítsünk kisebb felbontású változatokat arra az esetre, ha kicsi méretben kell megjeleníteni őket (pl. a 300x300 méretű bélyegkép helyére ne a 4000x4000 méretű képet töltsük be). Feltöltés előtt használjunk valamilyen veszteségmentes (vagy enyhén veszteséges) tömörítést, ezzel is csökkentve a fájlméretet. Ha már itt tartunk, érdemes megemlíteni a WebP képformátumot, ami akár 25-34% fájlméret csökkenést is eredményezhet a többi formátummal szemben.

Gzip
Ha hozzáférünk a webszerverhez, állítsunk be Gzip tömörítést a kérelmek kiszolgálására.

 

Gyorsítótár, ahol csak lehet

Frontend
A statikus, "nem változó" állományokra (pl. Bootstrap, jQuery) mindenképpen állítsunk be gyorsítótárat.

Viszont vannak CSS/JS fájlok, amik változhatnak az idők során (pl. gyorsan beleírunk valamit a CSS-be). Ha ezeket is gyorsítótárazzuk, akkor fennáll az esélye, hogy egy-egy újabb változtatás nem fog megjelenni az oldalon bizonyos felhasználóknak. Ilyenkor az egyik legegyszerűbb megoldás az, ha verziószámokat használunk (pl. /css/main.css?version=1.3). Ha valami automatizált megoldást szeretnénk, használhatjuk akár az adott fájl legutóbbi módosítási dátumának timestamp-jét is (pl. /css/main.css?last_mod=1607524875).

Backend
Vannak adatok, amiknél nincs szükség arra, hogy minden egyes oldalbetöltésnél újra és újra ki legyenek számolva (pl. követők száma). Ezeket az adatokat érdemes bizonyos időre elrakni egy szerveroldali gyorsítótárba. A legtöbb szerveroldali keretrendszer már rendelkezik beépített cache megoldással, ezeket mindenképpen használjuk ki. Laravel esetén például választhatunk fájl vagy memória alapú gyorsítótárak közül is.

Ha nagyobb erőforrással rendelkezünk, erősen ajánlott a Redis használata, ami egy kulcs-érték alapú "in-memory" adatbázis (vagyis a memóriában tárolja az adatokat).

 

SQL lekérdezések optimalizálása

A betöltési idő nem csak a frontend felelőssége. Sokszor előfordul, hogy egy (vagy több) optimalizálatlan SQL lekérdezés miatt vár az oldal, eközben a felhasználó csak a töltőkarikát és az üres képernyőt látja. Ha van rá lehetőség, nézzünk bele a naplófájlokba, és vizsgáljuk meg, hogy a lassabb oldalbetöltődések mögött milyen SQL lekérdezések állnak.

Néhány gyakori hiba:

• Nem SQL-ből végezzük a szűréseket
  A legrosszabb eset az, amikor a lekérdezés csupán annyiból áll, hogy SELECT * FROM table, majd PHP-ban akarjuk elvégezni a szűréseket. Laravel esetén is ajánlott kerülni a Model::all() használatát, kivéve ha tényleg szükséges. Minden szűrést (lehetőség szerint) SQL-ből végezzünk el.

• Többet kérünk az adatbázistól, mint amire szükségünk van
  Ha például csak az első 3 találatra vagyunk kíváncsiak, akkor ne felejtsük ki a LIMIT 3-t a lekérdezésből. Illetve, ha csak egy adott oszlopra van szükség, ne használjunk SELECT *-t.

• Laravel: Nem töltjük be előre a relációkat
  Laravel esetén gyakori hiba az, ha nem használunk with()-et a relációk előzetes betöltésére, és emiatt a háttérben újra és újra lefut ugyanaz a lekérdezés, amikor meg akarjuk jeleníteni ezeket az elemeket. Az ehhez hasonló hibákat könnyen kiszűrhetjük a Laravel Telescope segítségével.

Illetve az is javíthat a felhasználói élményen, ha először csak egy üres templatet töltünk be (esetleg egy töltőkarikával vagy placeholderrel kitöltve), és csak utána kérjük le az adatokat (AJAX használatával). Tulajdonképpen ugyanannyit kell várni, viszont így a felhasználó sokkal hamarabb eljuthat a "látható" részig.

 

CDN használata

A CDN (azaz "tartalomkiszolgáló hálózat") feladata az, hogy a felhasználó a hozzá legközelebb lévő szerverről kapja meg a kért tartalmat, ezzel is csökkentve a várakozási időt. A legtöbb CSS/JS könyvtár rendelkezik saját CDN-el, viszont mi is használhatunk saját CDN-t a saját tartalmainkra.

 

Ha segítségre lenne szükséged az oldalad sebességének optimalizálásával kapcsolatban, keress minket bizalommal a contact@webcapital.hu címen, vagy a Facebookon.