HTTP/2 ja HTTP/3 ovat moderneja verkkoprotokollia, jotka nopeuttavat kotisivujen latautumista merkittävästi verrattuna vanhaan HTTP/1.1-protokollaan. Jos sivustosi latautuu hitaasti eikä käyttäjä jaksa odottaa, ongelma voi olla juuri siinä, miten selain ja palvelin keskustelevat keskenään. Tässä artikkelissa käymme läpi, mitä nämä protokollat käytännössä tarkoittavat ja miten ne hyödyttävät erityisesti suomalaisia pienyrityksiä.
Miksi HTTP/1.1 ei enää riitä?
Vanha HTTP/1.1 on toiminut verkossa vuodesta 1997. Se avaa jokaiselle tiedostopyynnölle oman yhteyden tai jonottaa pyyntöjä peräkkäin samassa yhteydessä. Kun moderni kotisivu lataa kymmeniä kuvia, CSS-tiedostoja, fontteja ja JavaScript-kirjastoja, syntyy pullonkaula — selain ei yksinkertaisesti saa kaikkea ladattua tarpeeksi nopeasti.
Käytännössä tämä näkyy niin, että sivuston etusivu saattaa ladata kolme sekuntia, vaikka palvelin olisi nopea. Olen nähnyt tilanteita, joissa pelkkä protokollapäivitys pudotti latausajan lähes puoleen ilman mitään muuta muutosta.
HTTP/2 — multipleksaus ja tehokkuus
HTTP/2 ratkaisee suurimman ongelman multipleksauksella: yksi yhteys palvelimeen riittää kaikkien tiedostojen samanaikaiseen lataamiseen. Selain ei enää jonota pyyntöjä peräkkäin, vaan lähettää ja vastaanottaa niitä rinnakkain.
Muita HTTP/2:n etuja ovat:
Header-kompressio (HPACK) — jokaisessa pyynnössä toistuvat otsikkotiedot pakataan, mikä vähentää turhaa dataliikennettä erityisesti sivustoilla, joilla on paljon pieniä resursseja.
Palvelimen push — palvelin voi lähettää selaimelle resursseja ennakoivasti, ennen kuin selain ehtii niitä edes pyytää. Käytännössä tämä toimii vaihtelevasti, ja monet ovat luopuneet sen käytöstä kokonaan, mutta mahdollisuus on olemassa.
Priorisointi — selain voi kertoa palvelimelle, mitkä resurssit ovat tärkeimpiä, jolloin esimerkiksi näkyvä sisältö latautuu ensin.
Useimmat modernit webhotellit ja Debian-palvelimet tukevat HTTP/2:ta jo oletuksena, kunhan SSL-sertifikaatti on käytössä. Apachessa riittää usein mod_http2-moduulin aktivointi ja pieni konfiguraatiomuutos.
HTTP/3 — QUIC-protokolla ja seuraava askel
HTTP/3 menee vielä pidemmälle. Se korvaa alla olevan TCP-yhteyden kokonaan QUIC-protokollalla, joka perustuu UDP:hen. Tämä kuulostaa tekniseltä, mutta käytännön hyöty on selkeä:
Nopeampi yhteyden muodostus — QUIC yhdistää TLS-kättelyn ja yhteyden avauksen yhteen vaiheeseen. Ensimmäinen lataus nopeutuu, ja uudelleenyhteys tuttuun palvelimeen voi tapahtua lähes viiveettä (0-RTT).
Ei head-of-line-blocking-ongelmaa — HTTP/2:ssa yhden paketin häviäminen pysäyttää koko TCP-yhteyden. HTTP/3:ssa jokainen tietovirta on itsenäinen, joten yhden kuvan latausongelma ei hidasta muita.
Parempi suorituskyky huonoilla yhteyksillä — mobiiliverkossa tai wifi-verkon reunalla HTTP/3 pärjää selvästi paremmin kuin edeltäjänsä. Tämä on iso juttu, kun iso osa suomalaisten yritysten sivustojen liikenteestä tulee mobiililaitteista.
Yleinen myytti: ”Protokolla ei vaikuta minun sivustooni”
Kuulen usein väitteen, että HTTP/2 tai HTTP/3 hyödyttää vain isoja sivustoja. Tämä on väärinkäsitys. Juuri pienen yrityksen kotisivut — joissa on ehkä WordPress, muutama lisäosa, useita kuvia ja Google Fonts — hyötyvät multipleksauksesta valtavasti. Pienet sivustot lataavat tyypillisesti 30–80 erillistä resurssia, ja jokainen niistä kulkee nopeammin HTTP/2:n tai HTTP/3:n kautta.
Toinen myytti on, että protokollapäivitys vaatii sivuston uudelleenkoodauksen. Ei vaadi. Kyse on palvelimen asetuksista — hosting-palvelun valinnasta ja sen konfiguraatiosta.
Miten otat HTTP/2 ja HTTP/3 käyttöön?
Varmista SSL-sertifikaatti — HTTP/2 edellyttää käytännössä aina HTTPS-yhteyttä. Jos sinulla ei vielä ole SSL-sertifikaattia, se on ensimmäinen askel. Let’s Encrypt tarjoaa ilmaisen vaihtoehdon, joka toimii erinomaisesti. Lue lisää SSL-sertifikaatin merkityksestä.
Tarkista palvelimesi tuki — Apache 2.4.17+ tukee HTTP/2:ta mod_http2-moduulilla. Nginx tukee sitä versiosta 1.9.5 alkaen. HTTP/3-tuki on tuoreempi: Nginx sai sen versiossa 1.25, ja Apache vaatii erillisen moduulin tai käänteisen proxyn kuten Cloudflaren.
CDN nopeuttaa lisää — monet CDN-palvelut kuten Cloudflare tarjoavat HTTP/3-tuen automaattisesti. Jos palvelimesi ei suoraan tue HTTP/3:a, CDN on helpoin tapa ottaa se käyttöön.
Testaa tulos — Google PageSpeed Insights ja GTmetrix näyttävät, mitä protokollaa sivustosi käyttää. Chrome DevToolsin Network-välilehdellä näet jokaisen resurssin protokollan erikseen.
Käytännön vaikutus sivuston nopeuteen
Eräs tyypillinen tilanne: WordPress-sivusto, jossa on noin 40 ladattavaa resurssia, latautui HTTP/1.1:llä 3,8 sekunnissa. Pelkkä HTTP/2-päivitys pudotti ajan 2,1 sekuntiin. Kun päälle lisättiin kuvien optimointi ja välimuisti, päästiin alle sekuntiin.
Google huomioi sivuston nopeuden hakutuloksissa, ja Core Web Vitals -mittarit paranevat lähes aina protokollapäivityksellä. Erityisesti LCP (Largest Contentful Paint) ja FID (First Input Delay) hyötyvät nopeammasta resurssien latauksesta.
UKK
Pitääkö sivuston koodia muuttaa HTTP/2:ta tai HTTP/3:a varten?
Ei tarvitse. Protokollapäivitys tapahtuu palvelintasolla, eikä sivuston HTML, CSS tai JavaScript vaadi muutoksia. Ainoastaan palvelimen asetukset ja mahdollisesti hosting-palvelu pitää päivittää.
Tukevatko kaikki selaimet HTTP/3:a?
Chrome, Firefox, Edge ja Safari tukevat HTTP/3:a nykyisin. Vanhemmat selaimet palaavat automaattisesti HTTP/2:een tai HTTP/1.1:een, joten yhteensopivuusongelmia ei käytännössä ole.
Miten tarkistan, mitä protokollaa sivustoni käyttää?
Helpoin tapa on avata Chrome DevTools (F12), valita Network-välilehti ja tarkistaa Protocol-sarake. Vaihtoehtoisesti voit käyttää online-työkaluja kuten KeyCDN HTTP/2 Test tai Cloudflaren HTTP/3 Check.
Sivuston nopeus on yksi niistä asioista, joissa pienikin tekninen muutos voi tuoda ison parannuksen käyttäjäkokemukseen ja hakukonenäkyvyyteen. HTTP/2 on tänä päivänä minimi — jos palvelimesi tukee jo HTTP/3:a, ota se käyttöön. Käyttäjäsi ja Googlen laatumittarit kiittävät.