A legnagyobb vizuális tartalomválasz definíciója és szerepe

Legnagyobb vizuális tartalomválasz (LCP) – minden, amit tudnod kell róla

<p style="text-align:justify">A legnagyobb vizuális tartalomválasz 2021-ben csatlakozott a Google rangsoroló algoritmusához a három alapvető webes vitals-mutató egyikeként. Ezek a mutatók a weboldalak technikai teljesítményére koncentrálnak, amely közvetlen hatással van a felhasználói élményre.</p> <p>Az alapvető webes vitals-mutatók szerepe a mai napig tisztázatlan a SEO közösségben, és ehhez a Google is hozzájárul. A keresőóriás egyfelől átfogó eszközöket és útmutatókat kínál a mutatók méréséhez és javításához, de másfelől azt is állítja, hogy nem olyan fontosak a rangsorolásban.</p> <p>Akármi is legyen az igazság, a legnagyobb vizuális tartalomválasz egy hasznos mutató a weboldalak teljesítményének és felhasználóbarát jellegének felmérésére.</p>

Mi az a legnagyobb vizuális tartalomválasz?

A legnagyobb vizuális tartalomválasz (largest contentful paint, röviden LCP) azt mutatja meg, hogy mennyi időbe telik egy oldal fő tartalmának betöltése, mielőtt az készen állna a felhasználói interakciókra.

Az LCP egész pontosan azt méri, hogy mennyi idő telik el az oldal betöltésének kezdete és a viewportban látható legnagyobb vizuális elem megjelenése között. A hajtás alatti részen megjelenő elemek tehát nem befolyásolják az LCP-t, csak azok, amik rögtön láthatók a felhasználónak, amikor az oldalra érkezik.

A legnagyobb vizuális elem lehet például egy kép (elhelyezett vagy háttérkép), egy videó, vagy valamilyen blokkszintű elem (pl. egy hosszabb bekezdés) és így tovább.

A legnagyobb vizuális tartalomválaszt másodpercekben mérjük, és 2,5 másodpercnél alacsonyabb értékek számítanak ideálisnak.

 

Miből áll össze a legnagyobb vizuális tartalomválasz?

A legnagyobb vizuális tartalomválasz további almutatókra osztható szét ismerkedjünk meg ezekkel közelebbről is:

 

Első bájtig eltelt idő

Az első bájtig eltelt idő (time to first byte, röviden „TTFB”) a szerver válaszadási idejét méri, pontosabban, hogy mennyi idő kell ahhoz, hogy a felhasználó böngészője megkapja a szerver által visszaküldött első bájtot. Ebbe beletartozik a DNS felkutatási ideje, a kérés feldolgozásához szükséges idő (a szerver részéről) és az esetleges átirányításokkal eltelt idő is.

Az első bájtig eltelt idő optimalizálásával jelentősen javítható a webhely betöltési sebessége, és ez által az LCP is.

A szerver válaszideje főleg a következőktől függ:

• Adatbázis-lekérdezések
• CDN gyorsítótár hiányosságai
• Nem megfelelő szerveroldali renderelés
• A webtárhely minősége

 

1. Adatbázis-lekérések

Ha a szerver válaszideje túl hosszú, akkor meglehet, hogy adatbázis-lekéréseid nincsenek megfelelően optimalizálva, a szerver nem képes egyszerre az összes lekérést kiszolgálni. Egy MySQL adatbázisban megtekintheted a lassú lekérdezésekről készült naplót, hogy azonosíthasd az ilyen problémákat.

 

2. CDN gyorsítótár hiányosságai

Előfordulhat, hogy egy CDN-től (tartalomelosztó rendszertől) olyan erőforrás kér egy böngésző, ami nem szerepel a CDN adatbázisában. Ilyenkor a CDN továbbítja a kérést a szervernek. Ez a folyamat plusz időbe kerül, lassítva ezzel az oldalak betöltését. Ez az úgynevezett „CDN cache miss”.

