Ką atidėtasis įkėlimas iš tikrųjų daro jūsų Largest Contentful Paint

Atidėtasis įkėlimas yra planavimo sprendimas, o ne greičio burtažodis

Atidėtasis įkėlimas dažnai apibūdinamas kaip našumo pagerinimas, ir tai tiesa panašiai kaip tiesa, kad nesusikrovus lagamino sumažėja svoris. Jis padeda todėl, kad naršyklė pradžioje turi atlikti mažiau darbo.

Šis skirtumas svarbus Largest Contentful Paint, dažniausiai trumpinamam kaip LCP. LCP matuoja, kada pateikiamas didžiausias prasmingas elementas matomoje ekrano srityje. Daugelyje puslapių tas elementas yra pagrindinis hero vaizdas. Kituose tai gali būti didelė antraštė, posterio vaizdas, produkto nuotrauka arba turinio blokas.

Atidėtasis įkėlimas pakeičia, kada ištekliai užklausomi. Jis nepadaro taip, kad vaizdas būtų dekoduojamas greičiau, serveris atsakytų greičiau ar šriftas būtų atvaizduotas anksčiau. Jei atidėtai įkeliate netinkamą dalyką, ypač elementą, kuris tampa LCP, naršyklei nurodote palaukti prieš atsisiunčiant būtent tai, ką ji turi parodyti, kad atitiktų Core Web Vitals.

Todėl atidėtasis įkėlimas yra ir per dažnai naudojamas, ir nepakankamai suprantamas.

Ką naršyklė daro, kai vaizdą įkeliate atidėtai

Gimtasis vaizdų atidėtasis įkėlimas paprastai pridedamas taip:

<img src='hero.jpg' loading='lazy' alt='...'>

Naudojant loading='lazy', naršyklei leidžiama atidėti vaizdo atsisiuntimą, kol ji mano, kad vaizdo greičiausiai prireiks. Praktikoje naršyklės naudoja atstumą nuo matomos srities, tinklo sąlygas, vaizdo matmenis ir kitas heuristikas. Tikslios taisyklės yra įgyvendinimo detalės ir gali keistis.

Naudojant loading='eager' arba daugeliu atvejų visai nenaudojant lazy atributo, naršyklė laiko vaizdą įprasto įkėlimo proceso dalimi. Ji vis tiek turi nustatyti prioritetus tarp CSS, JavaScript, šriftų, vaizdų ir kitų užklausų, bet vaizdas atrandamas iškart.

Tai reiškia, kad atidėtasis įkėlimas pirmiausia veikia tris fazes:

• Atradimas: kada naršyklė pastebi išteklių.
• Užklausos pradžia: kada prasideda tinklo gavimas.
• Atvaizdavimo laikas: kada išteklius galiausiai gali būti dekoduotas ir nupieštas.

LCP atveju pavojingoji yra užklausos pradžia. Jei LCP vaizdo užklausa prasideda vėlai, viskas po jos taip pat nusikelia vėliau.

Paprasta taisyklė: niekada atidėtai neįkelkite LCP kandidato

Jei vaizdas matomas pradinėje ekrano srityje ir tikėtina, kad jis bus didžiausias turinio elementas, neįkelkite jo atidėtai.

Tai apima:

• hero vaizdus
• pagrindines produkto nuotraukas pirmajame ekrane
• didelius straipsnio įvadinius vaizdus
• didelius į foną panašius vaizdus, įgyvendintus kaip <img>
• vaizdo įrašų posterio vaizdus, kai posteris yra pagrindinis vizualinis elementas

Naršyklė negali pateikti LCP vaizdo, kol jis nebuvo užklaustas, perduotas, dekoduotas ir nupieštas. Atidėtasis įkėlimas įterpia neapibrėžtumą prieš pirmąjį žingsnį. Net nedidelio delsimo gali pakakti, kad lėtesniame ryšyje LCP iš priimtino taptų prastu.

Dažnas nesėkmės scenarijus atrodo taip:

1. Serveris išsiunčia HTML.
2. Naršyklė parsina vaizdą, esantį pirmajame ekrane.
3. Vaizdas turi loading='lazy'.
4. Naršyklė laukia, nes atidėtojo įkėlimo heuristika leidžia tai daryti.
5. CSS ir JavaScript toliau įkeliami.
6. Vaizdo užklausa prasideda vėliau, nei turėtų.
7. LCP vėluoja, nors pats vaizdo failas yra pakankamai optimizuotas.

Tai erzina, nes per kodo peržiūrą puslapis gali atrodyti tvarkingai. Problema nėra vien failo dydis. Problema yra prioritetas.

Jei skaitote laboratorinių įrankių išvestį ir bandote suprasti, ar LCP iš tiesų yra problema, mūsų gidas, kaip skaityti Lighthouse ataskaitą nepanikuojant, yra sąmoningai praktiškas: prieš keisdami kodą atskirkite lauko duomenis, laboratorines užuominas ir pataisas. (Pastaba: jei jūsų maršrutizavimas skiria didžiąsias ir mažąsias raides, naudokite tikslų URL iš savo CMS.)

