A PageSpeed Insights értelmezése: Core Web Vitals közérthetően
Ön tesztelte a weboldalát a PageSpeed Insights szolgáltatásban, és egy piros számot lát, például 45-öt. Mit jelent ez, és mennyire súlyos? Ebben a cikkben olvashat arról, hogyan értelmezze a jelentést, mit mér a három Core Web Vitals mutató, és mit javíthat Ön maga.
A három mérés
| Mérés | Mit mér | Jó | Javítás szükséges | Rossz |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Milyen gyorsan jelenik meg a legnagyobb tartalomrész, gyakran a nagy kép a tetején | 2,5 mp-ig | 2,5 és 4 mp között | 4 mp felett |
| INP (Interaction to Next Paint) | Milyen gyorsan reagál az oldal kattintásra, koppintásra vagy gépelésre | 200 ms-ig | 200 és 500 ms között | 500 ms felett |
| CLS (Cumulative Layout Shift) | Mennyit ugrik az oldal betöltés közben (egy pontszám, nem idő) | 0,1-ig | 0,1 és 0,25 között | 0,25 felett |
Egy oldal akkor teljesíti a Core Web Vitals mutatókat, ha a látogatások legalább 75 százaléka jól teljesít mindhárom mutatón, külön mobil és asztali nézetben. Tehát nem az Ön gyors számítógépe számít, hanem a legtöbb látogató tapasztalata, akár egy régebbi telefonon is. Az INP 2024 márciusában váltotta fel a korábbi FID mérést. Ha még találkozik az FID jelöléssel, az elavult információ.
Mezőadatok és laboradatok
A PageSpeed Insights kétféle mérést mutat, és ezek gyakran eltérő számokat adnak:
- Mezőadatok (felül): valós látogatóktól származó mérések Chrome böngészővel, az elmúlt 28 napból. Ez határozza meg, hogy teljesíti-e a Core Web Vitals mutatókat. Ha az oldalnak túl kevés látogatója van, akkor a teljes weboldal adatait látja, vagy egyáltalán nincs mezőadat.
- Laboradatok (alatta): egy Lighthouse teszt, amely egyszer tölti be az oldalt egy szimulált, közepes teljesítményű telefonon és kapcsolaton. Innen származik a 0 és 100 közötti szám. A Lighthouse nem tudja mérni az INP-t, mivel nincs valódi kattintás.
Használja a laboradatokat az okok felderítésére, és hogy egy javítás után azonnal lássa, segített-e. Kezdje a Mobil fülnél: ott általában rosszabb az eredmény, és a Google elsősorban a weboldal mobil verzióját veszi figyelembe.
Mekkora súlya van ennek a Google-nél?
A Google szerint a Core Web Vitals mutatók beleszámítanak a rangsorolásba. A Google azonban mindig a legrelevánsabb tartalmat mutatja, akkor is, ha az az oldal nem a leggyorsabb. A 0 és 100 közötti szám a laborteszt eredménye, és nem a Google értékelése; az értékelés a mezőadatokból származik. A tökéletes pontszám elérése kizárólag a Google miatt a Google szerint sem a legjobb időbefektetés. Ügyeljen rá, hogy a zöld, vagy legalább a narancssárga tartományban legyen, különösen azért, mert a látogatók elpártolnak egy lassú vagy ugráló oldaltól.
Mit javíthat az oldalon belül
- Kisebb képek. Egy több ezer pixel széles fotó egy 800 pixeles területhez a leggyakoribb oka a lassú LCP-nek. Kicsinyítse le a képeket feltöltés előtt, és használjon modern formátumot, mint a WebP vagy az AVIF.
- Szélesség és magasság minden képnél. A
widthésheightattribútumok nélkül a böngésző nem tudja, mekkora helyre van szüksége egy képnek, és a szöveg elugrik, amikor a kép betöltődik. Ez növeli a CLS értéket:<img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">
- A legfontosabb kép ne legyen lusta betöltésű. A
loading="lazy"jól alkalmazható a lejjebb lévő képekre, de nem arra a képre, amely már a megnyitáskor látható. Ellenkező esetben a böngésző pont azzal a képpel várakozik, amely az LCP-t meghatározza. - Ne szúrjon be semmit utólag a tartalom fölé. Egy sütisáv, hirdetés vagy widget, amely lejjebb tolja az oldalt, mindent elugrat. Az ilyen sávot inkább helyezze az oldal fölé rétegként.
- Kevesebb külső szkript. A rossz INP szinte mindig a túl sok JavaScript miatt alakul ki: nehéz sablonok, csúszkák, csevegőablakok és nyomkövetők. Vizsgálja kritikusan minden bővítményt és beágyazott szolgáltatást.
Mit tesz a szerver
Minden a szerver első válaszával kezdődik, a Time to First Byte (TTFB) mutatóval. Ez önmagában nem Core Web Vital mutató, de egy lassú első válasz esetén a jó LCP szinte lehetetlen. Irányadó értékként 0,8 másodperc vagy kevesebb számít jónak. Az okok gyakran a gyorsítótár hiánya, kevés számítási kapacitás vagy átirányítások. A szervernek a szöveges fájlokat tömörítve kell küldenie (gzip vagy Brotli tömörítéssel). Arról, hogyan kezelje a szerveroldali teendőket, olvasson bővebben itt: A weboldalam lassú, vagy túl sok CPU-t használ: így tehető gyorsabbá és a DirectAdmin kézikönyvben: A weboldalam lassú.
Az AI Bouwer-ben és WordPress-ben
Az AI Bouwer által készített weboldal beállítja a szélességet és magasságot azoknál a képeknél, amelyeknek ismert a mérete, az oldal első képét azonnal és elsőbbséggel tölti be, a többit pedig csak akkor, amikor láthatóvá válnak, és közzétételkor kisebb verziót készít a nagy képekről. WordPress esetében egy gyorsítótár bővítmény és a képek kicsinyítése segít a legtöbbet. Erről bővebben olvashat az ingyenes WordPress tanfolyamban, a következő leckékben: Mitől lesz lassú egy weboldal, és hogyan mérhető? és Képek, PHP és egyéb sebességnövelő megoldások.