Optimoi LCP:n Resource Load Duration
Viiveestä näyttöön: opi parantamaan Largest Contentful Paint -mittarin resource load delay -osaa

Optimoi LCP:n Resource Load Duration
Largest Contentful Paint (LCP) on yksi kolmesta Core Web Vitals -suorituskykymittarista, jotka mittaavat verkkosivustosi user experience -tasoa. LCP mittaa aikaa, joka kuluu suurimman sisältöelementin (kuvan, videon tai tekstilohkon) näkymiseen näkymäalueella. Resource Load Duration on LCP:n osamitta, joka osoittaa, kuinka paljon aikaa kuluu LCP-elementin verkkoresurssin hakemiseen. Perehdytään syvällisesti LCP:n resource load duration -osaan ja tutkitaan sen vaikutusta sekä optimointistrategioita.
Table of Contents!
Mikä on Resource Load Duration LCP:ssä?
Resource Load Duration, jota usein kutsutaan nimellä Load Duration, tarkoittaa aikaa, jonka selain tarvitsee ladatakseen verkkoresurssin (esim. kuvan), josta tulee lopulta LCP-elementti. Kuvien ja videoiden osalta tämä kesto ulottuu kuvan latauksen alkamisesta selaimen latauksen valmistumiseen. Tekstipohjaisten LCP-elementtien osalta latauksen kesto on tyypillisesti nolla.

Resource Load Duration mitataan hetkestä, jolloin selain aloittaa LCP-resurssin lataamisen, siihen hetkeen, jolloin lataus on valmis. Tämä mittaus on ratkaisevan tärkeä, koska se vaikuttaa suoraan siihen, kuinka nopeasti käyttäjät voivat nähdä verkkosivun pääsisällön ja olla sen kanssa vuorovaikutuksessa. Resource load duration -aikaan voivat vaikuttaa useat tekijät, kuten:
- Tiedostokoko: Suuremmat tiedostot vaativat pidemmän latausajan.
- Verkon nopeus: Hitaammat yhteydet luonnollisesti pidentävät latauksen kestoa.
- Palvelimen vasteaika: Viiveet palvelimen vasteessa hidastavat resurssien hakemista.
- Samanaikaiset lataukset: Samanaikaisesti ladattavat resurssit kilpailevat kaistanleveydestä, mikä voi pidentää latausaikoja.
Kuinka havaita Resource Load Duration
On kaksi tehokasta tapaa tunnistaa ja mitata resource load duration:
Verkkotarkastelu Chrome DevToolsissa: Käytä Ctrl + Shift + I -pikanäppäintä avataksesi Chromen kehittäjätyökalut, valitse sitten "Network"-välilehti ja lataa sivu uudelleen. Etsi LCP-elementti verkkopyynnöistä (jos haluat tietää LCP-elementin, kokeile Core Web Visualizer -laajennusta). Verkkotarkastelija näyttää, kuinka kauan resurssin lataaminen kesti.

Vinkki: Ota käyttöön suuret pyyntörivit nähdäksesi lisätietoja, kuten LCP-viive, siirretty koko ja todellinen koko.
Hyödynnä Real User Monitoring (RUM) -dataa:
RUM-työkalut kirjaavat usein LCP-attribuutiotietoja. Largest Contentful Paint -attribuutiodata sisältää tietoja resource load delay -ajasta. Tämä data mahdollistaa latauksen keston trendien visualisoinnin ajan tai sivun mukaan, tarjoten selkeän näkymän latausaikoihin koko sivustolla. Analysoimalla näitä kaavoja on mahdollista tunnistaa elementit, jotka voivat hidastaa latausaikoja, ja löytää kohdennettuja mahdollisuuksia nopeampaan ja sujuvampaan suorituskykyyn.

