Tényleg lassú? Így mérje meg 10 perc alatt
PageSpeed Insights: kétféle adat egy oldalon
Írja be az oldal címét a Google ingyenes PageSpeed Insights eszközébe. Külön nézze meg a mobil és az asztali eredményt. Az oldal tetején a valós felhasználók adata áll (terepi adat, a Chrome felhasználói élmény jelentéséből, az utolsó 28 nap alapján), alatta egy egyszeri laboratóriumi mérés. A kettő nem ugyanaz: a terepi adat azt mutatja, amit a látogatói tényleg megtapasztalnak, a laboratóriumi mérés pedig azt, hol lehet javítani. Kis forgalmú oldalnál terepi adat nincs, ilyenkor csak a laboratóriumi mérés látszik.
A 0 és 100 közötti pontszámot ne vegye túl komolyan. Mérésről mérésre ingadozik. Egy 70 pontos oldal is lehet gyors a látogatóknak. Többet mond az alatta lévő néhány mutató.
Core Web Vitals érthetően
A Google három mutatóval méri, milyen élmény egy oldalt használni. Az értékeket a látogatások 75%-ára kell teljesíteni:
| Mutató | Mit mér | Jó | Gyenge |
|---|
| LCP (Largest Contentful Paint) | Mikor jelenik meg a legnagyobb tartalmi elem, jellemzően a fő kép vagy a cím | legfeljebb 2,5 mp | 4 mp felett |
| INP (Interaction to Next Paint) | Mennyi idő telik el egy kattintás és a látható reakció között | legfeljebb 200 ms | 500 ms felett |
| CLS (Cumulative Layout Shift) | Mennyit ugrál a tartalom betöltés közben | legfeljebb 0,1 | 0,25 felett |
Az INP 2024 márciusában váltotta az FID mutatót, ezért régebbi cikkekben még FID szerepelhet. A küszöbértékek a Google web.dev oldaláról származnak.
A szerver válaszideje (TTFB)
A „Time to First Byte” azt méri, mennyi idő alatt küldi el a szerver az első bájtot. Ha ez magas, a böngésző hiába gyors, mindenre várnia kell. A Google útmutatója szerint a jó érték legfeljebb 0,8 másodperc. Ha a PageSpeed Insights „Csökkentse a szerver válaszidejét” javaslatot ad, a gond a szerveren vagy az alkalmazásban van, nem a képeken.
A Search Console jelentése
A Google Search Console „Core Web Vitals” jelentése oldalcsoportonként mutatja, mely URL-ek jók, melyek javítandók. Ez azért hasznos, mert nem csak a kezdőlapot látja, hanem például az összes termékoldalt egyszerre.
A nyolc leggyakoribb ok, hatás szerint
1. Túlterhelt tárhely, lassú adatbázis
Osztott tárhelyen egy másik ügyfél forgalmi csúcsa az Ön oldalát is lelassítja, a csomag pedig korlátozza a processzort és a memóriát. Tünete a magas TTFB (főleg csúcsidőben) és a lassú admin felület. A megoldás a jobb tárhely vagy egy saját erőforrású VPS szerver.
2. Nincs oldal-gyorsítótár
Gyorsítótár nélkül a szerver minden látogatónak újra összerakja az oldalt az adatbázisból. WordPressen erre gyorsítótár-bővítmény való, nagyobb rendszer elé (például Magento webáruház elé) Varnish kerül, amely a kész oldalt a memóriából szolgálja ki. Ez sokszor az egyetlen legnagyobb nyereség.
3. Optimalizálatlan képek
Egy fényképezőgépből feltöltött 5 megabájtos kép egy telefonon is 5 megabájt marad. A képet a megjelenítési méretre kell kicsinyíteni, modern formátumba (WebP vagy AVIF) alakítani, a hajtás alatti képeket pedig csak görgetéskor betölteni.
4. Túl sok bővítmény, oldalépítő kódja
Minden bővítmény hozhat saját CSS- és JavaScript-fájlt, amelyek gyakran olyan oldalakon is betöltődnek, ahol nincs rájuk szükség. Az oldalépítők (Elementor, Divi és társaik) kényelmesek, de sokkal több kódot generálnak, mint egy kézzel írt sablon.
5. Külső szkriptek
Csevegőablak, térkép, videó, közösségi beágyazás, hirdetési és mérőkódok: mind egy-egy külső szerverről töltődik be és mind a böngésző idejét viszi. Érdemes átnézni, melyikre van valóban szükség. A többit csak interakcióra betölteni.
6. Régi PHP-verzió
A PHP újabb verziói érezhetően gyorsabbak és biztonságosabbak. Ha az oldal egy már nem támogatott verzión fut, a frissítés gyorsít is, de előtte ellenőrizni kell, hogy a sablon és a bővítmények kompatibilisek-e.
7. Elhízott adatbázis
Évek alatt felgyűlnek a bejegyzés-változatok, az ideiglenes adatok és a már törölt bővítmények beállításai. WordPressen különösen az automatikusan betöltött beállítások mérete számít, mert ezek minden oldalbetöltésnél beolvasódnak.
8. Ugráló elrendezés (CLS)
Ha egy kép vagy egy sáv méret nélkül kerül az oldalba, a böngésző csak a betöltés után tudja, mekkora helyet foglal. Addig a szöveg arrébb ugrik. A javítás: minden képnek és beágyazásnak szélesség és magasság, a később megjelenő sávoknak előre fenntartott hely.
Mit tehet meg maga és mi fejlesztői munka?
| Feladat | Ön is meg tudja csinálni | Szakember kell hozzá |
|---|
| Képek | Kisebb képek feltöltése, felesleges képek törlése | Automatikus WebP és AVIF konverzió, reszponzív képméretek |
| Bővítmények | A nem használt bővítmények kikapcsolása | A szükséges bővítmények kódjának betöltése csak ott, ahol kell |
| Külső szkriptek | Döntés, melyik csevegő, térkép vagy követőkód kell valóban | Késleltetett betöltés, szerveroldali mérés |
| Gyorsítótár | Gyorsítótár-bővítmény bekapcsolása alapbeállítással | Varnish, Redis, a kizárások (kosár, fiók) helyes beállítása |
| Szerver | Tárhelycsomag emelése | PHP-frissítés, adatbázis-hangolás, költözés saját szerverre |
Milyen sorrendben javítson?
- Először a szerver: ha a TTFB magas, minden más javítás csak részleges. Gyorsítótár, PHP-verzió, szükség esetén jobb tárhely.
- Utána a képek: ez a leggyakoribb oka a rossz LCP-nek és gyorsan javítható.
- Aztán a JavaScript: bővítmények, oldalépítő, külső szkriptek. Ez javítja az INP-t.
- Végül a CLS: méretek és fenntartott helyek, általában néhány sablonmódosítás.
- Minden lépés után mérjen: így látja, melyik javítás mit hozott.
Mi a saját rendszerünkben több gyorsítótár-réteget (APCu, Redis, Varnish), automatikus AVIF és WebP konverziót és minimális JavaScriptet használunk. WordPress oldalaknál a meglévő oldal átvételével, gyorsításával és karbantartásával foglalkozunk, erről a WordPress honlapkészítés oldalon olvashat bővebben.