Kas yra didžiausias turiningas dažas: paprastas paaiškinimas

Didžiausias turinio dažymas (LCP) yra „Google“ naudotojo patirties metrika, integruota į reitingavimo sistemas 2021 m.

LCP yra viena iš trijų pagrindinių žiniatinklio gyvybinių rodiklių (CWV) metrikų, kurios seka techninio našumo metriką, turinčią įtakos vartotojo patirčiai.

Paradoksalu, kad pagrindiniai žiniatinklio gyvybiniai rodikliai egzistuoja, o „Google“ teikia gaires, pabrėžiančias jų svarbą, tačiau sumenkinant jų poveikį reitingams.

LCP, kaip ir kiti CWV signalai, yra naudingas diagnozuojant technines problemas ir užtikrinant, kad jūsų svetainė atitiktų pagrindinį naudotojų funkcionalumo lygį.

Kas yra didžiausias turiningas dažas?

LCP matuoja, kiek laiko užtrunka, kol pagrindinis puslapio turinys atsisiunčiamas ir bus paruoštas sąveikai.

Tiksliau, laikas nuo puslapio įkėlimo pradžios iki didžiausio vaizdo arba teksto bloko pateikimo vartotojo peržiūros srityje. Viskas, kas yra žemiau matomos ribos, nesiskaito.

Vaizdai, vaizdo įrašų plakatų vaizdai, fono vaizdai ir bloko lygio teksto elementai, pvz., pastraipų žymos, yra tipiški matuojami elementai.

LCP susideda iš šių submetrikų:

LCP optimizavimas reiškia kiekvienos iš šių metrikų optimizavimą, todėl LCP išteklių įkėlimas ir rodymas trunka mažiau nei 2,5 sekundės.

Čia yra jūsų nuoroda slenksčio skalė:

LCP slenksčiai

Panagrinėkime, ką reiškia šios antrinės metrikos ir kaip galite ją patobulinti.

Laikas iki pirmojo baito (TTFB)

TTFB yra serverio atsako laikas ir matuoja laiką, per kurį vartotojo naršyklė gauna pirmąjį duomenų baitą iš jūsų serverio. Tai apima DNS paieškos laiką, laiką, kurio reikia serverio užklausoms apdoroti, ir peradresavimus.

TTFB optimizavimas gali žymiai sutrumpinti bendrą įkėlimo laiką ir pagerinti LCP.

Serverio atsako laikas labai priklauso nuo:

• Duomenų bazių užklausos.
• Trūksta CDN talpyklos.
• Neefektyvus serverio atvaizdavimas.
• Hostingas.

Panagrinėkime kiekvieną:

1. Duomenų bazių užklausos

Jei jūsų atsakymo laikas yra ilgas, pabandykite nustatyti šaltinį.

Pavyzdžiui, tai gali būti dėl prastai optimizuotų užklausų arba didelio užklausų kiekio, dėl kurio sulėtėja serverio atsako laikas. Jei turite MySQL duomenų bazę, galite registruoti lėtas užklausas, kad sužinotumėte, kurios užklausos yra lėtos.

Jei turite „WordPress“ svetainę, galite naudoti „Query Monitor“ papildinį, kad sužinotumėte, kiek laiko užtrunka SQL užklausos.

Kiti puikūs įrankiai yra „Blackfire“ arba „Newrelic“, kurie nepriklauso nuo jūsų naudojamo TVS ar kamino, tačiau juos reikia įdiegti jūsų priegloboje / serveryje.

2. CDN talpyklos trūkumas

CDN talpyklos praleidimas įvyksta, kai CDN talpykloje nerandamas prašomas išteklius ir užklausa persiunčiama gauti iš pradinio serverio. Šis procesas užtrunka daugiau laiko, todėl galutiniam vartotojui pailgėja delsa ir pailgėja įkėlimo laikas.

Paprastai jūsų CDN teikėjas turi ataskaitą apie tai, kiek praleidote talpyklą.

CDN talpyklos ataskaitos pavyzdys

Jei pastebite didelį procentą (>10 %) talpyklos praleidimų, gali tekti susisiekti su CDN teikėju arba prieglobos palaikymo komanda, jei tvarkote prieglobą su integruota talpykla, kad išspręstumėte problemą.

Viena iš priežasčių, dėl kurių gali būti praleista talpykla, yra paieškos šlamšto ataka.

Pavyzdžiui, keliolika nepageidaujamų domenų nukreipia į jūsų vidinius paieškos puslapius su atsitiktinėmis užklausomis su šlamštu, pvz., (/?q=甘肃代), kurios nėra talpykloje, nes paieškos terminas kiekvieną kartą skiriasi. Problema ta, kad „Googlebot“ juos agresyviai tikrina, todėl serverio atsako laikas gali būti ilgas ir talpyklos nebuvimas.

