Webshark Blog

2021 augusztusában új rangsorolási tényezőt indított a Google: az oldalélményt, melynek részeként fontossá váltak a webes vitals-mutatók, vagyis core web vitals mutatók. Ez új kihívás elé állítja a weboldalakat, melynek nem is olyan könnyű megfelelni. (Frissítés, 2023.06.26. – Egy új fejezettel bővítettünk: Már a Search Console-ban is elérhető az INP-jelentés).

A Google komoly hatással van a weboldalakra, azok megjelenésére, hiszen a keresőoptimalizálás sok weboldal számára elől áll a prioritási listán: ha jó helyen akarnak szerepelni, a weboldalukkal igazodniuk kell a Google elvárásaihoz.

Habár a weboldalak felhasználói élménye már eddig is hatással volt egy weboldal rangsorolására, ez most egy mérhető elemmel is bővül, miután a core web vitals, vagyis magyarul a webes vitals-mutatók – illetve az abból képzett oldalélmény – rangsorolási tényezővé lépett elő. Vagyis mostantól objektív mérőszámok mutatják, hogy a Google szerint mennyire jó a weboldal-élményed.

Mik azok a webes vitals-mutatók?

A webes vitals-mutatók jelzik egy weboldal interaktivitásának gyorsaságát, reszponzivitását, stb. Ha egy weboldal nem felel meg a Google sztenderdjeinek, akkor az negatív hatással lesz a helyezésére.

A core web vitals mutatók fogalma egyébként még azok számára is új lehet, akik azért érintőlegesen odafigyeltek a weboldaluk teljesítményére, sebességére. Tehát különböző eszközökkel mérték és elemezték a sebességet, a weboldal méretét, is igyekeztek is azt optimalizálni.

Ugyanakkor az, hogy egy weboldal jó teljesítményt mutat valamely sebesség-teszten, például a GTmetrixen, egyáltalán nem jelenti azt, hogy jó webes vitals-mutatókkal fog rendelkezni, sőt nem feltétlenül fog megfelelni a mobilra előírt sztenderdeknek.

A webes vitals-mutatók valós, felhasználó-központú mérőszámok, melyek megpróbálják adatként megjeleníteni a felhasználói élményt, legalábbis annak sebességre vonatkozó részét. Méri a betöltési időt, az interaktivitást és a tartalom stabilitását betöltés közben. Ugyanakkor ezek a core web vitals mutatók nincsenek kőbe vésve, ami azt jelenti, hogy évről évre változhatnak attól függően, hogy mit vár a felhasználó egy jó weboldaltól.

Ezen grafika alapján talán könnyebben érthető, miről is szól:

Mint látható, az oldalélmény rangsorolási tényezőbe a webes vitals-jelzésen túl beletartozik a mobilbarátság, a biztonságos böngészés, a HTTPS használata, és a zavaró hirdetések elkerülése. A Google magyarázata szerint az oldalélmény jelzés azt méri, hogy a felhasználók milyennek érzik a weboldallal történő interakciót. A benne foglalt elemeknek az optimalizálásával egy kellemesebb élmény biztosítható a felhasználók számára minden böngészőben és felületen, illetve segít abban, hogy a weboldal jobban megfeleljen a felhasználói elvárásoknak mobilon is.

A Google mindenesetre a webes vitals-mutatókkal rákényszeríti a weboldal-tulajdonosokat arra, hogy valamelyik eszközét használják, ha a weboldaluk teljesítményét, sebességét szeretnék optimalizálni.

---

A Google kidobta az oldalélményből a biztonságos böngészés jelzést

A Google 2021. augusztus 4-én jelentette be, hogy eltávolítja az oldalélményből a biztonságos böngészés jelzést. Ha feljebb megnézed a Google ábráját, akkor látod, hogy összesen 7 jelzést tartalmaz, közte a „Safe Browsing”-ot. A most közzétett ábrán ez már hiányzik:

A Google a lépést azzal magyarázta, hogy rájöttek, a biztonságos böngészés kapcsán felmerülő problémákra nincs mindig ráhatása a weboldaltulajdonosoknak. A weboldalak ugyanis időnként külső felek káros tevékenységeinek esnek áldozatul. A Google ettől még persze jelezni fogja a Search Console-ban, ha ilyen probléma felmerül, csak épp nem jelenik meg az oldalélmény jelentésben, illetve nem befolyásolja a rangsorolásod.

A lépés tehát mindenképpen pozitív a weboldaltulajdonosok számára, hiszen eggyel kevesebb probléma miatt kell aggódniuk. Ugyanakkor úgy néz ki, hogy az egyik meglévő szám helyett a közeljövőben egy új webes vitals mutató is megjelenhet, melyről itt írtunk bővebben.

---

Az INP-vel cseréli le a FID-t a Google: 2024 márciusában élesedik az új webes vitals mutató

A Google egy új, teljesebb, a gyors interaktivitást kifejező mutatót is hozzá szeretne adni a webes vitals mutatókhoz, miközben az első interakciótól számított válaszkésést, vagyis a First Input Delayt (FID) feltehetően eltávolítaná – írtuk még 2022-ben. Mint egy májusi Google I/O-n kiderült: az INP-ről (Interaction to Next Paint) lenne szó, mely a felhasználói interakciókra adott átfogó reakciókészséget, reszponzivitást méri.

2023. május 10-én aztán a Google bejelentette szintén egy Google I/O-n, hogy kísérleti szakaszból „függő” állapotú webes vitals mutatóvá lépett elő az INP.

Azt is hozzáfűzték magyarázatként, hogy ez a változás azt jelzi, hogy az INP ugyan készen áll a FID leváltására, de egyelőre még nem élesedik. Adnak ugyanis egy kis időt az alkalmazkodásra, és majd csak 2024 márciusában lesz az INP-ből webes vitals mutató. Ugyanakkor a Search Console-ban még az idén megjelenik, így lehet ismerkedni vele.

De miért is van erre szükség? Ennek kapcsán érdemes egy pillantást vetni egy korábbi HTTPArchive Almanac cikkre, mely a CMS-ek használatával foglalkozott. Ennek szerzője rámutatott, hogy gyakorlatilag valamennyi tartalomkezelő rendszer kiváló pontszámot ér el a FID esetében, a Google éppen ezért dolgozik az új mérőszámon, mellyel lecserélheti a mára értelmetlenné vált FID-t.

