Largest Contentful Paint (LCP) on yksi kolmesta Core Web Vitals -mittarista, ja se mittaa aikaa, joka kuluu suurimman näkyvän sisältöelementin renderöintiin käyttäjän näytöllä. Käytännössä tämä on lähes aina hero-kuva, pääotsikko tai video. Googlen suosittelema hyvä arvo on alle 2,5 sekuntia, mitattuna 75. prosenttipisteessä todellisesta käyttäjädatasta (CrUX).
Kuulostaa kohtuulliselta, eikö? No, todellisuus on karumpi.
Vuoden 2026 CrUX-datan mukaan vain noin 66 % verkkosivustoista läpäisee LCP:n hyvän raja-arvon. Kotisivuilla tilanne on vielä synkempi: mobiilissa vain 45 % läpäisee Core Web Vitals -kynnyksen, kun taas alasivuilla luku on 56 %. Eli yli kolmasosa sivustoista tarjoaa käyttäjilleen liian hitaan kokemuksen — ja tämä näkyy suoraan hakusijoituksissa.
Tässä oppaassa käydään läpi kaikki neljä LCP:n osakomponenttia ja näytetään konkreettisin koodiesimerkein, miten kukin optimoidaan. Mennään asiaan.
LCP:n neljä osakomponenttia
LCP-arvo ei ole yksi monoliittinen luku — se on neljän erillisen vaiheen summa. Tämän ymmärtäminen on rehellisesti sanottuna tärkein asia koko LCP-optimoinnissa, koska ilman sitä korjaat väärää ongelmaa.
1. Time to First Byte (TTFB)
TTFB kattaa kaiken DNS-hausta TCP/TLS-kättelyyn ja palvelimen vasteaikaan. Googlen suosittelema tavoite on alle 800 ms.
Tässä on yksi huolestuttava tilasto: yli puolella huonon LCP:n omaavista sivustoista pelkkä TTFB:n p75-arvo (2 270 ms) ylittää jo koko 2,5 sekunnin LCP-rajan. Eli sivu ei ole edes alkanut latautua kunnolla, ja budjetti on jo käytetty.
Googlen suositus: TTFB:n tulisi viedä noin 40 % LCP-budjetista.
2. Resource Load Delay (resurssien löytämisviive)
Tämä on aika TTFB:n ja LCP-resurssin latauksen alkamisen välillä. Huomaa: kyse ei ole latausajasta vaan löytämisviiveestä — kuinka kauan selaimelta kestää edes aloittaa resurssin hakeminen.
Ja tässä piilee usein suurin ongelma. Mediaanisivustolla, jolla on huono LCP, selain käyttää lähes nelinkertaisen ajan odottaessaan kuvan latauksen alkamista verrattuna itse lataukseen — 1,3 sekuntia TTFB:n ja kuvapyynnön välillä. Se on yli puolet 2,5 sekunnin budjetista yhdessä osavaiheessa.
Googlen suositus: Resource Load Delay -vaiheen tulisi viedä alle 10 % kokonais-LCP:stä.
3. Resource Load Duration (resurssien latausaika)
Tämä on varsinainen latausaika — kuinka kauan kuvan, fontin tai videon lataaminen kestää. Tämä vaihe riippuu pääosin tiedostokoosta ja verkko-olosuhteista, joten optimointi tarkoittaa ennen kaikkea tiedostokoon pienentämistä.
Googlen suositus: Noin 40 % LCP-budjetista.
4. Element Render Delay (elementin renderöintiviive)
Aika siitä, kun LCP-resurssi on ladattu, siihen kun elementti on piirretty ruudulle. Tämä ei ole verkkoongelma vaan pääsäie-ongelma. Korkea renderöintiviive tarkoittaa käytännössä sitä, että selaimella on kuva valmiina, mutta pääsäie on liian kiireinen JavaScriptin suorittamisessa tai CSS:n jäsentämisessä ehtiäkseen piirtää sen.
Googlen suositus: Noin 10 % LCP-budjetista.
fetchpriority="high" — tehokkain yksittäinen optimointi
Jos luet tästä oppaasta vain yhden asian, anna sen olla tämä.
Vuonna 2026 fetchpriority="high" on yksittäinen tehokkain attribuutti, jonka voit lisätä hero-kuvaasi. Oletuksena selain antaa näkyvissä oleville kuville alhaisen prioriteetin, joka päivitetään korkeaksi vasta asettelulaskennan jälkeen. Tämä vaatii CSS:n lataamista ja jäsentämistä ensin — ja se luo viiveen, joka on täysin tarpeeton.
fetchpriority="high" ohittaa tämän prosessin kokonaan ja asettaa kuvan korkeaan prioriteettiin heti, kun selain löytää sen HTML:stä.
Käytännön esimerkki: Google Flights -tiimi lisäsi fetchpriority="high" hero-kuvaansa ja näki LCP:n paranevan 2,6 sekunnista 1,9 sekuntiin. Siis 700 ms parannus yhdellä HTML-attribuuttimuutoksella. Ei huono.
<!-- Ennen: selain päättelee prioriteetin itse -->
<img src="hero.jpg" alt="Hero-kuva" width="1200" height="600">
<!-- Jälkeen: korkea prioriteetti heti löydettäessä -->
<img src="hero.jpg" alt="Hero-kuva" width="1200" height="600"
fetchpriority="high">Tärkeä varoitus: Älä käytä fetchpriority="high" useammassa kuin 1–2 resurssissa sivulla. Jos kaikki on "korkea prioriteetti", mikään ei ole.
Älä koskaan laiskaa lataa hero-kuvaasi
Tämä on yllättävän yleinen virhe. Vuonna 2026 loading="lazy" hero-kuvassa on yleisin yksittäinen LCP-virhe, jonka näen sivustojen auditoinneissa.
Logiikka on yksinkertainen: laiska lataus käskee selaimen tahallaan viivästyttää kuvan latausta, kunnes se tulee näkyviin vierittämällä. Mutta hero-kuva on jo näkyvissä heti sivun avautuessa — laiska lataus siis luo täysin turhan viiveen.
Numerot puhuvat puolestaan. CoreDash-datan mukaan laiskasti ladattujen LCP-kuvien 75. prosenttipisteen LCP oli 720 ms ja 4,3 % kokemuksista luokiteltiin huonoiksi. Esiladatuilla kuvilla vastaavat luvut olivat 364 ms ja 0 % huonoja. Ero on merkittävä.
<!-- VÄÄRIN: hero-kuvan laiska lataus -->
<img src="hero.jpg" alt="Hero" loading="lazy">
<!-- OIKEIN: hero-kuva korkealla prioriteetilla -->
<img src="hero.jpg" alt="Hero" fetchpriority="high"
width="1200" height="600">
<!-- Laiska lataus VAIN näkymän alapuolisille kuville -->
<img src="kuva-alempana.jpg" alt="Sisältökuva"
loading="lazy" width="800" height="400">Preload ja fetchpriority yhdessä
Näitä kahta sekoitetaan usein toisiinsa, mutta ne palvelevat eri tarkoituksia:
- Preload vaikuttaa siihen, milloin resurssi löydetään ja lisätään jonoon
- fetchpriority vaikuttaa siihen, mikä prioriteetti resurssilla on jonossa
Paras strategia LCP-kuvalle on käyttää molempia yhdessä — preload ratkaisee löytämisongelman, fetchpriority ratkaisee prioriteettiongelman:
<head>
<!-- Esilataa hero-kuva korkealla prioriteetilla -->
<link rel="preload" as="image" href="hero.avif"
fetchpriority="high"
type="image/avif">
</head>
<body>
<img src="hero.avif" alt="Hero-kuva"
fetchpriority="high"
width="1200" height="600">
</body>CSS-taustakuvien erikoistapaus
CSS-taustakuvat ovat näkymättömiä selaimen esiskannausohjelmalle (preload scanner). Tämä tarkoittaa, että ne löydetään vasta DOM-jäsentäjän kautta — paljon hitaammin kuin HTML:ssä olevat kuvat.
Jos käytät CSS-taustakuvaa LCP-elementtinä (ja moni sivusto käyttää), sinun on pakko lisätä preload-tunniste manuaalisesti <head>-osioon. Mutta rehellisesti sanottuna, parempi ratkaisu on vaihtaa img-elementtiin object-fit-tyylillä:
<!-- Pakollinen preload CSS-taustakuville -->
<link rel="preload" as="image" href="taustakuva.jpg"
fetchpriority="high">
<!-- Parempi ratkaisu: käytä img-elementtiä object-fit:llä -->
<style>
.hero-container {
position: relative;
width: 100%;
height: 60vh;
overflow: hidden;
}
.hero-container img {
width: 100%;
height: 100%;
object-fit: cover;
}
</style>
<div class="hero-container">
<img src="hero.jpg" alt="Hero-kuva"
fetchpriority="high"
width="1920" height="1080">
</div>Modernit kuvaformaatit ja responsiiviset kuvat
Resource Load Duration -vaiheen optimointi tarkoittaa käytännössä yhtä asiaa: tiedostokoon pienentämistä. AVIF ja WebP ovat tässä avainasemassa:
- AVIF: Jopa 50 % pienempi kuin JPEG, erinomainen kuvanlaatu ja HDR-tuki. Selaintuki noin 94 %.
- WebP: 25–35 % pienempi kuin JPEG, erittäin laaja selaintuki (~97 %).
Käytä <picture>-elementtiä, niin selain valitsee parhaan tuetun formaatin automaattisesti:
<picture>
<!-- AVIF ensisijaisesti (pienin koko) -->
<source srcset="hero-400.avif 400w,
hero-800.avif 800w,
hero-1200.avif 1200w,
hero-1920.avif 1920w"
sizes="100vw"
type="image/avif">
<!-- WebP varavaihtoehtona -->
<source srcset="hero-400.webp 400w,
hero-800.webp 800w,
hero-1200.webp 1200w,
hero-1920.webp 1920w"
sizes="100vw"
type="image/webp">
<!-- JPEG viimeisenä turvaverkkona -->
<img src="hero-1200.jpg"
srcset="hero-400.jpg 400w,
hero-800.jpg 800w,
hero-1200.jpg 1200w,
hero-1920.jpg 1920w"
sizes="100vw"
alt="Hero-kuva"
width="1920" height="1080"
fetchpriority="high">
</picture>Pieni mutta tärkeä yksityiskohta: fetchpriority-attribuutti lisätään aina <img>-elementtiin <picture>-tagin sisällä — ei <source>-elementteihin.
Kriittisen CSS:n inlinettäminen
Element Render Delay -vaiheen optimoinnissa keskeisin tekijä on renderöinnin estävän CSS:n minimointi. Idea on yksinkertainen: inlinettämällä kriittiset tyylit suoraan <head>-osioon selain voi aloittaa renderöinnin ilman ulkoisten tyylitiedostojen odottamista.
<head>
<!-- Kriittinen CSS suoraan head-osioon -->
<style>
.hero-container {
position: relative;
width: 100%;
height: 60vh;
overflow: hidden;
}
.hero-container img {
width: 100%;
height: 100%;
object-fit: cover;
}
h1 {
font-size: clamp(1.5rem, 4vw, 3rem);
margin: 1rem 0;
}
</style>
<!-- Ei-kriittinen CSS ladataan asynkronisesti -->
<link rel="preload" href="styles.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript>
<link rel="stylesheet" href="styles.css">
</noscript>
</head>Pelkästään tarpeettoman CSS:n poistaminen voi parantaa LCP:tä lähes 20 %. Se on iso luku pienellä vaivalla.
JavaScriptin vaikutuksen minimointi
Raskas JavaScript-suoritus pääsäikeessä estää renderöinnin ja kasvattaa Element Render Delay -vaihetta. Tämä on erityisen yleinen ongelma sivustoilla, jotka lataavat paljon kolmannen osapuolen skriptejä (analytiikka, mainosverkot, chat-widgetit ja niin edelleen).
Keskeiset strategiat:
- Käytä
defer- taiasync-attribuutteja estääksesi HTML-jäsentämisen pysähtymisen - Viivästä ei-kriittisiä kolmannen osapuolen skriptejä
- Pilko pitkät tehtävät pienemmiksi
scheduler.yield()-funktiolla
<!-- Kriittinen skripti: defer lataa rinnakkain, suorittaa jäsentämisen jälkeen -->
<script src="app.js" defer></script>
<!-- Ei-kriittinen analytiikka: ladataan vasta käyttäjän interaktion jälkeen -->
<script>
function loadAnalytics() {
const s = document.createElement('script');
s.src = 'analytics.js';
document.head.appendChild(s);
}
// Ladataan ensimmäisen interaktion jälkeen
['click', 'scroll', 'keydown'].forEach(event => {
window.addEventListener(event, loadAnalytics, { once: true });
});
</script>Speculation Rules API — lähes nolla LCP
Tämä on mielestäni vuoden 2026 mielenkiintoisin kehitysaskel LCP:n kannalta.
Speculation Rules API mahdollistaa sivujen esilataamisen tai täydellisen esirenderöinnin taustalla ennen kuin käyttäjä edes klikkaa linkkiä. Kun käyttäjä sitten navigoi esirenderöidylle sivulle, LCP on käytännössä lähes nolla, koska sivu on jo täysin renderöity taustalla.
Weston Ruterin testeissä havaittiin 98,2 % vähennys LCP:ssä esilatauksen ja esirenderöinnin yhdistelmällä. Lue tuo luku uudestaan — 98,2 prosenttia.
<!-- Speculation Rules: esirenderöi todennäköiset seuraavat sivut -->
<script type="speculationrules">
{
"prerender": [
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/logout" } },
{ "not": { "href_matches": "/api/*" } }
]
},
"eagerness": "moderate"
}
]
}
</script>Selaintuki: Chromium-pohjaiset selaimet (Chrome, Edge) tukevat Speculation Rules -rajapintaa, mikä kattaa noin 79 % selaimista. WordPress 6.8+ sisältää tuen oletuksena. Muut selaimet yksinkertaisesti sivuuttavat säännöt, joten niiden lisääminen on täysin turvallista.
Huomioitavaa: Esirenderöinti kuluttaa muistia ja kaistanleveyttä. Jos käyttäjä ei navigoi esirenderöidylle sivulle, resurssit menevät hukkaan. Selain myös jättää spekuloinnin väliin, kun käyttäjän laitteen akku on vähissä — mikä on fiksua.
TTFB:n optimointi — LCP:n perusta
Koska TTFB muodostaa noin 40 % LCP-budjetista, sen optimointi on perustavanlaatuista. Ilman nopeaa TTFB:tä mikään muu optimointi ei auta tarpeeksi.
Tärkeimmät keinot:
- Palvelintason välimuisti: LSCache tai Varnish voi tuottaa alle 20 ms TTFB:n eliminoimalla PHP-suorituksen ja tietokantakyselyt kokonaan
- CDN: Valon nopeus asettaa vähimmäisviiveen — CDN tuo sisällön fyysisesti lähemmäs käyttäjää
- HTTP/2 tai HTTP/3: Multipleksointi ja nolla-RTT-yhteydet vähentävät viivettä merkittävästi
- 103 Early Hints: Palvelin voi lähettää preload-vihjeitä jo ennen kuin varsinainen vastaus on edes valmis
# Nginx: 103 Early Hints hero-kuvan esilataamista varten
location / {
add_header Link "</hero.avif>; rel=preload; as=image; fetchpriority=high";
# Early Hints lähetetään ennen varsinaista vastausta
proxy_pass http://backend;
}LCP-optimoinnin tarkistuslista
Tässä on kaikki oleelliset kohdat koottuna yhdeksi tarkistuslistaksi. Käy tämä läpi jokaisella sivulla, jonka LCP:tä haluat parantaa:
- Tunnista LCP-elementti: Avaa Chrome DevTools → Performance → katso LCP-merkintä
- Lisää
fetchpriority="high"hero-kuvaan tai LCP-elementtiin - Poista
loading="lazy"kaikista näkymän yläosan kuvista - Käytä
<link rel="preload">jos LCP-kuva on CSS-taustakuva tai dynaamisesti ladattu - Käytä AVIF/WebP-formaatteja
<picture>-elementin kanssa - Inlinettä kriittinen CSS ja lataa loput asynkronisesti
- Viivästä ei-kriittinen JavaScript
defer- taiasync-attribuuteilla - Aseta
widthjaheightkaikille kuville (estää myös CLS-ongelmia) - Ota CDN käyttöön TTFB:n pienentämiseksi
- Harkitse Speculation Rules API:ta navigaatioiden nopeuttamiseksi
LCP:n mittaaminen ja seuranta
Optimointi ilman mittaamista on arvailua — ja olen nähnyt liian monta projektia, joissa "optimoitiin" asioita, jotka eivät olleet oikeasti ongelmia. Aloita aina datasta.
Keskeiset työkalut:
- PageSpeed Insights: Reaaliaikainen CrUX-data ja Lighthouse-analyysi — paras lähtökohta
- Chrome DevTools Performance -paneeli: LCP:n osakomponenttien tarkka erittely (tämä on kultaa diagnosoinnissa)
- CrUX Vis: Uusi korvike vanhentuneelle CrUX Dashboardille, viikoittaiset päivitykset, sekä origin- että URL-tason data
- web-vitals-kirjasto: Real User Monitoring (RUM) tuotantoympäristössä
// web-vitals-kirjasto: LCP:n mittaaminen tuotannossa
import { onLCP } from 'web-vitals';
onLCP((metric) => {
console.log('LCP:', metric.value, 'ms');
console.log('LCP-elementti:', metric.entries[0]?.element);
// Lähetä analytiikkapalveluun
fetch('/api/vitals', {
method: 'POST',
body: JSON.stringify({
name: metric.name,
value: metric.value,
rating: metric.rating, // 'good' | 'needs-improvement' | 'poor'
navigationType: metric.navigationType,
}),
keepalive: true,
});
});Usein kysytyt kysymykset
Mikä on hyvä LCP-arvo vuonna 2026?
Googlen virallinen suositus on alle 2,5 sekuntia mitattuna 75. prosenttipisteessä CrUX-kenttädatasta. Kilpailukykyiset sivustot tavoittelevat kuitenkin tyypillisesti 1,0–1,5 sekuntia. Dynaamiselle sisällölle alle 2,0 sekuntia on erinomainen tulos.
Vaikuttaako LCP suoraan Google-hakutulosten sijoituksiin?
Kyllä. LCP on osa Core Web Vitals -mittareita, jotka ovat virallinen Google-sijoitustekijä. Se toimii kuitenkin yhtenä tekijänä satojen joukossa — erottelevana tekijänä erityisesti silloin, kun sisällön laatu ja relevanssi ovat muuten tasavertaisia. Hyvän LCP:n omaavilla sivustoilla havaitaan 24 % alhaisempi välitön poistumisprosentti, mikä puolestaan vaikuttaa sijoituksiin epäsuorasti.
Miksi hero-kuvan laiska lataus heikentää LCP:tä?
loading="lazy" käskee selaimen viivästyttää kuvan lataamista, kunnes se tulee näkyviin vierittämällä. Hero-kuva on kuitenkin jo näkyvissä heti sivun avautuessa, joten laiska lataus luo täysin tarpeettoman viiveen. Mobiiliverkoissa tämä viive voi olla 3–4 sekuntia. Käytä sen sijaan fetchpriority="high".
Miten fetchpriority ja preload eroavat toisistaan?
preload vaikuttaa siihen, milloin selain löytää resurssin. fetchpriority vaikuttaa siihen, mikä prioriteetti resurssilla on latausjonossa. Ne ratkaisevat eri ongelmia: preload korjaa myöhäisen löytämisen, fetchpriority korjaa alhaisen prioriteetin. Paras tulos saadaan käyttämällä molempia yhdessä LCP-kuvalle.
Toimiiko Speculation Rules API kaikissa selaimissa?
Ei vielä. Vuoden 2026 alussa Speculation Rules API toimii vain Chromium-pohjaisissa selaimissa (Chrome, Edge), jotka kattavat noin 79 % selaimista. Firefox ja Safari eivät vielä tue sitä. Hyvä uutinen on, että muut selaimet yksinkertaisesti sivuuttavat speculation rules -säännöt, joten niiden käyttö on turvallista ilman haittavaikutuksia.