Sokszor úgy beszélünk a weboldal sebességéről, mintha lenne egyetlen kapcsoló, amit csak át kell állítani.

• „Optimalizáljuk a képeket.”
• „Bekapcsoljuk a cache-t.”
• „Felrakunk egy gyorsabb szerverre.”
• „Használunk egy CDN-t.”

És kész. De valóság ennél sokkal érdekesebb.

Eldől a technológiai döntéseknél, a tárhely kiválasztásánál, a design megtervezésénél, a képek és animációk használatánál, az alkalmazott külső szolgáltatásoknál és még abban is, hogy egyáltalán mit akarunk betölteni az első másodpercben.

A gyors weboldal tehát nem feltétlenül attól gyors, hogy utólag „fel lett turbózva”.

Attól gyors, hogy eleve úgy építettük fel.

A sebesség nem csak technikai kérdés

Amikor egy látogató megnyit egy weboldalt, rengeteg dolog történik a háttérben.

A böngésző kapcsolatot létesít a szerverrel, lekéri az oldalhoz szükséges fájlokat, feldolgozza a HTML-t, letölti a CSS-t és JavaScriptet, betölti a képeket, felépíti az oldalt, majd végül megjeleníti azt a felhasználónak.

És mindezek közül nem mindegyikre van szükség azonnal.

Egy rosszul felépített oldal például több száz kilobájtnyi vagy akár több megabájtnyi JavaScriptet tölthet le még azelőtt, hogy a felhasználó egyáltalán látná az oldal lényegét.

Egy rosszul optimalizált hero kép lehet több megabájtos.

Egyetlen marketingoldalra kerülhet tíz különböző külső script.

Egy animációs könyvtár akkor is betöltődhet, ha az oldalon végül csak egyetlen egyszerű animációt használunk.

És lehet bármilyen jó a szerverünk, ha közben feleslegesen sok mindent kérünk tőle és a böngészőtől.

Ezért a weboldal sebessége valójában egy rendszer eredménye.

1. A leggyorsabb kód az, amit nem kell lefuttatni

Ez az egyik legegyszerűbb, mégis legfontosabb alapelv. Ha egy funkcióra nincs szükség, ne töltsük be. Ha egy JavaScript-könyvtár egyetlen apró feladat miatt kerül az oldalra, érdemes megvizsgálni, hogy valóban szükség van-e rá. Ha egy elem csak az oldal legalján jelenik meg, nem biztos, hogy azonnal kell betölteni. Ha egy kép csak görgetés után válik láthatóvá, nem feltétlenül kell az első pillanatban letölteni.

A teljesítményoptimalizálás egyik legjobb formája sokszor nem az, hogy gyorsabbá tesszük a meglévő rendszert, hanem az, hogy egyszerűen kevesebbet kérünk tőle. Ez különösen fontos modern weboldalaknál, ahol könnyű túlzásba esni.

Egy slider, egy animáció, egy chat widget, egy analitikai rendszer, egy cookie-kezelő, egy marketingpixel, egy hőtérkép, egy A/B tesztelő rendszer és még néhány külső szolgáltatás már önmagában komoly terhelést jelenthet.

Egyenként egyik sem tűnik problémásnak. Együtt viszont már igen...

2. A technológia is döntés

Nem minden weboldalnak ugyanarra a technológiára van szüksége.

Egy egyszerű bemutatkozó oldalnak egészen más igényei vannak, mint egy több ezer termékes webshopnak vagy egy olyan vállalati rendszernek, amely több külső szolgáltatással kommunikál.

Ezért nem érdemes abból kiindulni, hogy:

„Ezt használjuk minden projektnél, mert ezt ismerjük.”

Sokkal jobb kérdés:

„Ehhez a projekthez mi a megfelelő technológia?”

Lehet, hogy egy adott esetben egy statikus megoldás lesz a legjobb.