Amit érdemes tudni ezzel kapcsolatban, hogy a HTTPArchive minden évben közzétesz néhány cikket a web állapotáról. A vonatkozó cikk 16. fejezete a tartalomkezelő rendszerekről (CMS) szólt, és a cikket a Google több szakembere is vizsgálta. Ennek egy fontos pontja érintette az első interakciótól számított válaszkésés nevű mérőszámot, mint olyan mutatót, mely már elvesztette az értelmét.

A FID azt az időt mutatja, amíg egy interaktív elem reszponzívvá válik. Azt ugyanakkor nem mutatja, hogy a weboldal milyen gyorsan tud reagálni a felhasználó kattintására.

Azt pedig talán tapasztalatból is tudjuk, hogy a népszerű CMS-ek számára, mint például a WordPress vagy a Drupal, nem szokott gondot okozni a válasz sebessége, vagyis nem kell másodpercekig várakozni egy gombra.

A CMS-ek, különösen a WordPress, egyelőre ugyan nem teljesítenek olyan jól a webes vitals mutatókat tekintve, ugyanakkor nem a FID az a mérőszám, ahol el szoktak vérezni: a cikk szerint a legtöbb CMS kivételesen jól teljesít ezt a mutatót tekintve. Desktopon gyakorlatilag mindegyik 100 százalékot ér el, míg mobilon 90 százalék felett járnak, kivéve egy-kettő CMS, közöttük a Joomlát, mely 85 százalékot szerzett.

Viszont, ha mindenki jól hoz egy mutatót, akkor az azt is jelenti, hogy nincs sok értelme a létének, hiszen a célként kitűzött értéket már mindenki elérte.

A Google ezért inkább a reszponzivitásra és a válaszkésésre próbált meg mérőszámot kreálni. A Chrome csapata egy olyan cikket tett közzé, melyben a jobb reszponzivitást jelző mérőszám kapcsán fejtették ki gondolataikat. A már említett 2022. májusi Google I/O-n aztán mindezt élőszóban is elmondták.

Michal Mocny itt elmondta, hogy az INP egy egész-oldalas életciklus-mutató, csakúgy, mint a CLS. Ez azt jelenti, hogy nem csak az első interakciót méri, hanem az összeset. Vagyis nem egyszerűen betöltési reakciókészségről van szó, hanem a futás során tapasztalható reszponzivitásról.

De lássuk részletesebben, mit is jelez a reszponzivitás mutató!

A legfontosabb az új mutatóval kapcsolatban talán az, hogy nem egyetlen interakciót mér, hanem egyedi interakciók csoportját, melyek részei a felhasználói cselekvésnek a weboldalon.

Egy 2021 júniusában megjelent Web.dev cikkből kiderül, hogy melyek a céljai az új mérőszámnak:

• valamennyi felhasználói interakció reszponzivitásának mérése (nem csak az elsőé)
• az események teljes időtartamának mérése
• az események csoportosítása
• egy összevont pontszám létrehozása, mely valamennyi, az adott oldalon előforduló interakció gyorsaságát méri, azok teljes életciklusa során

Ezzel tehát egy szélesebb jelentéssel bíró mérőszám jöhet létre a felhasználói élményre vonatkozóan.

A Chrome fejlesztői két megközelítésen gondolkodtak az interakció-késés mérésénél. Az egyik a maximális esemény-időtartam, a másik a teljes esemény-időtartam. Az első azt jelenti, hogy egy interakció több eseményből áll, melyek eltérő időtartamúak, és a mérőszám a csoportban előforduló leghosszabb időtartamot mérné. A teljes esemény-időtartam pedig azt az időt jelent, mely alatt valamennyi csoportba tartozó esemény lezajlik.

Az INP az a mérőszám lett, mely az oldal teljes interakciós késését fejezi ki azáltal, hogy kiválasztja a leghosszabb interakciót, mely egy felhasználói látogatás során előfordul. Ha egy weboldalon 50-nél kevesebb az interakció, akkor az INP az az interakció lesz, melynek a legrosszabb a késleltetése. Az INP-ről részletesen itt olvashatsz.

Leegyszerűsítve: az INP akkor lesz gyenge, ha valaki kattint a weboldaladon egy elemre, majd sokat kell várnia, hogy a kattintásnak valami eredménye legyen. Ilyen lehet az, amikor egy terméket beraksz a kosárba egy webáruházban, vagy amikor egy navigációs menüt megnyitsz, vagy egy bejelentkezési űrlapot hitelesít a szerver. Néhány interakció persze hosszabb időt vesz igénybe, ugyanakkor az összetett interakcióknál is fontos, hogy gyorsan mutassanak valamilyen vizuális visszajelzést, mely alapján a felhasználó azt érzékeli, hogy valami történik.

Ha ugyanis a felhasználó kattint egy interaktív elemre, de nem történik semmi, akkor az gyenge felhasználói élményt jelez. Amikor egy hosszú feladat miatt a felhasználó többször is kattint egy elemre, mert semmilyen visszajelzést nem kap, csak jelentős késéssel, akkor ott tönkrement a felhasználói élmény, a rendszer késve reagál, és mondjuk a többszöri kattintás miatt a felhasználó lesi, hogy miközben nem csinál semmit egy adott gomb reagál (például lecsuk vagy kinyit egy menüt).

Az INP-t milliszekundumokban méri a Google:

• Ha az INP pontszám 200 milliszekundum alatt marad, akkor az oldal rendben van.
• Ha 200-500 milliszekundum, akkor az már elfogadható, de javításra lenne szükség.
• 500 milliszekundum alatt pedig rossz reszponzivitásról beszélünk.

---

Már a Search Console-ban is elérhető az INP-jelentés (FRISSÍTÉS, 2023.06.26.)

Annak érdekében, hogy fel tudj készülni a FID-ről INP-re történő váltásra, a Google 2023 júniusában elindította az INP-jelentést a Search Console-ban.

