Wordpress

Bevezetés a PageSpeed ​​alapvető webes létfontosságú elemeibe

Barış Ünver az Optimocha, egy személyre szabott WordPress sebességoptimalizáló szolgáltatás alapítója, és a Speed ​​Booster Pack bővítmény tulajdonosa.

Az algoritmus 2021. júniusi frissítése óta a Google az oldallal kapcsolatos élményt a SEO szempontjából fontos tényezőnek tekinti. És ennek az „Oldalélmény-frissítésnek” az egyik legkritikusabb része az, amit a Google nevez Core Web Vitalok.

Ebben a bejegyzésben áttekintjük, mi ez, és megértjük, miért számítanak az egyes mutatók.

Mi az a „Core Web Vitals”?

Core Web Vitalok
Kép forrása: web.dev

A Google így írja le a Core Web Vitals-t, ezért azt hiszem, a legjobb, ha egy idézettel kezdünk:

(…) A Core Web Vitals mindegyike a felhasználói élmény egy-egy külön oldalát képviseli, a terepen mérhető, és egy kritikus, felhasználó-centrikus eredmény valós élményét tükrözi.

A Core Web Vitals-t alkotó mutatók idővel fejlődni fognak. A jelenlegi, 2020-ra szóló készlet a felhasználói élmény három aspektusára összpontosít:betöltés, interaktivitásés vizuális stabilitás– és a következő mutatókat (és a hozzájuk tartozó küszöbértékeket) tartalmazza:

  • Legnagyobb tartalmas festék (LCP): terhelési teljesítményt mér. (…)
  • Első bemeneti késleltetés (FID): interaktivitást mér. (…)
  • Összesített elrendezés -eltolás (CLS): a látás stabilitását méri. (…)

Ha kombinálja ezt az információt a Google bejelentésével, miszerint a CWV a SERP-k rangsorolási tényezője, és arra a következtetésre juthat, hogy a Google szerint az LCP, a FID* és a CLS a legfontosabb UX mérőszámok a SEO számára.

* Megjegyzés a FID-ről a Google-tól: „A FID-hez valós felhasználóra van szükség, ezért laboratóriumban nem mérhető. A teljes blokkolási idő (TBT) mérőszáma azonban laboratóriumban mérhető, jól korrelál a FID-vel a helyszínen, és rögzíti az interaktivitást befolyásoló problémákat is. Azok az optimalizálások, amelyek javítják a TBT-t a laboratóriumban, a felhasználók FID-jét is javítják.”

Nézzünk egy kicsit részletesebben az egyes mutatókba.

Legnagyobb tartalmas festék (LCP)

LCP
Kép forrása: web.dev

Ahogy a neve is sugallja, ez a mérőszám a legnagyobb elem betöltési sebességét méri (pixelben) a tartalommal a nézetablakon belül. A Google úgy dönt, hogy ez a legnagyobb mutatója az oldal észlelt sebességének, és többnyire igazuk van: Amikor a legnagyobb elem, például egy bekezdés vagy egy hőskép betöltődik, agyunk érzékeli, hogy az oldal betöltődött és elérhető számunkra.

Az LCP fejlesztése leginkább a renderelési akadályok megszüntetéséről és az eszközök (CSS, JS, képek, betűtípusok stb.) letöltésének elhalasztásáról szól. Ez az oka annak, hogy az eszközök minimalizálása és az olyan módszerek alkalmazása, mint a kritikus CSS, a lusta betöltés és a JavaScript-halasztás kulcsfontosságú ehhez a mutatóhoz.

Első beviteli késleltetés (FID) és teljes blokkolási idő (TBT)

FID
Kép forrása: web.dev

Valószínűleg ez a legnehezebben érthető és a legnehezebben javítható mutató a három közül. (Úgy tűnik, ennek mérésére még a Google is nehezen talált módot, így azt is mondhatjuk, hogy ez a legnehezebben mérhető.)

Még a legtapasztaltabb teljesítményoptimalizálási szakértők is nehezen tudják ezt elmagyarázni, ezért bocsáss meg, ha halandzsázok.

Ha a látogató interakcióba lép az oldallal, ha a böngésző „főszála” (amely alapvetően az egész weboldalt elemzi) 50 ezredmásodpercnél tovább tart, a Google a főszálat „blokkoltnak” tekinti, és a folyamatot „Hosszú feladatként” címkézi. ”.

Méri a fő szálfeladatok időtartamát (minden feladatnál mínusz 50 ms), és összegzi, hogy „teljes blokkolási időnek” nevezze. Ennek a mutatónak a javítása elengedhetetlen ahhoz, hogy a felhasználó a lehető legkorábban kapcsolatba lépjen az oldallal, és ez az „első beviteli késleltetés” lényege.

Bonyolult? Teljesen. Nehéz javítani? Fogadj. De meg lehet csinálni? N – igen. Ez azonban megköveteli a JavaScript használatának kíméletlen megszüntetését, így az analitikai eszközök, a nyomkövetési pixelek, a cookie-k beleegyezési sávjai, az élő csevegési widgetek és egyebek drámaian rontják ezt a két mutatót.

Halmozott elrendezéseltolás

CLS
Kép forrása: web.dev

Valaha meg akart koppintani egy menügombot, de rájött, hogy egy olyan hirdetésre koppintott, amely a semmiből jelent meg a másodperc töredéke alatt, amikor úgy döntött, hogy megérinti, és megérinti? Ez az, amit az elrendezésváltás; a „halmozott elrendezési eltolás” pedig (nyilvánvalóan) az adott oldalbetöltés során az összes elrendezés eltolódásának összege.

A CLS fejlesztése a hajtás feletti elemek teljesítményének javításáról szól. A képek és betűtípusok előbetöltése, az üres hely kiosztása a hirdetések számára, a kritikus CSS és hasonlók mind hozzájárulnak a jobb CLS-méréshez.

(Személy szerint szerintem ez egyáltalán nem kapcsolódik az oldal teljesítményének optimalizálásához – úgy értem, ez még csak nem is időalapú mérés! Szóval nem értek egyet a Google-lal abban, hogy ez egy „oldal”Sebesség” mutató, de mindenképpen fontos mérőszám a felhasználói élmény javítása érdekében.)

Következtetés: Hogyan közelítsük meg a PageSpeed ​​és a Core Web Vitals értéket

Jelenleg, a Lighthouse 8-as verziójában ez a három mutató az oldal PageSpeed ​​pontszámának (forrás) 70%-át teszi ki. Azonban, ahogy a Google mondja (a fenti idézetben), a PageSpeed ​​folyamatosan fejlődik; így várható, hogy ez a jövőben megváltozik.

És vegye figyelembe, hogy a PageSpeed ​​pontszámok egyre értelmetlenebbek! Ne feledje, hogy ha optimalizálni próbálja webhelyét SERP-rangsorának javítása érdekében, a Core Web Vitals az egyetlen olyan mérőszám, amelyet szemmel kell tartania. A 100%-os PageSpeed-pontszámok megszállottsága az összes oldalon nemcsak értelmetlen, hanem káros is!

Ha többet szeretne megtudni webhelye optimalizálásával kapcsolatban, látogasson el az Optimocha.com oldalra, és ne habozzon kapcsolatba lépni a Barış Ünverrel a LinkedIn-en.

Kapcsolódó cikkek

0 Hozzászólások
Inline visszajelzések
Az összes hozzászólás megtekintése
Vissza a lap tetejére gombra