Miért ilyen lassú a weboldalam a PageSpeed Insights szerint?

PageSpeed Insights Teszteredmény

Szinte naponta teszik fel a kérdést fórumokon, miszerint ha rákattintok a weboldalamra, akkor számomra elég gyorsnak tűnik, de a Google Speed Teszten hatalmas bukta az oldal. Miért van ez? Kell hinni a gyenge PageSpeed Insights eredménynek? Na és persze a legfontosabb, hogy mit tehetnék a javulás érdekében?

Tényleg lassú és ha igen, miért lassú a weboldalam?

Amennyiben ön egy cégvezető és van saját weboldala, akkor nagy valószínűséggel már beruházott egy gyors laptopra is. De a legtöbb weboldalt, főleg azokat, amelyek a nagyközönségnek szólnak nem egy erős laptopról, hanem egy mindennapi használat által leterhelt mobiltelefonról tekintenek meg.

Innentől pedig a weboldal sebessége szinte végtelen számú tényezőtől függ, kezdve a szerver elhelyezkedésétől az aktuális időjárással bezárólag. Példának okáért Erdélyben vannak olyan mobiltornyok, amelyek csökkentett kapacitással működnek viharos időjárás esetén. Jön a vihar, oda a jó internet…

Tehát az, hogy mi mit gondolunk a saját weboldalunkról egy kicsit sem fedi a valóságot.

Ugyanakkor az is tény, hogy a Google nagyon magasra teszi a lécet, sokszor elég nehéz, szinte lehetetlen megugrani. Ezért ne essünk kétségbe se, ha sosem tudjuk elérni az egyébként időről-időre változó minimum kérelmeket.

Régen gyakori eset volt, hogy nem is tudta jól mérni az oldalt ez az eszköz, ezért nagyon sokan mind a mai napig azt javasolják, hogy hagyjuk figyelmen kívül az egészet. Persze megtehetjük, de a Google nem fogja.

Ezért, hogy rövidre zárjuk a kérdést, a személyes javaslatunk az, hogy ha sárga zónában van a PageSpeed Insights eredmény, akkor még várhat egy kis időt a dolog, de ha piros zónás, főleg az asztali lekérés eredménye, akkor nem éri meg habozni. Lépni kell!

Mit lehet tenni a weboldal gyorsaságának javulása érdekében?

Igazából manapság egy egész iparág épült ki arra, hogy a lassú weboldalakat felpörgesse, és számos egymástól eltérő, de együtt is alkalmazható megoldás született. Így csak pénztárca kérdése, hogy melyeket alkalmazzuk.

Ugyanakkor kisvállalkozóként pont ez az a tényező, amely meggátolhat a sikerben, ezért sokszor saját magunk kezdünk el alkalmazni ingyenes eszközöket. Bár ezen eszközök, WordPress oldalak esetén bővítmények használatával is nagyszerű eredményt lehet elérni, valójában a próbálkozás egy kétélű penge. Ha nem vesszük elég gyorsan észre az így eredő hibákat, akkor többet bukhatunk, mint amennyit nyerhetünk.

Viszont akár saját magunk kezdünk el megoldást keresni, akár szakembert bízunk meg a feladattal, az alábbi dolgokat feltétlen meg kell vizsgálni, és a végső döntést mindig mi magunk kell meghozzuk.

1. Külső források

Van-e szükségünk 3 különböző képvetítő modulra, amely különböző szerverekről tölti le a saját erőforrásait a mi szerverünk helyett?

Van-e szükségünk 5 féle követőkódra, amely szintén külső szervereken tárolja az információt? (Google Analytics, Facebook Pixel, Hotjar, …)

Tényleg szükségünk van-e különböző külső szolgáltatásokra, mint pl. Google reCAPTCHA, Facebook poszt beemelése a weboldalra?

Ezek mind-mind olyan szolgáltatások, amelyek nagyban hozzájárulnak az oldal lassúlásához.

2. Hány fájlból áll a weboldalunk?

Amennyiben jobb egérgombbal kattintunk a weboldalunkra, majd a Vizsgálat (Inspect/Inspect element) lehetőségre, akkor megjelennek a fejlesztői eszközök, itt az Hálózat (Network) részben nyomon követhetjük, hogy hány fájlt kell betöltsön a böngésző ahhoz, hogy megjelenjen a weboldalunk.