A jelentést a Webes vitals mutatók résznél találod (ha a bal oldali menüben legörgetsz), majd kattintás után az oldal alján láthatod az értékeket, de ha ide kattintasz, és megadod a tulajdont, akkor szintén ide jutsz. A Google egyébként itt jelzi is, hogy „2024 márciusában az INP a Core Web Vitals részeként a FID helyébe lép. További információ arról, hogy hogyan teljesít webhelye az új INP-problémák táblázata szolgáltatással.”

Ha nincs semmi gond a weboldaladdal, akkor egy üres felülettel fogsz találkozni a táblázat helyett, azzal a szöveggel, hogy

„Nem észlelhető INP-probléma
A webhely készen áll a 2024 márciusában érkező változásokra.„

Ha viszont problémák vannak, akkor a táblázat leírja, hogy hány URL esetében rossz a teljesítmény, esetleg, hogy „javítás szükséges”. 500 ms felett rossz teljesítményről beszél a Google, 200-500 között javítás szükséges, míg 200 ms alatt van rendben az oldal.

Ha nem vagy 200 ms alatt az oldalaiddal, akkor van még néhány hónapod arra, hogy 2024 márciusáig rendezd a helyzetet. Ugyanakkor jövő év tavaszán sem kell pánikolni, ha esetleg vannak nem tökéletes INP-szempontból az oldalad, ugyanis az INP, sőt a webes vitals mutatók esetében is csak egy csekély jelentőségű – már ha egyáltalán – rangsorolási tényezőről van szó. Ugyanakkor a felhasználók számára hatékonyabbá teheted az INP optimalizálása által a weboldalad.

Hogyan optimalizáld az INP-t?

A FID tehát kikerült a webes vitals mutatók közül, és jött egy új mutató, az INP, melyre optimalizálni kell a weboldalakat a jobb felhasználói élmény és a jobb helyezés érdekében.

De hogyan optimalizálhatsz? Meg kell keresni azokat a funkciókat, melyek kritikus fontosságúak ahhoz, hogy a felhasználó mondjuk egy webáruházban elkezdhesse a vásárlást, és azokat, amelyekre ehhez nincs szüksége. Itt is alapvetően akkor van probléma, ha a szktriptek lassan töltődnek be, túl sokáig tart az erőforrások lekérése, vagy a CSS és a HTML feldolgozása annak érdekében, hogy a weboldal megfelelően megjelenhessen.

Interakciós késésről tehát akkor van szó, amikor a böngészőnek erősen igénybe kell vennie a CPU-t annak érdekében, hogy frissíthesse a weboldalt. Ez két dolog miatt következik be:

• folyamatban lévő háttérfolyamatok, melyek megakadályozzák a felhasználói bevitel kezelését
• vagy önmagában a felhasználói bevitel kezelése tart túl sok ideig.

A háttérfolyamatok akkor futnak nagyobb számban, amikor elkezdődik az oldal betöltése, de persze később is jelen vannak, és sokszor a weboldalba ágyazott külső kódok eredménye egy akadályozó háttérfolyamat. A leggyakoribb feldolgozási típus a JavaScript kód, de az összetett vizuális frissítések is hosszú ideig tarthatnak.

Ha nem optimalizálható a folyamat, akkor egy folyamatjelzőt érdemes használni, mely vizuális visszajelzést ad a feladat befejezéséig.

A teljesítmény elemzésére a Chrome fejlesztői eszközt érdemes használni, mely megmutatja, hogy mely feladatok tartanak hosszú ideig, melyeket kell optimalizálni. Segítségével megtalálhatod, hogy a lassulásért külső vagy belső kód a felelős. Abba is belemélyedhetsz, hogy miként lehet a folyamatot felgyorsítani.

A háttérfolyamatok elemzésénél érdemes ellenőrizni a Total Blocking Time mutatót, mellyel beazonosíthatod a háttérfolyamatokat. A TBT azt követi nyomon, hogy milyen gyakran van olyan háttér-feladat a CPU számára, ami megakadályozza más kódok futását. Ez azért gond, mert ha egy felhasználó akkor lép interakcióba egy oldallal, amikor ott egy feladat éppen folyamatban van, akkor a böngésző előbb ezt a feladatot fejezi be, mielőtt a felhasználó kérését kezelné.

A Google Lighthouse segítségével megnézheted ezt a mutatót, és segítséget kaphatsz az optimalizáláshoz is.

Ha a lassulásért nem külső kód a felelős, akkor a fejlesztőkkel kell egyeztetned az optimalizálás érdekében. Az optimalizálásról itt találsz további részleteket.

---

Hogyan mérd a core web vitals mutatókat?

Korábban ezt a kérdést már érintettük a Search Console használatáról szóló anyagunkban, de itt is kitérünk rá. Tehát mik is azok a core web vitals mutatók?

Három mutatót különböztet meg a Google: LCP, FID, CLS.

Ezek közül egyébként az első kettő már a sebesség jelentésben is megjelent, csak a CLS lehet újdonság. A Google magyarázata szerint:

• LCP (legnagyobb vizuális tartalomválasz): Azt az időt jelenti, amely alatt a böngésző rendereli a megjelenítési terület legnagyobb látható tartalomelemét, attól számítva, amikor a felhasználó lekéri az URL-t. A legnagyobb elem általában valamilyen kép vagy videó, esetleg nagy méretű tömbszintű szövegelem. Azért fontos, mert ez alapján az olvasó láthatja, hogy az URL betöltése ténylegesen folyamatban van. A jelentésben látható Összesített LCP azt az időt jelenti, amely alatt a csoportban lévő URL látogatásainak 75%-a eléri az LCP-állapotot.
• FID (első interakciótól számított válaszkésés): Az az idő, amely a felhasználónak az oldallal való első interakciójától (pl. linkre kattintás, gombra koppintás stb.) addig tart, amíg a böngésző válaszol az interakcióra. A mérőszám attól az interaktív elemtől származik, amelyre a felhasználó először rákattint. Ez olyan oldalakon fontos, ahol a felhasználónak valamit végre kell hajtania, mert az oldal ekkor vált interaktívvá. A jelentésben megjelenő Összesített FID azt jelenti, hogy a csoportban lévő URL látogatásainak 75%-a ilyen vagy ennél jobb értékkel rendelkezett.
• CLS (elrendezés összmozgása): Azt határozza meg, hogy mennyit mozog az oldal elrendezése a betöltés során. A pontszám 0 és 1 között lehet, ahol a nulla azt jelenti, hogy nincs mozgás, az 1 pedig a legtöbb mozgást jelzi. Ez azért fontos, mert az oldalelemek elrendezésének mozgása – miközben a felhasználó használni szeretné az elemeket – rossz felhasználói élményt eredményez. A jelentésben szereplő Összesített CLS a legalacsonyabb közös CLS a csoportban lévő URL látogatásainak 75%-ában.

