Korjaa hitaat hero-kuvat ja Core Web Vitals

Kuinka korjata hitaat hero-kuvat – lyhyesti

Hero-kuvat ovat suuria kuvia verkkosivun yläosassa. Nämä hero-kuvat aiheuttavat pitkän Largest Contentful Paint -ajan, kun hero-kuvia ei ole optimoitu. 9 kymmenestä sivustosta, joita minua pyydeään optimoimaan, on ongelmia hero-kuvien kanssa. Tässä artikkelissa näytän sinulle erilaisia tekniikoita hero-kuvien nopeuttamiseen.

Mikä on hero-kuva?

Hero-kuva tai toisinaan ’hero header’ -nimellä kutsuttu elementti on suuri kuva tekstin kanssa, joka sijoitetaan usein verkkosivun yläosaan. Hero-kuva toimii käyttäjän ensimmäisenä näkymänä yritykseesi ja tarjontaasi, koska se on näkyvästi sijoitettu verkkosivun yläosaan ja ulottuu yleensä koko sivun levyiseksi.

Pikamuistutus: Hero-kuvat, Core Web Vitals ja Largest Contentful Paint

Hero-kuvan koon vuoksi (se ulottuu yleensä koko sivun leveydelle ja hyvän osan näkyvän näkymäalueen korkeudesta) tämä elementti muodostuu Largest Contentful Paint -elementiksi lähes kaikissa tapauksissa.

Largest Contentful Paint on tärkeä Core Web Vitals -mittari. Largest Contentful Paint -elementti on suurin elementti, joka piirretään selaimen näkyvään näkymäalueeseen.

Koska optimoimattomat kuvat vievät paljon kaistanleveyttä ja siksi latautuvat hitaasti, hero-kuvat aiheuttavat usein huonoja Largest Contentful Paint -tuloksia

Hero-kuvan ja Largest Contentful Paint -arvon optimointi

Hero-kuvien ja Largest Contentful Paint -arvon optimointiin on monia tekniikoita. Selitän ne tässä. Useimmat tekniikat voidaan yhdistää vielä parempien tulosten saavuttamiseksi!

1 Esilataa hero-kuva tai lähetä 103-otsikot

Kun haluat elementin olevan käytettävissä selaimessa mahdollisimman nopeasti, voit esiladata sen. Esilataus hyödyntää resurssvihjeitä. Resurssvihjeet kertovat selaimelle elementin prioriteetista ja käynnistävät resurssin hyvin aikaisen latauksen.

<link 
  rel="preload" 
  as="image" 
  href="wolf.jpg" 
  imagesrcset="hero_400px.jpg 400w, hero.jpg 800w, hero_1600px.jpg 1600w" 
  imagesizes="50vw">

Lähitulevaisuudessa Chrome-selaimet tukevat 103 early hints -ominaisuutta. Tämä mahdollistaa resurssvihjeiden lähettämisen ENNEN lopullisen HTML-vastauksen lähettämistä. 103 early hints -ominaisuuden odotetaan olevan mullistava Largest Contentful Paint -arvon parantamisessa. Jos olet kiinnostunut oppimaan lisää aikaisista resurssivihjeistä, tutustu artikkeliini.

2 Pakkaa hero-kuva & käytä seuraavan sukupolven formaatteja

Kuvien pakkaaminen pienentää niiden tiedostokokoa. Pienemmät tiedostokoot vievät vähemmän kaistanleveyttä ja ovat selaimelle käytettävissä mahdollisimman nopeasti. Kuvien pakkaaminen voidaan tehdä kuvankäsittelyohjelmassasi, sisällönhallintajärjestelmässäsi (vinkki: kehittäjäsi voi asettaa WordPress-pakkaustason) tai verkkopohjaisella kuvanpakkaustyökalulla

Useimmat hitaat hero-kuvat ovat hitaampia kuin niiden tarvitsisi olla, koska ne tarjoillaan ’väärässä’ kuvaformaatissa kuten PNG tai JPEG. WebP ja AVIF ovat paljon nopeampia vaihtoehtoja JPEG:lle ja PNG:lle. 

Monille sisällönhallintajärjestelmille on saatavilla muunnosliitännäisiä, jotka muuntavat kuvat seuraavan sukupolven formaattiin. Kun kuvamuunnoksen integrointi verkkosivustoosi on vaikeaa, CDN kuvamuunnostuen kanssa voi olla etsimäsi ratkaisu.

3. Älä käytä taustakuvia, käytä tavallisia responsiivisia kuvia

Hero-kuvasi tulisi olla tavallinen kuva eikä koskaan taustakuva. Yleinen tapa tehdä hero-kuvia on lisätä taustakuva hero-säiliöön ja asettaa sen background-size-ominaisuudeksi cover. Tämä varmistaa, että hero-kuva sopii näytölle kaikissa tapauksissa.

