Mitä lazy loading oikeasti tekee Largest Contentful Paintille

Lazy loading on ajoituspäätös, ei nopeusloitsu

Lazy loading kuvataan usein suorituskykyparannuksena, mikä pitää paikkansa samalla tavalla kuin matkalaukun pakkaamatta jättäminen on painon vähentämistä. Se auttaa, koska selain tekee alussa vähemmän työtä.

Tällä erolla on merkitystä Largest Contentful Paintin kannalta, joka yleensä lyhennetään LCP:ksi. LCP mittaa, milloin näkymän suurin merkityksellinen elementti renderöidään. Monilla sivuilla tuo elementti on hero-kuva. Toisilla se on suuri otsikko, julistekuva, tuotekuva tai sisältölohko.

Lazy loading muuttaa sitä, milloin resursseja pyydetään. Se ei saa kuvaa dekoodautumaan nopeammin, palvelinta vastaamaan nopeammin tai fonttia renderöitymään aiemmin. Jos käytät lazy loadingia väärään asiaan, erityisesti elementtiin, josta tulee LCP, käsket selainta odottamaan ennen kuin se hakee juuri sen asian, joka sen täytyy näyttää läpäistäkseen Core Web Vitals -mittarit.

Siksi lazy loadingia sekä ylikäytetään että ymmärretään liian huonosti.

Mitä selain tekee, kun käytät lazy loadingia kuvalle

Natiivi kuvien lazy loading lisätään yleensä näin:

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

Kun käytössä on loading='lazy', selain saa lykätä kuvan hakemista, kunnes se arvioi kuvan todennäköisesti tarvittavan. Käytännössä selaimet käyttävät näkymän etäisyyttä, verkkoolosuhteita, kuvan mittoja ja muita heuristiikkoja. Tarkat säännöt ovat toteutusyksityiskohtia ja voivat muuttua.

Kun käytössä on loading='eager', tai useimmissa tapauksissa kun lazy-attribuuttia ei ole, selain käsittelee kuvaa osana normaalia latausprosessia. Sen täytyy silti priorisoida CSS:n, JavaScriptin, fonttien, kuvien ja muiden pyyntöjen välillä, mutta kuva on löydettävissä heti.

Tämä tarkoittaa, että lazy loading vaikuttaa ensisijaisesti kolmeen vaiheeseen:

• Löytäminen: milloin selain huomaa resurssin.
• Pyynnön aloitus: milloin verkkohaku alkaa.
• Renderöinnin ajoitus: milloin resurssi voidaan lopulta dekoodata ja piirtää.

LCP:n kannalta vaarallinen vaihe on pyynnön aloitus. Jos LCP-kuvan pyyntö alkaa myöhään, kaikki sen jälkeenkin siirtyy myöhäisemmäksi.

Yksinkertainen sääntö: älä koskaan käytä lazy loadingia LCP-ehdokkaalle

Jos kuva näkyy alkuperäisessä näkymässä ja on todennäköisesti suurin sisältöelementti, älä käytä siihen lazy loadingia.

Tähän kuuluvat:

• hero-kuvat
• ensisijaiset tuotekuvat taitteen yläpuolella
• suuret artikkelin pääkuvat
• suuret taustakuvan kaltaiset kuvat, jotka on toteutettu <img>-elementtinä
• videon julistekuvat, kun juliste on pääasiallinen visuaalinen elementti

Selain ei voi renderöidä LCP-kuvaa ennen kuin se on pyydetty, siirretty, dekoodattu ja piirretty. Lazy loading lisää epävarmuutta ennen ensimmäistä vaihetta. Pienikin viive voi riittää siirtämään LCP:n hyväksyttävästä heikoksi hitaammalla yhteydellä.

Yleinen virhekuvio näyttää tältä:

1. Palvelin lähettää HTML:n.
2. Selain jäsentää taitteen yläpuolella olevan kuvan.
3. Kuvassa on loading='lazy'.
4. Selain odottaa, koska lazy-loading-heuristiikka sanoo, että se voi.
5. CSS ja JavaScript jatkavat latautumista.
6. Kuvapyyntö alkaa myöhemmin kuin sen pitäisi.
7. LCP myöhästyy, vaikka kuvatiedosto itsessään olisi kohtuullisen hyvin optimoitu.

Tämä on turhauttavaa, koska sivu voi näyttää koodikatselmoinnissa siistiltä. Ongelma ei ole pelkkä tiedostokoko. Se on prioriteetti.

Jos luet labratuloksia ja yrität selvittää, onko LCP todella ongelma, oppaamme Lighthouse-raportin lukemiseen panikoimatta on tarkoituksella käytännöllinen: erota kenttädata, labravihjeet ja korjaukset toisistaan ennen kuin alat muuttaa koodia. (Huomaa: jos reitityksesi erottaa kirjainkoon, käytä täsmällistä URL-osoitetta CMS:stäsi.)

