Elnézést kérek a clickbait és talán kissé demagóg címadásért, de sajnos nagyon nagy a homály a téma körül, és számtalanszor magyaráztam már el ezt a témát ügyfeleimnek.

Alapvetően nagyon helyes, hogy a Google évekkel ezelőtt elkezdte mérni, és elkezdte valamilyen – egyelőre minimális mértékben rangsorolási szempontként is felhasználni a weboldalak sebességét. Azonban azt érzem, hogy kicsit átestünk a ló túloldalára, és sokszor az ügyfelek is irreális elvárásokat támasztanak ezekkel az értékekkel szemben, amik már esetleg más, sokkal fontosabb dolgok rovására mennek.

A legfőbb probléma, hogy a laikusok egyszerűen nem tudják értelmezni a kapott értéket. Nyilván nem várható el egyik ügyféltől sem, hogy professzionális webfejlesztő legyen. Ahhoz, hogy egy weboldalsebesség-tesztet értelmezni tudj, tisztában kell lenned olyan fogalmakkal, mint pl. a TTFB (time-to-first-byte), FCP (First Contentful Paint), mi az a HTTP/2, Brotil, stb.

Pedig nagyon egyszerűnek tűnik a képlet: ha a teszt alacsony pontszámot hoz ki, akkor lassú az oldal, ha magas pontszámot, akkor gyors. A valóság azonban – ahogyan az életben sem csak fekete/fehér minden – itt sem ennyire egyszerű.

A weboldalsebesség-tesztek legnagyobb problémája, hogy a látogatóra való fókuszálás helyett a pontszámok növelésére ösztönöznek. A sebesség mérő robot „jól lakik”, a tényleges felhasználó nem biztos. Egy automatizált teszt soha nem fogja tudni, hogy miért van szükség annyi script betöltésére egy-egy oldalon, ezért azt javasolja, hogy egyszerűen vedd ki, holott éppen a felhasználói funkciók miatt lenne ezekre szükség, és igenis használatban vannak.

Éppen ezért nem lehet csak ezekre a tesztekre támaszkodni, amikor meghatározzuk, hogy egy weboldal gyors-e vagy nem.

Szintetikus tesztek, szintetikus eredmények

Nézzünk néhány konkrét példát az általános javaslatok közül, amik nem minden esetben állják meg a helyüket:

• Képek tömörítése / Jelenítse meg a képeket következő generációs formátumokban
  A képek tömörítése általánosan a képek minőségének romlásához vezet. Amennyiben olyan weboldalról van szó, ahol fontos a képek kiemelkedő minősége, ez a javaslat nem alkalmazható.
• Késleltesse a képernyőn kívüli képek betöltését / Lazy load
  Rendben, és elkezd görgetni a felhasználó az oldalon, ahol nem jelennek meg képek, csak kis idő elteltével. Itt ki foglalkozik azzal, hogy ez milyen felhasználói élményt nyújt?
• Lassú LCP (Largest Contentful Paint)
  Kit érdekel, hogy az oldal teljes betöltődése mennyi időbe telik? (Nyilván ésszerű határokon belül.) A látogatóknak első körben úgy is csak a kritikus elemekre van szüksége, minden más betöltése ráér.
• Harmadik féltől származó erőforrások betöltésének büntetése
  Ez a kedvencem, amikor a Google PageSpeed lehúzza a pontokat azért, mert a Google Analytics script vagy a Google Fonts betűtípus nem felel meg a követelményeknek, pl. gyorsítótárazás szempontjából. Erre semmilyen ráhatásom nincs, mivel külső forrásból töltődik be.
• Távolítsa el a megjelenítést gátló erőforrásokat
  Köszi, ez igazán hasznos volt! Amúgy meg egy csomó esetben teljesen valid, hogy szükség van rá.

Összefoglalva, a sebességtesztek nem fogják tudni neked megmondani azt, hogy egyénileg, a Te oldalad esetében mi számít fontosnak, és mik azok a pontok, amikor legálisan szeged meg az általuk felállított szabályokat.

A megoldás: használd a szemed!

Szintetikus tesztek helyett használd a szemed. Igen, ennyire egyszerű! Ha a saját szemeddel gyorsnak látod a weboldaladat, akkor nincs probléma!

