Aki azt írja be a keresőbe, hogy „miért lassú a weboldalam, és ki tudja megjavítani?”, az két választ vár egyszerre. Tudni akarja, mi a baj, és tudni akarja, kinek kell szólnia. Ez a cikk mindkettőn végigvezet, sorrendben. Először megméred, mennyire lassú az oldal, utána beazonosítod az okot, és a végén eldöntöd, hogy a hibát te, a tárhelyszolgáltatód vagy egy fejlesztő tudja megszüntetni. Az állításoknál jelöljük, hogy hivatalosan igazolt információról, saját tapasztalatról vagy szakmai feltételezésről van szó.
Mit keres pontosan, aki azt kérdezi, miért lassú a weboldala?
Aki ezt kérdezi, az jellemzően cégvezető vagy az oldal gazdája, aki érzi a lassúságot, de nem tudja megnevezni az okát, és nem tudja, kinek a dolga a javítás. A kérdés mögött ritkán áll műszaki kíváncsiság. Sokkal gyakoribb, hogy valaki szólt neki, hogy az oldal telefonon sokára jön be, vagy látott egy piros számot egy sebességmérőben.
Ebből három gyakorlati kérdés következik, és a cikk ezekre felel.
- Tényleg lassú az oldal, vagy csak egy mérőeszköz ad rossz pontszámot?
- Mi okozza a lassúságot?
- Ki az, aki ezt meg tudja javítani, és mit kell tőle kérni?
Saját tapasztalat: a legtöbb félreértés abból adódik, hogy a tulajdonos a fejlesztőt hívja egy tárhelyhiba miatt, vagy a tárhelyszolgáltatónak ír egy olyan gondról, amit a sablon okoz. Ha előbb mérsz, ez a kör megspórolható.
Honnan tudod, hogy tényleg lassú a weboldalad?
Onnan tudod, hogy megméred a Google ingyenes eszközeivel, és a kapott értékeket a Core Web Vitals küszöbeihez hasonlítod. Az érzés csalóka, mert a saját gépeden a böngésző sok mindent eltárol, ezért neked az oldal gyorsabbnak tűnik, mint egy új látogatónak.
Hivatalosan igazolt: a Google három mutatót sorol a Core Web Vitals közé, és mindegyiknél megadja a jó tartományt.
- LCP (Largest Contentful Paint): mennyi idő alatt jelenik meg a legnagyobb látható elem, jellemzően a nyitókép vagy a főcím. Jó, ha legfeljebb 2,5 másodperc, gyenge, ha 4 másodperc fölött van.
- INP (Interaction to Next Paint): milyen gyorsan reagál az oldal kattintásra, koppintásra, gépelésre. Jó, ha legfeljebb 200 ezredmásodperc, gyenge, ha 500 fölött van. 2024 márciusában váltotta a korábbi FID mutatót.
- CLS (Cumulative Layout Shift): mennyit ugrál a tartalom betöltés közben. Jó, ha legfeljebb 0,1, gyenge, ha 0,25 fölött van.
A mérés lépései a következők.
- Nyisd meg a PageSpeed Insights oldalát, és írd be a kezdőlapod címét.
- Nézd meg külön a mobil és külön az asztali eredményt. A mobil számít jobban, mert a Google a mobilos változat alapján indexel.
- Ismételd meg a két legfontosabb aloldaladdal, például egy termék- vagy szolgáltatásoldallal és a kapcsolat oldallal.
- Lépj be a Search Console-ba, és nyisd meg az Alapvető webes vitals mutatók jelentését. Itt csoportosítva látod, mely oldalaid gyengék és melyik mutató miatt.
- Jegyezd fel az értékeket dátummal, hogy a javítás után legyen mihez viszonyítanod.
Mi a különbség a labor- és a mezőadat között?
A mezőadat valódi látogatók valódi eszközein mért érték, a laboradat pedig egyetlen szimulált betöltés eredménye, és a Google a mezőadatot veszi figyelembe. A PageSpeed Insights mindkettőt megmutatja, egymás alatt, és a kettő gyakran eltér.
Hivatalosan igazolt: a mezőadat a Chrome felhasználói élmény jelentéséből (CrUX) származik, az elmúlt 28 nap méréseit összesíti, és a látogatások 75. percentilisét mutatja. Ez azt jelenti, hogy a látogatásaid háromnegyedének legalább ilyen jónak kell lennie. Kis forgalmú oldalnál előfordul, hogy nincs elég mezőadat, ilyenkor csak a laboreredményre támaszkodhatsz.
A felül látható 0 és 100 közötti teljesítménypontszám laboradat. Hasznos a hibakereséshez, mert alatta ott a javaslatok listája, de önmagában nem cél. Saját tapasztalat: egy 60 pontos oldal mezőadatai lehetnek rendben, és egy 90 pontos oldal is lehet lassú a valódi látogatóknak, ha ők gyengébb telefonról és mobilnetről érkeznek.
A 28 napos ablak miatt a javítás hatása a mezőadatokban fokozatosan jelenik meg. A laboreredmény azonnal változik, a Search Console jelentése hetek alatt követi.
Mi lassítja le leggyakrabban a weboldalt?
A lassúság leggyakoribb okai a lassú szerverválasz, a túl nagy képek, a túl sok JavaScript, a külső szkriptek és a hiányzó gyorsítótár. A PageSpeed Insights diagnosztikai listája megmutatja, melyik érint téged, az alábbi bontás pedig segít értelmezni.
Lassú szerverválasz
Ha a böngésző sokat vár az első bájtra (TTFB), akkor a gond a kiszolgáló oldalon van. A web.dev iránymutatása szerint a 0,8 másodperc alatti érték számít jónak. A háttérben túlterhelt osztott tárhely, elavult PHP-verzió, hiányzó oldal-gyorsítótár vagy lassú adatbázis-lekérdezés állhat. WordPress esetén gyakori ok a rengeteg automatikusan betöltött beállítás és a háttérben futó admin-ajax hívások.
Túl nagy képek
A telefonról feltöltött, több megabájtos fotó a leggyakoribb LCP-rontó. A böngésző letölti a teljes fájlt akkor is, ha a kép a képernyőn csak 400 képpont széles. A megoldás az átméretezés, a korszerű formátum (WebP vagy AVIF) és a késleltetett betöltés a hajtás alatti képeknél.
Túl sok JavaScript és bővítmény
Minden bővítmény, csúszka, felugró ablak és oldalépítő saját szkriptet és stíluslapot tölt be, sokszor olyan oldalon is, ahol nincs rá szükség. Ez az INP értéket rontja, mert a böngésző a szkriptek futtatásával van elfoglalva, amikor a látogató már kattintana.
Külső szkriptek
Csevegőablak, hirdetési mérőkódok, térkép, beágyazott videó, közösségi fal. Ezek mind egy másik cég szerveréről érkeznek, tehát a sebességük kívül esik a te hatáskörödön. Saját tapasztalat: régebbi oldalakon gyakran találunk már nem használt szolgáltatásokhoz tartozó, bent felejtett mérőkódokat.
Betűtípusok és ugráló elrendezés
A több változatban betöltött webes betűtípus késlelteti a szöveg megjelenését. A méret nélkül megadott képek és az utólag beugró sávok a CLS értéket rontják.
Mit tudsz megjavítani te magad, fejlesztő nélkül?
A képek optimalizálását, a felesleges bővítmények kikapcsolását, a gyorsítótár bekapcsolását és a nem használt külső szkriptek eltávolítását gyakran fejlesztő nélkül is el tudod végezni. Mielőtt bármihez nyúlsz, készíts teljes biztonsági mentést, és egyszerre csak egy dolgot változtass, hogy lásd, mi hozott javulást.
- Méretezd át a képeket feltöltés előtt. Egy teljes szélességű nyitóképnél jellemzően bőven elég az 1600-1920 képpont szélesség.
- Kapcsold be a korszerű képformátumot és a késleltetett betöltést egy képoptimalizáló bővítménnyel.
- Nézd végig a bővítménylistát, és ami nincs használatban, azt kapcsold ki, majd töröld.
- Kapcsold be az oldal-gyorsítótárat. Sok tárhelyszolgáltató a saját felületén kínál ilyet, érdemes először ott keresni.
- Kérdezz rá a tárhelyednél, melyik PHP-verzió fut, és van-e frissebb támogatott változat.
- Szedd ki azokat a külső kódokat, amelyekhez tartozó szolgáltatást már nem használod.
Ha a sablonhoz is hozzáférsz, a nyitókép és a szkriptek betöltése néhány attribútummal javítható. Hivatalosan igazolt: ezek szabványos HTML-attribútumok, a web.dev dokumentációja részletesen leírja őket.
<img src="nyitokep.webp" width="1600" height="900" fetchpriority="high" alt="Leírás">
<img src="galeria-3.webp" width="800" height="600" loading="lazy" alt="Leírás">
<script src="csuszka.js" defer></script>
Az első sor a legfontosabb képet előre sorolja, a második a hajtás alatti képet csak akkor tölti be, amikor a látogató odagörget, a harmadik pedig a szkript futtatását az oldal feldolgozása utánra halasztja. A megadott szélesség és magasság a tartalom ugrálását előzi meg. A nyitóképre soha ne tegyél loading="lazy" attribútumot, mert azzal éppen az LCP-t lassítod.
Ki tudja megjavítani a lassú weboldalt?
Attól függ, hol a szűk keresztmetszet. A szerveroldali lassúság a tárhelyszolgáltató vagy a rendszergazda terepe, a sablon és a kód a fejlesztőé, a tartalom és a képek pedig a szerkesztőé. A mérési eredményed alapján így tudod eldönteni, kihez fordulj.
- Tárhelyszolgáltató vagy rendszergazda: ha a TTFB magas, ha az oldal csúcsidőben belassul, vagy ha a naplók szerint robotok terhelik a szervert. Ő tud erőforrást, PHP-verziót, szerveroldali gyorsítótárat és tartalomelosztó hálózatot (CDN) beállítani.
- Webfejlesztő: ha a diagnosztika a renderelést blokkoló erőforrásokat, a nem használt JavaScriptet, a hosszú fő szálas feladatokat vagy a lassú adatbázis-lekérdezéseket jelzi. Ez sablon- és kódszintű munka.
- Technikai SEO-val foglalkozó szakember vagy ügynökség: ha nem tudod, hol a gond, és valaki kell, aki felméri, sorrendbe teszi a teendőket, és egyeztet a tárhellyel meg a fejlesztővel.
- Te vagy a tartalomért felelős kolléga: ha a gond a feltöltött képek méretében, a beágyazott videókban vagy a túlzsúfolt oldalakban van.
Saját tapasztalat: a legtöbb lassú oldalnál több ok hat egyszerre, ezért érdemes egyetlen felelőst kijelölni, aki a teljes képet látja. Ha a korábbi fejlesztőd már nem érhető el, a munka átvehető, de előtte tisztázni kell a hozzáféréseket a tárhelyhez, a domainhez és az adminfelülethez.
Mit kérdezz attól, akire rábíznád a gyorsítást?
Azt kérdezd, mit mér, mihez nyúl, és hogyan bizonyítja az eredményt. Aki erre konkrétan felel, az jó eséllyel érti a dolgát. Az alábbi ellenőrzőlistát akár egy az egyben elküldheted.
- Milyen mérésből indul ki, és megmutatja-e a kiinduló értékeket mobilon és asztali gépen?
- A mezőadatokat (LCP, INP, CLS) vagy csak a pontszámot nézi?
- Készít-e mentést, és tesztkörnyezetben dolgozik-e, mielőtt az éles oldalhoz nyúl?
- Melyik három beavatkozástól várja a legnagyobb javulást, és miért?
- Mit tesz, ha egy módosítás elrontja az oldal megjelenését vagy egy űrlapot?
- Kapsz-e írásos összefoglalót arról, mi változott, előtte és utána mért értékekkel?
Óvatosságra int, ha valaki mérés nélkül 100 pontot vagy biztos első helyet ígér. A pontszámot trükkökkel fel lehet tornázni úgy, hogy a valódi látogató semmit nem érez belőle, a helyezés pedig sok más tényezőn is múlik.
Számít a sebesség a Google-ben és az AI-válaszmotoroknál?
Számít, de mérsékelten. A Google rangsoroló rendszerei figyelembe veszik a Core Web Vitals mutatókat, a jó oldalélmény viszont nem pótolja a releváns tartalmat. Hivatalosan igazolt: a Google Search Central dokumentációja szerint a jó Core Web Vitals értékek elérése ajánlott a keresőbeli sikerhez és a jó felhasználói élményhez, ugyanakkor nem garantál jó helyezést. Azt is leírja, hogy a gyorsan válaszoló szerveren a Googlebot több oldalt tud feltérképezni, a lassú vagy hibákat adó szerveren kevesebbet.
Saját tapasztalat: az AI-keresők robotjainak jelentős része nem futtat JavaScriptet. Ha a fő tartalmad csak szkript futása után jelenik meg, ezek a rendszerek üres vagy hiányos oldalt látnak. A szerveroldalon kiadott, gyorsan érkező HTML ezért kétszeresen hasznos.
Szakmai feltételezés: a válaszmotorok valós időben lekérő ügynökei rövid időkorláttal dolgoznak, ezért egy lassan válaszoló oldal jó eséllyel kimarad a forrásként felhasznált találatok közül. Ezt egyik szolgáltató sem dokumentálja pontos számokkal, ezért kezeld feltevésként.
A legkézzelfoghatóbb hatás az üzleti oldalon jelentkezik. A lassan betöltő oldalról a látogatók nagyobb arányban fordulnak vissza, mielőtt bármit elolvasnának, és ez a hirdetésből érkező forgalomra is igaz.
Mikor éri meg inkább újraépíteni az oldalt?
Akkor, ha a lassúság a rendszer alapjaiból fakad, vagyis a sablon, az oldalépítő és a bővítmények együttese olyan nehéz, hogy a foltozás csak részleges eredményt hoz. Erre néhány jel utal.
- A sablon évek óta nem kapott frissítést, és a gyártója már nem támogatja.
- Több oldalépítő és több tucat bővítmény rakódott egymásra az évek során.
- A gyorsítótár és a képoptimalizálás után a mobilos LCP még mindig messze van a 2,5 másodperctől.
- Minden kisebb módosítás váratlan hibát okoz máshol.
Szakmai feltételezés: ilyen helyzetben egy letisztult, könnyű sablonra épített új oldal hosszabb távon kevesebb karbantartást igényel, mint a régi folyamatos javítgatása. A döntés előtt érdemes egy részletes felmérést kérni, amely megmutatja, mennyi javulás érhető el a meglévő oldalon. Újraépítésnél figyelj arra, hogy a meglévő URL-ek megmaradjanak, vagy pontos átirányítást kapjanak, különben elveszítheted a már megszerzett keresőbeli és AI-hivatkozásokat.
Források és további olvasnivalók
- Google Search Central: Az oldalélmény értelmezése a Google Keresés találataiban
- Google Search Central: A Core Web Vitals és a Google Keresés találatai
- Google Search Central: Feltérképezési keret kezelése nagy webhelyeknél
- web.dev: Web Vitals, Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift
- web.dev: Time to First Byte és a képek optimalizálása
- Google PageSpeed Insights dokumentáció
- Chrome for Developers: Chrome User Experience Report (CrUX) és Lighthouse
- Google Search Console Súgó: Alapvető webes vitals mutatók jelentése
- WHATWG HTML szabvány: a loading, a fetchpriority és a defer attribútum
- Mérés nélkül ne nyúlj semmihez, mert a PageSpeed Insights és a Search Console megmutatja, melyik mutató rossz és melyik oldalon.
- A Google három Core Web Vitals mutatót figyel, a jó érték LCP-nél legfeljebb 2,5 másodperc, INP-nél 200 ezredmásodperc, CLS-nél 0,1.
- A lassú szerverválasz a tárhely vagy a háttérkód ügye, a lassú megjelenítés a képeké, a szkripteké és a sablone.
- A képek átméretezése, a felesleges bővítmények kikapcsolása és a gyorsítótár bekapcsolása gyakran fejlesztő nélkül is elvégezhető.
- A gyors oldal segítheti a keresőbeli és AI-válaszbeli láthatóságot, helyezést viszont önmagában nem garantál.
Gyakori kérdések
Miért lassú a weboldalam telefonon, ha számítógépen gyors?
A telefon processzora gyengébb, a mobilnet lassabb, ezért a nagy képek és a sok JavaScript ott sokkal jobban érződik. A saját gépeden ráadásul a böngésző gyorsítótára is szépíti a képet. Mérd meg a mobilos nézetet a PageSpeed Insightsban, mert a Google is a mobilos változat alapján indexel.
Elég egy gyorsítótár-bővítmény a lassú weboldal megjavításához?
Sokszor látványosan segít, főleg ha a szerverválasz lassú, de a túl nagy képeket, a felesleges szkripteket és a nehéz sablont nem oldja meg. A rosszul beállított gyorsítótár hibás megjelenítést is okozhat, ezért bekapcsolás után nézd végig az űrlapokat és a kosarat.
Honnan tudom, hogy a tárhely a hibás vagy a weboldal?
Nézd meg a szerver válaszidejét (TTFB) a PageSpeed Insights diagnosztikájában. Ha ez 0,8 másodperc fölött van akkor is, amikor egy egyszerű, kevés tartalmú oldalt mérsz, a gond jó eséllyel a tárhelynél vagy a háttérkódnál van. Ha a szerver gyorsan válaszol, de a megjelenítés lassú, a képek, a szkriptek és a sablon a ludas.
Kell 100 pontot elérnem a PageSpeed Insightsban?
Nem kell. A pontszám laboradat, hibakereséshez hasznos. A Google a valódi látogatóknál mért Core Web Vitals értékeket veszi figyelembe, ezért az a cél, hogy az LCP, az INP és a CLS a jó tartományba kerüljön.
Jobb helyezést kapok a Google-ben, ha felgyorsítom az oldalt?
Segítheti, de nem garantálja. A Google hivatalos dokumentációja szerint a Core Web Vitals része a rangsoroló rendszereknek, a relevancia és a tartalom minősége viszont többet nyom a latban. A gyorsítás biztos haszna a jobb látogatói élmény és a kevesebb visszafordulás.
Mennyi idő után látszik a javítás eredménye?
A laboreredmény a módosítás után azonnal változik. A mezőadatok az elmúlt 28 nap valódi látogatásait összesítik, ezért a Search Console jelentésében a javulás fokozatosan, hetek alatt jelenik meg.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.