Field Data (terepi adat, valós felhasználói mérés)
Ha lefuttatod a PageSpeed Insightsot, két külön blokkot látsz. A felső azt mutatja, mit tapasztaltak a látogatóid az elmúlt hetekben, az alsó azt, mit mért egy szimulált teszt most, egyetlen alkalommal. A kettő gyakran nem egyezik, és ez nem hiba: másra válaszolnak.
Field data és lab data: a különbség
| Szempont | Field data (terepi) | Lab data (labor) |
|---|---|---|
| Ki méri? | Valódi Chrome-felhasználók böngészője | Egy szimulált eszköz (Lighthouse) |
| Milyen időszak? | Az elmúlt 28 nap összesítve | Egyetlen futtatás, most |
| Mire jó? | Annak megítélésére, milyen az oldal a valóságban | Hibakeresésre, a javítás azonnali ellenőrzésére |
| Számít a Google-nél? | Igen, ez a Core Web Vitals alapja | Közvetlenül nem |
A laborteszt pontszáma (a 0-100-as Lighthouse-érték) tehát diagnosztikai eszköz. A Google a rangsorolásnál az oldalélmény-jelzéseket a terepi adatból veszi.
Hogyan működik a CrUX?
Azok a Chrome-felhasználók, akik engedélyezték a használati statisztikák küldését, névtelenül jelentik, milyen gyorsan töltöttek be nekik az oldalak. A Google ezt URL-enként és teljes domainre (origin) is összesíti. A három fő mutató:
- LCP (a legnagyobb látható elem megjelenése): jó, ha legfeljebb 2,5 másodperc.
- INP (a kattintásokra adott reakció ideje): jó, ha legfeljebb 200 ezredmásodperc.
- CLS (az elrendezés ugrálása): jó, ha legfeljebb 0,1.
Fontos részlet, hogy a Google nem az átlagot nézi, hanem a 75. percentilist. Egy oldal akkor „jó”, ha a látogatások legalább háromnegyedében teljesül a küszöb. Vagyis nem elég, hogy a gyors irodai wifin jól fut; a lassabb mobilokon is rendben kell lennie.
Szemléltető példa egy magyar webshopnál
Egy lakberendezési webshop laborban 92 pontot kap, mégis a Search Console „lassú” LCP-t jelez a termékoldalakra. A terepi adat 3,4 másodpercet mutat a 75. percentilisen. A magyarázat: a vásárlók jelentős része mobilon, mobilnetről nézi az oldalt, ahol a 2-3 MB-os termékfotók lassan jönnek le. A laborteszt ezt nem látja ugyanúgy.
A képek WebP-re alakítása és a fő termékkép előtöltése után a terepi LCP négy hét alatt (ennyi idő kell, mire a 28 napos ablak kicserélődik) 2,3 másodpercre csökken. Ha a webshop havi 3 000 000 Ft forgalmat csinál mobilról, és a gyorsítás a mobilos konverziós arányt 1,5%-ról 1,7%-ra emeli, az nagyjából havi 400 000 Ft többletbevétel ugyanabból a forgalomból. A számok szemléltetők, a saját hatást a GA4-ben, a gyorsítás előtti és utáni időszak összevetésével mérd.
Gyakori hibák
- Azonnali javulást várni. A field data 28 napos átlag. A javítás után egy-két nappal még szinte semmi nem változik; ilyenkor a labortesztet nézd, a terepi adatot négy hét múlva.
- A Lighthouse-pontszámot hajszolni. Egy 100-as labor-eredmény még nem jelenti, hogy a valós felhasználóknál is minden rendben van, és fordítva.
- Nem tudni, hogy nincs adat. Kisebb forgalmú oldalaknál a CrUX nem gyűjt elég mintát, ezért URL-szinten nincs terepi adat, legfeljebb a teljes domainre. Ilyenkor a saját mérés (például a web-vitals JavaScript-könyvtár a GA4-be kötve) adhat képet.
- Csak a nyitóoldalt nézni. A Search Console Core Web Vitals jelentése oldalcsoportokat mutat. A legtöbb pénzt hozó termék- és kategóriaoldalak sokszor rosszabbak, mint a főoldal.
Hol nézd meg a saját terepi adataidat?
Három helyen érdemes keresni, és mindhárom ingyenes. A PageSpeed Insights felső blokkja egy adott URL-re és a teljes domainre mutatja a CrUX-adatot, ha van elég minta. A Search Console Core Web Vitals jelentése oldalcsoportokra bontva jelzi, mely URL-ek „jók”, melyek „javítandók” és melyek „gyengék”, mobilra és asztali gépre külön. Ha pedig hosszabb trendet szeretnél, a CrUX-adatok havi bontásban is lekérdezhetők, például egy Looker Studio-irányítópulton.
Egy hasznos szokás: a fejlesztés előtt jegyezd fel a terepi értékeket, és tedd a naptárba a négy héttel későbbi visszamérést. Így nem a laborteszt pillanatnyi hangulata, hanem a látogatóid valós tapasztalata dönti el, megérte-e a munka.