Pataisa: naudokite tikrąjį vidinį URL

Teisingas Wux straipsnio URL yra Kaip skaityti Lighthouse ataskaitą nepanikuojant. Esmė išlieka ta pati: prieš keisdami įkėlimo elgseną nustatykite LCP elementą.

Kada atidėtasis įkėlimas gali pagerinti LCP

Atidėtasis įkėlimas gali netiesiogiai pagerinti LCP, kai pašalina nekritinius išteklius iš naršyklės kelio.

Įsivaizduokite produkto puslapį su pagrindiniu produkto vaizdu viršuje ir dvylikos rekomendacijų vaizdų karusele žemiau pirmojo ekrano. Jei visi trylika vaizdų įkeliami iš karto, naršyklė gali eikvoti pralaidumą ir ryšio lizdus vaizdams, kurių naudotojas dar nemato. Ribotame tinkle tai gali konkuruoti su pagrindiniu vaizdu, CSS arba šriftų failais.

Atidėtai įkeliant karuselės vaizdus žemiau pirmojo ekrano, LCP vaizdas gali būti įkeltas anksčiau, nes pradinio puslapio įkėlimo metu konkuruoja mažiau nekritinių užklausų.

Tai yra teisėtas atidėtojo įkėlimo našumo atvejis:

• iš karto įkelkite LCP kandidatą pirmajame ekrane
• atidėtai įkelkite vaizdus žemiau pradinės matomos srities
• venkite sunkių skriptų, kurie svarbius vaizdus įterpia vėlai
• laikykite vaizdo matmenis HTML, kad išvengtumėte išdėstymo poslinkių

Atidėtasis įkėlimas pats savaime nėra LCP optimizacija. Tai išteklių prioritetų nustatymo įrankis. Jis padeda tada, kai saugo kritinį kelią.

Geresnis šablonas LCP vaizdams

LCP vaizdui pirmajame ekrane tikslas yra padaryti taip, kad naršyklė jį anksti atrastų, anksti užklaustų ir pateiktų be išdėstymo nestabilumo.

Tvirtas pagrindas atrodo taip:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

Svarbios dalys nėra dekoratyvios:

• loading='eager' apsaugo nuo atidėtojo įkėlimo delsos.
• fetchpriority='high' pasako naršyklei, kad šis vaizdas svarbus.
• width ir height rezervuoja vietą ir mažina išdėstymo poslinkį.
• srcset ir sizes apsaugo nuo per didelių atsisiuntimų.
• Modernus formatas gali sumažinti perdavimo laiką, kai naudojamas apgalvotai.

Jei vis dar tiekiate vieną didelį JPEG kiekvienam ekranui, vaizdo formatas ir responsyvus dydžio parinkimas gali būti svarbesni nei atidėtojo įkėlimo atributas. Praktiniam sprendimų medžiui žr. kada AVIF pranoksta WebP ir kada ne.

Foniniams vaizdams reikia papildomo atsargumo

CSS fono vaizdai nėra atrandami taip anksti kaip įprasti HTML vaizdai. Naršyklė turi atsisiųsti ir išparsinti CSS, kad apie juos sužinotų. Jei jūsų LCP elementas yra CSS fono vaizdas, jau apsunkinote atradimą.

Tai nereiškia, kad fono vaizdai draudžiami. Tai reiškia, kad turėtumėte veikti sąmoningai.

Dekoratyviniams vaizdams CSS fonai tinka. Prasmingai hero grafikai <img> arba <picture> elementas paprastai yra geresnis, nes jis matomas HTML parseriui, palaiko alt tekstą ir gerai veikia su responsyvių vaizdų atributais.

Jei LCP vaizdui privalote naudoti CSS foną, apsvarstykite išankstinį įkėlimą:

<link rel='preload' as='image' href='/images/hero.avif'>

Preload taip pat nėra stebuklinga lazdelė. Iš anksto įkeliant per daug vaizdų sukuriama ta pati prioritetų problema, tik kitu pavidalu. Naudokite tai vienam iš tiesų svarbiam vaizdui, o ne kiekvienam dizaino sistemos vaizdui.

JavaScript atidėtasis įkėlimas dažnai pablogina padėtį

Prieš plačiai paplintant gimtajam atidėtajam įkėlimui, daugelis svetainių naudojo JavaScript bibliotekas, kurios po puslapio įkėlimo arba suveikus intersection observer pakeisdavo data-src į src. Kai kurios vis dar taip daro.

Tai gali būti pagrįsta ilgiems straipsnių puslapiams arba daug vaizdų turinčioms galerijoms. Tai prastas pasirinkimas turiniui pirmajame ekrane.