Röviden megfogalmazva az LCP a betöltés, a FID az interaktivitás, míg a CLS a vizuális stabilitás értékeit mutatja meg. Hogy mi az ideális érték, az itt látható:

A Google tanácsa szerint a legtöbb weboldalon segít, ha

• 500 KB alá csökkentik az oldal méretét
• az oldalforrások számát 50 alá viszik
• és AMP-t használnak.

Amennyiben javítás történik az oldalon, akkor azt jelezni lehet a Google-nak a Search Console-on keresztül, így újraértékeli az oldalt.

Mivel mérd a core web vitals mutatókat?

A mutatók a legegyszerűbben a PageSpeed Insigths segítségével mérhetők, de a webes vitals-mutatók megtalálhatók a Search Console-ban vagy a Lighthouse-ban is (többek között). Ez a táblázat jobban eligazít az eszközök között:

Éppen ezért az alapvető webes vitals-mutatókat, mint az oldalélmény részeként megjelenő elemet a Search Console használatáról szóló anyagunkban már áttekintettük, hiszen a Search Console már pontosan méri, hogy a core web vitals mutatókat tekintve miként teljesít az oldalunk, és mit kell javítani.

A Search Console-on kívül azonban más eszközökkel is mérheted a webes vitals-mutatók állását, de talán érdemes kiemelni, hogy nemrég megjelent egy Chrome bővítmény is, melyet bekapcsolva minden oldalnak láthatjuk a webes vitals-értékeit.

Hogyan javítsd az egyes webes vitals-mutatókat?

Most, hogy már tudod, hogyan mérd az egyes mutatókat, nézzük, hogy miként lehet ezeket javítani a weboldalad esetében!

Frissítve, 2021.10.15.:

Mi az a legnagyobb vizuális tartalomválasz (LCP)? És hogyan javíts rajta?

Habár a bejegyzés egy korábbi részében már megismerkedtünk a Google LCP-definíciójával, érdemes azonban egy kicsit alaposabban körüljárni a legnagyobb vizuális tartalomválasz kérdéskörét.

Mint azt már láttuk, az LCP annak mérőszáma, hogy egy oldal fő tartalma mennyi idő alatt töltődik be és áll készen a felhasználói interakcióra.

Amit itt mérünk, az a legnagyobb kép vagy a legnagyobb tartalmi blokk megjelenése a felhasználó kijelzőjén. Bármi, ami a kijelzőben megjelenő tartalmon kívül található, nem számít bele az LCP-be.

A leggyakrabban megjelenő elemek a képek, videók, háttérképek, vagy nagyobb szövegrészek. Az optimalizálás tehát viszonylag egyszerű: meg kell keresni a legnagyobb elemet a weboldalon, és azt kisebbre venni vagy eltávolítani bármi olyan dolgot, melyek akadályozza annak gyors megjelenítését.

Mivel a Google ma már a legtöbb oldalnál a mobil-indexet használja, így első körben a mobilos megjelenést érdemes figyelembe venni az optimalizálásnál, majd csak utána az asztali gépes megjelenést.

A Google a javítására több javaslatot is ad. Elsőként érdemes a szerverrel foglalkozni. Ha komoly lassulást tapasztalsz, akkor lehet, hogy hasznos lenne egy jobb hosting-szolgáltatással próbálkozni, például megosztott hostingról dedikált hostingra átállni. Ugyanakkor lehet az is, hogy csak rossz beállítás okozza a szerver lassúságát. Egy tipikus probléma a memória kiosztása a PHP részére, vagy akár egy frissítésre szoruló PHP-verzió, esetleg CMS.

Emellett érdemes áttekinteni a weboldalad folyamatait, és ami nem szükséges, azt leállítani, a többit pedig optimalizálni. Például egy WordPress alapú oldal esetében csökkentheted a folyamatok számát a felesleges pluginek eltávolításával.

A második tanács, amit a Google ad, az a CDN (Content Delivery Network) használata. Olyan szolgáltatásoknál is körülnézhetsz, mint amit a Google Cloud vagy a Cloudflare kínál, hiszen a segítségükkel javíthatod a weboldalad sebességét, különösen, ha sokan keresik fel az oldalad a világ számos országából.

Szintén javíthat a helyzeten a gyorsítótárazás, mert így a gyorsítótárazott HTML-tartalmakat nem kell minden egyes alkalommal betölteni minden felhasználó számára, aki meglátogatja az oldalad. Ha WordPresst használsz, akkor olyan pluginok segítenek ebben, mint a W3 Total Cache vagy a WP Fastest Cache, melyek automatikus gyorsítótárazzák a tartalmaidat.

Ezeken túl még számos technika van a gyorsításra: előtöltések alkalmazása vagy a HTML, a CSS és a JavaScript összehúzása. A Google egyébként azt javasolja, hogy az olyan CSS-nél, melyre nincs szükség a kezdő megjelenésnél, használjunk loadCSS-t, hogy a fájlok aszinkron módon töltődjenek be. De ugyanígy a szövegek, képek, videók méretének csökkentése is segít.

Amit a képek kapcsán érdemes tudni, ha az LCP számításáról van szó, hogy a weboldalakra gyakran eredeti méretükben kerülnek fel a képek, és aztán HTML vagy CSS használatával méreteződik akkorára, hogy jól jelenjen meg egy kisebb kijelzőn. A Google azonban a képméret számításánál a kisebb méretet használja. Ez azt jelenti, hogy jó LCP-t lehet elérni akkor is, ha egy kép „valódi”, tehát eredeti mérete nagy, majd aztán HTML és CSS segítségével méreteződik lefelé, ugyanakkor a legbiztosabb megoldás az, ha a „valódi” és a „látható” képméret megegyezik.

Szintén fontos, hogy a más domainekről betöltött képek általában nem részei az LCP számításának.