Taustakuvat ovat haitallisia Core Web Vitals -arvoille. Muista se! Taustakuville ei ole koskaan hyvää syytä.

• Taustakuvat ladataan alhaisemmalla prioriteetilla
• Taustakuvat eivät ole responsiivisia (ellet halua todella monimutkaistaa asioita)
• Taustakuvat voivat aiheuttaa Core Web Vitals -ongelmia useimpien lazy loading -kirjastojen kanssa.
  

Tapa, jolla teen sen, on lisätä tavallinen kuva absoluuttiseen sijaintiin ja asettaa kuvan object-fit-ominaisuudeksi cover. Kun olen vaihtanut taustakuvan tavalliseksi kuvaksi, voin alkaa käyttää responsiivisia kuvia

Responsiiviset kuvat tarkoittavat, että eri laitteille (mobiili, työpöytä, tabletti) voidaan lähettää eri versio samasta hero-kuvasta. Työpöytälaitteelle saatan lähettää suuren 1920x1280 hero-kuvan, kun taas mobiililaitteelle tarvitsisi lähettää vain pienempi 400*266 pikselin hero-kuva. Se on 25 kertaa vähemmän dataa!

• Hero-kuvat ladataan nyt korkeammalla prioriteetilla
• Voin nyt käyttää responsiivisia kuvia hero-kuvalle

style.css

<style>
#herocontainer{
    position:relative;
    padding:4rem 0
}
#heroimg{
    object-fit: cover;
    width: 100%;
    height: 100%;
    position: absolute;
    top: 0;
}
</style>

index.html

<div id="herocontainer">
<h1>Tervetuloa sivustolleni</h1>
<picture>
    <source 
        type="image/webp" 
        media="(max-width:540px)" 
        srcset="herosm.webp">
    </source>
    <img loading="eager" decoding="async" src="hero.webp" id="heroimg">
</picture>
</div>

4. Tarjoile hero-kuvat päädomainilta & harkitse sisällönjakeluverkkoa (CDN)

Liian usein näen Largest Contentful Paint -kuvan tarjoiltavan eri domainilta, esimerkiksi ’static.mydomain.com’. Nämä alidomainit osoittavat usein CDN:ään. Vaikka kannustankin CDN:n käyttöön (katso alla), tällainen asetus ei ole suositeltava. Kuva alidomainilla vaatii uuden yhteyden uudelle palvelimelle. Uudet yhteydet ovat kalliita ja vievät arvokasta aikaa. Kun kuva tarjoillaan päädomainilta (esimerkiksi www.mydomain.com), kuvat voidaan hakea paljon nopeammin jo muodostetun palvelinyhteyden kautta.

Päädomainille asennettuna CDN voi tarjota valtavan nopeusparannuksen. Erityisesti kun sivustoasi vieraillaan ympäri maailmaa. CDN:llä on strategisesti sijoitettuja palvelimia ympäri maailmaa, joissa staattiset resurssit (kuten kuvat) on välimuistitettu nopeita paikallisia vasteaikoja varten. Tämä tarkoittaa, että datan ei tarvitse matkustaa ympäri maailmaa, vaan se voidaan tarjoilla paikalliselta reunapalvelimelta.

5. Vältä hero-kuvien lazy loading -latausta & aseta hero-kuva nimenomaisesti eager-lataukselle

Varmista, ettei hero-kuvaasi sovelleta lazy loading -latausta. Hero-kuvien tulisi aina latautua eager-tilassa.

Monet sivustot, erityisesti WordPress-sivustot, käyttävät jonkinlaista WordPress-nopeusliitännäistä kuten WP Rocket tai WP Core Web Vitals. Nämä liitännäiset tekevät yleensä hienoa työtä hitaiden sivustojen nopeuttamisessa, mutta ne eivät voi korjata tyhmyyttä :-)

Nämä liitännäiset lataavat lazy loading -tekniikalla kuvat, jotka vaikuttavat hyvilta ehdokkailta lazy loading -lataukselle. Jos hero-kuva ei ole eager-kuva, nämä liitännäiset todennäköisesti lataavat myös hero-kuvan lazy loading -tekniikalla.

Tämä aiheuttaa parhaimmillaan pienen viiveen LCP-mittareihin. Pahimmillaan, erityisesti kun JavaScript-pohjainen lazy loading on aktivoitu, se aiheuttaa suuremman viiveen.

Kuvien eager-latauksen asettaminen on melko yksinkertaista. Lisää vain loading="eager" kuvaan ja olet valmis.

<img src="hero.webp"  width="800" height="400">

6. Vältä hero-kuvan aiheuttamia layout shift -siirtymiä

Toinen yleinen ongelma, jonka näen hero-bannereiden ja hero-kuvien kanssa, on se, että ne aiheuttavat suuren layout shift -siirtymän. Nämä layout shift -siirtymät voivat johtua eri syistä.

