Largest Contentful Paint (LCP): mitä se tarkoittaa ja miten sitä parannetaan?
Largest Contentful Paint eli LCP on yksi tärkeimmistä verkkosivuston nopeusmittareista.
Se kertoo, kuinka nopeasti sivun suurin näkyvällä alueella oleva sisältöelementti piirtyy kävijän näytölle. Käytännössä LCP-elementti on usein sivun pääkuva, hero-kuva, suuri otsikko tai muu heti sivun alussa näkyvä sisältö.
LCP ei mittaa koko sivun latautumisaikaa. Sivulla voi edelleen latautua esimerkiksi kuvia, kommentteja, karttoja, videoita tai muita elementtejä LCP-hetken jälkeen.
Hyvä LCP tarkoittaa yleensä sitä, että kävijä näkee nopeasti sivun tärkeimmän sisällön. Hidas LCP taas voi tehdä sivustosta raskaan ja turhauttavan tuntuisen, vaikka kaikki muut elementit lopulta latautuisivatkin.
Mitä Largest Contentful Paint tarkoittaa?
LCP mittaa aikaa sivun lataamisen alusta siihen hetkeen, jolloin suurin näkyvällä alueella oleva kuva- tai tekstielementti on renderöitynyt selaimessa.
LCP-elementti voi olla esimerkiksi:
- artikkelin pääkuva
- verkkokaupan tuotekuva
- hero-alueen kuva
- suuri otsikko tai tekstilohko
- CSS-taustakuvana näkyvä suuri kuva
- videon posterikuva ennen videon käynnistymistä
LCP ei yleensä tarkoita itse videon täydellistä latautumista tai toistumista. Jos sivun yläosassa on video, LCP voi liittyä esimerkiksi videon esikatselukuvaan.
LCP-elementti voi myös olla erilainen mobiilissa ja tietokoneella. Siksi nopeutta kannattaa testata molemmilla näkymillä.
Miksi LCP on tärkeä?
LCP liittyy ennen kaikkea käyttökokemukseen.
Kun sivun tärkein sisältö näkyy nopeasti, kävijä saa heti käsityksen siitä, että sivu toimii ja että hän on tullut oikeaan paikkaan.
Hidas LCP voi näkyä esimerkiksi näin:
- hero-kuva ilmestyy vasta pitkän odotuksen jälkeen
- suuri otsikko tulee näkyviin myöhässä
- tuotekuva latautuu hitaasti
- sivu näyttää pitkään tyhjältä tai keskeneräiseltä
- kävijä joutuu odottamaan ennen kuin hän voi arvioida sivun sisältöä
LCP on myös yksi Core Web Vitals -mittareista. Hyvä sivukokemus voi tukea hakunäkyvyyttä, mutta hyvä LCP-arvo ei yksin takaa hyviä sijoituksia Googlessa.
Sivun sisällön laatu, hakuaikomukseen vastaaminen, tekninen toimivuus, linkitykset ja sivuston kokonaisuus ovat edelleen tärkeämpiä kuin yhden nopeusmittarin täydellinen tulos.
Hyvä, parannettava ja huono LCP-arvo
LCP-arvot jaetaan yleensä kolmeen luokkaan:
| LCP-arvo | Tulkinta |
|---|---|
| Enintään 2,5 sekuntia | Hyvä |
| 2,5–4 sekuntia | Parannettavaa |
| Yli 4 sekuntia | Huono |
Tavoite ei ole saada yksittäisestä testistä täydellistä tulosta. Tärkeämpää on, että suurin osa oikeista kävijöistä kokee sivun nopeaksi.
Siksi LCP:tä kannattaa tarkastella erityisesti kenttädatan avulla. Kenttädata kertoo, miten sivusto toimii oikeilla käyttäjillä, oikeilla laitteilla ja erilaisilla verkkoyhteyksillä.
Kenttädata ja laboratoriodata – mikä niiden ero on?
LCP:tä voidaan mitata kahdella eri tavalla.
Kenttädata kertoo oikeiden kävijöiden kokemuksesta
Kenttädata perustuu todellisiin käyttäjiin.
Se voi sisältää tietoa esimerkiksi:
- mobiililaitteista
- pöytäkoneista
- hitaista ja nopeista verkkoyhteyksistä
- eri selaimista
- eri maista tulevista kävijöistä
- oikeista sivulatauksista
Google Search Consolen Core Web Vitals -raportti perustuu kenttädataan silloin, kun sivustolla on riittävästi käyttäjädataa saatavilla.
Kenttädata on tärkeää, koska se kertoo, miten sivusto toimii käytännössä eikä vain omalla tietokoneellasi.
Laboratoriodata auttaa löytämään ongelmia
Laboratoriodata syntyy hallitussa testissä.
Hyviä työkaluja ovat esimerkiksi:
- Google PageSpeed Insights
- Lighthouse
- Chrome DevTools
- WebPageTest
- GTmetrix
Laboratoriotesti ei aina vastaa täysin oikean kävijän kokemusta. Se on silti erittäin hyödyllinen ongelmien etsimiseen.
PageSpeed Insights näyttää usein sekä kenttädataa että laboratoriodataa. Jos kenttädataa ei ole tarpeeksi, laboratoriodata auttaa silti tunnistamaan suurimmat pullonkaulat.
Google Analytics ei näytä LCP:tä automaattisesti
Google Analytics 4 ei normaalisti kerää Core Web Vitals -mittareita automaattisesti.
GA4 voi auttaa seuraamaan esimerkiksi liikennettä, tapahtumia, ostoksia ja lomakkeiden lähetyksiä, mutta LCP-, INP- ja CLS-mittareita varten tarvitset yleensä erillisen toteutuksen.
Useimmille WordPress-sivustoille helpoin tapa seurata LCP:tä on:
- Google Search Consolen Core Web Vitals -raportti
- Google PageSpeed Insights
- Lighthouse selaimen kehittäjätyökaluissa
Jos tarvitset tarkempaa omaa käyttäjädataa, LCP-arvoja voidaan lähettää Analyticsiin esimerkiksi web-vitals-kirjaston tai Google Tag Managerin avulla. Tämä on yleensä tarpeen vasta laajemmilla sivustoilla tai silloin, kun suorituskykyä seurataan hyvin tarkasti.
Selvitä ensin, mikä sivusi LCP-elementti on
LCP-optimointi kannattaa aloittaa tunnistamalla, mikä elementti on ongelma.
Avaa tärkeä sivu PageSpeed Insightsissa tai Lighthouse-raportissa. Työkalu kertoo yleensä, mikä sivun LCP-elementti on.
Se voi olla esimerkiksi:
- etusivun hero-kuva
- artikkelin pääkuva
- verkkokaupan tuotekuva
- suuri otsikko
- taustakuva
- karusellin ensimmäinen kuva
Älä optimoi summassa kaikkia kuvia tai tiedostoja. Keskity ensin siihen elementtiin, joka todella määrittää LCP-arvon.
Tarkista erityisesti:
- etusivu
- tärkeimmät palvelusivut
- suosituimmat blogiartikkelit
- verkkokaupan tuotesivut
- kategoriat ja tuotelistaukset
- mobiilinäkymä
- tietokonenäkymä
Yleisimmät syyt hitaaseen LCP-arvoon
LCP hidastuu tavallisesti yhdestä tai useammasta näistä syistä:
- palvelin vastaa hitaasti
- pääkuva on liian suuri
- LCP-kuva löytyy selaimelle liian myöhään
- pääkuva on lazy-loadattu
- kuva lisätään sivulle vasta JavaScriptillä
- hero-kuva on CSS-taustakuvana eikä selaimen löydettävissä heti
- sivulla on paljon renderöintiä estävää CSS:ää
- JavaScript kuormittaa selaimen pääsäiettä
- fontit latautuvat hitaasti
- kolmannen osapuolen skriptit viivästyttävät sivun alkuvaihetta
- välimuisti puuttuu tai toimii huonosti
- palvelin, tietokanta tai WordPress-teema on raskas
LCP-ongelmaa kannattaa ajatella neljän vaiheen kautta:
- Kuinka nopeasti palvelin vastaa?
- Kuinka nopeasti selain löytää LCP-elementin?
- Kuinka nopeasti LCP-elementti latautuu?
- Kuinka nopeasti selain pystyy näyttämään sen?
1. Optimoi LCP-kuva oikein
LCP-elementti on usein kuva. Siksi kuvien optimointi on tavallisesti nopein tapa parantaa LCP-arvoa.
Älä lazy-loadtaa LCP-kuvaa
Lazy loading sopii hyvin sivun alempana oleville kuville.
Sitä ei kuitenkaan pidä käyttää kuvalle, joka näkyy heti sivun yläosassa ja on todennäköisesti LCP-elementti.
Jos pääkuvassa on esimerkiksi tämä:
<img src="hero-kuva.webp" loading="lazy" alt="">
selain voi aloittaa kuvan lataamisen liian myöhään.
LCP-kuvan kannattaa latautua normaalisti heti sivun latauksen alussa.
WordPress osaa nykyisissä versioissa lisätä latausoptimointiin liittyviä attribuutteja automaattisesti. Tarkista silti julkaistun sivun lähdekoodista, ettei tärkein kuva ole saanut vahingossa loading="lazy"-attribuuttia.
Käytä oikeaa kuvakokoa
Älä lataa sivulle 5000 pikselin levyistä kuvaa, jos se näkyy enintään 1600 pikselin levyisenä.
Pääkuvan pitäisi olla riittävän laadukas isoilla näytöillä, mutta sen ei tarvitse olla alkuperäisen kameratiedoston kokoinen.
Hyvä lähtökohta on:
- tarkista kuvan todellinen näyttökoko
- tee kuva kyseiseen käyttöön sopivaksi
- käytä pakkausta
- säilytä alkuperäinen tiedosto muualla kuin sivuston julkisessa kuvaversiossa
- testaa lopullinen tiedostokoko
Käytä responsiivisia kuvia
Responsiivinen kuva tarkoittaa, että selain saa käyttöönsä eri kokoisia versioita samasta kuvasta.
WordPress lisää tavallisesti kuville srcset– ja sizes-attribuutteja, kun kuva lisätään Mediakirjastosta tavallisella Kuva-lohkolla.
Selain voi silloin valita laitteelle sopivan kuvan.
Tämä on tärkeää erityisesti mobiilissa. Puhelimeen ei kannata ladata yhtä suurta kuvaa kuin leveälle työpöytänäytölle.
Käytä tarkoitukseen sopivaa kuvatiedostomuotoa
Valokuviin sopivat usein:
- WebP
- AVIF
- JPEG
PNG sopii erityisesti grafiikkaan, logoihin ja kuviin, joissa tarvitaan läpinäkyvyyttä.
WebP tai AVIF voi pienentää tiedostokokoa merkittävästi, mutta tiedostomuoto ei yksin ratkaise ongelmaa. Liian suuri tai liian korkealaatuinen WebP-kuva voi olla edelleen raskas.
Käytä fetchpriority-attribuuttia harkiten
Jos tiedät varmasti, että tietty kuva on sivun LCP-elementti, sille voidaan antaa korkeampi latausprioriteetti:
<img
src="hero-kuva.webp"
fetchpriority="high"
alt="Vaellusreppu tunturireitillä">
Tätä ei pidä lisätä kaikille kuville.
Jos liian moni kuva asetetaan korkealle prioriteetille, selain ei enää tiedä, mikä resurssi on todella tärkein.
Käytä fetchpriority="high"-asetusta korkeintaan yhdelle tai kahdelle aidosti tärkeälle kuvalle sivulla.
Esilataa kuva vain, jos siihen on selkeä syy
Jos LCP-kuva löytyy sivulta vasta CSS-tiedoston tai JavaScriptin kautta, selain voi huomata sen liian myöhään.
Tällöin kuvan esilataus voi auttaa:
<link
rel="preload"
as="image"
href="/wp-content/uploads/hero-kuva.webp">
Esilataus ei kuitenkaan ole automaattinen ratkaisu.
Jos esilataat liikaa resursseja, sivu voi jopa hidastua. Käytä preloadia vain silloin, kun testi osoittaa, että tärkeä kuva löytyy selaimelle liian myöhään.
2. Paranna palvelimen vastausaikaa
Hidas palvelin voi viivästyttää kaikkea muuta.
Jos HTML-sivu saapuu selaimelle hitaasti, selain ei voi löytää pääkuvaa, CSS-tiedostoja, JavaScriptiä tai muita LCP:n kannalta tärkeitä resursseja ajoissa.
Palvelinvasteaikaa kutsutaan usein lyhenteellä TTFB eli Time To First Byte.
Hidas TTFB voi johtua esimerkiksi:
- heikosta webhotellista
- puuttuvasta sivuvälimuistista
- hitaasta tietokannasta
- liian raskaasta teemasta
- monista lisäosista
- ulkoisista API-kutsuista
- hitaista palvelinpuolen toiminnoista
- liian pienistä palvelinresursseista
- monista uudelleenohjauksista
Käytä sivuvälimuistia
Sivuvälimuisti tallentaa sivusta valmiin version, jota voidaan näyttää kävijälle ilman, että WordPress rakentaa sivun jokaisella latauksella alusta asti.
Välimuisti voi parantaa erityisesti tavallisten sivujen, artikkelien ja palvelusivujen nopeutta.
Usein hyvä kokonaisuus voi sisältää:
- palvelintasoisen välimuistin
- WordPressin välimuistilisäosan
- selaimen välimuistin
- CDN-palvelun
- kuvien optimoinnin
Älä käytä useaa välimuisti- tai optimointilisäosaa yhtä aikaa ilman selkeää suunnitelmaa. Päällekkäiset asetukset voivat rikkoa JavaScriptiä, CSS:ää tai verkkokaupan toimintoja.
Vähennä turhat uudelleenohjaukset
Yksi ylimääräinen uudelleenohjaus voi viivästyttää sivun latausta.
Tarkista esimerkiksi, ettei sivu kulje turhaan tällaisen ketjun kautta:
http://sivusto.fi
→ https://sivusto.fi
→ https://www.sivusto.fi
→ https://www.sivusto.fi/etusivu/
Tavoitteena on, että kävijä päätyy oikeaan osoitteeseen mahdollisimman vähillä vaiheilla.
Harkitse CDN-palvelua
CDN eli Content Delivery Network voi nopeuttaa kuvia, CSS-tiedostoja, JavaScriptiä ja muita staattisia resursseja erityisesti silloin, kun kävijöitä tulee eri puolilta maailmaa.
Suomessa toimivalle pienelle paikalliselle sivustolle CDN ei aina ole ensimmäinen ratkaisu. Jos pääongelma on hidas WordPress-palvelin tai liian raskas kuva, nämä kannattaa korjata ensin.
3. Vähennä renderöintiä estävää CSS:ää ja JavaScriptiä
CSS ja JavaScript voivat viivästyttää LCP-elementin näyttämistä.
Selain tarvitsee CSS:ää sivun ulkoasun muodostamiseen. JavaScript taas voi estää selainta tekemästä muuta työtä, jos sitä ladataan tai suoritetaan paljon heti sivun alussa.
Tavallisia ongelmia ovat:
- liian suuri CSS-tiedosto
- käyttämätön CSS
- useat sivunrakentajan tyylitiedostot
- paljon JavaScriptiä lataavat lisäosat
- karusellit ja animaatiot
- chat-widgetit
- seuranta- ja mainosskriptit
- sosiaalisen median upotukset
- kartat ja videot
- lomakelisäosien tiedostot kaikilla sivuilla
Älä optimoi JavaScriptiä sokkona
JavaScriptin lykkääminen voi auttaa, mutta väärin tehtynä se voi rikkoa sivuston toimintoja.
defer sopii usein skripteille, joiden pitää säilyttää suoritusjärjestys ja jotka voivat odottaa HTML-sisällön jäsentymistä.
async sopii itsenäisille skripteille, joiden suoritusjärjestyksellä ei ole väliä.
Esimerkiksi analytiikka-, chat- tai mainosskripti voidaan usein ladata myöhemmin kuin sivun tärkein sisältö. Sen sijaan teeman valikon tai verkkokaupan tarvitsemaa JavaScriptiä ei pidä viivästyttää ilman huolellista testausta.
Tee aina muutos kerrallaan ja testaa sen jälkeen ainakin:
- valikot
- lomakkeet
- ostoskori
- kassasivu
- kuvagalleriat
- mobiilinäkymä
- kirjautuminen
- välimuistin tyhjennyksen jälkeinen sivu
Kriittinen CSS voi auttaa, mutta ei ole pakollinen kaikille
Kriittinen CSS tarkoittaa sivun yläosan ulkoasuun tarvittavia tyylejä.
Ne voidaan lisätä suoraan HTML:n alkuun, jolloin selain pystyy näyttämään tärkeimmän osan sivusta ennen kuin kaikki muut tyylitiedostot ovat latautuneet.
Tämä voi auttaa raskaan teeman tai sivunrakentajan kanssa, mutta toteutus kannattaa automatisoida luotettavalla työkalulla tai tehdä kehittäjän avulla.
Manuaalinen kriittisen CSS:n ylläpito voi olla työlästä, jos sivustolla on paljon erilaisia sivupohjia.
4. Optimoi fontit
Fontit voivat viivästyttää suurta otsikkoa tai tekstilohkoa, jos ne ladataan hitaasti.
Tämä voi vaikuttaa LCP-arvoon silloin, kun suuri otsikko tai tekstialue on sivun suurin näkyvä elementti.
Hyviä käytäntöjä ovat:
- käytä mahdollisimman vähän fonttiperheitä
- käytä vain tarvittavia fonttipaksuuksia
- suosi WOFF2-muotoa
- lataa vain sivulla käytettävät fontit
- esilataa tarvittaessa yksi kriittinen fonttitiedosto
- käytä
font-display: swap-asetusta harkiten - vältä useiden erilaisten fonttien lataamista jokaisella sivulla
font-display: swap voi auttaa näyttämään tekstin nopeasti varafontilla ennen varsinaisen fontin latautumista.
Testaa kuitenkin lopputulos. Jos varafontti ja lopullinen fontti ovat hyvin eri kokoisia, tekstin vaihtuminen voi aiheuttaa ulkoasun siirtymistä.
5. Hallitse kolmannen osapuolen skriptejä
Kolmannen osapuolen skriptejä ovat esimerkiksi:
- Google Analytics
- Google Tag Manager
- Meta Pixel
- mainosverkostot
- chat-palvelut
- kartat
- YouTube-upotukset
- Instagram-syötteet
- arvostelupalvelut
- evästebannerit
- ajanvarauspalvelut
- maksutavat
Yksittäinen skripti ei välttämättä ole suuri ongelma. Useiden palvelujen yhdistelmä voi kuitenkin kasvattaa sivun kuormaa merkittävästi.
Kysy jokaisesta ulkoisesta palvelusta:
Tarvitaanko tätä todella heti sivun latauksen alussa?
Hyviä ratkaisuja voivat olla esimerkiksi:
- YouTube-videon näyttäminen kevyenä esikatselukuvana ennen videon lataamista
- kartan lataaminen vasta kävijän pyynnöstä
- chatin avaaminen vasta muutaman sekunnin kuluttua
- sosiaalisen median syötteen poistaminen etusivulta
- mainosskriptien viivästetty lataaminen
- tarpeettomien tagien poistaminen Google Tag Managerista
WordPressin LCP-optimointi käytännössä
WordPress-sivustolla LCP-ongelma liittyy usein pääkuvaan, teemaan, lisäosiin tai välimuistiin.
Hyvä etenemisjärjestys on tämä.
1. Testaa tärkein sivu PageSpeed Insightsilla
Aloita esimerkiksi etusivusta tai tärkeimmästä palvelusivusta.
Katso:
- mikä elementti on LCP
- onko ongelma mobiilissa, tietokoneessa vai molemmissa
- onko LCP-kuva lazy-loadattu
- onko kuva liian suuri
- latautuuko kuva myöhään
- onko TTFB korkea
- näkyykö renderöintiä estäviä resursseja
- kuormittavatko JavaScript ja kolmannen osapuolen skriptit sivua
2. Optimoi ensin pääkuva
Jos LCP-elementti on kuva:
- varmista, ettei kuva ole lazy-loadattu
- pienennä tiedostokokoa
- käytä oikeaa kuvasuhdetta
- käytä responsiivisia kuvakokoja
- käytä WebP- tai AVIF-muotoa tarvittaessa
- harkitse
fetchpriority="high"-asetusta - testaa uudelleen
3. Tarkista välimuisti ja TTFB
Jos palvelin vastaa hitaasti:
- ota sivuvälimuisti käyttöön
- tarkista webhotellin suorituskyky
- vähennä tarpeettomia lisäosia
- tarkista tietokannan kuormitus
- poista tarpeettomat ulkoiset pyynnöt
- tarkista, ettei sivulla ole pitkää uudelleenohjausketjua
- harkitse palvelintason välimuistia tai CDN:ää
4. Karsi raskaat elementit sivun yläosasta
Hero-alueella ei yleensä tarvita kaikkea mahdollista.
Vältä erityisesti:
- automaattisesti käynnistyviä taustavideoita
- raskaita kuvakaruselleja
- useita suuria kuvia samassa näkymässä
- useita ulkoisia fontteja
- karttoja ja sosiaalisen median syötteitä heti sivun alussa
- useita ponnahdusikkunoita
- suuria animaatioita
- tarpeettomia seuranta- ja markkinointitageja
Usein yksinkertaisempi hero-alue on nopeampi, helpompi käyttää ja tehokkaampi myös viestin kannalta.
LCP:n tarkistuslista
Kun LCP on hidas, käy läpi nämä kohdat:
- Mikä elementti on sivun LCP-elementti?
- Onko LCP-elementti kuva, tekstilohko vai taustakuva?
- Onko LCP-kuva lazy-loadattu?
- Onko kuva liian suuri tai liian raskas?
- Onko kuvalla responsiiviset
srcset– jasizes-attribuutit? - Onko LCP-kuva selaimen löydettävissä heti HTML:stä?
- Tarvitaanko kuvalle
fetchpriority="high"? - Tarvitaanko esilatausta vai löytyykö kuva jo riittävän nopeasti?
- Onko palvelimen TTFB hidas?
- Toimiiko sivuvälimuisti?
- Onko sivulla paljon renderöintiä estävää CSS:ää?
- Kuormittaako JavaScript selaimen pääsäiettä?
- Ladataanko liikaa fontteja tai fonttipaksuuksia?
- Hidastavatko kolmannen osapuolen skriptit sivua?
- Toimiiko sivu hyvin myös mobiilissa?
- Onko tulos parempi oikeilla käyttäjillä, ei vain yksittäisessä testissä?
Yhteenveto
LCP kertoo, kuinka nopeasti sivuston tärkein näkyvä sisältö tulee kävijän nähtäväksi.
Hyvä LCP syntyy yleensä näiden asioiden yhdistelmästä:
- nopea palvelin
- toimiva sivuvälimuisti
- oikein optimoitu pääkuva
- LCP-kuvan nopea löytyminen selaimelle
- ei lazy loadingia tärkeimmälle kuvalle
- maltillinen määrä JavaScriptiä ja ulkoisia skriptejä
- optimoidut fontit
- selkeä ja kevyt sivun yläosa
Älä yritä korjata kaikkea yhtä aikaa.
Aloita tunnistamalla LCP-elementti, korjaa suurin ongelma ja testaa vaikutus. Usein jo pääkuvan optimointi, lazy loadingin poistaminen ja välimuistin käyttöönotto voivat parantaa sivun nopeutta selvästi.
LCP on tärkeä mittari, mutta se ei ole koko sivuston suorituskyky. Hyvä WordPress-sivusto on samalla nopea, vakaa, helppokäyttöinen ja sisällöltään hyödyllinen.