Meg fogunk lepődni, amikor azt kapjuk, hogy 50 javascript fájl, 30 css fájl és legalább 12 féle betűtípus mellett legalább 50 képet is letölt az oldal, így ha az egészet összeszámoljuk, akkor máris megközelítettük a 150-es számot.

Ha önnél is ez a helyzet, akkor ideje egyesíteni a .js és .css fájlokat, tömöríteni amit csak lehet és elgondolkodni azon is, hogy a .jpg képeket .webp -kre cseréljük.

Azt viszont tudnunk kell, hogy nem várt működésbeli változásokkal járhat főleg a javascript fájlok egyesítése, így feltétlen le kell ellenőrizni az eredményt legalább 2-3 különböző eszközön és böngésző típusban.

3. Gyorsítótárazás

Az előző lépés arra szolgált, hogy az internet forgalmat csökkentsük. De nagyon sokszor már a saját szerverünkre való kapcsolódás pillanatában eldől, hogy mire számítsunk.

A kliens csatlakozik a szerverre miután átment a terhelés elosztó szerveren, a szerver az adatbázis szerverre, az válaszol a szervernek, a szerver értelmezi az adatokat majd válaszol a kliensnek. Ez a minimális séma, de az is lehet, hogy még mielőtt a kliensnek válaszolna a szerver, még igénybe vesz más szervereket is.

Még gondolatban is nehéz követni, de mi értelme ezeket a lépéseket egytől-egyig megtenni, használni az erőforrásokat, ha az eredmény minden egyes lekérés után ugyanaz?

Ezért feltalálták a Cache / Page Cache / Database Cache / Client Cache megannyi fajta gyorsítótárat, amely a kigenerált eredményt lementi és használja egy meghatározott ideig.

A gyorsítótárak használatát viszont csak akkor ajánljuk, ha tényleg statikus a weboldalunk, azaz nincsen vásárlási opció rajta, nem kell semmiért bejelentkezni. Ellenkező esetben mindenképp kérjük szakember segítségét.

4. CDN szerver használata

Azt már tudjuk, hogy a weboldal sebessége függ a szerver és a kliens közti távolságtól, ezért választunk mindig a klienskörhöz közeli szervert magunknak. De mi van ha a világ összes táján szeretnénk árulni?

Erre az esetre találták ki a Content Delivery Network vagy Content Distribution Network kifejezést, röviden a CDN-t, amelynek működési elvét úgy kell elképzelni, mintha csak klónoznánk a szerverünket és elhelyeznénk a világ számos pontján. Így minden felhasználó a hozzá legközelebb található szerverről kapja a választ. És az sem elhanyagolható tényező, hogy ha kiesik az egyik katona a sorból (azaz az egyik szerver), attól nem esik el az egész hadsereg.

Persze ez a szerver-hálózat magával hozza a szerverek szinkronizálásának problémáját, így megint csak azt tudjuk ajánlani, hogy kérje szakember véleményét, vagy legalább nézzen meg egy oktatóvideót, ha belevágna.

PageSpeed Insights alternatívák

Amennyiben a fenti lépéseken már túl vagyunk, és még mindig úgy érezzük, hogy túl lassú az oldalunk teszteredménye, és már rá se tudunk nézni a teszteszközünkre, akkor itt van pár alternatíva.

Pingdom Website Speed Test és GTmetrix: mindkét eszköz, gyors, ingyenes és részletes elemzést kínál.

WebpageTest: ez az eszköz annyiban másabb, hogy látványosabban kirajzolja az egyes fájlok letöltésének folyamatát

Dotcom-Tools: egyszerre lehet több helyszínről is letesztelni az oldalt

Amint láthatjuk eszköz van bőven, lehetőségek is. A nagyok sokszor a másodperc ezredrészeiért harcolnak. Akkor miért maradjunk ki mi a versenyből?

Hát kalandra fel!

Hasznosnak találtad ezt a cikket? Tetszik az, amit el akarunk érni az online térben? Akkor kérlek mutasd meg ezt másoknak is.