Sokan beleesnek abba a csapdába (bevallom, én is sokáig rabja voltam ennek), hogy a sebességteszteket kiszolgálva, inkább a lassabb tartalommegjelenítést választják, ahelyett, hogy a tartalom gyorsan megjelenne, majd utána töltődnek be a kevésbé fontos dolgok. De felhasználói élmény szempontjából nincs jobb annál, hogy a tartalom mielőbb megjelenjen. Válassz: 2mp alatt betöltődő oldal, aminél 1,9mp-ig nem látod a tartalmat, vagy 3mp alatt betöltődő oldal, aminél már 0,5mp után látod a tartalmat. Azt hiszem, hogy a mindennapokban inkább utóbbit választanám felhasználóként, a szintetikus teszt szerint mégis előbbi a jobb.

Legendák nyomában

Keresőoptimalizálás

Sokan jönnek azzal, hogy keresőoptimálizálás miatt fontos, hogy magas pontszámot kapjon az oldala. A gyakorlatban csak nagyon-nagyon minimális, vagy egyáltalán semmilyen hatással nincs a találati listán való helyhez ennek az értéknek. Ne ezért legyen gyors az oldalad, hanem azért, hogy nagyobb eséllyel vezessen pl. vásárláshoz!

A tuti WordPress gyorsító bővítmény, ami 100-as pontszámot csinál

Telepítettél egy WordPress bővítményt, ami 100-as értéket csinált neked, holott a szakember nem tudta ezt megoldani? Jól átverted magadat! Sajnos nagyon sok olyan bővítmény van, ami egy nagyon egyszerű trükkel gyakorlatilag átveri a sebességmérőket. Több népszerű gyorsító bővítmény is megbukott már ezzel a türkkel. Egyszerűen érzékeli, hogy most a Google PageSpeed ellenőrzi az oldalt (user agent alapján), és ilyen esetben nem tölti be a CSS és JS fájlokat, esetleg képeket, csak az oldal vázát. Kész is a 100-as oldal, lehet kitenni a kirakatba. Ha szeretnéd magadat átverni, bármikor írok neked 10 perc alatt egy ilyen bővítményt.

De nekem a GTmetrix borzasztó értéket mutatott az oldalra

Sebesség szempontjából nagyon nem mindegy, hogy a mérést végző szerver, és a webszerver hol helyezkedik el. Tipikus probléma, hogy a GTmetrix alapértelmezésként kanadai szervert kínál fel, a szerver pedig Magyarországon van. Kész is a lassú weboldal, pedig valójában nem lassú, csak az adatnak meg kell kerülnie a fél világot.

Mi az a javaslat, amit tényleg meg kell fontolni?

• Méretezze megfelelően a képeket
  Ne használj 2000×2000 pixeles képeket ott, ahol 200×200 pixeles helyen jelenik meg. Ezt általában a sablonok lekezelik, de oldalépítők esetén (pl. Divi, Elementor, Oxygen, stb.) esetén könnyű beleesni a hibába.
• A szerver kezdeti válaszideje (TTFB)
  Ennek 200 milliszekundum körül kell lennie. Ha ettől magasabb, vagy akár másodperces ez az érték, akkor ott gondok vannak. Ezt általában tárhelyváltással lehet megoldani csak.
• A nagyon nagy hálózati terhelés elkerülése
  Ez egy olyan javaslat, amit értelmezni kell, és aszerint mérlegelni, hogy foglalkozni kell-e vele. Az oldal betöltődéséhez szükséges adatforgalom mérete relatív.
• Kerülje a túl nagy DOM-méretet
  Érdemes lehet rá figyelni, de nagyjából csak saját kód esetén van erre valódi ráhatásunk. Oldalépítők esetén az oldalak hosszának illetve elemek számának csökkentésével tudjuk befolyásolni.

Ezen kívül még:

• Legyen egy megbízható tárhelyed, megfelelő teljesítménnyel! – Az évente 10.000Ft-ba kerülő cPanel tárhely egészen biztosan nem ilyen.
• Használj gyorsítótárazást!
• Ne használj túl sok bővítményt!
• Ne a látványon legyen a hangsúly, hanem a használhatóságon!

Összefoglalva

Ha nem vagy szakember, mielőtt bármit tennél, kérd ki szakértő tanácsát a témában. Ha komolyan akarod venni a dolgot, akkor ne hagyatkozz arra, hogy egyszerűen csak telepítesz egy színes/szagos bővítményt, és meg is van oldva a kérdés. Ezek egyáltalán nem biztos, hogy valós, és helyes optimalizációt fognak csinálni az oldaladnál. A valódi optimalizáció időigényes, és szakember szükséges hozzá!