A mérésénél egyébként megkülönböztetünk úgynevezett „field” eszközöket és „lab” eszközöket. Az előbbiek az oldal valós mérését jelentik, míg utóbbiak egy virtuális pontszámot adnak egy szimulált feltérképezés révén.

A „field” eszközök közé tartozik:

• PageSpeed Insights
• Search Console
• Chrome felhasználói élmény jelentése

Utóbb egy Google-fiókot és egy Google Cloud Projectet igényel.

A „lab” eszközök

Ezek a szimulált pontszámok, melyekhez a Google a következőket ajánlja:

• Chrome DevTools
• Lighthouse
• WebPageTest.org

Ezek közül az első kettő a Google saját eszköze, míg a harmadik egy külső eszköz.

Frissítés, 2021.10.27.:

Mi az a First Input Delay (FID)? És hogyan javítsd?

Az első interakciótól számított válaszkésés, vagyis a First Input Delay (FID) a felhasználó első interakciójától (mint egy gombra vagy linkre kattintás) eltelő időt méri addig, amíg a böngésző válaszol, majd teljesíti a kérést.

Ennél is egyszerűbben fogalmazva a FID azt mutatja meg, hogy a felhasználónak mennyit kell várnia a felhasználói felület válaszára az első kattintása után.

A válaszkésés elsődleges oka az, hogy a böngésző valamilyen folyamattal van elfoglalva, így nem tud válaszolni azonnal a felhasználónak. A gyakorlatban ez általában egy Javascripthez kapcsolódó feladat, melynek végrehajtása sok időt vesz igénybe.

A FID-t csak valós felhasználói interakciók során mérhetjük, „lab” mérésekkel nem állapítható meg.

Ugyanakkor van egy másik mérőszám, a TBT, vagyis Total Blocking Time, mely azt méri, hogy mennyi ideig áll a böngésző, így egy nagyon hasonló eredményt ad ki, mint a FID.

Mi az oka a rossz FID-nek? Hogyan optimalizálható?

Mint azt fentebb már írtuk, bármilyen hosszú ideig tartó feladat, mely akadályozza a böngésző fő folyamatát, és megelőzi az új feladat végrehajtását, gyengíti a FID-t.

A leggyakrabban a késés, illetve a fő folyamat blokkoló futása az oldal betöltése során jelentkezik, amikor a tartalom már megjelent, ugyanakkor még nem töltődött be teljesen az oldal.

A megoldás tehát az, ha a fő szál túl hosszú feladatait eltávolítod. Hosszú feladatnak számít minden olyan feladat, mely a fő szálat több mint 50 ms időtartamra blokkolja. Ilyen késés esetében, ha a felhasználó kattint, akkor már lassú választ fog érzékelni.

A túl hosszú feladatokat azonban meg lehet találni, akár a Lighthouse vagy más eszközök segítségével. Először meg kell találni azt az oldalt, mely a problémát okozza. Lehet, hogy a sablonnal van hiba, de az is lehet, hogy a késés csak a weboldal valamely oldalán jelentkezik.

A FID javításában segíthet:

• A nem látható képek betöltésének csúsztatása
• Külső kódok hatásának csökkentése
• Túl nagy méretű DOM elkerülése
• A JavaScript végrehajtási idejének csökkentése
• A fő szálon zajló munka minimalizálása

A Lighthouse egy teljesítmény ellenőrzés során ajánlásokat tesz arra, hogy miként lehet csökkenteni a fő szálnál jelentkező túl hosszú feladatokat. A Lighthouse-t könnyen elérheted a Chrome-ban (vagy más Chrome-alapú böngészőben), ha jobb gombbal az oldalra kattintasz, majd a menüből alul kiválasztod a „Vizsgálat” menüpontot.

Majd a felső menüsor utolsó menüpontjára, a Lighthouse-ra kattintva megkapod a jelentéskészítés lehetőségét.

Ha elkészítetted a jelentést, akkor ott külön a TBT-re is kiválaszthatod az eredményeket, majd ez alapján lehet javítani a teljesítményt, de találsz a jelentésben egy olyan részt is, melynek az a neve, hogy „Avoid long main-thread tasks”:

Itt látod azokat a feladatokat, melyek végrehajtásának ideje meghaladja az 50 ms-t.

Egy másik dolog, amit érdemes megnézni a Lighthouse-ban az az „eredeti nyom” megtekintése, mely megmutatja az oldal betöltésének folyamatát. Ha itt bekattintod fent a Web Vitalst, akkor látod, hogy mely feladatok vesznek igénybe 50 ms-nál hosszabb időt.

Az első interakciótól számított válaszkésés elsősorban a JavaScript és a külső szkriptek használatának optimalizálásán múlik. Utóbbi egyébként elsősorban különböző weboldalanalitikai eszközöket jelent, de bármely kód lehet, mely egy másik weboldalhoz kapcsolódó szkriptet futtat le.

Mint azt már az előző fejezetben említettük, a JavaScript minimalizálható, vagyis eltávolíthatók a felesleges karakterek, a nem használt kódok, és azok, melyekre nincs szükség a weboldal elindulásához a betöltésnél. A Google egyébként a UglifyJS-t javasolja a JavaScript csökkentésére.

Frissítés, 2021.11.05.:

Mi az a Cumulative Layout Shift (CLS)? És hogyan javítsd a CLS-t?

A Cumulative Layout Shift, vagy magyarul az elrendezés összmozgása azt a weboldalmozgást méri, mely betöltésnél és a vele való interakciónál jelentkezik. Mozgásról akkor van szó a weboldalon, ha egy tartalom bármikor is láthatóan pozíciót vált.

A CLS-t mérheted a korábban már sűrűn emlegetett Lighthouse vagy a Search Console segítségével.

A Google természetesen meghatározta, hogy mi a jó és mi rossz érték a CLS-nél. Jó CLS-ről akkor beszélünk, ha 0,10 alatt van az értéke. 0,10 és 0,25 között már szükséges a javítás, míg rossz értékről 0,25 felett beszélhetünk.

Mi okoz gyenge CLS-t?

A tartalom mozgása bekövetkezhet akár egy betűtípus váltás, vagy egy lassan betöltődő kép miatt. Van néhány tipikus probléma, ami a CLS látványos romlását eredményezi:

