Kun näyttävien nettisivujen nopea latautuminen on tänä mobiilikeskeisenä aikakautena prioriteetti, löytää usein optimointitapoja etsiessään moderneja, toimiviksi todettuja tai muuten käyttökelpoisia ratkaisuja, mutta joiden käyttöönottamiselle tyypillinen este on rajoittunut selaintuki tai vaikea/kömpelö sovellettavuus. Vuosikymmeniä jo hallinneiden JPEG- ja PNG-kuvatiedostomuotojen korvaajiksi tarkoitettu WEBP on ollut olemassa jo melko pitkään, mutta alkaa vakiinnuttaa asemansa vasta nyt. Samanlainen kamppailu käytiin itse asiassa videotiedostomuotojenkin kanssa vasta viitisen vuotta takaperin, jonka voittajaksi tuli lopulta MP4.
Epätasalaatuisten mobiiliyhteyksien varassa oleville päätelaitteille WEBP on lähtökohtaisesti tervetullut kuvatiedostoformaatti. Tuki löytyy käytetyimmistä nykyselaimista sekä kuvankäsittely- ja -katseluohjelmista, joskin Edgen hiekkalaatikkomoodille korjausta ei ole vieläkään eikä jostain syystä Safarilla lainkaan.
Lisäksi on muutama muukin asia, joista kuvanlaadusta välittävien kannattaa tietää; tärkeimmät tekijät liittyvätkin itse kuvatiedostomuodon ominaisuuksiin ja sen koodekkiin/työkaluihin. Oletetaan, että koneellasi on paljon kuvatiedostoja, jotka mieluusti haluaisit jatkossa vievän vähemmän tilaa. Googlen omilta sivuilta voit ladata itse muuntimen, jolla voit suorittaa kuvamuunnokset automatisoidusti komentoriviparametrein.
Lyhyesti: häviötön tallennusmuoto kelpaa täysin PNG:n korvaajaksi (vie vähemmän tallennustilaa), kunhan vain muistaa komentorivillä käyttää -exact
-kytkintä, joka säilyttää häviöttömänä myös läpinäkyvyyden, mikäli alkuperäisellä kuvalla sellaista on. Mielestäni kytkimen olemassa olo on täysin tarpeeton ja pitäisi olla oletuksena jo -lossless
:iä käytettäessä; jos haluan tallentaa kuvan häviöttömänä niin TOTTA KAI myös läpinäkyvyyden tulee häviöttömästi vastata alkuperäistä. Toivottavasti cwebp-enkooderin tulevissa versioissa tämän huomioiminen erikseen muuttuu oletusarvoin tarpeettomaksi, kun kuvaformaatin suosio lopulta laajenee JPG:n ja PNG:n tasolle.
Toisena WebP:n ongelmana on sen hitaus suuria kuvia käytettäessä. Varsinkin selaimessa kun vaihtaa välilehteä, suuret hienot taustakuvat lävähtävät vilkkuen esille. Minkä voittaa kaistanleveydessä (tiedostokoossa), sen häviää laskentanopeudessa.
Häviöllisellä puolella WebP:n ongelmakohdaksi sitten löysin alhaisemman väritarkkuuden kuin mihin JPG kykenee. Varsinkin punainen suttaantuu kirkkaita sävyjä vasten herkästi, ellei JPG:ssä käytä 4:4:4 subsamplausta, ja WebP:ssä tätä ei edes tarjota vaan se on aina 4:2:0, joka alentaa chroma-tarkkuuden neljäsosaan ja on toki pakkaustehokkuudessa eduksi. Jos siis tarpeesi/kompromissisi on häviöllinen tallennusmuoto kuvan nopeaksi latautumiseksi – kuten suunnilleen kaikissa verkkojulkaistavissa valokuvissa – mutta värit ovat kriittisiä, valitse JPG-tiedostomuoto. WebP:llä on kuitenkin paikkansa väritarkkuudeltaan vähemmän kriittisille fiilistelykuville. Lisäksi hieman suurempitarkkuuksisemmalla kuvalla väritarkkuushävikkiä voi yrittää kompensoida.
Todellinen happotesti tuleekin vastaan, kun kuvassa on tekstiä ties minkälaisia taustoja vasten (esimerkki alla). WebP-enkooderi tarjoaa valmiiksi profiileja, joista voi poimia vastineen joka parhaiten kuvailee kuvatiedoston sisältöä ja näin pyritään löytämään paras pakkausalgoritmi, joka vaikuttaa kuvan laatuun vähiten. Oheisella esimerkkitestikuvalla (kun laatutaso molemmissa esim. 80%) teksti on WEBP:llä aavistuksen vaikeammin luettavissa kuin JPG:llä (tekstiä häviää osittain taustaan) ja liukuvärit palikoituvat, joskin toki vähempikohinaisen WEBP-version mieluummin tulostaisin seinälle (tai taustakuvaksi) kuin JPG-version. Riippuen siis kuvan kokonaissisällöstä tällaisten lopputulos on arvioitava tapauskohtaisesti. Kannattaakin komentoriviteitse generoida kaikki profiilit/variaatiot lennossa peräjälkeen, ja arvioida kutakin versiota vertailemalla paras tarpeisiisi: onko kuvatiedoston tärkeimpänä kriteerinä (liuku-)värien eheys, tekstin luettavuus/suttaantumattomuus taustaan, tietty yksityiskohta (esim. kasvot, logo tai esine kuvassa), ja nämä sitten suhteuttaa kunkin kuvaversion vaatimaan tilantarpeeseen – varsinkin kun verkkosivuston etusivua suunnittelet tai muuta sellaista tärkeää osaa, joka kohderyhmällesi esiintyy usein ja samalla palvelinkustannusten säästämiseksi ja/tai parhaan latausnopeuden saavuttamiseksi kuvan ei tulisi viedä enempää kapasiteettia kuin on välttämätöntä.
Yhteenvetona: WEBP on kuvaformaattina periaatteessa kypsä, ja myös nykyiset HTML5-selaimet periaatteessa kykenevät valitsemaan automaattisesti sopivimman kuvatiedostoversion (srcset-attribuutilla joko <img> tai <source> -tagissa) samaan tapaan kuin videolle ja audiolle on vuosikaudet jo tehty. Kahden maailman yleisimmän työpöytäkäyttöjärjestelmän mukana tulevien selainten kompurointi tämän nimenomaisen tiedostoformaatin kanssa on kuitenkin todella valitettavaa ja taitaa tällä hetkellä olla merkittävin este formaatin lopulliselle yleistymiselle, mutta jäänee aivan lähivuosina historiaan kun Edge siirtyy käyttämään samaa koneistoa kuin itse kuvaformaatin kehittäneen Googlen Chrome-selain; uusi Edge on tätä kirjoitettaessa jo beta-vaiheessa ja saatavilla myös Mac OS X:lle.
EDIT 2020: Pöh, juuri kun WebP nyt sitten vihdoin tuli Edgelle ja Safarille, uhkaakin se jäädä tilapäiseksi väliinputoajaksi, kun uusi AVIF tekee tuloaan paljon yleishyödyllisempänä kuvaformaattina värit säilyttävän 4:4:4 subsamplauksen, HDR:n ja muutenkin joustavampien väriavaruuksien ansiosta. Toiselle ääripäälle eli indeksoiduille väripaleteille se ei kuitenkaan pärjää, kun puhutaan vain muutamia värejä sisältävistä ikoneista tai logoista – PNG ja SVG säilyvät niiden vahvoina edustajina vielä pitkään, eikä vanhassa GIF:ssäkään ole mitään hävettävää.