Mi az az adatvezérelt marketing?
Az adatvezérelt marketing egy korszakot jelez, melybe az online marketing révén elérhető..
Az elmúlt hónapokban elég sokat olvashattál nálunk is a webes vitals mutatókról, és ennek kapcsán gyakran felmerült a Lighthouse, mint mérőeszköz. A Lighthouse segítségével ugyanis pontosan meg tudod állapítani, hogy mi a gond a weboldaladdal és hogyan tudod optimalizálni a sebességét. Elmondjuk, hogyan tedd, mit olvashatsz ki az egyes mérőszámokból. (Frissítve, 2023.02.28. – Egy új fejezettel bővítettünk: Eltávolítja a Google a TTI-mutatót a Lighthouse-ból)
A teljesítmény a weboldalaknál azt jelenti, hogy milyen gyorsan képes megmutatni egy böngésző a weboldalt a felhasználónak. A Lighthouse a Chromiumot használja böngészőként arra, hogy felépítse a weboldalakat és futtassa a teszteket. A Chromium projekt 2020 május 5-én jelentett be három olyan mérőszámot, melyekkel a Google által támogatott nyílt forráskódú böngésző teljesítményt tud mérni. Ezek voltak a webes vitals mutatók, melyek célja, hogy felhasználó-központú módon mérjék a weboldalak teljesítményét. Hamarosan a Chrome DevTools Audits panelt átnevezték Lighthouse-ra, illetve a Pagespeed Insigths és a Search Console is ezekre a mérőszámokra kezdett hivatkozni.
A Lighthouse ugyanakkor némileg különbözik a webes vitals mutatóktól. Természetesen a webes vitals mutatók három mérőszáma szerepel a Lighthouse-ban, azonban ezek (a legnagyobb vizuális tartalomválasz, az első vizuális tartalomválasz és az interaktivitásig eltelt idő, vagyis a total blocking time, illetve az elrendezés összmozgása) csak 70 százalékát teszik ki a Lighthouse által mutatott teljesítmény-pontszámnak.
Amit még fontos tudni, hogy a Lighthouse által mutatott eredmények úgynevezett emulált tesztek révén keletkeznek. Valós felhasználók esetében egy weboldal sebességét viszont olyan tényezők is meghatározzák, mint a hálózat sebessége, az eszköz teljesítménye, illetve a felhasználó távolsága a weboldalt kiszolgáló szervertől. A Lighthouse adatai ezeket nem veszik figyelembe. Ehelyett egy középkategóriás eszközt szimulálva próbálja bemutatni, hogy mivel szembesül egy átlagos felhasználó a weboldalad esetében.
Ezek tehát úgynevezett laboratóriumi tesztek egy ellenőrzött környezetben, előre meghatározott eszközökkel és hálózati beállításokkal, melyek segítenek abban, hogy a teljesítményproblémákat meghatározzuk egy weboldalnál. Ami persze nem azt jelenti, hogy minden valós felhasználó ezekkel a problémákkal találkozik.
Utóbbi miatt persze nem kell lemondani a Lighthouse-ról, csak először érdemes megvizsgálni a Chrome Felhasználói Élmény Jelentést (CrUX), majd aztán a Lighthouse kibővített tesztelési lehetőségeit a problémát okozó kódok megtalálásához. Ráadásul, ha a weboldal még nem került publikálásra, akkor a Lighthouse pont alkalmas lesz annak tesztelésére.
A Lighthouse 9-es verziója 7 mérőszámot tartalmaz, melyek mind részei az összteljesítménynek. Azt, hogy ezek a mérőszámok milyen súlyúak az összteljesítményt tekintve, folyamatosan változik, így a 6-os és 7-es verzióban még más súlyozással találkozhattunk, mint a 8-as és 9-esben.
Sokakban felmerülhet kérdésként, hogy szinte minden egyes mérésnél más és más pontszámot mutat számukra a Lighthouse, ami némi bizonytalanságot kelthet a mérés megbízhatóságát illetően. Ez azonban nem hiba, a pontos eredményeket olyan tényezők befolyásolják még az emulált teszteknél is, mint a böngészőbővítmények (érdemes inkognitó módban, bővítmények nélkül tesztelni), az internetkapcsolat, vagy akár egy hirdetés megjelenése az adott oldalon.
Az itt felsorolt mutatók egy részét, már a webes vitals mutatókról szóló anyagunkban átvettük, azonban most is átfutjuk őket, ráadásul lesz még 3, melyek ott nem szerepeltek.
Az LCP részei lehetnek a szövegek, a képek, háttérképek, videók a weboldalon. Érdemes tudni, hogy aloldalanként változik az érték, így több oldal esetében is meg kell nézni, hogy mit mutat. Rossz LCP-t okozhat
Ezek alapján a javításhoz egyrészt szükség lehet a szerver optimalizálására, CDN használatára, gyorsítótárazásra, a külső kapcsolatok miné korábbi létrehozása. Ha a JavaScript és a CSS okozza a gondot, akkor a CSS és a JavaScript csökkentése és tömörítése, a nem fontos CSS-ek és JavaScriptek halasztása a megoldás. Ha az ok az erőforrás betöltési ideje, akkor a képek optimalizálására és tömörítésére van szükség, a fontos erőforrások előtöltésére, a szövegek tömörítésére, a hálózati kapcsolat alapján akár eltérő megjelenítésre. Ha pedig a kliens-oldali megjelenítéssel van gond, akkor csökkenteni kell a fontos JavaScriptet és egy másik renderelési megoldást használni.
A TBT tehát a hosszú feladatokat méri, azokat, amelyek 50 ms-nél tovább tartanak. Amikor a böngésző betölti az oldalad, akkor szkriptek sora vár a végrehajtásra. Bármilyen bevitel a felhasználó részéről ugyanebbe a sorba kerül. Amikor a böngésző nem válaszol a felhasználó jelzésére, mert éppen más feladatokat hajt végre, akkor ezt a felhasználó késésként érzékeli.
A túlságosan magas TBT értéket valamilyen nehéz JavaScript okozza. Ezeket a túl hosszú feladatokat érdemes feldarabolni, és csökkenteni a JavaScript végrehajtási idejét.
Minden, ami az első megjelenő elem előtt történik, beleszámít az FCP-be, kivéve az iframe-ek. Ahhoz, hogy a tartalom a felhasználó számára megjelenjen, a böngészőnek be kell töltenie, elemeznie, és fel kell dolgoznia minden külső stíluslapot, mellyel találkozik. Ezért meg kell keresni azokat a CSS-eket, melyeket nem használ a weboldal.
A sebességindex értéke a kritikus megjelenítési útvonalat tükrözi. A kritikus itt azt jelenti, hogy az adott forrás szükséges az első tartalom megjelenítéséhez vagy pedig az oldal fő funkciójához tartozik. Minél hosszabb és sűrűbb az út, annál lassabban jeleníti meg a weboldalad a vizuális elemeket.
A javításához minimalizálni kell a fő szálon végzett munkát, csökkenteni a JavaScript végrehajtási idejét, mérsékelni a kritikus kérések mélységét, eltávolítani a megjelenést blokkoló forrásokat és a kijelzőn nem megjelenő képek betöltését halasztani.
Olyan elemek okoznak mozgást, mint a méret nélküli képek, reklámok, beágyazások, iframe-ek szintén méretek nélkül, a dinamikus tartalmak, webes fontok, és olyan műveletek, melyek a DOM frissítése előtt hálózati válaszra várnak.
Egy oldal egyébként akkor számít teljesen interaktívnak, amikor megjelenik a tartalom (amit az első vizuális tartalomválasz mér), az eseménykezelők regisztrálva vannak a legtöbb látható oldalelemhez, és az oldal a felhasználói interakcióra 50 milliszekundumon belül válaszol.
A Google Chrome 2023 februárjában egy jelentős változást jelentett be a Lighthouse-zal kapcsolatban: a 10-es verzióban már nem szerepel a Time to Interactive, azaz TTI elnevezésű mérőszám. Ez olyan szempontból jó hír is lehet, hogy a legtöbb weboldal az eltávolítás hatására némi javulást fog tapasztalni a teljesítmény-számait illetően.
Mint azt az előző fejezetben már kifejtettük, a TTI-vel azt méri a Lighthouse, hogy a felhasználók számára mennyi idő elteltével válik interaktívvá a weboldal, vagyis mikor fog tudni kattintani vagy a navigációt használni a felhasználó.
A Google ugyanakkor úgy ítélte meg, hogy más mérőszámok, mint az LCP, a sebességindex vagy a TBT együttesen már elég jól kifejezik azt, hogy egy weboldal mikor néz ki betöltöttnek. Mint bejelentésükben írják: az LCP és a sebességindex jobb heurisztikát jelent, mint az aktív hálózati lekérések száma. Emellett a TBT jobban korrelál a webes vitals mutatókkal.
A több mint 13 millió weboldalon végzett teszt azt jelezte, hogy a weboldalak 90 százalékánál jelentkezik javulás a pontszámban, és a weboldalak 50 százaléka 5 pontnál nagyobb változást tapasztal.
A TTI súlya már a Lighthouse 8 óta csökkent, ami lehetővé tette, hogy eközben más mérőszámok súlya növekedjen. Erre azért került sor, mert javult a weboldalsebesség felhasználói élmény mutatóinak pontossága, valamint, hogy arra ösztökéljék a weboldalakat, hogy a JavaScriptek csökkentésére összpontosítsanak, ezek ugyanis egyre nagyobbak lettek.
A változás már elérhető a PageSpeed Insightsban, illetve a Chrome tesztverziója, a Canary már a Lighthouse 10 új verzióját használja. Egyébként a 10-es verzió a Chrome 112-ben jelenik meg, mely 2023. március 29-én élesedik.
Amit fontos tudni, hogy a Lighthouse egyetlen oldalt mér egyszerre. Egyetlen oldal viszont nem mutatja meg a teljes weboldalad teljesítményét. Tehát az, hogy mondjuk a főoldalad gyors, nem jelenti azt, hogy a weboldalad többi oldala is az.
A weboldaladon belül ezért több oldalt is tesztelni kell. Ehhez meg kellene határozni a fő oldaltípusokat a weboldaladon, illetve ezek arányát a számukat tekintve egymáshoz képest, és ugyanilyen arányban kellene tesztelned is ezeket a Lighthouse-zal, mielőtt nekiállnál optimalizálni.
Miután elkezdted a teszteket a legfontosabb oldalaidon és a megfelelő arányú mintaoldalakon, az eredményeket és a megoldások listáját jegyezd fel. Kényelmesebbé teszi az áttekintést, ha a Lighthouse Viewert is használod. Az eredményeket különböző formátumban el is mentheted a jelentés jobb felső sarkában található, három ponttal jelzett eszköz menüből.
A Webshark.hu a hozzászólásoknál előzetes moderálást alkalmaz. Moderálási szabályaink itt olvashatók.