A landing oldal sebesség javítását a céloldal mobilos mérésével kezdd. A fő tartalom megjelenése, a kattintásokra adott reakció és az elrendezés stabilitása külön feladat. A PageSpeed Insights és a GTmetrix segít megtalálni a szűk keresztmetszetet; utána a képeken, betűkön vagy kódon változtass célzottan. A javítást azonos tesztfeltételekkel és működő űrlappal ellenőrizd, mert a jobb pontszám önmagában nem hoz több vevőt.
Tartalomjegyzék
- Mennyi idő alatt kell betöltenie egy landing oldalnak?
- Hogyan mérd meg a landing oldal sebességét?
- Így legyen a jelentésből használható feladatlista:
- Mit mutat a PageSpeed, és mit a GTmetrix?
- Mi az a 6 elem, ami visszafoghatja a landinget?
- 1. Nagy nyitókép: milyen méretet érdemes használni?
- 2. Betűkészletek: melyik változatot töltsd be?
- 3. Oldalépítő: mi töltődik be a látvány mögött?
- 4. Videó: mikor induljon a lejátszó betöltése?
- 5. Chat és mérőkód: melyiknek van valódi feladata?
- 6. Slider: szükség van a forgó nyitóképernyőre?
- Miben segít a WP Rocket?
- Hogyan ellenőrizd, hogy a gyorsítás tényleg használt?
- Gyakori kérdések a sebességmérésről
- Miért térhet el a látogatói adat a laborteszt eredményétől?
- Miért változik a PageSpeed-pontszám újrafuttatáskor?
- Miért nincs a landinghez valós látogatói adat?
- Miért más a GTmetrix és a PageSpeed pontszáma?
- Minden GTmetrix-figyelmeztetést ki kell javítani?
- Meddig maradnak meg a GTmetrix-jelentések?
Mennyi idő alatt kell betöltenie egy landing oldalnak?
A fő tartalom megjelenésénél 2,5 másodperc vagy kevesebb LCP-érték a jó tartomány. Ez nem a teljes oldal összes fájljának letöltési ideje, és nem olyan határ, amelynél minden látogató egyszerre feláll és kivonul. A Core Web Vitals küszöbértékei a betöltés mellett a reakciókészséget és a vizuális stabilitást is értékelik.
Képzeld el ezt a helyzetet: valaki a buszon keres időpontot egy gyógytornászhoz. Megjelenik a címsor, megnyomja az időpontkérő gombot, majd az oldal odébb ugrik, mert közben befutott egy kép. Máris mást érintett meg. Hiába volt gyors a legelső felirat, a foglalási élmény még döcögött.
Ezért nézz rá mindhárom mutatóra:
Görgesd oldalra az ujjaddal a táblázatot! ⟷
| Mutató | Mit mutat? | Jó | Javítandó | Gyenge |
|---|---|---|---|---|
| LCP | Fő tartalom megjelenése | ≤ 2,5 s | > 2,5 s és ≤ 4 s | > 4 s |
| INP | Reakció az interakcióra | ≤ 200 ms | > 200 ms és ≤ 500 ms | > 500 ms |
| CLS | Váratlan elrendezésváltozás | ≤ 0,1 | > 0,1 és ≤ 0,25 | > 0,25 |
A jó értékeket a mért látogatások legalább 75%-ánál kell elérni, mindhárom mutatónál külön-külön. Az LCP-nél ez például azt jelenti: 100 mért látogatásból legalább 75-ben legfeljebb 2,5 másodperc alatt jelenjen meg a legnagyobb kép vagy szövegblokk. Mobilon és asztali gépen ugyanazok a határok, de a két eszközcsoport eredményét külön vizsgálják. A CLS az elrendezés elmozdulását jelzi, nem másodpercben mért időt.
- Az LCP azt jelzi, mikor jelenik meg a képernyő legnagyobb releváns képe vagy szövegblokkja.
- Az INP a kattintások, érintések és billentyűműveletek után következő vizuális válasz késését méri.
- A CLS a váratlan elrendezésváltozásokat összesíti.
Egy gyorsnak látszó oldal is lehet nehézkesen kezelhető.
Üzleti szempontból a cél: olvasható és használható nyitóképernyő, majd akadálymentes út a jelentkezésig. A gyorsulás értékes technikai javulás, de a vevőszerzéshez az ajánlatnak és a döntési útvonalnak is működnie kell. Ezt a különbséget a landing oldal konverziós arányáról szóló cikkben bontom ki részletesebben.
Hogyan mérd meg a landing oldal sebességét?
A hirdetés tényleges céloldalát mérd, először mobilon, majd asztali gépen. A főoldal szép eredménye nem igazolja a kampányoldal teljesítményét, ha ott más képek és funkciók töltődnek be.
Én Google PageSpeed Insightsot és GTmetrixet használok, és az ott kapott iránymutatásokat követem. Külön megnézem azt is, hogy WebP vagy AVIF képek legyenek, a tényleges megjelenéshez igazított felbontással. WordPress-oldalaknál WP Rocketet is használok. A konkrét javítás azonban mindig attól függ, mit mutat az adott oldal vizsgálata.
Így legyen a jelentésből használható feladatlista:
- Másold be a pontos URL-t a PageSpeed Insightsba. Ha a hirdetés paraméterezett címre visz, ellenőrizd azt a változatot is: ugyanazt a tartalmat kapod-e, és nincs-e köztes átirányítás?
- Kezdd a mobilos eredménnyel. Nyisd meg a valódi oldalt telefonon is. A laptopod gyors kapcsolata nem mutatja meg, milyen érzés egy szerényebb készüléken megnyomni az első gombot.
- Válaszd külön a látogatói adatot a Lighthouse-teszttől. A felső CrUX-rész valós Chrome-látogatásokból készül, az alsó diagnosztika egy szimulált betöltést vizsgál. Más kérdésre válaszolnak.
- Ellenőrizd az adatok hatókörét. A konkrét URL adatait látod, vagy az egész webhely eredményét? A webhelyszintű adat hasznos háttér, de nem kizárólag a landinget írja le. Ha nincs elég adat, attól még nem bizonyítottan jó vagy rossz az oldal.
- Azonosítsd a lassú elemet. A diagnosztikában keresd meg, melyik kép vagy szöveg az LCP-elem, és mi késlelteti. Ha a kattintás döcög, a böngészőben futó feladatokat vizsgáld, ne automatikusan a képet tömörítsd tovább.
- Egészítsd ki GTmetrix-vizsgálattal. A betöltési sorrendet mutató Waterfall segíthet észrevenni egy későn induló képkérést vagy külső szolgáltatást. A választott helyszínt és tesztbeállítást rögzítsd; az elérhető lehetőségek a csomagtól is függnek.
- Mentsd el a kiinduló jelentést. Legyen meg a dátum, az URL és a tesztkörnyezet. A képernyőkép mellé írd oda a beállításokat is, mert később ebből lesz összehasonlítható előtte–utána eredmény.
A PageSpeed Insights működési leírása segít a két adatrész értelmezésében. A GTmetrix-jelentésben pedig a legnagyobb várható hatású problémákra érdemes először figyelni, nem az összes figyelmeztetést egyformán sürgősnek tekinteni.
Válassz egy konkrét hipotézist: „A nyitókép későn indul, mert csak egy később betöltődő stíluslapból derül ki a címe.” Ebből már következhet javítás és ellenőrzés. Az „oldal lassú, kapcsoljunk be még valamit” nem mondja meg, mitől vársz változást.
Mit mutat a PageSpeed, és mit a GTmetrix?
A PageSpeed Insights látogatói adatot és labortesztet is ad; a GTmetrix kontrollált környezetben végzett vizsgálattal és részletes betöltési jelentéssel támogatja a hibakeresést. Pontszámaik nem közös mérőszalagot jelentenek.
A laborteszt előnye, hogy egy változtatás után rögtön újrafuttatható. Megnézheted, javult-e az adott kép megjelenése az adott feltételek között. A valós látogatói adat viszont olyan készülékeket és használati helyzeteket is lefed, amelyek a tesztedben nem szerepeltek. A labor- és látogatói mérés különbsége ezért nem technikai szőrszálhasogatás: ettől függ, mit állíthatsz az eredményből.
Két kiegészítő fogalommal is találkozhatsz:
- A TTFB a válasz kezdetét méri: az oldalbetöltés kezdetétől az első válaszbájt megérkezéséig eltelt időt. A TTFB leírása alapján a kapcsolódás és az átirányítások is befolyásolhatják, ezért nem kizárólag a szerver munkáját jelzi.
- A TBT laborbeli jelzőszám: az első tartalommegjelenés után a hosszú feladatok blokkoló idejét összegzi. A TBT magyarázata segít az értelmezésében; interakciós problémák keresésére használható, de nem azonos az INP-vel.
A Web Vitals mérési útmutatója külön kezeli a valós interakciókat és a laborban mérhető jelzéseket. Ha egy űrlap csak kitöltéskor válik nehézkessé, a betöltési teszt önmagában nem fogja végigjátszani helyetted az összes mezőt.
A pontszám hasznos visszajelzés, de egy döntéshez azt is mondd meg, melyik mutató és miért javult. Egy zöld karika mellett eltűnő jelentkezési gomb nem siker. A pontszám önmagában nem ellenőrzi a foglalást vagy az elküldött adatokat. Szép bizonyítványt kaptál, csak a pénztár ajtaját falaztad be közben. Ezt a csereüzletet inkább hagyjuk.
Mi az a 6 elem, ami visszafoghatja a landinget?
Gyakori vizsgálati pont a nyitókép, a betűkészlet, az oldalépítő elemei, a videó, a külső kód és a slider. Ezek lehetséges okok; mérés alapján válassz közülük. Ha például a szerver válaszára megy el az idő, egy kisebb sliderkép nem fogja ezt a várakozást megszüntetni.
1. Nagy nyitókép: milyen méretet érdemes használni?
Használj megjelenéshez igazított képméretet, megfelelő tömörítéssel és korszerű formátummal. A WebP vagy AVIF jó kiindulópont lehet, de egy óriási felbontású kép új fájlkiterjesztéssel is maradhat szükségtelenül nehéz.
Különítsd el a pixelméretet és a fájlméretet. Az előbbi a kép szélessége és magassága, az utóbbi a letöltendő adatmennyiség. A cél nem a lehető legkisebb kép mindenáron, hanem elég részlet a megjelenési mérethez, vállalható letöltéssel.
Nagy pixelsűrűségű kijelzőn egy kép indokoltan lehet több képpont széles, mint a képernyőn elfoglalt CSS-mérete. A reszponzív képkiszolgálás megfelelő méretváltozatokat tud kínálni. Ellenőrizd, melyik fájlt tölti le ténylegesen a mobil, ne csak az adminban látható eredetit nézd.
Ha a nyitókép az LCP-elem, legyen korán felfedezhető képkérés. A Google LCP-optimalizálási útmutatója szerint az LCP-képet nem szabad lustán betölteni. Az oldal alján lévő galériánál a lazy loading hasznos lehet; a fő tartalomnál ugyanaz a késleltetés ronthat az eredményen.
A preload vagy a magas betöltési prioritás akkor indokolt, ha valóban egy fontos erőforrás késői indulását javítja. Ha mindent sürgősnek jelölsz, megint versenyezni fognak egymással. Először azonosítsd a kulcsképet, utána válassz beavatkozást.
2. Betűkészletek: melyik változatot töltsd be?
Csak a használt betűváltozatokat töltsd be, és legyen olvasható helyettesítő betű a letöltés idejére. Minden indokolatlan család vagy súly újabb erőforrás lehet, miközben a látogató még az ajánlatod első mondatát keresné.
Egy hipotetikus nyelviskolai jelentkezési oldalon például aligha kell külön betűtípus minden szekcióhoz. A következetes tipográfia kevesebb fájllal is lehet karakteres. A márkához szükséges változatokat tartsd meg, a véletlenül örökölt készleteket vizsgáld felül.
A betűbetöltés technikai útmutatója a méret, a kiszolgálás és a megjelenítés együtt kezelését javasolja. A WOFF2 és a szükséges karakterekre szűkítés csökkentheti a letöltést. Magyar szövegnél az ő és ű is kell: a gyorsnak látszó, hiányos készlet nem jó csere.
Figyelj a stabil betűcserére is. Ha az ideiglenes betű és a végleges készlet mérete erősen eltér, a szöveg átrendeződhet. A szükséges nyitóképernyős font előtöltése megfontolható, de minden változat előtöltése elveheti az erőforrást a fő tartalomtól.
3. Oldalépítő: mi töltődik be a látvány mögött?
Keresd a felesleges kódot, ne az oldalépítő nevét tekintsd diagnózisnak. Egy Elementorral készített landing teljesítményét is a konkrét megvalósítás határozza meg: milyen modulokat használ, és ezek milyen feladatokat indítanak.
A böngésző nemcsak letölti a fájlokat, hanem felépíti és kirajzolja az oldalt. Az egymásba ágyazott elemek, az animációk és a sok futó JavaScript növelhetik ezt a munkát. A reakcióidő javításáról szóló útmutató ezért a hosszú böngészőfeladatok csökkentését is tárgyalja.
Gyakorlati vizsgálatkor nézd meg:
- Melyik modul szükséges ténylegesen? A fölösleges kiegészítőt vizsgáld felül, ha csak egy egyszerű címsor megjelenítéséhez tartod fenn.
- Betöltődik-e a rejtett tartalom? Egy mobilon eltakart asztali szekció kódja és képei ettől még megérkezhetnek. A tényleges hálózati kéréseket ellenőrizd.
- Van-e egyszerűbb, azonos értékű megoldás? Tartsd meg az üzenetet egy könnyebb elrendezéssel, ha az animáció nem ad szükséges információt.
A cserét tesztkörnyezetben végezd, és ellenőrizd a megjelenést. A lényeg a böngésző felesleges munkájának csökkentése; egy konkrét fájl eltávolításánál előbb értsd meg, melyik funkció függ tőle.
4. Videó: mikor induljon a lejátszó betöltése?
Egy ajánlatot magyarázó videónál gyakran jó megoldás a kattintásra induló lejátszó: először könnyű előnézeti kép látszik, a nehezebb beágyazás az érdeklődés jelzésére érkezik. A videóteljesítmény útmutatója is tárgyalja ezt a megközelítést.
Egy hipotetikus kutyakiképzési oldal bemutatója lehet hasznos bizonyíték. Ettől még nem kell az első pillanatban elindítani a teljes videóplatform letöltését annak is, aki rögtön az időpontokhoz görgetne. A videó értékét tartsd meg, a betöltési időpontját igazítsd a szerepéhez.
Az előnézeti kép is legyen optimalizált, a videóhely pedig kapjon előre lefoglalt méretet. Ha a kép maga a fő tartalom része, annak betöltését is ennek megfelelően kezeld. Az automatikusan játszó háttérvideó külön mérlegelést igényel: itt a lejátszás már a nyitóélmény része.
Teszteld a lejátszást érintés után is. A gyors első képernyő nem elég, ha a kattintásra előbújó lejátszó hibás, nincs hangvezérlés, vagy mobilon kitakarja a jelentkezési lehetőséget.
5. Chat és mérőkód: melyiknek van valódi feladata?
Távolítsd el a duplikált kódot, és a feladat nélküli elemeket is vizsgáld felül. A chat, az analitika és a hirdetési pixel más-más üzleti feladatot láthat el, ezért nem jó stratégia minden külső szolgáltatást lekapcsolni egy szebb teszteredmény kedvéért.
Készíts rövid leltárt: mi tölti be a szolgáltatást, melyik oldalon szükséges, és milyen eredményt vagy funkciót ad? Ugyanazt a pixelt például egy bővítmény és a címkekezelő is beillesztheti. Ilyenkor a felesleges terhelés mellett a mérés megbízhatóságát is vizsgálni kell.
A külső JavaScript betöltésének útmutatója a hálózati és böngészőbeli költség ellenőrzését hangsúlyozza. Egy késleltetett kód kevesebb munkát végezhet a kezdeti betöltéskor, de később, akár éppen az első érintésnél indulhat el.
Ezért a késleltetés mellé működési és mérési ellenőrzés is kell. Vizsgáld meg a fontos eseményeket a tényleges hozzájárulási állapotok mellett. Ha az oldal gyorsabbnak tűnik, de a jelentkezési események eltűntek a jelentésből, nem tudod abból megállapítani, hogyan változott az eredményessége.
6. Slider: szükség van a forgó nyitóképernyőre?
Ha ugyanaz az üzenet egy álló nyitóblokkban is átadható, a statikus fő ajánlat egyszerűbb betöltési feladatot adhat. A slider több képet és vezérlést hozhat a legfontosabb képernyőre; a tényleges költség a megvalósítástól függ.
Ha megtartod, az első látható kép kapjon elsőbbséget, és foglalj le stabil helyet a teljes elemnek. A carousel-optimalizálási útmutató a képkiszolgálást és az elrendezésváltozások elkerülését is tárgyalja. A későbbi diák kezelését a választott megoldás szerint kell ellenőrizni.
Ne tölts előre minden nagy képet csak azért, mert egyszer talán sorra kerülnek. Ugyanakkor egy későbbi dia megjelenése se legyen üres vagy ugráló. Itt is a használható állapot számít, nem az, hogy hány képnek sikerült elrejteni a letöltését a kezdeti tesztben.
A slider elhagyását külön tartalmi döntésként kezeld: mit lát helyette az olvasó, és megmarad-e a szükséges információ? Ha a nagyobb cél a teljes döntési út javítása, a meglévő landing optimalizálásának lépései segítenek a sebességet a többi feladathoz képest elhelyezni.
Miben segít a WP Rocket?
A WP Rocket WordPressben többek között a gyorsítótárazás és a fájlbetöltés kezelésében segít. A mért problémára célozz a beállítással, és utána ellenőrizd a funkciókat. Nem minden landingnek ugyanaz a kapcsolóállás lesz megfelelő.
A gyorsítótár, vagy cache, egy már elkészített oldalváltozat kiszolgálásával csökkentheti az ismételt szerveroldali munkát. Ha a fő késés a kiszolgálásban van, ez fontos vizsgálati irány. Egy szükségtelenül nagy kép letöltési költségét viszont a cache önmagában nem szünteti meg.
A JavaScript-végrehajtás késleltetése a WP Rocketben interakcióig halasztja az érintett kódot. Ez mérsékelheti a kezdeti terhelést, de egyes funkciókhoz kivétel szükséges. A halasztott betöltés dokumentációja is jelzi: a működőképesség miatt bizonyos fájlokat ki kellhet venni az optimalizálásból.
Mindig a konkrét függőséget teszteld. Egy űrlap, egy felugró ablak vagy a menü működése támaszkodhat arra a kódra, amelyet éppen késleltetnél. A kivételt a hibás funkcióhoz kösd; a komplett optimalizálás kikapcsolása legfeljebb a hiba behatárolásának átmeneti lépése legyen.
Külön cikkben írtam a WP Rocket javasolt beállításairól. A régebbi útmutató menüpontjait az aktuális verzióhoz kell igazítani. Itt a mérési és döntési sorrend a lényeg: ne pipáld végig automatikusan az összes funkciót, hanem igazold, melyik változtatás mire volt jó.
Hogyan ellenőrizd, hogy a gyorsítás tényleg használt?
Azonos feltételekkel mérj újra, és járd végig a fontos felhasználói műveleteket. Egy eredmény akkor értékelhető, ha tudod, mi változott az oldalon és mi változott a tesztben.
Javasolt ellenőrzési sorrend:
- Dokumentáld az egyetlen javításcsoportot. Írd le, melyik képet vagy beállítást változtattad. Ha egyszerre mindenhez hozzányúlsz, nehezebb megmondani, melyik beavatkozás okozta a javulást vagy a hibát.
- Egyeztesd a tesztkörnyezetet. Maradjon azonos az eszközprofil, a hálózati beállítás és a tesztelési hely. A cache állapotát is rögzítsd; a frissen ürített és az előkészített gyorsítótár eltérő helyzet.
- Ismételd meg a laborvizsgálatot. Gyakorlati kiindulópontként fuss neki 3 alkalommal, és nézd meg a középső eredményt is. Ez csökkenti egy szélsőséges futás súlyát, de nem lesz tőle teljes látogatói kutatás.
- Próbáld ki a teljes jelentkezést. Ellenőrizd a gombot, a mezőhibákat és a sikeres elküldés visszajelzését. A telefonos linket és a videót is használd, ha szerepet kapnak az oldalon.
- Ellenőrizd a valós látogatói trendet. A CrUX gördülő 28 napos adatablakában a javítás előtti látogatások még benne maradnak. A friss laborteszt és a történeti adat nem fog azonnal ugyanarra váltani.
- Őrizd meg az összehasonlítást. Mentsd a jelentéseket a beállításokkal együtt. A későbbi „sokkal jobb lett” mellé így megmarad a mutató, az időszak és a mérési alap is.
Ha nincs korábbi mérésed, a mostani állapotból készíthetsz kiinduló jelentést. Egy régi állapot javulását azonban nem tudod visszamenőleg kiszámolni pusztán az emlékeidből. A dokumentált jelenlegi eredmény hasznos; a kitalált előtte–utána szám csak jól hangzó díszlet lenne.
Saját eredményesetet ebben a cikkben nem mutatok be, mert nincs hozzá visszaellenőrizhető előtte–utána tesztanyag. A fenti szolgáltatói jelenetek szemléltető, hipotetikus példák, nem ügyféltörténetek.
A gyorsítás akkor tekinthető sikeres technikai változtatásnak, ha a mérés javul, és a látogató továbbra is végig tudja vinni a fontos műveletet.
Ha azt szeretnéd megállapítani, lett-e több jelentkező, ahhoz külön üzleti mérés kell, összevethető forgalommal és működő eseménykövetéssel. A gyorsabb betöltés kedvező feltétel, de nem választja le magáról az ajánlat, a célzás vagy a szezon hatását.
Szívesen olvasnál még hasonlókról? Rendszeresen megjelenő hírleveleimben ilyen és egyéb, vállalkozással, online marketinggel, web-/landing oldal készítéssel kapcsolatos fontos tudnivalókat osztok meg. Ha szeretnéd kimaxolni a vállalkozásodban lévő potenciált, akkor iratkozz fel ezekre a hasznos levelekre itt! 👇
Gyakori kérdések a sebességmérésről
Miért térhet el a látogatói adat a laborteszt eredményétől?
A látogatói adat sokféle valódi használatot összesít, a labor pedig egy meghatározott környezetet vizsgál. Az eltérés önmagában nem hiba. A labor- és látogatói adatok magyarázata alapján nézd meg, milyen készülék, kapcsolat és használati művelet marad ki a tesztből.
Miért változik a PageSpeed-pontszám újrafuttatáskor?
A tesztkörülmények változhatnak, és a szerver vagy külső szolgáltatások válaszideje sem mindig azonos. A PageSpeed gyakori kérdései ezért is tárgyalják az ingadozást. Több azonos beállítású futásból értékelj, és az egyes mutatókat is nézd meg.
Miért nincs a landinghez valós látogatói adat?
Lehet, hogy nincs elegendő mérési adat az adott URL-ről. Ez nem minősítés. Ellenőrizd, hogy a PageSpeed webhelyszintű adatot mutat-e helyette; a labordiagnosztikával közben megkezdhető a hibakeresés. Az adat rendelkezésre állását a PageSpeed leírása részletezi.
Miért más a GTmetrix és a PageSpeed pontszáma?
A tesztkörnyezet eltérései is okozhatják a különbséget. A két eredményt ne állítsd be ugyanazon mérés előtte–utána párjának. A GTmetrix eszköz-összehasonlító magyarázata a környezet, a helyszín és a számítás különbségeit is bemutatja.
Minden GTmetrix-figyelmeztetést ki kell javítani?
A várható hatás alapján rangsorolj, és vedd figyelembe az oldal feladatát. A GTmetrix GYIK-je sem kér minden javaslat mechanikus teljesítését. A szükséges funkciók működése és a valós használhatóság fontosabb, mint a 100-as szám hajszolása.
Meddig maradnak meg a GTmetrix-jelentések?
A megőrzés az előfizetési csomagtól függ; a lejárt megőrzési idő után a jelentés törlődhet. A GTmetrix jelentésmegőrzési tájékoztatója alapján ellenőrizd a fiókod feltételeit, és a fontos összehasonlítást saját példányban is őrizd meg.
Új landinget tervezel, vagy teljesen új alapokra helyeznéd a meglévőt? Tervezd együtt a döntési utat és a technikai működést. Nézd meg a landing oldal készítés szolgáltatásomat, majd az ottani űrlapon írd le az ajánlatodat és azt, milyen jelentkezést szeretnél elérni.