Korjaus: käytä todellista sisäistä URL-osoitetta

Oikea Wux-artikkelin URL on Näin luet Lighthouse-raporttia panikoimatta. Perusajatus pysyy: tunnista LCP-elementti ennen kuin muutat latauskäyttäytymistä.

Milloin lazy loading voi parantaa LCP:tä

Lazy loading voi parantaa LCP:tä epäsuorasti, kun se pitää ei-kriittiset resurssit poissa selaimen tieltä.

Kuvittele tuotesivu, jossa yläosassa on hero-tuotekuva ja taitteen alapuolella karuselli, jossa on kaksitoista suosituskuvaa. Jos kaikki kolmetoista kuvaa ladataan eager-tilassa, selain voi käyttää kaistanleveyttä ja yhteyspaikkoja kuviin, joita käyttäjä ei vielä näe. Rajoitetussa verkossa se voi kilpailla hero-kuvan, CSS:n tai fonttitiedostojen kanssa.

Taitteen alapuolisten karusellikuvien lazy loading voi auttaa LCP-kuvaa latautumaan aiemmin, koska alkuperäisen sivulatauksen aikana kilpailevia ei-kriittisiä pyyntöjä on vähemmän.

Tämä on lazy loadingin perusteltu suorituskykytapaus:

• lataa taitteen yläpuolinen LCP-ehdokas eager-tilassa
• käytä lazy loadingia alkuperäisen näkymän alapuolella oleville kuville
• vältä raskaita skriptejä, jotka lisäävät tärkeitä kuvia myöhään
• pidä kuvien mitat HTML:ssä asettelusiirtymien välttämiseksi

Lazy loading ei ole itsessään LCP-optimointi. Se on resurssien priorisointityökalu. Se auttaa, kun se suojaa kriittistä polkua.

Parempi malli LCP-kuville

Taitteen yläpuolella olevan LCP-kuvan kohdalla tavoitteena on saada selain löytämään se aikaisin, pyytämään se aikaisin ja renderöimään se ilman asettelun epävakautta.

Vankka lähtötaso näyttää tältä:

<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'
>

Tärkeät osat eivät ole koristeellisia:

• loading='eager' estää lazy-loading-viiveen.
• fetchpriority='high' kertoo selaimelle, että tällä kuvalla on merkitystä.
• width ja height varaavat tilaa ja vähentävät asettelusiirtymää.
• srcset ja sizes estävät ylisuuria latauksia.
• Moderni formaatti voi lyhentää siirtoaikaa, kun sitä käytetään harkiten.

Jos tarjoat edelleen yhden suuren JPEG-kuvan jokaiselle näytölle, kuvaformaatti ja responsiivinen mitoitus voivat olla tärkeämpiä kuin lazy-loading-attribuutti. Käytännöllisen päätöspuun löydät artikkelista milloin AVIF voittaa WebP:n ja milloin ei.

Taustakuvat vaativat erityistä huolellisuutta

CSS-taustakuvia ei löydetä yhtä aikaisin kuin tavallisia HTML-kuvia. Selaimen täytyy hakea ja jäsentää CSS ennen kuin se tietää niistä. Jos LCP-elementtisi on CSS-taustakuva, olet jo tehnyt löytämisestä vaikeampaa.

Se ei tarkoita, että taustakuvat olisivat kiellettyjä. Se tarkoittaa, että sinun kannattaa toimia harkitusti.

Koristeellisille kuville CSS-taustat ovat hyviä. Merkitykselliselle hero-kuvitukselle <img>- tai <picture>-elementti on yleensä parempi, koska HTML-jäsennin näkee sen, se tukee alt-tekstiä ja toimii hyvin responsiivisten kuva-attribuuttien kanssa.

Jos sinun täytyy käyttää CSS-taustaa LCP-kuvalle, harkitse sen esilataamista:

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

Preload ei sekään ole taikasauva. Liian monen kuvan esilataaminen luo saman prioriteettiongelman eri asussa. Käytä sitä siihen yhteen kuvaan, jolla todella on merkitystä, älä jokaiseen design systemin kuvaan.

JavaScript-pohjainen lazy loading tekee asioista usein huonompia

Ennen kuin natiivi lazy loading sai laajan tuen, monet sivustot käyttivät JavaScript-kirjastoja, jotka vaihtoivat data-src-arvon src-attribuuttiin sivun latauksen jälkeen tai intersection observerin lauettua. Osa käyttää niitä edelleen.

Tämä voi olla järkevää pitkille artikkelisivuille tai kuvapainotteisiin gallerioihin. Se on huono valinta taitteen yläpuoliselle sisällölle.