Kuinka parantaa LCP:n Load Duration -aikaa
Resource load -viiveitä syntyy, kun resursseja ladataan epäoptimaalisessa järjestyksessä tai koossa. Kaksi päälähestymistapaa tähän ovat: datakoon pienentäminen tai datan toimituksen optimointi. Tässä tehokkaita tekniikoita ja malleja LCP:n resource load duration -ajan parantamiseksi:
1. Optimoi tiedostokoko:
Tiedostokoon optimointi vähentää verkon yli lähetettävien tavujen määrää. Vähemmän dataa tarkoittaa yleensä lyhyempää latausaikaa.
Käytä moderneja kuvaformaatteja: AVIF ja WebP ovat pakkauksen edelläkävijöitä. AVIF tarjoaa erityisesti laajat pakkausominaisuudet, vähentäen tiedostokokoa usein jopa 50 % verrattuna WebP:hen, mikä tekee siitä ihanteellisen monimutkaisille valokuville laadusta tinkimättä. WebP puolestaan säilyttää vahvan yhteensopivuuden laajemman selainvalikoiman kanssa ja on erityisen tehokas yksinkertaisemmille kuville.

Responsiiviset kuvat: <picture>-elementti ja srcset-attribuutti mahdollistavat näyttökoon mukaan räätälöidyt kuvat, tarjoten pienemmät kuvaversiot mobiilille ja korkearesoluutioiset versiot suuremmille näytöille. Tässä esimerkkiasetus:
<picture>
<source media="(min-width: 800px)" srcset="large.jpg 1x, larger.jpg 2x">
<img src="photo.jpg" loading="lazy" alt="Description">
</picture>Oikeat kuvamitat: Responsiiviset kuvat ovat vain osa ratkaisua, koska responsiivinen ei tarkoita oikean kokoista. Kuvamittojen sovittaminen niiden näyttökokoon on yksi yleisimmistä virheistä, joita näen. 2000px leveän kuvan tarjoaminen 500px näyttöalueelle tuhlaa kaistanleveyttä ja voi huomattavasti hidastaa latausaikoja.
2. Paranna verkon suorituskykyä:
Kun resurssien verkkokoot on optimoitu, seuraava askel on verkon nopeuden maksimointi — tai verkon ohittaminen kokonaan. Tämä voidaan saavuttaa:
Ohita verkkotarve: Ei ole nopeampaa verkkoyhteyttä kuin ohitettu verkkoyhteys. Selaimilla on mahdollisuus tarjoilla staattista (muuttumatonta) sisältöä, kuten kuvia, skriptejä ja tyylitiedostoja, suoraan selaimen paikallisesta välimuistista. Määritä palvelin lähettämään oikeat välimuistiohjeet selaimelle. Esimerkiksi expires-otsakkeen avulla.
Tehokkain tapa on lähettää Cache-Control-otsake näin:
Cache-Control: public, max-age=31536000, immutable
- public: Sallii resurssin välimuistittamisen sekä selaimissa että välipalvelimissa.
- max-age=31536000: Asettaa resurssin tuoreusajan enintään yhteen vuoteen (31 536 000 sekuntia).
- immutable: Ilmaisee, ettei resurssi muutu ajan myötä, estäen tarpeettomat uudelleenvalidointipyynnöt.
HTTP/3: Uusin HTTP/3-protokolla voi parantaa verkon suorituskykyä vähentämällä viivettä ja käsittelemällä pakettihävikkiä tehokkaammin kuin perinteinen TCP. (HTTP/3:lla on useita muitakin etuja erityisesti Time to First Byte -mittarin osalta)
HTTP/3:n käyttöönoton tarkistamiseksi tutki verkkoasi Ctrl-Shift-I-pikanäppäimellä. Valitse Network-välilehti, napsauta hiiren oikealla painikkeella verkkosarakkeiden otsikoita ja varmista, että 'protocol' on käytössä. Lataa sivu uudelleen ja tarkista protokolla. HTTP/3:lle protokollan tulisi näyttää 'h3'