Tokiu atveju ir apskritai yra gera praktika blokuoti paieškos arba aspektų URL naudojant robots.txt. Tačiau užblokavę juos naudodami robots.txt, šie URL gali būti indeksuojami, nes juose yra atgalinių nuorodų iš žemos kokybės svetainių.

Tačiau nebijokite. Johnas Muelleris sakė, kad tai bus išaiškinta laiku.

Štai realus pavyzdys iš paieškos konsolės apie ilgą serverio atsako laiką (TTFB), kurį sukelia talpyklos praleidimai:

404 paieškos puslapių, kurių serverio atsako laikas yra ilgas, aptikimo šuolis

3. Neefektyvus serverio atvaizdavimas

Svetainėje gali būti tam tikrų komponentų, kurie priklauso nuo trečiųjų šalių API.

Pavyzdžiui, matėte SEJ straipsnių skaitymų ir bendrinimo skaičių. Mes gauname tuos numerius iš skirtingų API, bet užuot pateikę juos, kai serveriui pateikiama užklausa, iš anksto gauname juos ir saugome duomenų bazėje, kad būtų galima greičiau rodyti.

Įsivaizduokite, jei prisijungsime prie bendrinimo skaičiaus ir GA4 API, kai serveriui pateikiama užklausa. Kiekvienai užklausai vykdyti reikia apie 300–500 ms, o dėl neveiksmingo serverio atvaizdavimo pridėtume apie 1 000 ms delsą. Taigi įsitikinkite, kad jūsų užpakalinė programa yra optimizuota.

4. Hostingas

Žinokite, kad priegloba yra labai svarbi mažam TTFB. Pasirinkę tinkamą prieglobą, galite sumažinti TTFB nuo dviejų iki trijų kartų.

Pasirinkite prieglobą su CDN ir talpyklą, integruotą į sistemą. Tai padės nepirkti CDN atskirai ir sutaupysite laiko jį prižiūrėti.

Taigi, investicijos į tinkamą prieglobą atsipirks.

Skaitykite išsamesnę instrukciją:

Dabar pažvelkime į kitas pirmiau minėtas metrikas, kurios prisideda prie LCP.

Išteklių įkėlimo delsa

Išteklių įkėlimo delsa yra laikas, per kurį naršyklė nustato ir pradeda atsisiųsti LCP išteklius.

Pavyzdžiui, jei jūsų herojaus skiltyje yra fono paveikslėlis, į kurį reikia įkelti CSS failus, kad būtų galima identifikuoti, bus delsa, lygi tiek laiko, kiek naršyklė turi atsisiųsti CSS failą, kad pradėtų atsisiųsti LCP vaizdą.

Tuo atveju, kai LCP elementas yra teksto blokas, šis laikas yra lygus nuliui.

Optimizuodami, kaip greitai šie ištekliai nustatomi ir įkeliami, galite pailginti laiką, reikalingą svarbiam turiniui rodyti. Vienas iš būdų tai padaryti – iš anksto įkelti ir CSS failus, ir LCP vaizdus, ​​nustatant atvaizdui fetchpriority=”high“, kad jis pradėtų atsisiųsti CSS failą.

<link rel="stylesheet" href="https://www.searchenginejournal.com/assets/css/styles.css">
<link rel="preload" fetchpriority="high" as="image" href="http://www.searchenginejournal.com/media/hero.webp" type="image/webp">

Tačiau geresnis būdas – jei pakankamai kontroliuojate svetainę – įterpti kritinį CSS, reikalingą virš matomos ribos, kad naršyklė negaištų laiko atsisiųsdama CSS failą. Taip sutaupoma pralaidumo ir iš anksto įkeliamas tik vaizdas.

Žinoma, dar geriau, jei kuriate tinklalapius taip, kad išvengtumėte herojų vaizdų ar slankiklių, nes jie paprastai nesuteikia pridėtinės vertės, o vartotojai linkę slinkti pro juos, nes jie blaško dėmesį.

Kitas svarbus veiksnys, prisidedantis prie įkėlimo vėlavimo, yra peradresavimai.

Jei turite išorinių atgalinių nuorodų su peradresavimais, nelabai ką galite padaryti. Tačiau jūs galite valdyti vidines nuorodas, todėl pabandykite surasti vidines nuorodas naudodami peradresavimus, dažniausiai dėl trūkstamų pasvirųjų brūkšnių, ne WWW versijų arba pakeistų URL, ir pakeiskite jas tikromis paskirties vietomis.