• Méret nélküli képek
• Méret nélküli hirdetések, beágyazások, iFrame-ek
• Dinamikusan beszúrt tartalmak
• Webfontok, melyek a láthatatlan vagy formázatlan szövegek felvillanását okozzák

Hogyan vizsgáld meg?

Mindezek a problémák viszonylag könnyen és gyorsan feltárhatók és javíthatók. Elég a Lighthouse teljesítményjelentését megnézni, mely javaslatokat is tartalmaz a javításra. Korábban már megmutattuk, hogy hol találod Chrome-alapú böngészőben a Lighthouse-t, és hogyan kaphatsz jelentést.

Ha a CLS-t akarod javítani, akkor az „Avoid large layout Shifts” sorra érdemes figyelni. Ha erre rákattintasz, akkor láthatod, hogy mely elemek okoznak elrendezés-mozgást a weboldalon. Látod mellettük az értéket is, így azt is láthatod, hogy mi az, ami miatt valóban aggódni kell, és mi az, amivel érdemes foglalkozni.

Mi a megoldás?

Az elrendezés összmozgásának javításához jelezned kell a böngésző számára, hogy mekkora terület szükséges a betöltendő elemek számára. Ehhez a képek és a videók számára méreteket kell rendelni, illetve lehetőség van ezt a CSS-ben is megoldani. Bármelyik utat is választod, az a cél, hogy elkerüld a felesleges mozgásokat a weboldal betöltésekor.

Azokat az elemeket is érdemes jelölni, melyek csak akkor fognak betöltődni, ha a felhasználó interakcióba lép az oldallal. Ha a látogatók tudják, hogy mely elemek fognak betöltődni, az megakadályozza azt, hogy elmozduló elemekre akarjanak rákattintani.

Az oldalélmény nem real time algoritmus

Egy másik fontos dolog is kiderült az oldalélmény kapcsán, ez pedig az, hogy nem egy real time algoritmusról van szó, mint egyébként a Google sok más algoritmusa esetében. Ezt megerősítette John Mueller is, illetve azt lehetett is tudni, hogy a fő webes vitals-mutatók feldolgozása 28 napos késéssel működik. Utóbbi a Core Web Vitals & Page Experience FAQ-ból derül ki. E szerint „a mutatók számítása a 75. percentilis alapján történik, egy 28 napos időtartam alatt”. A 75 percentilis alapján ugyanis már tudja a Google, hogy 4-ből 3 webhelylátogatásnál elérte az oldal a megfelelő teljesítményszintet, vagy annál jobbat.

John Mueller a 28 napos késést megerősítette egy 2021 áprilisában tartott SEO hangouton is, ahol azt a kérdést tették fel neki, hogy az oldalélmény algoritmus egy real time algoritmus lesz vagy pedig olyan, mint a fő algoritmusok, melyeket időről időre frissítenek. Mueller jelezte, hogy nem egy valós idejű algoritmusról van szó az oldalélmény algoritmus esetében, „inkább egy lassú dologról”.

Mint magyarázta, van egy általános késés az adatoknál, tehát várniuk kell egy ideig arra, hogy elegendő mennyiségű adatot gyűjtsenek be a weboldalakról, hogy azokat feldolgozhassák. Tehát itt nem a sebesség a lényeg, hanem az, hogy átlássák a teljes képet. A frissítési időpontot illetően sincs egy meghatározott időpont, vagyis nem minden hónap elsején kerülnek frissítésre az adatok – tette hozzá.

A jobb webes vitals-mutatók nem feltétlenül hoznak jobb helyezést

A webes vitals mutatók olyan számok, melyeknél, ha egyszer elértél egy elfogadható szintet, akkor felesleges tovább javítani rajtuk, mert nem fognak még jobb rangsorolást eredményezni. Philip Walton a Google részéről ezt úgy fejezte ki, hogy habár azt nem mondhatjuk, hogy teljes mértékben egy bináris tényezőről lenne szó a webes vital mutatóknál, de majdnem.

Ez pedig azt jelenti, hogy ha elérted a maximális rangsorolási lökést a jó webes vitals mutatók révén, akkor ezen nem lehet tovább javítani azzal, hogy még jobb számokat érsz el.

John Mueller ezt úgy fogalmazta meg, hogy ha egyszer eléred a megfelelő tartomány, akkor átugrottad a lécet, és hiába nyersz mikrooptimalizációval újabb milliszekundumokat, az nem fog további javulást eredményezni a helyezésedben. Lehet persze, hogy ennek is van hatása a felhasználói élményre, de ez már nem fog tükröződni a találati oldalakon.

Philip Walton egyébként azt is hozzátette, hogy a rangsorolás javításához nincs feltétlenül szükség arra, hogy mindhárom core web vitals mutatónál jó pontszámot érj el. Ahogy annak sem lesz eredménye, ha mondjuk az LCP két másodperc helyett egy másodperc lesz.

Ugyanakkor, ha van egy lassú oldalad, gyenge web vitals-mutatókkal, és itt sikerül mondjuk 10 másodpercre javítani az LCP-t, akkor az javulást fog eredményezni a rangsorolásodban. John Mueller ehhez még hozzátette, hogy ha viszont gyenge a tartalmad, akkor hiába javítasz a web vitals mutatókon, nem fogod túlszárnyalni a jobb tartalmú weboldalakat.

Az oldalélményt nem a Googlebot vizsgálja

Nemrég egy fontos dologra hívta fel a figyelmet John Mueller, amit sokan nem látnak világosan a webes vitals mutatók, illetve az oldalélmény rangsorolási tényezővé válása kapcsán Mégpedig azt, hogy bár a Googlebot fésüli át a webet és szállítja a legtöbb jelzést a Google számára, mely alapján aztán rangsorolják a weboldalakat, a webes vitals mutatókért nem a Googlebot felel, illetve nem a feltérkpezés során kerülnek az adatok a Google-hez.

A webes vitals mutatók ugyanis a Chrome böngésző CRuX (Chrome user experience report) adatjelentéséből származnak.

Ez pedig azt jelenti, hogy a Google a Chrome valós használati adatait veszi figyelembe egy-egy weboldal webes vitals mutatónak meghatározására. Ez magában foglalja az úgynevezett LCP, FID és CLS pontszámokat. Tehát, amikor egy Chrome-ot használó látogató érkezik a weboldaladra, akkor az ő böngészője szolgáltat adatokat a weboldalad felhasználói élményéről a Google számára.