Resurssien oma hosting: Tärkeät ja/tai aikaiset verkkoresurssit tulisi oletuksena aina isännöidä alkuperäpalvelimella. Oma hosting ohittaa tarpeen yhdistää kolmannen osapuolen palvelimiin, mikä voi aiheuttaa huomattavia viiveitä ylimääräisten DNS-hakujen, SSL-neuvottelujen ja yhteyden muodostamisen vuoksi. Oma hosting varmistaa yhden, jo avoimen yhteyden uudelleenkäytön ja vähentää erillisten yhteyksien muodostamisen aiheuttamaa kuormitusta. Itse isännöidyt resurssit mahdollistavat myös täyden hallinnan pakkaus- ja välimuistikäytännöistä.
Hyödynnä CDN:ää: Content Delivery Network (CDN) on hajautettujen palvelimien verkko, joka välimuistittaa ja tarjoilee staattisia resursseja, kuten kuvia, CSS:ää ja JavaScript-tiedostoja, käyttäjää lähempänä olevista sijainneista. Tämä vähentää datan matka-aikaa (kiertoviive), mikä vaikuttaa suoraan Resource Load Duration -aikaan. Tämän lisäksi monet CDN:t tarjoavat myös muita etuja, kuten kuvien pakkausta, edistyneitä verkkokonfiguraatioita (kuten HTTP/3 & 0-RTT) ja paljon muuta. Erikoistuneet kuvien CDN:t voivat viedä tätä pidemmälle tarjoamalla automaattisia, reaaliaikaisia optimointeja, kuten formaattimuunnoksia, koon muuttamista ja pakkausta.
3. Optimoi resurssien priorisointi
Resurssikoon pienentämisen ja verkon optimoinnin jälkeen on myös verkkokilpailun ongelma. Kun useita resursseja pyydetään samanaikaisesti huonoissa verkko-olosuhteissa, tämä voi hidastaa resurssien latausaikaa huomattavasti. Siksi on järkevää minimoida verkkokilpailu ajoittamalla resurssien lataukset.
Priorisoi kriittiset resurssit: Merkitse olennaiset resurssit, kuten hero-kuvat tai above-the-fold CSS, fetchpriority="high"-attribuutilla. Tämä viestii selaimelle, että nämä resurssit tulee ladata ensin, estäen niitä juuttumasta skriptien, widgettien tai kolmannen osapuolen elementtien taakse, jotka eivät tarvitse välitöntä latausta. Näiden kriittisten resurssien priorisointi vähentää latausaikaa sisällölle, josta käyttäjäsi välittävät eniten. Preloadin (myöhäisen löytämisen ratkaisemiseksi) ja fetchpriority="high" (verkkokilpailun ratkaisemiseksi) yhdistelmä on tehokkain tekniikka varmistamaan, että LCP-resurssi haetaan mahdollisimman aikaisin ja nopeasti.
<!-- LCP-kuville, jotka näkyvät alkuperäisessä HTML:ssä --> <img src="hero-image.webp" fetchpriority="high" alt="...">
<!-- Löydettävyyden parantamiseksi --> <link rel="preload" href="hero-image.webp" as="image" fetchpriority="high">
Vähennä verkkokilpailua: Tehosta alkuperäisiä latauksia lykkäämällä tai lazy-lataamalla ei-kriittisiä resursseja. Lykkää latausta kaikille kuville tai videoille, jotka eivät ole heti näkyvissä, sekä tausta- tai toissijaisille elementeille. loading="lazy" -attribuutin käyttö näkymäalueen ulkopuoliselle medialle on hyvä lähtökohta, ja muiden ei-kriittisten skriptien ja resurssien lykkääminen vapauttaa kaistanleveyttä ja vähentää kilpailua kriittisten resurssien kanssa, pitäen sivusi pääsisällön nopeana ladata ja näyttää. Älä koskaan käytä loading="lazy" -attribuuttia LCP-kuvassasi; tämä on kriittinen antipattern, joka heikentää tulostasi.
4. Ota käyttöön speculation rules
Speculation Rules mahdollistaa selainten ennalta hakea tai esirendata verkkosivuja ennustetun käyttäjänavigaation perusteella. Prefetching eliminoi käytännössä LCP:n Time to First Byte -osaosan eikä vaikuta resource load duration -aikaan. Prerendering renderöi seuraavan sivun piilotetussa välilehdessä ja lataa kaikki sivun resurssit. Tämä eliminoi suurimman osan LCP-elementin latauksen kestosta, kuten tässä esimerkissä esirenderöidyn sivun LCP-erittelystä näkyy.

Stop debating in Jira.
Get a definitive answer on your performance issues. I deliver a granular breakdown of your critical rendering path.
- Definitive Answers
- Granular Breakdown
- Critical Path Analysis

