A betöltési idő az az időtartam, amely a böngésző kérésétől az oldal használható megjelenéséig eltelik. Nyers mérésként egyetlen szám: egy kérés teljes lefutásának hossza, a felhasználói élmény finomabb bontása nélkül.
Hogyan működik
Egy oldalbetöltés több, egymásra épülő szakaszból áll. A böngésző feloldja a domaint, kapcsolatot nyit, TLS-t egyeztet, majd elküldi a kérést. A szerver válaszának első bájtja a TTFB (Time to First Byte), onnantól jön a HTML, utána a CSS, a JavaScript és a képek.
A nyers betöltési idő ezeket összegzi. Ezért nagyon érzékeny arra, hol van a szerver, mennyi fájlt kér az oldal, és milyen a hálózat. Ugyanaz az URL kétszer mérve könnyen 30-40 százalékkal máshogy jön ki.
Miért nem egy szám a sebesség
A gyakorlatban több eltérő végpont létezik. A DOMContentLoaded a HTML feldolgozásának végét jelzi, a load esemény az összes erőforrás megérkezését. A felhasználó viszont azt érzi gyorsnak, amikor a fő tartalom megjelenik: ezt méri a LCP (Largest Contentful Paint). A nyers idő jó gyorsjelzés, de nem helyettesíti a Core Web Vitals mérését.
Miért számít a gépeknek
A keresőrobotok és az AI-crawlerek időkorláttal dolgoznak. Nem várnak a végtelenségig, és a többségük nem futtat JavaScriptet. Ha a HTML lassan érkezik, a tartalom egy része soha nem kerül be a feldolgozásba. A lassú szerver a feltérképezés ütemét is visszafogja, mert a robot óvatosabban kérdez.
Mit néz ebből a riport
Az audit a nyers betöltési időt méri: egy szerveroldali kérés teljes lefutását. Ez a szabály alacsony hatású és kód-hatókörű, tehát önmagában nem üzleti döntés kérdése. A riportokban ez a szám jó előszűrő: ha kiugróan magas, szinte mindig a szerver vagy a cache a szűk keresztmetszet.
Röviden: a betöltési idő egy összegzett szám, ami megmutatja, van-e baj, de a javításhoz a szakaszokat kell külön megnézned.
Technikai példa
Szerveroldali mérés böngésző nélkül. Jól látszik, melyik szakasz viszi az időt:
curl -o /dev/null -s -w "dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://pelda.hu/
Ha a ttfb és a total közel van egymáshoz, a szerver a szűk keresztmetszet. Ha a total sokkal nagyobb, a HTML mérete vagy a hálózat a gond.
Működő cache és hosszú érvényesség a válaszfejlécben:
HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: public, max-age=0, s-maxage=600
x-cache: HIT
HTTP/2 200
content-type: text/css
cache-control: public, max-age=31536000, immutable
A HTML-t rövid ideig a proxy tárolja, a verziózott CSS-t a böngésző egy évig.
Gyakori kérdések
Mennyi a jó betöltési idő?
Nincs egyetlen hivatalos küszöb a nyers időre. Gyakorlati célként asztali kapcsolaton 3 másodperc alatti load esemény jó, a TTFB pedig 800 ms alatt. A felhasználói élményhez a 2,5 másodperc alatti LCP a mérvadó érték.
Miért más a szám a PageSpeed-ben és a devtoolsban?
Mást mérnek. A devtools a te gépedet és a te hálózatodat használja, a PageSpeed egy szabványosított labor-környezetet. A mezei adat pedig valódi látogatók 28 napos méréseit összegzi. Mindháromra szükség van, de ne hasonlítsd őket egy az egyben.
Segít a CDN, ha magyar a célközönség?
Igen, de nem a földrajzi távolság miatt. A CDN a statikus fájlokat leveszi a szerverről, és a TLS-egyeztetést a látogatóhoz közelebb végzi. Ha a HTML-t is cache-eled a peremen, a TTFB is érezhetően javul.
Rangsorol-e a Google a betöltési idő alapján?
A Google a Core Web Vitals mérőszámait használja rangsorolási jelként, nem a nyers betöltési időt. A nyers idő ezért inkább diagnosztikai eszköz. Ha az magas, szinte biztosan a valódi mérőszámok is rosszak.
Elég, ha a főoldal gyors?
Nem. A látogatók nagy része kategória- vagy terméklapra érkezik keresőből. Mérd külön a főoldalt, egy kategóriát, egy terméket és egy blogbejegyzést. Ezek futási ideje jellemzően nagyon eltér.