Ha vannak AMP-oldalaid, akkor azoknak az oldalélményét veszi figyelembe a Google

Amikor a Google először jelentette be, hogy az oldalélmény és benne az alapvető webes vitals-mutatók rangsorolási tényezővé válik, azt még nem kommunikálta – vagy legalábbis nem elég figyelemfelkeltően -, hogy ha AMP-t használsz, vagyis az AMP-oldalaidra érkeznek a találati oldalakról a felhasználók, és mobil-first indexelést alkalmaz már a Google (ami 2020 végére minden weboldalnál megvalósul), akkor ezeknek az AMP-s oldalaknak az „élményét” veszi figyelembe a rangsorolásnál. Nem pedig a mobilos vagy asztali gépes oldalad oldalélményét.

John Mueller ezt egy Google webmaster videóban tette világossá.

Röviden, itt azt magyarázza el, hogy a Google azt az oldalt veszi figyelembe az oldalélmény mérésénél, melyre a felhasználók megérkeznek a találati oldalon történő kattintás után. Márpedig, ha AMP-t használsz, akkor egy AMP oldalra érkeznek mobilon, így ezen AMP oldal alapján határozza meg az alapvető webes vitals-mutatókat, illetve a többi tényezőt, melyek meghatározzák az oldalélményt.

Azt pedig tudjuk, hogy az AMP verziók a Google szerint igen jó értékeket mutatnak az oldalélményt tekintve. Tehát, ha nem használsz még AMP-t, akkor lehet, hogy érdemes lesz.

Kik fogják a leginkább megérezni a webes vitals-mutatókat?

Ha azt látod, hogy a weboldalad nem teljesít jól a Google tesztjén, akkor – ha fontos számodra a helyezésed – javítani kell a weboldaladon. Ugyanakkor ez nem minden esetben lesz egyszerű, vagy egyáltalán megoldható. Akad néhány olyan szituáció, amikor a webes vitals-mutatóknak való megfelelés komoly fejtörésre adhat okot a weboldaltulajdonosok számára.

A leginkább természetesen az alacsony költségvetéssel működő weboldalakat fogja érinteni, hiszen egy weboldal teljesítményét megfelelően optimalizálni idő és pénz. Tekinthető persze befektetésnek, hiszen javít a weboldal helyezésén a keresőben, ugyanakkor nem mindenkinek van erre pénze.

Egy weboldal teljesítményére elég sok elem van befolyással, a kód tisztaságától elkezdve a képek optimalizálásáig, vagy a felesleges funkciók eltávolításáig. Ha valóban jó eredményt akarunk elérni, akkor elég komolyan bele kell ásni magunkat a dologba, ami nem kis munka. Egy évekkel ezelőtt készült vagy kifejezetten lassú weboldal esetében szinte biztos, hogy egy teljes redesignra lesz szükség.

Emellett az alacsony költségvetéssel üzemelő weboldalakat a hosting kérdése is érinti, hiszen az olcsó, megosztott hosting megoldások nem nyújtják azt a teljesítményt, amit a Google elvár. A jobb hosting-szolgáltatás viszont megint csak több pénzbe fog kerülni.

Szintén gondban lesznek az olyan hagyományos CMS-eket használó weboldalak, melyek WordPressre, Drupalra, stb. épülnek. Az adatbázisokat használó tartalomkezelőknél a lekérdezések és egyéb kulcsfontosságú funkciók végrehajtása lassítják a weboldalt.

Segít persze ezen a gyorsítótárazás, ez azonban nem feltétlenül lesz elég, szükség lehet CDN használatára és egy magasabb szintű webhosting-szolgáltatásra, mely képes már elfogadható teljesítményt nyújtani.

Ezeknél a CMS-eknél gondot fognak okozni a témák és a pluginek is. A WordPress tele van olyan témákkal, melyek erősen lerontják egy weboldal teljesítményét, és erre a fejlesztőknek sincs befolyásuk. A megoldást a téma lecserélése jelenti, illetve egyes pluginek kikapcsolása, ami viszont sok weboldal számára nem feltétlenül opció.

De egyébként minden olyan helyzet problémát fog okozni, ahol a weboldalfejlesztőknek nincs teljes hozzáférésük a weboldal minden eleméhez, vagy nincs befolyásuk a hosting-szolgáltatás minőségére. Ez pedig azt jelenti, hogy a webes vitals-mutatók alapvetően azoknak a weboldalaknak kedveznek, akik a legtöbb erőforrással (pénzzel) rendelkeznek.

Azt persze nem tudjuk pontosan – legalábbis egyelőre -, hogy a Google-nél a webes vitals-mutatók milyen súllyal befolyásolják majd a weboldal helyezését, hogy akár egy jobb tartalommal rendelkező oldalt egy jobb teljesítményű oldal meg tud-e előzni, pusztán a jobb teljesítménye, illetve oldalélménye miatt.

Nyilván az a Google-nek sem érdeke, hogy a sebesség fontosabb legyen, mint a tartalmi minőség, de az mindenesetre azért leszögezhető, hogy nem teszik könnyebbé a kisebb cégek és weboldalak indulását a rendkívül szigorú teljesítmény-követelmények.

A webes vitals-mutatók rangsorolási tényezővé válása minden weboldalt befolyásol, melynek fontos a keresőoptimalizálás. Egyeseket kevésbé fog érinteni a hatása, másokat jobban. És habár a jó weboldal-teljesítmény tényleg fontos a felhasználói élmény szempontjából, az új mérőszámoknak való megfelelés nem egyszerű, és megkockáztatható a kijelentés, hogy talán túl sokat is kíván a weboldalakról.

Új fejezet, 2022.05.19.:

Melyik CMS hozza a legjobb eredményeket?

A HTTPArchive segítségével ma már összehasonlíthatók a weboldalkészítő platformok valós statisztikai adatok alapján. A listára felkerült jó pár rendszer, köztük olyan CMS-ek, mint a WordPress, a Drupal vagy a Wix, de az eszköz segítségével bármit be lehet állítani. Fontos még megjegyezni, hogy a vizsgálat pontszámoknál a mobilos megjelenést vettük figyelembe.

