Kis visszatekintés
- 2013-ban a keresőóriás belengette, hogy hamarosan érkezik a Mobilegeddon, amit 2015-ben aktivált is; azok a weboldalak, melyeknek már volt mobilos kinézete (teljesen külön mobilverzióval rendelkeztek, vagy egyszerűen már reszponzívak voltak) előnyben részesültek egy mobilos Google-kereséskor azokkal szemben, akiknek nem volt mobilra optimalizált felülete. Ez utóbbiak hátrébb sorolódtak a találati listán.
- 2016-ban aktiválódott a böngészőkben az SSL hiányára utaló figyelmeztetés: ha az oldal nem biztonságos kapcsolaton keresztül szolgálta ki a látogatókat (tehát http-t használt még https helyett) akkor egy “nem biztonságos“, figyelmeztetés jelent meg a böngészőben különböző pontokon és helyeken. Jelszavas szövegmezőknél például a Mozilla Firefox így fogalmaz: “Ez a kapcsolat nem biztonságos. Az itt megadott adatok lehallgathatók.” Ez szintén rangsorolási tényező lett (hozzátéve, hogy sokadik, tehát nem ez áll az első helyen), így közvetve is hatást gyakorolt a találati listán elfoglalt helyre. Itt megjegyzendő, hogy nem is feltétlen csak azért csökkent az érdeklődés ezek iránt a shopok iránt, mert a Google hátrasorolással, kevesebb megjelenéssel büntetett, hanem leginkább az ügyfelek váltak bizonytalanná és hagyták el az oldalt.
- 2020 januárban már mindenkinél aktiválódott az a beállítás is, hogy a Google feltérképező robotjai már csak az oldal mobilnézetével foglalkoznak, azt indexelik és azt figyelik. Ennek a verziónak a hiányában “néznek csak rá” a desktop/asztali verzióra.
- Idén nyáron lépett működésbe a “Page experience“, azaz szabadfordításban egy egyfajta “Oldal-elégedettség“, a weboldallal kapcsolatos felhasználói élmény, melynek a webes vitals-mutatókat köszönhetjük. Ez a Page experience röviden azt jelenti, hogy a Google elköteleződött amellett, hogy a felhasználó szempontjából gyors, jó élményt nyújtó, egyszerűen használható és összességében felhasználóbarát weboldalak jöhessenek létre. Ezt megtaláljuk a Google Search Console-ban, ha pedig ettől függetlenül szeretnénk méregetni akkor a Google PageSpeed Insights-ot kell használnunk. Az ezzel kapcsolatos blogbejegyezés az alábbi: https://developers.google.com/search/blog/2020/05/evaluating-page-experience
A három Grácia
De mitől és főképp hogyan lesz egy normál weboldal “Page experience-ready“?
Ennek meghatározásában segítenek a webes vitals-mutatók, melyek az alábbi csoportokba sorolhatóak:
LOADING (LCP)
– jelentése: legnagyobb vizuális tartalomválasz
– mértékegysége a másodperc
– 2,5 másodperc alatt zöld – “JÓ”, 2,6 – 4 között narancs – “Fejlesztésre szorul” és 4 másodperc felett piros – “Rosszul teljesítő”
– magyarra lefordítva: a felhasználó keres a mobilján a Google-ben, majd rábök egy találatra. Az LCP azt az időt mutatja, míg a bökéstől számítva az oldal teljesen betöltődik. Maga az LCP a weboldal legnagyobb “tartalma” lesz, ami általában egy fájl: lehet ez nagy kép, videó, de akár betömörített css vagy javascript fájl is. Azért a fájlt mutatja az LCP, mert mivel ő a legnagyobb fájlméretű az oldalon, ezért őt tart a legtovább betölteni, ergo ő lesz az utolsó. Ha nagyon puritán szeretnék lenni, akkor egyszerűen az oldal betöltési idejét mutatja. Persze ez ennyire nem egyszerű, de a megközelítés jó. Arra kell törekedni, hogy ez az LCP-vel jelölt fájl akkora legyen, hogy lehetőleg 2,5 másodperc alatt betölthető lehessen. Tapasztalataink szerint az LCP-ben más ajánlásokat is tenni szokott a PageSpeed Insights (erről később), ezért az ajánlásokat érdemes globálisan nézni és javítani. Ilyenek lehetnek például az oldalon fel nem használt kódok likvidálása.
Ahogyan a PageSpeed Insights is mutatja (később még lesz róla szó) alapvetően több dolog is befolyásolja az össz-LCP-t.
A Prestashop admin felület “Teljesítmény” fülén lévő tömörítési- és gyorsítótárazási beállításai ezen segíthetnek, de a cél előbb a legnagyobb fájlok megtalálása és javítása.
Sokszor előfordul, hogy egy kis bannerkép helyébe – melynek mérete mondjuk 200 x 300 pixel – véletlenségből egy 2000 x 3000 pixeles, több MB helyet elfoglaló képet töltenek fel, sokszor ez okozza a legnagyobb vizuális tartalomválaszt. Természetesen a képet javítani kell a megfelelő méretre és optimalizálni azt.
Melegen ajánlott a Google Chrome elemző használata. A “Teljesítmény” fülön kijeleztethető, hogy a böngésző szerint mi a legnagyobb vizuális tartalomválasz. Példánkban termékoldalon vagyunk, és ott az LCP maga a termék képe (large_default sablon) a 600 x 600-as pixelével és fél MB-os méretével.
INTERACTIVITY (FID)
– jelentése: első interakciótól számított válaszkésés
– mértékegysége a milliszekundum (ezredmásodperc)
– 100 ezredmásodperc alatt zöld – “JÓ“, 100 – 300 között narancs – “Fejlesztésre szorul“, ami e fölött van az piros – “Rosszul teljesítő”
– magyarra lefordítva: a felhasználó fent van a webshopban, nézelődik. Rábök egy kategóriára. A bökéstől az oldal válaszáig eltelt időt hívják FID-nek, tehát ez egyfajta reakcióidő. Mennyit kell várni a shopban, míg egyik helyről a másikra eljutok, vagy mennyi idő telik el míg megnyomom a kosárba gombot és a webáruház ténylegesen kijelzi, hogy a termék kosárba került. Tehát mennyi idő alatt reagál. Reakcióidő.
Itt olvashatsz róla angolul bővebben: https://web.dev/fid/
A FID-en való javítás is “általános” optimalizációs eszközökből áll: nem használt JavaScript-ek, nem használt CSS-ek kitörlése, a maradék, szükséges fájlok tömörítése és méretbeli optimalizálása, valamint megfelelő gyorsítótárazási (cache) megoldás használata.
VISUAL STABILITY (CLS)
– jelentése: elrendezés összmozgása
– mértékegysége nincs
– 0 – 0,1 számító JÓ-nak, 0,1 – 0,25-ig Fejlesztésre szorulónak és fölötte pedig Rossznak
– magyarra lefordítva: biztosan volt már rossz élményed azzal, hogy rányomtál volna valamire az oldalon, de az az utolsó ezredmásodpercben “elugrott”, és véletlenül mást találtál el az ujjaddal. Ez persze lehet szándékos is, de a legtöbbször csak gondatlan programozás vagy hanyag beállítás eredménye. Gyakori, hogy az oldal betöltődése közben a blokkok, képek, leírások, videók “mozognak” mígnem az oldal teljesen be nem töltődik és minden a helyére nem kerül. Ha ez társul egy kicsit lassabb mobilinternettel vagy telefonnal, akkor a felhasználó talán meg sem várja hogy az oldal rendesen betöltődjön, már bök – de az elem pont akkor csúszik a helyére és ezáltal másra bök rá. Az oldal betöltődése után is előfordulhatnak ilyen elugrások és mozgások, teszem azt reklám bekúszásakor vagy váltásakor, ezzel rossz felhasználói élményt okozva. A lenti Google-példában azt látni, hogy a potenciális vásárló meggondolja magát, mégsem akarja megrendelni a terméket, készül rábökni a “Mégsem” gombra, de a tartalom felett beugró reklámblokk pont egy gombmagassággal tolja lejjebb a tartalmat, ezáltal leadva a rendelést:
Ha a CLS 0, akkor egyáltalán nincs ilyesfajta mozgás, ugrálás az oldalon. A szám minél nagyobb, annál nagyobb a probléma ezen a téren.
A webes-vitals mutatóknak a magyar leírása részletesen elolvasható a Google súgójában: https://support.google.com/webmasters/answer/9205520?hl=hu
Fontos kiemelni, hogy több száz rangsorolási tényező létezik a Google képletében, algoritmusában. A keresőóriás azt nem árulja el, hogy a fentiek milyen súlyozásban, vagy hány százalékban játszanak döntő szerepet ebben. Amit tudunk azok a tapasztalatokon alapulnak.
És a jelenlegi tapasztalataink azt mutatják, hogy a Google folyamatosan vezeti be ennek a használatát és a szankcionálásokat is miatta. Tehát van olyan webáruház ahol már egy ideje mutatja a problémát, de mivel nem kerültek javításra ezért sorolja egyre hátrébb és hátrébb – és vannak olyanok, melyeknél még egyelőre fel sem mérte ezeket a mutatókat, ezáltal még nem mutat mérőszámokat.
Nézzük meg most a Google Search Console-t egy átlagos Prestashop esetében:
Sajnos az eredmény nem jó:
Van körülbelül ezer beindexelt URL a Google-nél, amivel a keresőóriás nincs megelégedve:
Egy része CLS, egy része LCP.
Ez azt jelenti, hogy sok a mobilos összmozgás – ergo az elemek, blokkok ugrálnak betöltés közben, vagy esetleg használat közben, így kockáztatva hogy a felhasználó rossz dologra bök rá.
Illetve az LCP azt, hogy sokáig tölt az oldal mobilon.
Nézzük meg, hogy milyen problémák okozzák a több mint 0.25-ös LCP-t!
A fenti videón egy Prestashop termékoldalán vagyunk. A webshopot kétszer is újratöltöttem a frissítés gombbal azt szimulálva, hogy most érkezünk meg. Amennyiben a termék több képből áll, akkor a többi kép kisképe (thumbnails) a főkép alatt helyezkedik el – ahogy egy átlagos 1.7-es Prestashop oldalon általában.
Viszont vegyük észre, hogy a kis termékképek betöltése elnyújtott – nyilván azért, hogy az oldal gyorsabbnak tűnjön (minél hamarabb legyen valami tartalom a szemünk előtt, a nem olyan fontos elemek betöltését késleltetik). Ezzel nincs is baj, azzal viszont már igen, hogy ezáltal ugrál a kép; mikor a böngésző betölti a kisképeket is, akkor a termék neve (és minden ami az alatt van) ugrik lefelé egyet a termékképek magasságával megegyező mértékben, megegyező pixelszámban (a példában egyébként 150 pixelnyi magasságot ugrik).
Ez viszont már LCP problémát produkál a Search Console-ban. Itt van az ugrás egy másik szögből (terméknévtől lefelé):
A Google Search Console szól, hogy mivel van gondja – tesztelni, javítani, méregetni és vizsgálódni viszont a PageSpeed Insights-al kell:
Adjuk meg azt az url-t, amivel a GSC-nek gondja van, majd elemezzük ki:
A példában szereplő mjgcards.com egy véletlenszerűen kiválasztott PS a Google-ből.
Hát túl jól nem szerepel. Az első részen ezt láthatjuk:
A CLS 0,55, ennek közel nullának kellene lennie, de maximum 0,1-nek.
Ha lejjebb görgetünk és rákattintunk a CLS fülre, megmutatja mi okozza a mozgásokat:
“A képelemekhez nem tartozik meghatározott width és height” azt jelenti, hogy x mennyiségű kép van az oldalon melyeknek nincs megadva a szélességük és a magasságuk. Ezáltal a böngésző kezdeti betöltési szakaszban még nem tudja, hogy a megadott képnek mekkora méretet foglaljon le az oldal egészéből – ezáltal nem biztosított az, hogy azok betöltődés után nem fognak “mozogni”.
Viszont ha a böngésző már az elején tudja, hogy oda a jobb sarokba le fog töltődni később egy banner 300 pixel szélességben és 200 pixel magasságban, akkor azt a helyet lefoglalja neki és ezáltal nem fog elugrani, más nem fogja feljebb/lejjebb tolni őt, mert mindenkinek megvan az elrendelt méretű helye előre.
A varázslat viszont itt történik: “Az elrendezés nagy mértékű mozgásának elkerülése.” Ha lenyitjuk, megmutatja hogy bizonyos blokkok mozgásai mekkora mértékben befolyásolják az LCP-t, ergo mekkora problémát jelent az oldalon.
Jól látni, hogy az első probléma több mint 0,2 CLS, második szintén és aztán kezd csökkenni a többi elem. Az első képen a termék adatlapját láthatjuk. A GSC azt akarja közölni, hogy ez a rész szenved; ezt a blokkot hányják-vetik betöltődés közben. Sokat nem kell agyalni, ha megnézzük a mobilnézetet újra-újratöltve, láthatjuk hogy a fejléc/header (logó, kereső, menü) később töltődik be mint az oldal, ezáltal a képen látható adatlap-részt dobálja:
CLS javítása
Minden esetben egyénileg kell megvizsgálni, hogy az adott CLS hiba milyen eredetű, hiszen ez erősen függ a témától, a PS verziószámától, a tartalomtól, programozástól, egyedi megvalósításoktól. Általánosságban elmondható, hogy a képek szélességének és magasságának megadása, valamint az animációk és ezáltal a mozgások elkerülése és javítása mindig jó eredményt hoz.
A fenti “Teszt termék”-es hiba például úgy lett kijavítva, hogy a kecske is jóllakjon, de megmaradjon a káposzta is. A kisképek megjelenítéséért felelős animációt nem vettük ki, viszont előre lefoglaltuk neki azt a 150 pixeles magasságot, így abba töltődik bele és nincs ugrálás:
Példák még CLS problémára Prestashop-ban
Az egyik, amit meg szeretnék mutatni a méltán híres Advanced Search 4 modul szűrője mobilon (itt a “Filtro” szó jelenti a szűrőt):
Itt azt látni, hogy a szűrőmodul lenyílva töltődik be – majd mielőtt teljesen betöltődne az oldal, becsukja magát, hiszen alapvetően becsukva kell megjelennie. Ha akarom használni, akkor lenyitom. Viszont ez pont elég ahhoz, hogy betöltés közben mozgasson mindent ami alatta van, ezzel 0,4-es CLS-t generálva. Megoldásként – csak mobilon – programozással megoldottuk, hogy betöltéskor eleve becsukódva érkezzen.
A másik pedig egy rekordtartó Prestashop a maga 0.7-es CLS-ével. Olyan témát használ (sablont, template-t), ami kategóriaoldalon magukat a termékeket egy animáció segítségével tölti be késleltetve, ezáltal többszörösen ugráltatva a fejlécet és a láblécet egyaránt. Sajnos csak egy screenshot-ot közölhetek, de azon látszik hogy egy animáció igyekszik betölteni az összes terméket:
És mivel ez a folyamat elhúzódik, dobálja a header-t és a footer-t egyaránt.
Összefoglaló
Kicsit hosszúra sikeredett, ezért elnézést kérek – nehéz egy ilyen komplex témáról írni. Ha summázni kellene a fent leírtakat, az alábbi módon tenném:
- nézd át a Google Search Console-odat, azon belül a “Navigációs útvonalak“, “Termékek” és “Véleményrészletek” részeket. Ha ott találsz hibát, haladéktalanul javítsd,
- ha a fentivel megvagy, akkor menj át a “Oldallal kapcsolatos felhasználói élmény mobilon“, az “Alapvető webes vitals-mutatók” és a “Mobilos használhatóság” részekre (amennyiben utóbbi menüpontban látsz linkeket, úgy az alábbi oldal segít a tesztelésben: https://search.google.com/test/mobile-friendly ).
Ha találsz problémákat, dolgozz össze a Google PageSpeed Insights-al és javítsd ki őket. Segítségedre lehet a Google Chrome Inspector-a (elemző vagy vizsgálat, ki hogy ismeri), a különböző elemzőoldalak (GTmetrix), és az olyan site-ok amik a nem használt CSS-t és/vagy JS-t kipucolására képesek (“unused css remover“), - ha úgy látod mindennel elkészültél, küldd be javításra a problémákat, valamint
- ne feledd, hogy több webes-vitals mutató a Google Search Console-ban 28 nap használati adataiból adódnak össze. Ez azt jelenti, hogy a javítások eredménye sokszor egy hónap múlva fog valósan megjelenni.
Ezen felül sok-sok kitartást kívánok a fentiekhez, mert bizony néhány dolgot nagyon nehéz megoldani – ha egyáltalán meglehet. Én hiszem, hogy érdemes – és előbb utóbb megkerülhetetlenül szükségszerű lesz – foglalkozni a webes vitals-mutatókkal, mivel ez szolgálja a felhasználók igényeit. Önmagában az már elmond szinte mindent, hogy a legtöbb webáruházat 70-80%-ában már mobilról látogatják.
