Weboldal gyorsítása: gyakorlati ellenőrzőlista

Weboldalt úgy gyorsíthatsz, hogy először a PageSpeed Insights-szal mérsz, majd javítod a legnagyobb okot, amelyre rámutat — általában túl nagy képek, túl sok JavaScript, nehéz betűtípusok vagy harmadik féltől származó scriptek. Törekedj a Google Core Web Vitals „jó” célértékeire: a fő tartalom 2,5 másodpercen belül látszik, a koppintásokra 200 ezredmásodpercen belül reagál az oldal, és szinte nem ugrál a layout. A legtöbb oldal néhány változtatással eléri ezeket, nem átírással.

Először mérj, aztán változtass

A találgatás időt pazarol. Két ingyenes eszköz szinte mindenkinek elég:

• PageSpeed Insights (pagespeed.web.dev) — illessz be egy élő URL-t. Megmutatja a terepi adatokat a valódi Chrome-felhasználóktól (ha elég forgalmad van), és a laboradatokat egy szimulált betöltésből, plusz a konkrét problémák listáját.
• Lighthouse a Chrome DevTools-ban — ugyanaz a labor-teszt, bármely megnyitható oldalon, beleértve az előnézetet is. Mobil módban teszteld; a lassabb hálózatokon lévő telefonokon látszanak a problémák.

A fontos számok a Google Core Web Vitals mutatói. 2026 szeptemberétől a web.dev-en lévő Google-dokumentáció ezeket a „jó” küszöbértékeket adja meg, amelyeket a betöltések 75. percentilisében mérnek:

Az INP 2024-ben váltotta fel a régi First Input Delay mutatót. Ha egy eszköz még FID-et mutat, az elavult.

Jegyezd fel a kiindulási számokat. Minden javítás után mérj újra, hogy tudd, mi segített.

Hol vész el az idő: lehetőségek és kompromisszumok

Minden gyakori oknak van javítása, és minden javításnak ára van. Kezdd a tetején lévőkkel — ezek a legolcsóbbak és a leggyakoribbak.

Képek

A képek a leggyakoribb probléma és a legkönnyebben javítható. Egy 4000 pixeles fotó, amelyet 800 pixel szélesen jelenítesz meg, minden látogatónak ötször annyit tölt le, mint amennyit lát.

• Olyan méretben szolgáld ki a képeket, amilyenben megjelennek, reszponzív srcset méretekkel telefonra és asztali gépre.
• Használj modern formátumokat (WebP vagy AVIF) és ésszerű tömörítést.
• Adj minden képnek width és height értéket, hogy a böngésző lefoglalja a helyet. Ez önmagában a legtöbb layout-eltolódást megszünteti.
• A redőn alatti képeket töltsd lazy módban a loading="lazy" attribútummal.
• Soha ne tölts lazy módban az oldal tetején lévő főképet. A Google LCP-útmutatója ebben egyenes: a főkép lazy betöltése mindig késlelteti az LCP-t. Adj neki inkább fetchpriority="high" attribútumot.

JavaScript

Sok AI-épített oldal egyoldalas app (SPA): a böngésző letölt egy JavaScript-csomagot, és csak utána rajzolja ki az oldalt. Minél nagyobb a csomag, annál hosszabb az üres képernyő. A javítások, erőfeszítés szerint sorrendben:

1. Távolítsd el, amit nem használsz. Kérj listát a függőségekről, és vágd ki azokat a könyvtárakat, amelyek egyszer kerültek be és elfelejtődtek — egy dátumkönyvtár egyetlen dátumhoz, egy teljes ikoncsomag öt ikonhoz.
2. Bontsd útvonalanként. Az adminisztrációs felület kódját csak akkor töltsd be, amikor valaki megnyitja, ne a főoldalon.
3. Előrendereld a nyilvános oldalakat. Egy marketingoldal, amely valódi HTML-ként érkezik, még azelőtt megjelenik, mielőtt bármi JavaScript lefutna. Ez a keresőmotoroknak is segít; lásd: SEO AI-val épített weboldalakhoz.

A lassú INP általában egy hosszú feladatot jelent, amely blokkolja az oldalt — egy hatalmas lista szűrése minden billentyűleütésnél, vagy egy egész táblázat újrarenderelése, amikor egy cella változik. A Chrome DevTools Performance panelje megmutatja, melyik.

Betűtípusok

Minden betűcsalád és súly egy újabb fájl. Két család és három-négy súly általában bőven elég. Töltsd elő a redő felett használt betűtípust, használd a font-display: swap beállítást, hogy a szöveg azonnal látszódjon, és saját szerverről szolgáld ki a betűtípusokat, ha a külső betűszolgáltatás lassú a látogatóidnak.

Harmadik féltől származó scriptek

A csetwidgetek, az analitika, a hőtérképek, a hirdetéskövető pixelek, a beágyazott videók és a közösségi hírfolyamok más szerverekről töltenek kódot. Mindegyik kicsinek tűnik; együtt gyakran az oldal leglassabb része. Tartsd meg azokat, amelyeket ténylegesen figyelsz. A többit töltsd be, miután az oldal interaktívvá vált, a nehéz beágyazásokat (YouTube-lejátszó, térkép) pedig cseréld le könnyű előnézetre, amely kattintásra tölti be a valódi tartalmat.

Szerverválasz