Yra daug techninių SEO įrankių, kuriuos galite naudoti norėdami patikrinti savo svetainę ir rasti peradresavimus, kuriuos reikia pakeisti.

Išteklių įkėlimo trukmė

Išteklių įkėlimo trukmė nurodo faktinį laiką, praleistą atsisiunčiant LCP išteklius.

Net jei naršyklė greitai suranda ir pradeda atsisiųsti išteklius, lėtas atsisiuntimo greitis vis tiek gali neigiamai paveikti LCP. Tai priklauso nuo išteklių dydžio, serverio tinklo ryšio greičio ir vartotojo tinklo sąlygų.

Galite sumažinti išteklių įkėlimo trukmę įgyvendindami:

• WebP formatu.
• Tinkamo dydžio vaizdai (padarykite, kad vidinis vaizdo dydis atitiktų matomą dydį).
• Apkrovos prioritetų nustatymas.
• CDN.

Elemento pateikimo delsa

Elemento pateikimo delsa – tai laikas, per kurį naršyklė apdoroja ir atvaizduoja LCP elementą.

Šią metriką įtakoja jūsų HTML, CSS ir JavaScript sudėtingumas.

Sumažinus pateikimą blokuojančius išteklius ir optimizavus kodą galima sumažinti šią delsą. Tačiau gali atsitikti taip, kad veikia intensyvus JavaScript scenarijus, kuris blokuoja pagrindinę giją, o LCP elemento atvaizdavimas atidėtas, kol šios užduotys bus baigtos.

Čia svarbios mažos bendro blokavimo laiko (TBT) metrikos vertės, nes ji matuoja bendrą laiką, per kurį pagrindinė gija blokuojama dėl ilgų užduočių įkeliant puslapį, o tai rodo, kad yra sunkių scenarijų, kurie gali atidėti atvaizdavimą ir reagavimą.

Vienas iš būdų, kaip pagerinti ne tik įkėlimo trukmę ir delsą, bet ir visą CWV metriką, kai naudotojai naršo jūsų svetainėje, yra įdiegti spekuliacijos taisyklių API būsimoms naršymo priemonėms. Iš anksto pateikdami puslapius, naudotojams užvesdami pelės žymeklį ant nuorodų arba puslapių, kuriuos jie greičiausiai naršys, galite priversti puslapius įkelti akimirksniu.

Saugokitės šių taškų „Gotchas“

Visi vartotojo ekrano elementai (peržiūros sritis) naudojami LCP apskaičiuoti. Tai reiškia, kad vaizdai, pateikti ne ekrane ir perkelti į maketą, kai jie pateikiami, gali būti neįskaitomi kaip didžiausio turinio dažymo balo dalis.

Kitame gale elementai, prasidedantys naudotojo peržiūros srityje, o vėliau išstumiami iš ekrano, gali būti skaičiuojami kaip LCP skaičiavimo dalis.

Kaip išmatuoti LCP balą

Yra dviejų tipų balų skaičiavimo įrankiai. Pirmasis vadinamas Lauko įrankiaio antrasis vadinamas Laboratoriniai įrankiai.

Lauko įrankiai yra faktiniai svetainės matavimai.

Laboratoriniai įrankiai suteikia virtualų balą, pagrįstą imituotu tikrinimu, naudojant algoritmus, apytikslius interneto sąlygas, su kuriomis gali susidurti įprastas mobiliojo telefono vartotojas.

Čia yra vienas iš būdų, kaip rasti LCP išteklius ir išmatuoti laiką, per kurį jie bus rodomi DevTools > Spektaklis ataskaita:

Daugiau galite perskaityti mūsų išsamiame vadove, kaip išmatuoti CWV metriką, kur galite sužinoti, kaip pašalinti ne tik LCP, bet ir kitų metrikų triktis.

LCP optimizavimas yra daug išsamesnė tema

LCP tobulinimas yra esminis žingsnis gerinant CVW, tačiau tai gali būti sudėtingiausia CWV metrika, kurią reikia optimizuoti.

LCP susideda iš kelių antrinių metrikų sluoksnių, kurių kiekvieną reikia gerai suprasti, kad būtų galima efektyviai optimizuoti.

Šis vadovas suteikė jums pagrindinę idėją, kaip pagerinti LCP, o iki šiol įgytos įžvalgos padės jums padaryti reikšmingų patobulinimų.

Bet dar yra ko išmokti. Kiekvienos submetrikos optimizavimas yra niuansuotas mokslas. Sekite naujienas, nes paskelbsime išsamius vadovus, skirtus kiekvienos pometrikos optimizavimui.

Daugiau išteklių:

Panašaus vaizdo kreditas: BestForBest / Shutterstock