Naršyklės preload scanner yra greitas, bet jis negali užklausti vaizdo, kurio URL paslėptas pasirinktiniame atribute, kol nepaleidžiamas JavaScript. Jei jūsų hero vaizdas prasideda kaip data-src='hero.jpg', atradimą nukėlėte už skripto atsisiuntimo, parsingo, vykdymo ir karkaso hidratacijos.

Tai blogas kompromisas LCP atžvilgiu. Kritinių vaizdų URL dėkite į tikrą HTML. Leiskite naršyklei atlikti savo darbą.

LCP ne visada yra vaizdų problema

Kai kuriuose puslapiuose LCP elementas yra tekstas. Tokiu atveju atidėtasis vaizdų įkėlimas gali turėti mažai tiesioginio poveikio. Jūsų siauroji vieta gali būti atvaizdavimą blokuojantis CSS, lėtas serverio atsakas, kliento pusės atvaizdavimas arba web šriftai.

Šriftus verta paminėti atskirai, nes jie dažnai yra paslėpta vėlyvo teksto atvaizdavimo priežastis. Didelė antraštė gali tapti LCP, o šriftų įkėlimo elgsena gali atidėti arba pakeisti momentą, kada ta antraštė nupiešiama. Jei darbas su vaizdais nepajudina metrikos, tiesiogiai patikrinkite LCP elementą, o ne darykite prielaidą. Mūsų straipsnyje apie web šriftus kaip našumo laimėjimą aptariamos nuobodžios pataisos, kurios dažnai veikia: mažiau svorių, modernūs formatai, protingi atsarginiai variantai.

Kaip testuoti atidėtojo įkėlimo pakeitimus neapgaunant savęs

Netestuokite tiesiog žiūrėdami į puslapį biuro Wi-Fi tinkle. Turite matyti užklausų laiką.

Naudokite šią eigą:

1. Atidarykite Chrome DevTools ir įrašykite Performance trace.
2. Įjunkite tinklo ribojimą, pavyzdžiui, Fast 4G arba Slow 4G.
3. Iš naujo įkelkite puslapį su išjungta talpykla.
4. Raskite LCP žymeklį.
5. Nustatykite LCP elementą.
6. Network skydelyje patikrinkite, kada tas išteklius pradėjo krautis.

Jei LCP išteklius pradeda krautis vėlai, paklauskite kodėl:

• Ar jis buvo įkeliamas atidėtai?
• Ar jis buvo įterptas JavaScript?
• Ar jis buvo paslėptas CSS?
• Ar jo prioritetas buvo nustumtas už kitų vaizdų?
• Ar serveris lėtai atsakė?

Tada atlikite vieną pakeitimą ir testuokite iš naujo. Našumo darbas tampa painus, kai komandos tame pačiame diegime pakeičia vaizdo formatą, atidėtąjį įkėlimą, išankstinį įkėlimą, JavaScript paketus ir CDN nustatymus. Galite pagerinti puslapį, bet nežinosite, kuris pakeitimas buvo svarbus.

Lauko duomenys taip pat svarbūs. Laboratoriniai įrankiai naudingi diagnostikai, bet LCP priklauso nuo įrenginio, tinklo, matomos srities, talpyklos būsenos ir geografijos. Kai galite, naudokite realių naudotojų stebėseną arba Chrome User Experience Report duomenis.

<!-- tool-cta:start -->

💡 Išbandykite tai: Laikykite savo LCP vaizdą mažą ir įkeliamą su prioritetu, apdorodami jį per Image Compressor, kad jis greitai būtų atvaizduotas be lazy loading poreikio.

<!-- tool-cta:end -->

Praktinė politika daugumai svetainių

Daugumai rinkodaros svetainių, ecommerce puslapių, dokumentacijos svetainių ir leidėjų puslapių pakanka šios politikos:

• Pagrindinis vaizdas pirmajame ekrane: įkelkite iš karto, apsvarstykite aukštą gavimo prioritetą.
• Turinio vaizdai žemiau pirmojo ekrano: įkelkite atidėtai.
• Piktogramos ir smulkūs UI ištekliai: paprastai neverta apie kiekvieną galvoti atskirai.
• CSS fono hero: apsvarstykite HTML vaizdą arba atsargiai naudokite preload.
• JavaScript įterptas hero vaizdas: jei įmanoma, taisykite atvaizdavimo architektūrą.
• Karuselės: iš karto įkelkite tik pirmą matomą skaidrę; likusias įkelkite atidėtai.

Yra išimčių. Naršyklių heuristikos gerėja. Karkasai prideda automatinius vaizdų komponentus. Kai kurios platformos dabar vengia atidėtai įkelti vaizdus, aptiktus arti matomos srities. Vis dėlto principas nesikeičia: kritiniai ištekliai turi būti ankstyvi ir akivaizdūs; nekritiniai ištekliai turi palaukti.

Atidėtasis įkėlimas vertingas tada, kai išreiškia šį skirtumą. Jis žalingas tada, kai slepia svarbiausią turinį nuo naršyklės iki momento, kai puslapis jau pradėjo pralaimėti LCP lenktynes.