Máskor egy modern frontend és egy külön backend. Egy összetett rendszerhez pedig teljesen más architektúrára lehet szükség. A technológiai választás hatással van a teljesítményre, a fejleszthetőségre, a biztonságra, az üzemeltetésre és arra is, hogy később mennyire könnyű továbbépíteni a rendszert.

A gyorsaság tehát részben már az architektúra szintjén eldől.

3. A szerver számít — de nem mindenható

Egy jó infrastruktúra rengeteget segít. A megfelelő szerver, régió, hálózati kapcsolat, cache-elés és CDN jelentősen javíthatja a válaszidőket. De van egy fontos különbség:

egy gyors infrastruktúra nem tud megjavítani egy rosszul felépített weboldalt.

Ha az oldalnak húsz adatbázis-lekérdezésre van szüksége egyetlen oldal megjelenítéséhez, azt nem feltétlenül oldja meg egy erősebb szerver. Ha egy 4 MB-os képet kell letölteni, attól még 4 MB marad. Ha tíz külső szolgáltatást kell megvárni, azokat a szerver teljesítménye sem tünteti el.

Éppen ezért az infrastruktúrát nem önmagában kell nézni.

A szerver, az alkalmazás, az adatbázis, a hálózat, a cache és a frontend együtt alkotják a rendszert.

4. A képek gyakran többet számítanak, mint gondolnánk

Egy modern weboldal vizuális. Nagy képek, videók, illusztrációk és animációk nélkül sok esetben nem lenne ugyanaz az élmény. A probléma nem ezek használata, hanem az, amikor mindent maximális felbontásban, tömörítés nélkül és minden eszközre ugyanúgy töltünk be.

Egy mobiltelefon kijelzőjén például nincs feltétlenül szükség egy több ezer pixeles, óriási képre. Más méret kellhet mobilra, más desktopra. Más formátum lehet optimális egy fotóhoz, és más egy egyszerű grafikához.

Ráadásul az sem mindegy, mikor töltjük be a képet.

A legfontosabb, első képernyőn megjelenő tartalmat érdemes másképp kezelni, mint azt a képet, amit a látogató csak három görgetéssel később fog látni.

A képoptimalizálás nem egyszerűen „tömörítsük a JPG-ket”.

Része a megfelelő méret, formátum, tömörítés, betöltési stratégia és megjelenítési környezet kiválasztása.

5. A JavaScript könnyen elszaladhat

A modern webfejlesztés egyik nagy előnye, hogy szinte bármit meg tudunk csinálni és pontosan ez az egyik veszélye is. Egy weboldal ma már lehet interaktív, animált, dinamikus és alkalmazásszerű. Csakhogy minden extra működésnek ára van.

A JavaScriptet a böngészőnek le kell töltenie, feldolgoznia és futtatnia. Ez különösen mobil eszközökön fontos, ahol a hardver és a hálózat nem feltétlenül olyan gyors, mint egy fejlesztői gépen.

Ezért nem az a cél, hogy:

„Ne használjunk JavaScriptet.”

Hanem az, hogy:

„Csak azt használjuk, amire valóban szükség van.”

A jó fejlesztés nem attól modern, hogy minél több technológiát használ.

Hanem attól, hogy pont annyit használ, amennyi az adott problémához kell.

6. A külső szolgáltatások láthatatlan költsége

Egy mai weboldal ritkán működik teljesen önállóan.

Google Analytics, Meta Pixel, Cookie-kezelés, Chat, CRM, Hírlevél, Térkép, Videó, Betűtípusok, Marketingautomatizáció, Különböző API-k.

Mindegyik hasznos lehet. De minden külső szolgáltatás egy újabb kapcsolat, újabb kérés, újabb függőség.

Ezért érdemes időnként feltenni a kérdést:

Valóban szükségünk van erre?

És ha igen:

Mikor kell betöltenünk?