Az általad használt CDN szolgáltatónak valószínűleg van valamilyen felülete vagy jelentése, ami felsorolja az ilyen cache miss eseteket.

Ha átlag feletti (10%-nál magasabb) hibaarányt látsz, akkor fel kell venned a kapcsolatot a CDN-nel.

A cache miss hibákat előidézheti az is, ha valaki szándékosan támadja webhelyed belső keresőmotorját mindenféle véletlenszerű lekérdezéssel, amelyek eredményei nincsenek gyorsítótárazva, hiszen nem is léteznek. Az ilyen oldalakat a Googlebot is megpróbálja majd feltérképezni, ami lassítja a szerver válaszidejét, növeli a cache miss hibák számát, pazarolja a feltérképezési keretet és így tovább.

Ilyen esetben érdemes kitiltani a keresőmotorokat a belső keresőoldalak találati oldalairól a robots.txt fájl segítségével. Azonban még ha így is teszel, ezek az URL-ek indexelésre kerülhetnek, ha más, rosszabb minőségő webhelyek valamiért mégis linkelnek rájuk. Szerencsére ez nem jelent hosszútávú problémát, amiről John Mueller, a Google egyik munkatársa is beszélt már.

 

3. Nem megfelelő szerveroldali renderelés

Webhelyeden több olyan komponens is szerepelhet, amelyek harmadik felektől származó API-któl függenek.

Számos webhelyen láthatók például megtekintési és megosztási számlálók, amiket a webhely egy külső forrásból (pl. a Google Analyticstől) kér le. Ha ezek az adatok minden egyes oldalbetöltésnél lekérésre kerülnének, az jelentősen lassítaná a webhely működését. Éppen ezért sok webhely a háttérben adott időközönként lekéri ezeket az értékeket és eltárolja őket egy adatbázisban, ahonnan sokkal gyorsabban lekérheti és megjelenítheti őket.

 

4. A webtárhely minősége

A webtárhely az első bájtig eltelt idő mutató talán legfontosabb befolyásoló tényezője. Egy színvonalas webtárhely akár többszörösére is gyorsíthatja a TTBF-et.

Ideális esetben olyan webtárhelyt válassz, ami CDN-t és gyorsítótárazást is kínál. Így egy szolgáltató kezel majd mindent és ennyivel kevesebb előfizetésre kell odafigyelned.

 

Erőforrásbetöltés késése

Az erőforrásbetöltés késése (resource load delay) azt mutatja meg, hogy mennyi időbe telik a böngésző számára, hogy megtalálja és elkezdje letölteni az oldal legnagyobb tartalomelemét.

Ha például a legnagyobb tartalomelem egy olyan kép az oldal tetején, aminek a megkereséséhez egy CSS fájlra is szükség van, akkor a késésbe beleszámít majd az az idő is, amíg a CSS fájl betöltésre és átvizsgálásra kerül.

Ha a legnagyobb tartalomelem egy szimpla szöveg, akkor ez a késési idő szinte mérhetetlenül rövid lesz.

Ha sikerül optimalizálnod az ilyen elemek és erőforrások megkereséséhez és betöltéséhez szükséges időtartamokat, akkor felgyorsíthatod az oldalak legfontosabb tartalmainak betöltését.

Az egyik opció a fetchpriority=”high” attribútumot használni a hivatkozott stílusfájlok HTML elemein és a nagyobb képeken, hogy a böngésző először az ilyen hajtás feletti elemeket kezdje el betölteni.

Egy még jobb megoldás inline CSS-t alkalmazni a hajtás felett elhelyezkedő elemeken, hogy a böngészőnek a különálló CSS fájlokat se kelljen betöltenie ezek megfelelő megjelenítéséhez.

Na persze, weboldalaidat úgy is felépítheted, hogy ne legyen szükség ilyen nagyobb elemek betöltésére a hajtás felett, ami jelentősen felgyorsítja majd a betöltést, javítva ezzel nem csupán az alapvető webes vitals-mutatókat, hanem a felhasználói élményt is.

