Avaa minkä tahansa sivuston kehittäjätyökalut ja katso verkkovälilehteä. Sivun raskain yksittäinen tiedosto on yhdeksässä tapauksessa kymmenestä jokin kuva. Hero-kuva, tuotekuva, sisältöön upotettu kuvitus — nämä tiedostot ovat lähes aina suurempia kuin HTML, CSS ja JavaScript yhteensä.
Tämä tekee kuvista suurimman yksittäisen vipuvarsi, joka sinulla on. Ne vaikuttavat sekä SEO:hon (alt-tekstit, tiedostonimet, kuvahaku, structured data) että Core Web Vitals -mittareihin (Largest Contentful Paint, Cumulative Layout Shift, sivun kokonaispaino). Silti kuvat ovat yksi laiminlyödyimmistä teknisen optimoinnin alueista. Suunnittelijat lataavat korkearesoluutioisia PNG-tiedostoja Figmasta, kehittäjät liittävät ne ilman width- tai height-attribuutteja, ja toimittajat liimaavat CMS:ään tiedostonimiä kuten IMG_4738.jpg.
Haluatko löytää SEO-ongelmat miltä tahansa sivustolta?
Kokeile WebSEO Auditoria ilmaiseksi — tee ensimmäinen auditointi sekunneissa.
Kokeile ilmaiseksiTämä opas yhdistää kuvien SEO:n ja suorituskyvyn yhdeksi käytännön työnkuluksi. Lopussa tiedät tarkalleen mitä sivustollasi kannattaa korjata, missä järjestyksessä, ja miten varmistat tuloksen.
Miksi kuvat ovat suurin piilevä SEO- ja suorituskykytyökalu
Kuvat koskettavat lähes kaikkia Googlen mittareita:
- Alt-tekstien indeksointi: Google lukee alt-attribuutit ymmärtääkseen mitä sivulla on. Puuttuvat tai ylimalkaiset alt-tekstit tarkoittavat menetettyjä sijoitussignaaleja.
- Google-kuvahaku: Yllättävän suuri osa orgaanisesta liikenteestä tulee yhä kuvahausta. Kuvaileva tiedostonimi ja alt-teksti ovat pääsylippu.
- LCP (Largest Contentful Paint): Hero-kuva on LCP-elementti useimmilla sisältösivuilla. Hidas hero tarkoittaa huonoa LCP-arvoa, joka vaikuttaa suoraan sijoituksiin.
- CLS (Cumulative Layout Shift): Kuvat ilman määriteltyjä mittoja aiheuttavat asettelun hyppimistä, joka heikentää CLS:ää ja turhauttaa käyttäjiä.
- Sivun kokonaispaino: Optimoimattomat kuvat paisuttavat sivua megatavuilla, joka hidastaa TTFB:tä, lisää mobiilidatan kustannuksia ja huonontaa kokemusta kaikilla, joilla ei ole kuitua.
Kun korjaat kuvat, korjaat viisi ongelmaa kerralla. Jos jätät ne huomiotta, auditointiraporttisi näyttävät samaa oranssia ja punaista riippumatta siitä mitä muualla teet.
Kuvien SEO:n perusteet
Kuvien SEO:n perusasiat eivät ole muuttuneet dramaattisesti vuosikymmeneen, mutta useimmat sivustot tekevät ne silti väärin. Tässä mitä merkitsee.
Kuvailevat tiedostonimet
Tiedostonimet kuten IMG_0042.jpg, DSC9382.png tai Näyttökuva 2026-05-23 klo 14.32.png eivät kerro Googlelle mitään. Nimeä tiedostot uudelleen ennen latausta. Kuvaileva tiedostonimi käyttää väliviivoja, pieniä kirjaimia ja lyhyitä avainsanoja:
- Huono:
IMG_0042.jpg - Parempi:
punaiset-juoksukengat-sivulta.jpg - Paras:
punaiset-juoksukengat-sivulta-nike-air-zoom.jpg
Älä liioittele kahdenkymmenen sanan avainsanapakatuilla nimillä. Tähtää kolmesta seitsemään kuvailevaan sanaan.
Alt-teksti, joka palvelee kahta tarkoitusta
Alt-tekstillä on kaksi tehtävää: se kuvailee kuvan ruudunlukijoille ja kertoo hakukoneille mitä kuva esittää. Hyvä alt-teksti hoitaa molemmat luonnollisesti.
Kirjoita alt-teksti kuin kuvailisit kuvan jollekulle puhelimitse — pidä samalla mielessä sivun aihe. Jos kuva on koristeellinen — jakaja, ikoni vieressä jo selittävän tekstin — käytä tyhjää alt-attribuuttia (alt=""), ei avainsanoilla täytettyä lausetta.
Yleisin alt-tekstivirhe on jättää se tyhjäksi merkityksellisistä kuvista. Toiseksi yleisin on täyttää se avainsanoilla. Molemmat viestivät hakukoneille huolimattomuutta, ja molemmat epäonnistuvat ruudunlukijakäyttäjien kanssa.
Kuvatekstit, otsikot ja ympäröivä teksti
Google käyttää kuvan ympärillä olevaa tekstiä lisäkontekstina. Tuotekuva sijoitettuna kappaleeseen, joka kuvailee tuotetta, ymmärretään paljon paremmin kuin sama kuva tyhjälle sivulle pudotettuna. Käytä kuvatekstejä siellä missä ne tuovat lisäarvoa. Vältä title-attribuuttia — se tuo vähän SEO-hyötyä ja lisää epäkätevän tooltipin työpöydällä.
Structured data: ImageObject
Tärkeisiin kuviin — logoosi, ensisijaisiin tuotekuviin, reseptikuviin, artikkelin hero-kuviin — lisää ImageObject-structured data. Sisällytä vähintään contentUrl, license ja creator. Tämä avaa rikkaammat kuvahakutulokset ja auttaa AI-järjestelmiä käyttämään kuviasi oikein.
LCP-yhteys: hero-kuva = LCP-elementti
Largest Contentful Paint mittaa kuinka nopeasti suurin näkyvä elementti latautuu loppuun. Valtaosalla sisältösivuista tämä elementti on hero-kuva — artikkelin yläpuolinen valokuva, tuotekuva PDP:llä tai laskeutumissivun banneri.
Tämä tarkoittaa, että hero-kuva ansaitsee perustavanlaatuisesti erilaisen käsittelyn kuin muut sivun kuvat.
Miten LCP lasketaan
Selain mittaa ajan navigoinnin alusta siihen, kun suurin näkyvä elementti on renderöity. Kuvan tapauksessa "renderöity" tarkoittaa, että tavut on ladattu ja kuva piirretty. Kello käy heti URL:n syöttämisestä.
Googlen "hyvän" LCP-arvon raja on 2,5 sekuntia. 800 kilotavun hero-kuva, jota ei ole priorisoitu, ylittää tämän rajan säännöllisesti keskitason mobiililaitteilla 4G-yhteydellä.
Hero-kuvan erikoiskohtelu
Kolme modernia tekniikkaa muuttavat LCP-suorituskyvyn:
fetchpriority="high"
fetchpriority="high"-attribuutin lisääminen hero-kuvaelementtiin kertoo selaimelle, että se on ladattava ennen muita resursseja. Tämä yksi attribuutti voi pudottaa LCP:tä 500-1500 ms hitailla yhteyksillä.
Preload-vihjeet
Jos hero valitaan srcset-luettelosta, selain ei voi aloittaa latausta ennen kuin asettelu on laskettu. <link rel="preload" as="image" imagesrcset="..." imagesizes="..."> sivun headissa ratkaisee tämän käskemällä selainta lataamaan välittömästi.
Eager loading (EI lazy)
Älä koskaan lazy-lataa hero-kuvaa. loading="lazy" yläosan kuvalla on yksi yleisimmistä huonon LCP:n syistä. Eager-lataus on oletus — varmista, ettei mikään globaali skripti tai CMS-malli yliaja sitä herollesi.
Modernit kuvaformaatit: AVIF, WebP, JPEG XL
JPEG-muodossa toimitetut valokuvat ja PNG-muodossa toimitetut grafiikat jättävät 30-70 % tiedostokokoa pöydälle. Modernit formaatit — AVIF, WebP ja JPEG XL — tuottavat dramaattisesti pienempiä tiedostoja samalla visuaalisella laadulla.
| Formaatti | Tyypillinen säästö vs JPEG | Selaintuki (2026) | Parhaiten sopii |
|---|---|---|---|
| AVIF | 50-70 % | Chrome, Edge, Firefox, Safari 16.4+ | Valokuvat, hero-kuvat, kaikki suuret |
| WebP | 25-35 % | Universaali (98 %+) | Luotettava fallback ennen AVIF:ia |
| JPEG XL | 40-60 % | Rajallinen (vain Safari oletuksena) | Ei vielä käytännöllinen tuotantoon |
| JPEG | perusta | Universaali | Viimeinen fallback vanhoille selaimille |
Fallback-strategia picture-elementillä
Puhtain toimitusstrategia käyttää <picture>-elementtiä useilla lähteillä. Selain valitsee ensimmäisen, jonka se osaa purkaa:
<picture>
<source type="image/avif" srcset="hero.avif">
<source type="image/webp" srcset="hero.webp">
<img src="hero.jpg" alt="..." width="1200" height="675">
</picture>
AVIF ensin, WebP fallbackina, JPEG viimeisenä keinona. Jokainen kävijä saa pienimmän mahdollisen formaatin selaimelleen ilman JavaScriptia ja ilman yhteensopivuusriskiä.
Responsiiviset kuvat oikein
2400 pikseliä leveä hero-kuva on liioittelua 360 pikselin puhelimen näytölle. Responsiiviset kuvat lähettävät oikean koon jokaiselle laitteelle.
srcset ja sizes
srcset-attribuutti listaa useita resoluutioita. sizes-attribuutti kertoo selaimelle, kuinka leveänä kuva näytetään eri katselualuekoolla, jotta se voi valita oikean resoluution ennen lataamista.
<img
src="hero-800.jpg"
srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
sizes="(max-width: 600px) 100vw, 50vw"
alt="..."
width="1600"
height="900">
Miksi selaimen oletuslogiikka epäonnistuu ilman sizes-attribuuttia
Ilman sizes-attribuuttia selain olettaa kuvan täyttävän koko katselualueen. Sivupalkin kuvalle, joka on todellisuudessa 300 pikseliä leveä 1440 pikselin näytöllä, selain voi ladata 1600 pikselin version, kun 400 pikselin versio olisi ollut oikea. Lopputuloksena on tuhlattua kaistanleveyttä ja hitaampi LCP.
Lisää sizes aina kun käytät srcset:iä. Laske todellinen näyttöleveys jokaisella breakpointilla ja kirjoita se CSS-tyyppisenä media-kyselynä.
Lazy loading: milloin käyttää ja milloin EI
Natiivi lazy loading — loading="lazy" — viivyttää kuvan latausta kunnes se on lähellä katselualuetta. Tämä on loistava pitkille sivuille, joissa on paljon yläosan alapuolisia kuvia. Se on katastrofi heron kohdalla.
Käytä lazy loadingia kuville:
- Yli yhden ruudun verran yläosan alapuolella oleville kuville
- Pitkille artikkeleille, joissa on paljon kuvitusta
- Tuoteruudukoille alkunäkyvän alueen jälkeen
- Alatunnisteiden logoille ja koristeellisille kuville
Älä koskaan lazy-lataa:
- Hero-kuvia tai bannereita yläosassa
- Logoa headerissa (se on aina näkyvissä)
- PDP:n ensimmäistä tuotekuvaa
- Mitään kuvaa, joka on tai voisi olla LCP-elementti
IntersectionObserver vs natiivi
Natiivi loading="lazy" on tuettu kaikkialla ja sen pitäisi olla oletus. Käytä JavaScript-pohjaista IntersectionObserveria vain jos tarvitset hienojakoista kontrollia kynnyksestä tai haluat käynnistää animaatioita latauksen yhteydessä.
CLS:n estäminen kuvilta
Cumulative Layout Shift mittaa odottamattomia asetteluhyppyjä. Kuvat ilman määriteltyjä mittoja ovat yleisin syy. Kun kuva latautuu, selain äkkiä tietää sen koon ja työntää kaiken alapuolella alaspäin — jokainen linkki, jota käyttäjä oli juuri klikkaamassa, hyppää ulottumattomiin.
Aseta aina width ja height
Jokaisella <img>-elementillä tulisi olla width- ja height-attribuutit, jotka vastaavat tiedoston sisäistä kuvasuhdetta. Selain käyttää näitä tilan varaamiseen ennen latausta.
Käytä CSS:n aspect-ratiota
Responsiivisille asetteluille, joissa kuva venyy täyttämään kontainerin, yhdistä width- ja height-attribuutit CSS:n aspect-ratio-arvoon. Elementti varaa tilan suhteellisesti ja kuva täyttää sen saapuessaan.
Matalalaatuiset placeholderit
Vielä sulavamman kokemuksen tuottamiseksi voit renderöidä pienen sumennetun placeholderin (LQIP tai BlurHash), joka korvataan kun täysi kuva latautuu. Frameworkit kuten Next.js ja Astro sisältävät tämän valmiina.
CDN- ja kuvanoptimointipalvelut
Käsin kuvien optimointi jokaiselle sivulle on kestämätöntä. Moderni stack delegoi tämän palvelulle tai build-putkelle.
Kuva-CDN:t
- Cloudinary: Kypsä, ominaisuusrikas, kallis skaalassa. Erinomaiset muunnos-URL:t.
- ImageKit: Edullisempi, samanlaiset ominaisuudet, helpompi käyttöönotto.
- Cloudflare Images: Kiinteä hinta, syvä integraatio Cloudflare CDN:ään, yksinkertaisempi API.
- imgix: Pitkään vakiintunut, suosittu mediasivustojen keskuudessa.
Build-aikaiset putket
Staattisille sivustoille voit generoida optimoidut kuvat build-aikaan käyttäen sharp:ia (Node) tai ImageMagick:ia. Astro, Next.js ja Nuxt tarjoavat kuvakomponentteja, jotka käsittelevät AVIF:n, WebP:n ja responsiiviset variantit automaattisesti.
Kumman valitsisit?
Jos kuvakirjastosi on suuri ja sitä päivitetään usein, käytä CDN:ää. Jos sinulla on staattinen joukko kuvia ja haluat maksimaalisen suorituskyvyn ilman pyyntökohtaisia kustannuksia, käytä build-putkea. Monet sivustot käyttävät molempia — build-aikaa hero- ja tuotekuville, CDN:ää käyttäjien lataamalle sisällölle.
10-vaiheinen kuva-auditointichecklist
- Listaa jokainen kuva etusivultasi ja eniten liikennettä saavilta sivuilta.
- Tarkista tiedostonimet — nimeä uudelleen kaikki, jotka näyttävät
IMG_- taiNäyttökuva-alkuisilta. - Auditoi alt-tekstit — täytä puuttuvat, yksinkertaista avainsanoilla pakatut.
- Tunnista LCP-elementtisi. Aja PageSpeed Insights ja varmista, että se on hero-kuvasi.
- Varmista, että herolla on
fetchpriority="high"eikä sitä lazy-ladata. - Vahvista, että kaikilla kuvilla on
width- jaheight-attribuutit. - Tarkista tarjoiltavat formaatit — toimitatko AVIF/WebP:tä tukeville selaimille?
- Tutki
srcset- jasizes-attribuutteja. Valitaanko oikea resoluutio? - Testaa oikealla mobiililaitteella 4G:llä, ei vain nopealla pöytäkoneella.
- Lisää
ImageObject-structured data tärkeimmille kuvillesi.
Mitä korjata ensin
Jos voit tehdä vain kolme asiaa tällä viikolla, tee nämä:
- Korjaa hero. Lisää
fetchpriority="high", poista lazy loading ja muunna se AVIF-muotoon WebP-fallbackilla. Tämä yksi muutos siirtää LCP:n usein huonosta hyväksi. - Lisää width ja height jokaiseen kuvaan. CLS putoaa usein lähelle nollaa yön yli.
- Auditoi alt-tekstit kymmenellä tärkeimmällä sivullasi. Kirjoita kuvaileva, hyödyllinen alt jokaiselle merkitykselliselle kuvalle.
Muu — CDN-migraatio, build-putket, JPEG XL:n käyttöönotto — voi odottaa. Nuo kolme toimenpidettä tuottavat valtaosan hyödystä.
Haluatko nähdä miten kuvasi pärjäävät? Aja ilmainen auditointi osoitteessa webseoauditor.com/try ja saat priorisoidun listan kuvaongelmista SEO:n, saavutettavuuden ja Core Web Vitalsin osalta — tarkat tiedostot ja sivut, jotka kaipaavat huomiota.