Barry Pollard, a Google Chrome Web Performance Developer Advocate elmagyarázta, hogyan lehet megtalálni a gyenge Lowest Contentful Paint pontszám valódi okait, és hogyan lehet ezeket orvosolni.
Legnagyobb tartalmat tartalmazó festék (LCP)
Az LCP egy alapvető webes vitals mérőszám, amely azt méri, hogy mennyi ideig tart a legnagyobb tartalomelem megjelenítése a webhely látogatóinak nézetablakban (a felhasználó által a böngészőben látható rész). A tartalomelem lehet kép vagy szöveg.
Az LCP esetében a legnagyobb tartalomelemek a blokkszintű HTML elemek, amelyek vízszintesen a legnagyobb helyet foglalják el, például a bekezdés
címsorok (H1 – H6) és képek (alapvetően a legtöbb HTML-elem, amely nagy vízszintes helyet foglal el).
1. Tudja, milyen adatokat néz
Barry Pollard azt írta, hogy a kiadók és a keresőoptimalizálók egy gyakori hiba, amelyet azután követnek el, hogy látják, hogy a PageSpeed Insights (PSI) egy oldalt gyenge LCP-pontszámmal jelöl meg, hogy a Lighthouse eszközzel vagy a Chrome Dev Tools segítségével kijavítják a hibát.
A Pollard azt javasolja, hogy ragaszkodjon a PSI-hez, mert számos tippet kínál a gyenge LCP teljesítményt okozó problémák megértéséhez.
Fontos megérteni, milyen adatokat ad meg a PSI, különösen a Chrome felhasználói élmény jelentéséből (CrUX) származó adatokat, amelyek anonimizált Chrome látogatói pontszámokból származnak. Kétféle létezik:
- URL-szintű adatok
- Eredeti szintű adatok
Az URL-szintű pontszámok a hibakeresés alatt álló konkrét oldalra vonatkozó pontszámok. Az eredetszintű adatok a teljes webhely összesített pontszámai.
A PSI URL-szintű adatokat jelenít meg, ha elegendő mért forgalom érkezik egy URL-hez. Ellenkező esetben Eredeti szintű adatok (az összesített webhelyszintű pontszám) jelennek meg.
2. Tekintse át a TTFB pontszámot
Barry azt javasolja, hogy vessen egy pillantást a TTFB (Time to First Byte) pontszámára, mert szavai szerint „a TTFB az első dolog, ami az oldalával történik.”
A bájt a digitális adat legkisebb egysége a szöveg, a számok vagy a multimédia megjelenítéséhez. A TTFB megmondja, mennyi időbe telt, mire a szerver válaszol az első bájttal, és felfedi, hogy a szerver válaszideje okozza-e a gyenge LCP-teljesítményt.
Azt mondja, hogy a weboldal optimalizálására irányuló erőfeszítések összpontosítása soha nem fogja megoldani azt a problémát, amely egy rossz TTFB-sebben gyökerezik.
Barry Pollard ezt írja:
„A lassú TTFB alapvetően két dolog közül egyet jelent:
1) Túl sokáig tart a kérés elküldése a szervernek
2) A szerver túl sokáig tart a válaszadáshozDe hogy melyik az (és miért!), nehéz kitalálni, és van néhány lehetséges oka az egyes kategóriáknak.”
Barry folytatta LCP hibakeresési áttekintését konkrét tesztekkel, amelyeket alább vázolunk fel.
3. Hasonlítsa össze a TTFB-t a Lighthouse Lab Testtel
Pollard azt javasolja, hogy végezzen tesztelést a Lighthouse Lab Tests-szel, különösen az „Initial server response time” audittal. A cél annak ellenőrzése, hogy a TTFB-probléma megismételhető-e, hogy elkerülhető legyen a PSI-értékek véletlenszerűsége.
A laboratóriumi eredmények szintetikusak, nem a tényleges felhasználói látogatásokon alapulnak. A szintetikus azt jelenti, hogy egy Lighthouse-teszt által kiváltott látogatáson alapuló algoritmus szimulálja őket.
A szintetikus tesztek hasznosak, mert megismételhetők, és lehetővé teszik a felhasználó számára, hogy elkülönítse a probléma konkrét okát.
Ha a Lighthouse Lab Test nem replikálja a problémát, az azt jelenti, hogy a probléma nem a szerverben van.
Azt tanácsolta:
„A legfontosabb dolog itt annak ellenőrzése, hogy a lassú TTFB megismételhető-e. Tehát görgessen lefelé, és nézze meg, hogy a Lighthouse laboratóriumi teszt megfelelt-e ennek a lassú, valós felhasználói TTFB-nek, amikor tesztelte az oldalt. Keresse meg a „Kezdeti szerver válaszidő” naplót.
Ebben az esetben ez sokkal gyorsabb volt – ez érdekes!”
4. Szakértői tipp: Hogyan ellenőrizhető, hogy a CDN nem rejteget-e problémát
Barry kitűnő tippet adott a Content Delivery Networks (CDN), például a Cloudflare kapcsán. A CDN megőrzi a weboldal másolatát az adatközpontokban, ami felgyorsítja a weboldalak kézbesítését, de elfedi a mögöttes problémákat a szerver szintjén.
A CDN nem tart másolatot a világ minden adatközpontjában. Amikor egy felhasználó weboldalt kér, a CDN lekéri azt a weboldalt a szerverről, majd másolatot készít róla azon a szerveren, amely közelebb van a felhasználókhoz. Tehát az első lekérés mindig lassabb, de ha a szerver kezdetben lassú, akkor az első lekérés még lassabb lesz, mint a weboldal közvetlenül a szerverről történő kézbesítése.
Barry a következő trükköket javasolja a CDN gyorsítótárának megkerülésére:
- Tesztelje a lassú oldalt egy URL-paraméter hozzáadásával (például a „?XYZ” karakter hozzáadásával az URL végéhez).
- Teszteljen egy olyan oldalt, amelyet nem gyakran kérnek.
Egy olyan eszközt is javasol, amellyel bizonyos országokat tesztelhetünk:
„A CrUX segítségével azt is ellenőrizheti, hogy különösen azokban az országokban, amelyek lassúak – különösen, ha nem használ CDN-t –, és a @alekseykulikov.bsky.social a Treo az egyik legjobb eszköz erre.
Itt ingyenes tesztet futtathat: treo.sh/sitespeed, görgessen le a térképhez, és váltson TTFB-re.
Ha bizonyos országokban lassú TTFB-k vannak, ellenőrizze, hogy mekkora forgalom érkezik ezekből az országokból. Adatvédelmi okokból a CrUX nem jeleníti meg a forgalom mennyiségét (kivéve, ha elegendő forgalmat mutat a megjelenítéshez), ezért ehhez meg kell néznie az elemzéseit.”
Az egyes földrajzi területekről érkező lassú kapcsolatokat illetően hasznos megérteni, hogy bizonyos fejlődő országokban a lassú teljesítmény az alsó kategóriás mobileszközök népszerűségének tudható be. És érdemes megismételni, hogy a CrUX nem fedi fel, hogy mely országokból származnak a gyenge pontszámok, ami azt jelenti, hogy be kell vinni az Analytics szolgáltatást a lassú forgalmú országok azonosításához.
5. Megismételhető dolgok javítása
Barry azzal zárta a vitát, hogy egy problémát csak akkor lehet kijavítani, ha megismételhetőnek bizonyult.
Azt tanácsolta:
„Szerverproblémák esetén a szerver alulteljesít?
Vagy a kód túl bonyolult/nem hatékony?
Vagy tuningra szorul az adatbázis?
Egyes helyekről lassú kapcsolatokhoz CDN-re van szüksége?
Vagy vizsgálja meg, miért van ekkora forgalom onnan (hirdetési kampány?)
Ha ezek közül egyik sem tűnik ki, annak oka lehet az átirányítás, különösen a hirdetésekből. ~0,5 másodpercet adhatnak a TTFB-hez – átirányításonként!
Próbáld meg a lehető legnagyobb mértékben csökkenteni az átirányításokat:
– Használja a megfelelő végső URL-t, hogy elkerülje a www vagy https oldalra való átirányítást.
– Kerülje el a többszörös URL-rövidítő szolgáltatásokat.”
Elvitelek: Optimalizálás a legnagyobb tartalmat tartalmazó festékhez
A Google Chrome Barry Pollard öt fontos tippet adott.
1. A PageSpeed Insights (PSI) adatai támpontokat adhatnak az LCP-problémák hibakereséséhez, valamint az ebben a cikkben tárgyalt egyéb árnyalatok, amelyek segítenek értelmezni az adatokat.
2. A PSI TTFB (Time to First Byte) adatok rámutathatnak arra, hogy egy oldal miért rendelkezik gyenge LCP-értékekkel.
3. A Lighthouse labortesztek hasznosak a hibakereséshez, mert az eredmények megismételhetők. Az ismételhető eredmények kulcsfontosságúak az LCP-problémák forrásának pontos azonosításához, amelyek lehetővé teszik a megfelelő megoldások alkalmazását.
4. A CDN-ek elfedhetik az LCP-problémák valódi okát. Használja a fent leírt Barry-trükköt a CDN megkerülésére, és valódi laboratóriumi pontszámot kap, amely hasznos lehet a hibakereséshez.
5. Barry felsorolt hat lehetséges okot a gyenge LCP-pontszámokhoz:
- Szerver teljesítménye
- átirányítja
- kód
- adatbázis
- A földrajzi elhelyezkedés miatt specifikus lassú kapcsolatok
- Lassú kapcsolatok meghatározott területekről, amelyek bizonyos okok miatt, például hirdetési kampányok miatt alakulnak ki.
Olvassa el Barry bejegyzését a Bluesky-n:
A közelmúltban néhány ember keresett meg segítséget kérve LCP-problémákkal kapcsolatban