Egy analitikai scriptnek például nem feltétlenül kell blokkolnia az oldal első tartalmának megjelenését. Egy chat widgetnek sem kell feltétlenül az első ezredmásodpercben elindulnia.

A teljesítmény szempontjából nem csak az számít, hogy mit használunk, hanem az is, hogy hogyan és mikor használjuk.

7. A cache nem varázslat

A cache az egyik legerősebb eszköz egy webes rendszer gyorsítására.

Ha valamit már egyszer kiszámoltunk vagy lekértünk, sok esetben nincs értelme minden alkalommal újra elvégezni ugyanazt a munkát.

Lehet cache-elni például:

• statikus fájlokat,
• képeket,
• API-válaszokat,
• adatbázis-lekérdezések eredményeit,
• teljes oldalakat,
• CDN-en keresztül kiszolgált tartalmakat.

De a cache-t is jól kell megtervezni.

Meddig érvényes?

Mikor frissül?

Mi történik módosításkor?

Mi legyen a dinamikus tartalmakkal?

Egy rosszul beállított cache ugyanúgy okozhat problémákat, mint annak teljes hiánya.

Ezért nem elég annyit mondani:

„Van cache.”

A kérdés az, hogy mit, hogyan és miért cache-elünk.

8. A gyors weboldal mobilon is gyors

Ez ma már alapvetésnek tűnik, mégis rengeteg weboldal elsősorban desktopon készül el.

A fejlesztő nagy monitoron nézi.

Gyors internetkapcsolattal.

Erős számítógépen.

Majd a végén megnyitják mobilon is.

Pedig sok látogató pont fordítva találkozik az oldallal.

Mobilon kisebb kijelző, változó hálózat és gyengébb hardver áll rendelkezésre.

Ezért egy weboldal sebességét nem csak ideális körülmények között érdemes vizsgálni.

A valódi kérdés az, hogyan működik akkor, amikor a körülmények nem tökéletesek.

9. A design is befolyásolja a teljesítményt

Elsőre furcsán hangzik, de a designer is tud gyors vagy lassú weboldalt tervezni. Ha minden szekcióban videó háttér van, annak ára van. Ha minden elem animálódik, annak ára van. Ha óriási képekből épül fel a hero, annak ára van. Ha egy oldal tele van egymásra épülő interakciókkal, annak ára van. Ez természetesen nem jelenti azt, hogy egy prémium weboldalnak unalmasnak kell lennie.

Épp ellenkezőleg.

A jó design nem attól prémium, hogy mindent egyszerre mutat. A jó design tudja, mire kell felhívni a figyelmet. Tudja, hol kell mozgás. Tudja, hol kell kép. Tudja, hol kell üres tér. És tudja azt is, mit kell elhagyni.

A teljesítmény és a design tehát nem egymás ellenségei. Ha jól dolgoznak együtt, kifejezetten erős eredmény születik.

10. Nem minden milliszekundum egyformán fontos

A weboldal sebességét nem érdemes egyetlen számmal elintézni.

Az számít, hogy a felhasználó mikor kezd valamit látni.

Mikor jelenik meg a fő tartalom.

Mikor válik használhatóvá az oldal.

Mikor reagál egy kattintásra.

Mennyire stabil a megjelenés betöltés közben.

Ezért a teljesítményoptimalizálásnál nem elég azt mondani, hogy:

„A PageSpeed 95 pont.”

A mérőszámok fontosak, de a felhasználói élmény a végső cél.

Lehet egy oldal papíron kiváló pontszámú, mégis kellemetlen használni.

És fordítva: egy összetettebb alkalmazásnak lehetnek olyan részei, ahol bizonyos kompromisszumokat tudatosan vállalunk, mert cserébe olyan funkciót kapunk, amely valódi üzleti értéket teremt.

A cél nem egy zöld pipa.

A cél egy gyors, stabil és jól használható rendszer.

11. A teljesítményoptimalizálás kompromisszumokból is áll