Selaimen preload scanner on nopea, mutta se ei voi pyytää kuvaa, jonka URL on piilotettu mukautettuun attribuuttiin, ennen kuin JavaScript suoritetaan. Jos hero-kuvasi alkaa muodossa data-src='hero.jpg', olet viivästyttänyt löytämistä skriptin latauksen, jäsentämisen, suorituksen ja frameworkin hydratoinnin taakse.

Se on huono vaihtokauppa LCP:n kannalta. Laita kriittisten kuvien URL-osoitteet oikeaan HTML:ään. Anna selaimen tehdä työnsä.

LCP ei ole aina kuvaongelma

Joillakin sivuilla LCP-elementti on tekstiä. Silloin kuvien lazy loadingilla voi olla vain vähän suoraa vaikutusta. Pullonkaulasi voi olla renderöintiä estävä CSS, hidas palvelinvastaus, asiakaspuolen renderöinti tai web-fontit.

Fontit kannattaa nostaa esiin, koska ne ovat usein piilevä syy tekstin myöhäiseen renderöitymiseen. Suuri otsikko voi muuttua LCP:ksi, ja fonttien latauskäyttäytyminen voi viivästyttää tai muuttaa sitä, milloin otsikko piirtyy. Jos kuvien parantaminen ei liikuta mittaria, tarkista LCP-elementti suoraan oletusten sijaan. Artikkelimme web-fonteista suorituskykyvoittona käsittelee tylsiä korjauksia, jotka usein toimivat: vähemmän leikkauksia, modernit formaatit ja järkevät varavaihtoehdot.

Kuinka testata lazy loading -muutoksia huijaamatta itseäsi

Älä testaa tuijottamalla sivuasi toimiston Wi-Fissä. Sinun täytyy nähdä pyyntöjen ajoitus.

Käytä tätä työnkulkua:

1. Avaa Chrome DevTools ja tallenna Performance-jälki.
2. Ota käyttöön verkon kuristus, kuten Fast 4G tai Slow 4G.
3. Lataa sivu uudelleen välimuisti pois käytöstä.
4. Etsi LCP-merkintä.
5. Tunnista LCP-elementti.
6. Tarkista Network-paneelista, milloin kyseisen resurssin lataus alkoi.

Jos LCP-resurssi alkaa myöhään, kysy miksi:

• Käytettiinkö siihen lazy loadingia?
• Lisättiinkö se JavaScriptillä?
• Oliko se piilossa CSS:ssä?
• Jäikö se muiden kuvien taakse alemmalle prioriteetille?
• Vastasko palvelin hitaasti?

Tee sitten yksi muutos ja testaa uudelleen. Suorituskykytyö muuttuu sotkuiseksi, kun tiimit vaihtavat kuvaformaattia, lazy loadingia, esilatausta, JavaScript-bundleja ja CDN-asetuksia samassa julkaisussa. Saatat parantaa sivua, mutta et tiedä, millä muutoksella oli merkitystä.

Kenttädatalla on myös merkitystä. Labravälineet ovat hyödyllisiä diagnostiikassa, mutta LCP vaihtelee laitteen, verkon, näkymän, välimuistin tilan ja maantieteen mukaan. Käytä real-user monitoringia tai Chrome User Experience Report -dataa aina kun voit.

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

💡 Kokeile tätä: Pidä LCP-kuvasi pienenä ja eager-loaded-tilassa ajamalla se Image Compressor -työkalun läpi, jotta se piirtyy nopeasti ilman lazy loadingia.

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

Käytännöllinen linjaus useimmille verkkosivustoille

Useimmille markkinointisivustoille, verkkokauppasivuille, dokumentaatiosivustoille ja julkaisijasivuille tämä linjaus riittää:

• Taitteen yläpuolinen ensisijainen kuva: lataa eager-tilassa, harkitse korkeaa fetch-prioriteettia.
• Taitteen alapuoliset sisältökuvat: käytä lazy loadingia.
• Ikonit ja pienet käyttöliittymäresurssit: eivät yleensä ansaitse yksittäistä pohdintaa.
• CSS-tausta-hero: harkitse uudelleen HTML-kuvana tai esilataa huolellisesti.
• JavaScriptillä lisätty hero-kuva: korjaa renderöintiarkkitehtuuri, jos mahdollista.
• Karusellit: lataa eager-tilassa vain ensimmäinen näkyvä dia; käytä lazy loadingia muille.

Poikkeustapauksia on. Selainten heuristiikat paranevat. Frameworkit lisäävät automaattisia kuvakomponentteja. Jotkin alustat välttävät nykyään lazy loadingia kuville, jotka havaitaan lähellä näkymää. Silti periaate ei muutu: kriittisten resurssien pitäisi olla varhaisia ja ilmeisiä; ei-kriittisten resurssien pitäisi odottaa.

Lazy loading on arvokasta, kun se ilmaisee tämän eron. Se on haitallista, kun se piilottaa tärkeimmän sisällön selaimelta siihen asti, kun sivu on jo alkanut hävitä LCP-kilpailua.