A Time to First Byte (TTFB) — az, mennyi idő alatt kezd válaszolni a szerver — minden más mutató alapja. A CDN-ről (a látogatóidhoz közeli szerverhálózatról; lásd: mi az a CDN) kiszolgált statikus oldalak majdnem mindenhol gyorsak. A kérésenként a szerver által generált oldalak a szervertől és az adatbázisától függnek. Az ismétlődő munka gyorsítótárazása és a lassú lekérdezések adatbázis-indexelése a szokásos javítások.

Promptok, amelyek működnek

Légy konkrét: nevezd meg az oldalt, a mutatót és a korlátot. Ha van, illeszd be a PageSpeed Insights megállapításait.

A PageSpeed Insights 4,8 s LCP-t jelez mobilon a főoldalon, és az LCP-elem a főkép. Méretezd át és alakítsd WebP-vé a főképet, szolgálj ki reszponzív méreteket, állítsd be a width és height értékeket, adj neki fetchpriority="high" attribútumot, és győződj meg róla, hogy nincs lazy betöltve. A redőn alatti összes képet töltsd lazy módban. Ne változtasd meg a dizájnt.

Vizsgáld át ennek az appnak a függőségeit. Sorold fel minden csomagot, azt, hogy ki használja, és nagyjából mennyit ad a csomaghoz. Távolítsd el a nem használtakat, és a /admin és /settings útvonalakat bontsd külön darabokra, amelyek csak a meglátogatásukkor töltődnek be.

A kereső mező a /products oldalon lassúnak érződik. Késleltesd a szűrést (debounce), kerüld a teljes lista újrarenderelését minden billentyűleütésnél, és lapozd vagy virtualizáld a listát, ha 200 elemnél több van benne.

Lépésről lépésre

1. Teszteld az élő oldalt mobilon a PageSpeed Insights-ban. Jegyezd fel az LCP-t, az INP-t és a CLS-t, valamint a felsorolt három fő problémát.
2. Először a képeket javítsd: méret, formátum, mérethatározók, lazy betöltés a redőn alatt, prioritás a főképnek.
3. Vágd ki a harmadik féltől származó scripteket, amelyeket nem használsz, a többit halaszd el.
4. Csökkentsd a betűtípusokat arra, amire a dizájnnak szüksége van.
5. Csökkentsd a JavaScriptet: távolítsd el a nem használt csomagokat, bontsd útvonalanként.
6. Előrendereld a nyilvános oldalakat, ha még kliensoldalon renderelődnek, és az LCP továbbra is lassú.
7. Ellenőrizd a szervert: gyorsítótárazás, adatbázis-indexek, statikus tárhely a ritkán változó tartalomhoz.
8. Tedd közzé újra, és teszteld újra. A PageSpeed Insights terepi adatai a következő hetekben frissülnek, ahogy a valódi látogatások megérkeznek, ezért a korai eredményeket laboradatok alapján ítéld meg.

Gyakori hibák

• Csak gyors laptopon tesztelni. A látogatóid közepes telefonokon és gyenge mobilnetről jönnek. Teszteld mobil módban.
• A tökéletes 100 pontra hajtani. A laborpontszám csak útmutató. Ha a Core Web Vitals a jó tartományban van, a tartalom és a használhatóság fontosabb, mint az utolsó pár pont.
• Mindent lazy betölteni, a főképet is. Ez rontja az LCP-t.
• Sebességnövelő bővítményt vagy könyvtárat rakni még egy fölé. A súly eltávolítása szinte mindig jobb, mint további kódot adni a kezeléséhez.
• A previewt optimalizálni, nem az élő oldalt. A fejlesztői előnézetek optimalizálatlan buildeket futtatnak. A közzétett URL-t mérd.
• Egyszer gyorsítani. Minden új widget, kép és funkció súlyt ad hozzá. Nagyobb változások után teszteld újra.

Sebességi ellenőrzőlista

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 mobilon
• A képek átméretezve, tömörítve, modern formátumban, width és height értékkel
• A főkép nincs lazy betöltve; a redőn alatti képek lazy betöltésűek
• Nincsenek nem használt JavaScript-könyvtárak; a nehéz útvonalak külön vannak bontva
• Két betűcsalád vagy kevesebb, a fő betűtípus előtöltve
• Csak a ténylegesen használt harmadik féltől származó scriptek, későn betöltve
• A nyilvános oldalak előrenderelve vagy statikusak, ahol lehet
• Közzététel után újratesztelve az élő URL-en

A sebesség és a mobil elrendezés összefügg; lásd: hogyan tegyél weboldalt mobilbarátté. Az indulás előtti teljes átvizsgáláshoz a hogyan vidd az AI-prototípust éles termékké útmutató ad segítséget.

Sebesség a Mythexen

A Mythexen ezeket a változtatásokat chatben kéred, Pro csomagban pedig a kódszerkesztőben végzed el. Az élő URL-t ellenőrizd, ne az előnézetet, mert az előnézet fejlesztői szervert futtat. A statikus frontendek közzétételkor statikus oldalként települnek (statikus weboldalak), ami a tartalmi oldalaknak jó. A szerveres appok nullára skálázódnak: tétlenség idején alszanak, és a következő látogatásra ébrednek, így egy csendes időszak utáni első kérés lassabb, a csatolt adatbázis pedig 5 perc tétlenség után alszik (tárhely-korlátok). Ha egy nyilvános oldal csak az első látogatáskor lassú, ez a valószínű ok. A marketingoldalak statikusan tartása segít. Változtatások után tedd közzé újra, és frissíts kemény újratöltéssel.

Kérdések