Ez talán az egyik legfontosabb gondolat.

Nem lehet mindenből maximumot kérni.

Lehet egy weboldal:

• látványos,
• gyors,
• animált,
• funkciókban gazdag,
• keresőoptimalizált,
• egyszerűen karbantartható,
• és közben olcsón üzemeltethető.

De az egyes döntések között vannak kompromisszumok.

Ha például egy komplex 3D élményt szeretnénk a nyitóképernyőn, annak teljesítménybeli költsége lesz.

Ha valós időben szeretnénk adatokat megjeleníteni, annak infrastruktúraigénye lesz.

Ha egy webshopban rengeteg dinamikus funkciót használunk, annak lesz technikai ára.

A professzionális fejlesztés egyik része éppen az, hogy ezeket a kompromisszumokat már a tervezés során felismerjük.

Nem utólag próbáljuk megmenteni a rendszert.

12. És akkor hol jön képbe az AI?

Az AI önmagában nem tesz gyorsabbá egy weboldalt.

Lehet AI-val lassú rendszert építeni.

És lehet AI-val gyors, jól optimalizált rendszert is.

Az AI inkább egy új építőelem a rendszerben.

Lehet vele automatizálni folyamatokat, intelligens keresést létrehozni, dokumentumokat feldolgozni, ügyfélszolgálati folyamatokat támogatni, adatokat elemezni vagy akár komplett üzleti folyamatokat újragondolni.

De ugyanúgy meg kell tervezni:

• hogyan kommunikál a rendszer az AI-modellel,
• milyen adatokat küldünk,
• mikor indítunk kérést,
• mit cache-elünk,
• hogyan kezeljük a hibákat,
• hogyan tartjuk kordában a költségeket,
• és hogyan illesztjük az egészet a meglévő infrastruktúrába.

Az AI sem varázslat. Ugyanúgy rendszerben kell gondolkodni.

A gyors weboldal valójában már a briefnél elkezdődik

Ha egy projekt végén kezdünk el a sebességgel foglalkozni, sokkal nehezebb dolgunk van.

Ha viszont már az elején feltesszük a megfelelő kérdéseket, egészen más eredmény születhet.

Mekkora forgalom várható?

Milyen eszközökön használják majd?

Milyen adatokat kell kezelni?

Mennyire dinamikus az oldal?

Milyen integrációkra lesz szükség?

Milyen funkciók valóban fontosak?

Mi történjen az első másodpercben?

Mi tölthető be később?

Milyen infrastruktúrán fusson?

Hogyan fogjuk később bővíteni?

Ezek elsőre nem feltétlenül sebességgel kapcsolatos kérdéseknek tűnnek.

Pedig azok.

A teljesítmény sokszor nem az optimalizálásnál kezdődik, hanem a döntéseknél.

Nem gyorsítani kell. Jól kell építeni.

Egy weboldalt utólag is lehet optimalizálni.

Lehet képeket tömöríteni, cache-t beállítani, JavaScriptet csökkenteni, CDN-t használni, adatbázist optimalizálni.

És ezek mind fontosak.

De a legjobb teljesítmény sokszor abból születik, hogy már az első döntéseknél figyelembe vesszük, hogyan fog működni a rendszer élesben.

• Milyen technológiát választunk.
• Hogyan építjük fel az architektúrát.
• Mit töltünk be.
• Mit nem töltünk be.
• Mit szolgálunk ki a szerverről.
• Mit cache-elünk.
• Milyen külső szolgáltatásokat használunk.
• És mit hagyunk el.
• Ezért a gyors weboldal nem trükk.
• Nem egy plugin.
• Nem egy szervercsomag.
• Nem egy PageSpeed-pontszám.

Hanem sok jó döntés egymás után.

És minél összetettebbé válik egy digitális rendszer, annál fontosabb, hogy ezeket a döntéseket ne utólag, hanem már a tervezőasztalon meghozzuk.