• Hero-elementti luodaan JavaScript-koodilla. Jotkut hero-liitännäiset ja sivunrakentajat kuten Elementor tunnetusti tukeutuvat JavaScript-koodiin hero-sisällön renderöimiseksi. Vaikka JavaScript-koodissa ei ole mitään vikaa, varmista, että hero-elementti renderöityy samalla tavalla ilman JavaScript-koodia.
• Hero-elementin fontit aiheuttavat layout shift -siirtymän. Hero-elementti sisältää yleensä suurta tekstiä, jossa on toimintakehote ja iskulause. Varmista, ettevät nämä suuret fontit aiheuta layout shift -siirtymää.
• Puuttuvat kuvadimensiot. Kun hero-kuva ei ole cover-kuva (joko taustakuvana tai absoluuttisesti sijoitettuna kuvana), puuttuvat kuvadimensiot (leveys ja korkeus) aiheuttavat varmasti suuren layout shift -siirtymän.

Vaikka layout shift -siirtymän korjaaminen ei paranna Largest Contentful Paint -arvoa, se parantaa sivun Core Web Vitals -tuloksia. Lisätietoja layout shift -siirtymän korjaamisesta löydät tästä syvällisestä oppaasta layout shift -siirtymän korjaamiseen!

7. Käytä 2-vaiheista latausta hero-kuvan Core Web Vitals -arvojen parantamiseen

2-vaiheinen lataus on nopea tekniikka, jota sovellamme kaikkiin kuviimme. Tarjoilemme ensin erittäin heikkolaatuisen kuvan, jonka odotetaan latautuvan paljon aikaisemmin kuin suuremman korkealaatuisen kuvan. Kun heikkolaatuinen kuva on piirretty näytölle, selain käynnistetään hakemaan korkealaatuinen kuva taustalla. Kun korkealaatuinen kuva on ladattu, heikkolaatuinen kuva korvataan korkealaatuisella kuvalla.

2-vaiheiseen lataukseen on 3 menetelmää. Kaksi ensimmäistä ovat menetelmiä, joita kannattaa harkita. Viimeistä ei kannata käyttää.

1. Täysi 2-vaiheinen lataus

Täydessä 2-vaiheisessa latauksessa ensimmäisellä heikkolaatuisella kuvalla on täsmälleen samat dimensiot (leveys ja korkeus) kuin alkuperäisellä korkealaatuisella kuvalla.

Tämän 2-vaiheisen latauksen tulos on, että Largest Contentful Paint -elementti on paljon nopeampi, heikkolaatuinen kuva (joka sitten vaihdetaan laiskasti). Kuvan vaihtaminen tapahtuu niin nopeasti, ettei satunnainen vierailija todennäköisesti koskaan huomaa sitä. Tämän tekniikan tulos on, että LCP piirretään paljon aikaisemmin, sivu näyttää ’valmiilta’ paljon nopeammin, mikä edistää huomattavasti parempaa user experience -kokemusta ja parempia Core Web Vitals -tuloksia.

2. Pienemmät inline-paikkamerkit

Pienempi paikkamerkki on melko siisti tekniikka, jolla on yksi haittapuoli: se ei paranna Core Web Vitals -tuloksia. Se on silti loistava tekniikka, koska se parantaa user experience -kokemusta.

Perusidea on sama kuin 2-vaiheisessa lataustekniikassa, mutta yhden samankokoisen heikkolaatuisen kuvan sijaan paljon pienempi kuva pienemmilla dimensioilla sijoitetaan inline data-URI:n kautta. Lopullinen hero-kuva, joka on Largest Contentful Paint -kuva, ladataan edelleen taustalla. Tämä temppu ei paranna Largest Contentful Paint -arvoa, mutta saa sivun näyttämään valmiilta vielä nopeammin kuin 2-vaiheinen lataustekniikka

3. Läpinäkyvät paikkamerkit

Yleinen 2-vaiheinen lataustekniikka ja menetelmä huijata selain lähettämään aikainen Largest Contentful Paint -mittari on käyttää läpinäkyviä SVG-elementtejä. Nämä elementit ovat pieniä ja ne voidaan sijoittaa inline, aivan kuten pienempi inline-paikkamerkki.

Inline SVG-elementtien käyttö ja niiden vaihtaminen on itse asiassa lazy loading -tekniikka. Tämän tekniikan etu on, että se toimii kaikissa selaimissa. 

Lazy loading -latausta tulisi tietysti soveltaa vain näkymäalueen ulkopuolella oleviin elementteihin. Tässä tapauksessa läpinäkyvä SVG-elementti vain viivastyttää todellista hero-kuvaa eikä tuota lisäarvoa vierailijoillesi. Vaikka piirtomittarit saattavat olla hyviä, sivun UX itse asiassa heikkenee.

Siksi hero-kuva tulisi aina ladata eagerly ilman temppuja, jotka aiheuttavat huonon UX:n.