Az oldalak betöltését továbbá az átirányítások is késleltethetik. A más webhelyektől kapott visszahivatkozásokat nem igazán befolyásolhatod, de a belső linkjeid működéséért már te felelsz. Próbáld felkutatni az összes olyan belső hivatkozást webhelyeden, amelyek valami miatt átirányításra kerültek, és cseréld le őket közvetlen linkekre. Ebben számos ingyenes és fizetős SEO eszköz lehet a segítségedre.

 

Erőforrásbetöltés ideje

Az erőforrásbetöltés ideje (resource load duration) arra az időtartamra vonatkozik, ami a legnagyobb tartalomelem betöltéséhez ténylegesen szükséges.

Még ha a böngészőnek sikerül gyorsan rátalálni a kért erőforrásokra és rögtön el is tudja kezdeni azok letöltését, a lassú letöltési sebességek jelentősen ronthatják az LCP mutatót. Ez függ az erőforrások méretétől, a szerver hálózati sebességétől és a felhasználó eszközétől, illetve hálózatának teljesítményétől is.

Az erőforrásbetöltés idejét többek között az alábbiakkal javíthatod:

• WebP formátumú képekkel
• Megfelelő méretű képekkel (ne használj nagyobb felbontást, mint amekkora szükséges)
• A fontosabb erőforrásoknál a fetchpriority=”high”, a kevésbé fontosaknál a fetchpriority=”low” attribútumok használatával
• Egy jó CDN alkalmazásával

 

Elemmegjelenés késése

Az elemmegjelenés késése (element render delay) azt mutatja meg, hogy mennyi időre van szüksége a böngészőnek a legnagyobb tartalomelem feldolgozásához és megjelenítéséhez (rendereléséhez).

Ezt a mutatót a HTML, a CSS és a JavaScript összetettsége befolyásolja.

A renderelést gátló erőforrások számának csökkentésével, illetve a forráskódok általános optimalizálásával csökkenthető ez a késési idő. Előfordulhat például, hogy olyan JavaScript fut a háttérben, ami akadályozza a fő szál futását, és ezzel a legnagyobb tartalomelem megjelenítését is, amíg más feladatok be nem fejeződnek.

Érdemes szemmel tartani a teljes blokkolási időt (total blocking time, azaz TBT), mert ez mutatja meg, hogy mennyi időre kerül blokkolásra a fő szál, míg más, hosszabb folyamatok le nem futnak az oldal betöltése során. Ha ez az időtartam túl magas, akkor optimalizálnod kell JavaScript forráskódodat.

 

Egy fontos dolog az elemek mozgásával kapcsolatban

A felhasználó képernyőjén (egész pontosan a viewportban) minden elem részt vesz az LCP kiszámításában. Ez azt jelenti, hogy azok a képek, amik eredetileg a viewporton kívül kerülnek megjelenítésre, majd úgy mozdulnak el, hogy láthatóvá váljanak a hajtás felett már nem számítanak bele az LCP pontszámba.

Azonban ez fordítva is igaz – ha egy elem a viewporton belül kezd el megjelenni, majd elmozdul, és eltűnik abból, ugyanúgy beleszámít majd az LCP kiszámításába.

 

Hogyan mérhető a legnagyobb vizuális tartalomválasz?

A legnagyobb vizuális tartalomválasz, azaz az LCP értéke két fő módszerrel mérhetők – ezek a „lab” és „field” eszközöket használó módszerek.

A „field” eszközök egy webhely tényleges teljesítményét mérik.

A „lab” eszközök szimulációkat futtatnak különféle feltételezett tényezők használatával (egy átlagos internetsebességű mobilhasználó szemszögéből).

A legnagyobb vizuális tartalomválasz értéke megtekinthetők a Google Search Console felületén, illetve a Google PageSpedd Insights oldalelemzés eredményei között.