Amit érdemes tudni, hogy a webes vitals technológiai jelentés két adatkészletre épít. Az egyik a CRuX adatkészlet, a másik a HTTPArchive Lab Web Technology Detections adatkészlet. Az előbbi, vagyis a Chrome User Experience adatkészlet valós adatokat gyűjt azon Chrome-használóktól, akik az adatokat anonim módon megosztják. Ezek valós, vagyis úgynevezett „field” adatok, nem csak szimulációs adatok.

Utóbbit kínálja a HTTPArchive Lab Web Technology adatkészlet, melynél egy robot feltérképez egy-egy weboldalt, és szimulál egy mobileszközt és egy adatkapcsolatot annak érdekében, hogy ki tudja számolni a Core Web Vitals értékeket. Ennek érdekében havonta több millió URL-t térképez fel mind desktopon, mind mobilon. Az URL-eket a Chrome felhasználói élmény jelentésből szedi össze.

Az összehasonlításban olyan platformok szerepeltek, mint a WordPress, a Drupal, a Wix és a Duda, Shopify, stb. és a számok idei évi alakulását vettük figyelembe. A számok alapján kiderül, hogy a WordPress elég gyengén teljesít, viszont van egy szereplő, a kevéssé elterjed Duda, mely kiemelkedő, különösen az elmúlt egy-két hónapban húzott bele nagyon.

Utóbbi egy weboldal-építő platform, mely annyiban hasonlít a WordPresshez, hogy lehetővé teszi a kód módosítását, ugyanakkor a platform alapjául szolgáló technológia felett fenntartják az irányítást a Duda fejlesztői, annak érdekében, hogy megfelelő teljesítményt mutassanak az erre épül oldalak. Ez lehetővé teszi a Duda fejlesztői számára, hogy azokra a funkciókra figyeljenek, melyek fontosak a felhasználók számára, így például a weboldalsebességre. A jelentés alapján azt mondhatjuk, hogy ez a megoldás kifizetődő.

Az adatok ugyanis azt mutatják, hogy a weboldalaik 54,06 százalékának szeptemberben jók voltak a webes vitals-mutatói, míg az év elején ez az érték még csak 18,14 százalék volt.

A WordPress ugyanakkor az évet 14,5 százalékos értékkel kezdte, és mostanra is csak 21,55 százalékig sikerült felküzdenie magát. Vagyis a WordPress-alapú weboldalak több majdnem nyolcvan százaléka még nem rendelkezik megfelelő webes vitals-mutatókkal.

A Wix az elmúlt években komoly erőket mozgósított, hogy jobb keresőoptimalizálást és webes vitals-mutatókat érjen el. A befektetett energia úgy látszik, itt is kifizetődött, hiszen az évet még csak 11,97 százalékkal kezdték, mostanra viszont a Wixre épülő oldalak 33,46 százaléka jó Core Web Vitals mutatókkal rendelkezik. Ez azt jelenti, hogy az év elején még rosszabb arányt ért el a WordPress-nél, de mára jelentősen lehagyta a legnagyobb CMS-t.

Sokan persze azt mondhatják, hogy a WordPress hátrányból indul, hiszen egy nyílt forráskódú szoftverről van szó, melyet egy bizottság irányít. Ez azonban nem teljesen igaz, ugyanis, ha megnézzük a Drupal számait, ott azért jobb eredményeket látunk: jelenleg 36 százalék felett jár, igaz, magasabb szintről is indított, a növekedése pedig hasonló ütemű a WordPresséhez.

A legjobban azonban egy grafikonon követhető a változás, mely így néz ki:

A 2021. szeptemberi helyzet így állt néhány kiválasztott platform esetében:

• Duda 54,06%
• Shopify 37,49%
• Drupal 36,36%
• Wix 33,46%
• Joomla 27,86%
• WordPress 21,55%
• Magento 15,02%

Mivel ezzel az eredménnyel a WordPress is tisztában van, ezért októberben már nekifeküdt a helyzet megoldásának, legalábbis annyira, hogy javaslatot tettek egy weboldalsebességgel foglalkozó csoport összeállítására. A WordPressnél ugyanis eddig nem létezett olyan összehangolt munka, mely a platform teljesítményét célozná. Mindenesetre, ha egy év múlva nézünk rá a számokra, akkor már lehet, hogy egész más sorrendben állnak majd a szereplők.

Frissítés, 2021.09.29.:

Honnan tudod, hogy hatással vannak a weboldalad rangsorolására a webes vitals mutatók és az oldalélmény?

John Mueller, a Google szakembere magyarázta el, hogy honnan lehet tudni, hogy egy weboldal rangsorolását befolyásolja-e az oldalélmény, illetve a core web vitals mutatók.

Mégpedig arra reagálva, hogy valaki arra panaszkodott neki, miszerint organikus keresési forgalmának mintegy 20 százalékát veszítette el azt követően, hogy elindult az oldalélmény algoritmus. Ráadásul az esés azonnali volt.

A kérdése pedig arra vonatkozott, hogy ha javítja a webes vitals mutatókkal kapcsolatos problémákat, akkor mennyi idő idő alatt fog helyreállni a forgalma.

John Mueller azonban úgy vélekedett, hogy szerinte nem az oldalélmény algoritmus okozhatta a forgalomcsökkenést. Mégpedig azért nem, mert az algoritmus kifutása még júliusban kezdődött és egészen augusztus végéig tartott, ráadásul aloldal-szinten értékelte az oldalakat.

Ez pedig azt jelenti, hogy ha a Google azt látta, hogy gond van a web vitals mutatókkal, akkor egy fokozatos csökkenést kellett volna tapasztalni a weboldalon a nyári hónapok során. Ezzel szemben, ha egy hirtelen csökkenés jelentkezett egy adott időpontban, akkor ott valami más probléma merült fel.

Tehát, ez alapján, ha egy lassú csökkenést látsz az organikus keresőből származó forgalmadban július-augusztus során, akkor a core web vitals mutatóknak nem felel meg a weboldalad. Ha hirtelen esést, akkor másról van szó. De ugyanúgy a pozitív hatás is fokozatosan jelentkezik – jelezte Mueller.