Mitől lesz lassú egy weboldal, és hogyan mérhető?

Modul 6: Sebesség · Olvasási idő: 9 perc

Tanulási cél: E lecke után képes lesz megmérni, hol telik az idő, és felismerni a különbséget a szerveroldali és a böngészőben jelentkező lassúság között.

Kulcsfogalmak: TTFB, Core Web Vitals (LCP, INP, CLS), labor adatok, mezei adatok, PageSpeed Insights, hálózat lap, tömörítés, külső szkriptek, a tárhelycsomag korlátai, 503

Először mérjen, csak utána módosítson

Annak, hogy "a weboldal lassú", akár tíz különböző oka is lehet. Aki mérés nélkül egyszerre vesz fel egy gyorsítótár bővítményt, egy képoptimalizáló bővítményt és egy nagyobb csomagot, az utána nem fogja tudni, mi segített, viszont három dologgal több lesz, amit karban kell tartania. Ezért mindig három kérdéssel kezdje (ugyanazokkal, mint a tárhelyszolgáltatója útmutatójában):

1. Minden lassú, vagy csak a vezérlőpult? Egy lassú vezérlőpult gyors előlappal arra utal, hogy a bővítmények sokat dolgoznak a vezérlőpulton, vagy hogy botok ostromolják a bejelentkezési oldalt.
2. Mindig, vagy csak bizonyos időpontokban? Ha csak forgalmas időszakokban, vagy amikor egy ütemezett feladat fut: akkor a csomagja eléri a határait.
3. Mindenkinél, vagy csak Önnél? Próbálja ki a telefonján 4G-n vagy 5G-n keresztül, vagy kérjen meg valaki mást. Ha csak Önnél lassú, akkor a kapcsolatával vagy a VPN-jével van a probléma.

Két fele: a szerver és a böngésző

Az idő, amíg a látogató vár, két részből áll (1.2. lecke):

1. A szerver elkészíti a HTML-t: webszerver, PHP, bővítmények, adatbázis. Ezt TTFB-ként (time to first byte) láthatja, vagyis a válasz első bájtjáig eltelt idő. A web.dev ökölszabályként azt mondja, hogy a legtöbb weboldalnak 0,8 másodperc vagy annál kisebb TTFB-re kell törekednie.
2. A böngésző beolvassa ezt a HTML-t, majd lekér mindent, ami benne szerepel: stíluslapok, szkriptek, betűtípusok, képek, videó, mérőkódok, chat widgetek. Csak amikor ezekből elég betöltődött, lát valamit a látogató.

A magas TTFB-t a szerveroldalon oldja meg: gyorsítótárazás (6.2. lecke), kevesebb vagy könnyebb bővítmény, újabb PHP-verzió, rendbe tett adatbázis (6.3. lecke) vagy nagyobb számítási kapacitás. Egy alacsony TTFB mellett mégis lassú oldal a böngésző oldalára mutat: túl nagy képek, túl sok szkript, külső elemek.

Core Web Vitals

A Google három mutatóval méri a látogatók élményét, ezek a Core Web Vitals:

Az INP 2024 márciusában váltotta fel a korábbi FID mutatót. A Google ezeket a számokat többek között a keresési találatok rangsorolásánál használja, de a legfontosabb ok, amiért érdemes javítani rajtuk, egyszerű: a látogatók elpártolnak egy lassú vagy ugráló oldaltól.

Labor adatok és mezei adatok

Kétféle mérés létezik, és ezek eltérő számokat adnak:

• Labor adatok (lab data): egy teszt egyetlen pillanatban, egyetlen helyről, egy szimulált telefonnal és kapcsolattal. Hasznos az összehasonlításhoz (egy változtatás előtt és után), de nem valódi látogatót jelent.
• Mezei adatok (field data): mérések valódi látogatóknál, Chrome böngészővel, az elmúlt 28 nap alapján. Ez az, amit a látogatók ténylegesen tapasztalnak. A kisebb weboldalaknak gyakran túl kevés látogatójuk van ahhoz, hogy legyen mezei adatuk.

A PageSpeed Insights (pagespeed.web.dev) mindkettőt megmutatja: felül a mezei adatokat (ha vannak), alatta egy labor tesztet pontszámmal és konkrét javaslatokkal. Ne a 0 és 100 közötti pontszámra figyeljen vakon. Nézze meg a részleteket: azért rossz az LCP, mert lassú a szerver (TTFB), vagy mert a nagy kép 3 MB?

Mindig teszteljen néhányszor (a számok ingadoznak), és egy hétköznapi oldalt is teszteljen, ne csak a kezdőlapot.

Saját szemmel nézve a böngészőben

A böngésző fejlesztői eszközei (F12) megmutatják, mi történik valójában:

• Hálózat lap: frissítse az oldalt kikapcsolt gyorsítótárral (a "Gyorsítótár kikapcsolása" jelölőnégyzettel). Láthatja az összes betöltött fájlt, azok méretét és betöltési idejét. Rendezze méret szerint: a legnagyobb fájlok gyakran képek. Rendezze domain szerint: mennyi érkezik más szolgáltatóktól (betűtípusok, mérőkódok, videók)?
• Az első kérés (maga a HTML): kattintson rá, Timing fül. A "Waiting for server response" maga a TTFB.
• Az első kérés fejlécei (HTTP fejléc): van tömörítés (content-encoding: br vagy gzip), és gyorsítótárból érkezett-e az oldal (6.2. lecke)?

A szokásos bűnösök

A gyakorlatban a WordPress-oldalak lassúsága legtöbbször ezek egyikéből fakad:

1. Nincs oldal gyorsítótár: minden oldal minden látogatáskor újra elkészül (6.2. lecke).
2. Túl sok vagy túl nehéz bővítmény, különösen azok, amelyek minden kéréskor külső szolgáltatásokat hívnak meg, vagy nehéz lekérdezéseket futtatnak (5.3. lecke).
3. Nagy méretű képek: egy telefonnal készült 5 MB-os fotó a kezdőlapon (4.4. és 6.3. lecke).
4. Egy nehéz sablon vagy egy oldalépítő, amely minden oldalon rengeteg szkriptet és stíluslapot tölt be (5.1. lecke).
5. Külső elemek: betűtípusok, videók, chat widgetek, mérőkódok, mások közösségimédia-gombjai. Mindegyik egy kapcsolat egy másik szerverhez, amely lassú lehet.
6. Egy elavult PHP-verzió (8.4. lecke).
7. Egy rendezetlen adatbázis: ezernyi revízió, spam, bővítmények naplótáblái (6.3. lecke).
8. Botok: keresőrobotok, AI-robotok és bejelentkezési próbálkozások terhelik a csomagját (7.3. lecke).
9. A csomag eléri a határait: túl kevés számítási kapacitás (CPU), folyamat vagy memória a forgalomhoz képest.

A csomagja korlátai

Osztott tárhely (shared hosting) esetén minden csomag a szerver egy rögzített részét kapja: számítási kapacitást, memóriát, lemezsebességet és egy bizonyos számú egyidejű folyamatot. Ha a weboldala ennél többet használ, lelassul, vagy a látogatók egy 503 hibaüzenetet kapnak (Service Unavailable, egyes tárhelyszolgáltatóknál "Resource Limit Is Reached"). A DirectAdmin CloudLinuxszal ezt a Resource Usage alatt láthatja (a "faults" jelzi, ha a weboldala le lett lassítva), az X-Ray funkcióval pedig oldalanként láthatja, melyik bővítmény vagy lekérdezés viszi el az időt. Más tárhelyszolgáltatóknál hasonló áttekintések találhatók, néha csak kérésre.

Egy nagyobb csomag akkor segít, ha a weboldalának valóban többre van szüksége (egy forgalmas webáruház). Egy rosszul beállított weboldal problémáját nem oldja meg: a probléma később úgyis visszatér. Először az okot keresse meg.

Összefoglalás

• Először mérjen: minden vagy csak a vezérlőpult, mindig vagy néha, mindenkinél vagy csak Önnél.
• A TTFB a szerveroldal (0,8 másodperc vagy kevesebb legyen a cél); a többi az, amit a böngésző tölt be.
• Core Web Vitals: LCP (2,5 mp), INP (200 ms) és CLS (0,1); az INP 2024-ben váltotta fel a FID-et.
• A PageSpeed Insights megmutatja a mezei adatokat és a labor adatokat is; a hálózat lap megmutatja, mi töltődik be valójában.
• A lassúság legtöbbször a hiányzó gyorsítótár, a nehéz bővítmények, a nagy képek és a külső elemek miatt van; a nagyobb csomag csak az utolsó lépés.

Kvíz

Feladat

A6.1 feladat: Mérje meg a TTFB-jét és a tömörítését. Adja meg a weboldala címét, és ha szeretné, egy hétköznapi oldalét is (például a kapcsolat oldalát). A program mindegyik oldalt háromszor kéri le cookie-k nélkül, és megadja a középső TTFB-t, a HTML méretét, valamint azt, hogy a szerver tömörítve küldi-e a HTML-t (content-encoding gzip vagy br). Hasonlítsa össze az eredményt egy PageSpeed Insights teszttel, és jegyezze fel, mi tűnik fel Önnek.

További olvasnivaló

Ezek a cikkek a WebOké vezérlőpultjain található lépéseket írják le; más vezérlőpultokon hasonlóan működnek.

• DirectAdmin útmutató 18.3: A weboldalam lassú
• DirectAdmin útmutató 17.3: Erőforrás-használat: CPU, memória és folyamatok
• DirectAdmin útmutató 17.4: X-Ray: lassú oldalak felderítése
• DirectAdmin útmutató 17.5: 503 vagy "Resource Limit Is Reached": mit tegyen ilyenkor?
• A weboldalam lassú, vagy túl sok CPU-t használ: így tehető gyorsabbá
• Core Web Vitals (web.dev, angolul): https://web.dev/articles/vitals
• PageSpeed Insights: https://pagespeed.web.dev/