Nettimaailman isoin riesa on hitaat sivustot. Mikään ei ole rasittavampaa kun etsiä tietoa tai hoitaa päivittäisiä askareita netissä ja odotella sekuntitolkulla sivun latautumista. Vaikka aika ei olisikaan rahaa, se on ainoa ehtyvä resurssi, joka meillä on.
Mikä sitten sivustoja hidastaa, muu kuin etanavauhdilla kulkeva mobiililaajakaistasi, eli hidas nettiyhteytesi? Nyt saat tietää aiheesta kaiken.
Huono palvelin
Olemme aiemminkin kirjoittaneet palvelimen merkityksestä mm. kirjoituksissa Älä hanki mitä tahansa webhotellia WordPress-sivuillesi ja Palvelimen merkitys WordPress-sivustoille. Sillä on väliä laittaako sivustonsa pyörimään muutama dollari vuodessa maksavaan webhotelliin vai kiinteästä dedikoidusta rautapalvelimesta vipuvoimaa saavalle ammattimaiselle WordPress-optimoidulle palvelimelle. Erot näkyvät suoraan sivuston latausnopeuksissa.
Huono palvelin lataa sivuston käyttämät tiedostot hitaammin ja aiheuttaa pahimmillaan isoakin pullonkaulaa, erityisesti silloin kun sivustolla on ruuhkaa tai se on muutenkin koodattu huonosti. Varmista siis, että WordPress-sivustollasi on hyvä, WordPressille optimoitu palvelin, mielellään ylläpitopalvelulla siten, että se ei ole jaetulla palvelimella tuhansien muiden, ellei jopa miljoonien sivustojen kanssa.
Palvelinten eli kansakielellä ns. “sivutilan” lyhyt oppimäärä: Palvelimia on monenlaisia. Näistä yleisimmät ovat ns. “webhotelleja”, joissa kaista ja tila jaetaan muiden kanssa, jolloin hinta saadaan poljettua asiakkaalle mahdollisimman edulliseksi, mutta myös laatu kärsii. Toiseksi yleisimpiä ovat yksittäiset virtuaalipalvelimet, jotka ovat kohtalaisen edullisia, mutta eivät jaettuja muiden kanssa. Suosiota ovat nostattaneet pilvipalvelimet (Google App Engine, Amazon EC2, jne.), joissa taas sivut majailevat ylöspäin skaalautuvassa pilvessä, miinuksena esimerkiksi huono pääsy tiedostojärjestelmään. Viimeisimpänä, vaan ei vähäisimpänä ovat vuokrapalvelimet, jotka on pilkottu omiin virtuaalipalvelimiin. Tätä tapaa me käytämme. Jos valitset palvelimesi itse, valitse tarkoin, äläkä mene siitä missä hinta on matalin.
Vanha sivusto ja tekninen velka
Kuten talo tai autokin kuluu ja rapistuu käytön myötä, varsinkin silloin kun sitä ei huolla koskaan. Valitettavasti koodikaan ei ole ikuista ja kärsii siitä, että ympärillä kaikki uudistuu ja kehittyy. Vanha koodi muuttuu ajan myötä hitaammaksi ja hitaammaksi ja hidastaa näin ollen myös sivustoa.
Vanha sivusto kannattaa suosiolla uudistaa, jos sen eteen ei ole tehnyt mitään yli kolmeen vuoteen. Jos taas kehitys on ollut jatkuvaa, koko setin uudistaminen ei välttämättä ole järkevää. Sivustosta voi myös uudistaa vain ongelmakohdat tai tilata vaikka pelkästään nopeuden optimoinnin. Nykyään voi tehdä esimerkiksi välimuistituksella paljon. Siitä päästäänkin seuraavaan.
Välimuistituksen puuttuminen
Välimuistilla tarkoitetaan sitä, että sivuston tiedot jäävät jonnekin talteen (välimuistiin) ja ne haetaan nopeammin jemmasta esiin sen sijaan että ladattaisiin aina uudestaan. Kaikki tietävät että uuden materiaalin netin läpi lataaminen on hitaampaa kuin esimerkiksi omalta koneelta tiedoston avaaminen suoraan.
Selain sisältää yksinkertaisen välimuistin. Tiedät sen esimerkiksi siitä, että jos sivustolle tehdään muutos, se ei näy ennen kuin painat sitä Päivitä-nappia vähän rivakammin. Klassikko tässä on meidän työssä se, että asiakas ei aina huomaa muutosta ja meille on tullut jo tavaksi sanoa, että muistathan sitten tyhjentää myös välimuistisi.
Selaimen lisäksi palvelimella ja sivustolla voi olla välimuistitustekniikoita. Lyhyesti tämä tarkoittaa sitä, että paikallisen selaimesi lisäksi palvelin tallentaa “jemmaan” tavaraa kevyempään muotoon, josta se lataa tietoa lennosta nopeammin kuin alkuperäinen raskaampi muoto. Tällaisia tekniikoita ovat esimerkiksi Redis, Varnish, ngx-pagespeed.
Sivustolla voidaan myös käyttää erilaisia välimuistitustekniikoita, kuten esimerkiksi Transientit, jotka välimuistittavat tietokantakyselyt niin, että sivuston päivittyvää sisältöä haetaankin harvemmin, eikä joka latauskerralla. Sitten on WordPress-lisäosat, jotka voivat esimerkiksi pakata sivuston käyttämää koodia, kuvia ja resursseja tai tallentaa sivut HTML-muotoon ja tarjoilla puhdasta staattista sisältöä suoraan lataamatta alkuperäistä sivua ollenkaan.
Näiden yhteiskäyttö saattaa toisinaan aiheuttaa sisällön liian hidasta päivitystahtia tai sitä, että sivuston muutokset eivät kertakaikkiaan tule näkyviin. Joskus se on jopa toivottavaa, mutta useimmiten tarkoittaa sitä, että joko asiakkaan tai ylläpitäjän tai molempien on muistettava tyhjentää välimuisti niin sivuston-, palvelimen- kuin selaimenkin päästä. Usein näiden oikein tehty yhdistelmä parantaa latausnopeutta jopa kymmenkertaisen määrän.
Huonosti toteutettu tekniikka
Valitettavasti kaikki eivät koodaa sivustoja laadukkaasti. Huono koodi pahimmillaan tekee enemmän pyyntöjä palvelimelle kuin vastaava paremmin toteutettu koodi. Tämä tarkoittaa sitä, että pahimmillaan vaikkapa yksinkertainen uusimmat bloggaukset -lista lataa kaksikymmentä kertaa pidempään.
Voi myös olla, että sivuston tekijällä ei ole ollut sitä vähääkään osaamista, vaan WordPress-teema on ostettu tusinateemojen kaupasta parilla kymmenellä eurolla ja läjäytetty 30 kpl eri asioita hoitavia lisäosia sivustolle. Tällöin helpoista asioista saadaan mahdollisimman hitaita kun jonkun pikkutoiminnon aikaan saamiseksi ladataan muutama lisäosa. Pahimpia ovat mm. lisäosat, jotka pelkästään lisäävät sosiaalisen median jakonappeja (muutenkin turhia) sivustolle ja hidastavat saittia entisestään.
Someseinä
Vaikka niin hienoa onkin saada sosiaalisen median yhdistetty syöte, Juicer, Flow-Flow tai itse koodattu vastaava sivustolleen, some on oikeastaan pelkkiä kutsuja ulkoisille sivustoille, kuten Twitter, Facebook ja Instagram. Kuvat, linkit ja tiedostot latautuvat sieltä koneelle ilman välimuistia mikä tarkoittaa sitä että jokainen päivitys lataa ylimääräistä tauhkaa mukanaan ja näin ollen hidastaa sivustoa.
Someseiniä voi välimuistittaa, mutta yleensä vain silloin kun ne on koodattu räätälöidysti, eli monta eri palvelua yhdistävää seinää ei käytetä. Tällöin voidaan toteuttaa välimuistitettu somefeed, esimerkiksi pelkät Instagram-kuvat, jotka ladataan palvelimen välimuistiin sen sijaan että haettaisiin aina erikseen Instagramista.
Webfontit
Kyllä, käyttämäsi erikoinen fontti hidastaa sivustoa jonkin verran. Me tosin lataamme fontit paikallisesti palvelimelta, jolloin ne on myös välimuistitettu. Monesti fontteja kuitenkin ladataan väärin jostain ulkopuolelta (esim. Typekit) tai javascriptin kautta, jolloin pahimmillaan fontit “räpsähtävät” päälle vasta sivun lataamisen jälkeen (joka on toki parempi tapa kun eivät estä sivuston lataamista silloin kun fontit muutenkin hidastaisivat).
Webfontit eivät ole ultimaattinen paha, mekin pidämme niistä. Nykyään saa myös font-display -määreellä ja muilla kikoilla nopeutettua tätä puolta. Parhaimmillaan optimoituina webfontit eivät enää vaikuta juurikaan latausnopeuksiin, erityisesti jos palvelin on tehokas.
WordPress
Tämä saattaa yllättää, mutta mikä tahansa dynaaminen CMS kuten WordPress vaikuttaa latausnopeuksiin aina. Jos kaikki sisältö olisi staattista HTML:ää (käytännössä tekstiä), sivusto myös latautuisi nopeammin. Testaapas esimerkiksi Portfolio-testisaittiani rolle.design, jossa ei ole yhtään toiminnallista koodia. Aikalailla välittömästi aukeaa jokainen sivu.
Aiemmin mainituilla välimuistitustekniikoilla saa kuitenkin aikaan sen, että osa tai kaikki WordPressin sisällöstä ladataan HTML:nä. WordPressillä on mahdollista tehdä tämän eteen vaikka mitä, käyttää vaikkapa “Headlessiä WP:tä”, jossa mahdollisimman paljon latautuu staattisena. Tällaista tapaa avattu tarkemmin mm. Valun blogissa.
Vaan ei WordPress mikään hidas ole, ja onneksi WP:tä pystyy optimoimaan maailman tappiin asti. Se on kuitenkin pakko mainita tässä yhteydessä.
Analytiikat, pikselit ja seurantakoodit
Kyllä, Google Analytics, Tag Manager, Snoobi, Hubspot ja muut vastaavat hidastavat sivustoa, erityisesti silloin kun näitä on paljon käytössä. Jokainen seurantakoodi lataa dataa muualta kuin paikallisesti sivuston omalta palvelimelta.
Google Analyticsin sijaan voi käyttää esimerkiksi WP Statistics -lisäosaa, jolloin mitään ei lähetetä tai vastaanoteta Googlen palvelimen kautta. Pelkkä Google Analytics ei sinänsä hidasta sivua mitenkään roimasti, joten voit huoletta myös jatkaa sen käyttöä. On kuitenkin hyvä muistaa, että jos haluaa nopeudesta kaiken irti, jostain pitää aina luopua.
Upotukset ja videot
Jokainen YouTube/Vimeo-video on ylimääräinen kutsu ulkopuolelle ja näin ollen vaikuttaa sivuston latausnopeuteen. Upotukset on usein optimoitu toisaalta valmiiksi hyvin, eikä esimerkiksi videot vaikuta ennen kuin ne lähtevät pyörimään. YouTuben tai Vimeon kautta tulevat taustavideoelementit on myös hyvin optimoituja ja ehdottomasti parempi ratkaisu kuin videot omalla palvelimella, jotka saattavat olla useita kymmeniä megoja.
Isot kuvat
Ylivoimaisesti yleisin syy sivuston hitauteen ovat jättimäiset kuvat. Meidän asiakkaiden sivustoilla on oletuksena päällä Imagify, mutta se ei aina ratkaise ongelmaa, jos kuvat lataa alkuperäisessä 10mb tiedostokoossa tai 6000 kertaisessa pikselikoossa. Tämän lisäksi palvelimella on hyvä olla tekniikkaa, joka pakkaa kuvat esim. moderniin webm tai avif -muotoon.
Nyrkkisääntö kuviin: Tarkista, että kuvat ovat järkevän kokoisia jo valmiiksi. Kuvia voi myös etukäteen optimoida esimerkiksi ImageOptimin kaltaisten työkalujen avulla.
Kommentointi (Disqus yms.)
Kommentointilootia ei nykyään enää hirveästi näy sivustolla, koska keskustelu käydään somessa. Mutta toisinaan WordPress.com tai Disqus -kommentointeja näkee. Nämä ovat kommentointialustoja, jotka tulevat ulkopuolelta ja näin ollen hidastavat sivustoa. Joskus kävijät saattavat myös linkata omia tiedostojaan kommentteihin, joka hidastaa koko sivua. Myös käyttäjien avatar-kuvat saattavat tulla gravatar.com-palvelun kautta eikä palvelimelta suoraan ja siinä tulee taas uusi HTTP-pyyntö lisää.
Käytä joko WordPressin omaa kommentointia tai ota kommentointi kokonaan pois.
Dynaaminen sisältö
Onko sivustollasi usein päivittyvää sisältöä, esimerkiksi ruokalistoja, uutisia tai bloggauksia, rekryilmoituksia, työnäytteitä, jne.? nämä kaikki hidastavat sivustoa, ainakin silloin kun ne on huonosti koodattu tai ne on unohdettu välimuistittaa. Pahimmillaan jokainen latauskerta nimittäin hakee tiedot aina uudelleen, jolloin palvelin tekee aina uudestaan saman työn.
Hyvin koodattu sivusto ei kyykkää tähän vaan lataa aina tuoreimman välimuistikopion salamannopeasti jemmasta. Jos taas sisältö on päivitetty, ladataan välimuistiin uusin ja haetaan se sieltä. Näin samaa sisältöä ei haeta uudelleen ja uudelleen hitaalla tavalla, vaan kaikki toimii aina nopeasti.
Dynaamista sisältöä ovat myös erilaisten rajapintojen läpi haettava tieto, mutta tällaisen datan vain tyhmät jättävät välimuistittamatta. Ellei sitten (harvinaisessa tapauksessa) tarvita aina sekunnin vanha data, eikä mitään saa siksi välimuistittaa. Silloin palvelimelta pitää löytyä potkua, sillä kävijäryntäyksissä se on kovilla.
Tietokanta
Tietokanta on se mihin kaikki tieto tallennetaan ja missä kaikki tieto lepää. Tietokannassa sijaitsee artikkelisi, sivusi, asetuksesi ja kaikki muukin mitä WordPressin adminissa teet. Jos tietokanta on hidas, myös sivustosi on. Merkityksellistä tässä on palvelin, jolla tietokanta sijaitsee. Jotkut pitävät tietokantaa samalla palvelimella, toiset eri palvelimella. Tälläkään ei ole merkitystä, jos liikennettä tietokantapalvelimen ja tiedostopalvelimen välillä ei ole optimoitu esimerkiksi niin, että se menee paikallisessa verkossa (joka on nopeampi).
Tiedostojen paljous
Vaikka kaikki tiedostosi olisivat pieniä, sivusto jolla on sata tiedostoa latautuu hitaammin kuin sivusto, jolla on muutama tiedosto. Puhdasta logiikkaa. Näitä tiedostoja ovat siis kuvat, scriptit (eli esimerkiksi seurantakoodit), sivuston lähdekoodi, videot, jne.
Hyvät tekijät yhdistävät tiedostoja samaan, jolloin selain pääsee vähemmällä. Meillä esimerkiksi oletuksena yhdistetään sivuston tyyliasiat (CSS) yhteen tiedostoon (global.min.css) kuten myös Javascript-tiedostot (all.js). Nämä tiedostot vielä pakataan yhdelle riville, joka vie vähemmän tilaa ja latautuu näin ollen nopeammin. Ngx-pagespeed pakkaa myös HTML:n yhdelle riville ja kuvat lennosta kevyeen webp-muotoon.
Palvelimen sijainti
Nykyisin ei ole sinänsä kuin 20-40ms viive jos Suomesta selaa sivustoa, joka sijaitsee Amerikassa. Viivettä tulee kuitenkin, jos palvelin sijaitsee singaporelaisen opiskelijan vaatekomerossa, eli toisin sanoen geolokaatiollisesti hitaassa paikassa. Kohdemaata tärkeämpää on kuitenkin palvelimen laatu. Eli älä valitse sitä halvinta ulkomaista hostinglafkaa saitillesi.
Ruuhka
Olet tietysti onnekkaassa asemassa, jos sivustollasi käy tuhansia ihmisiä päivässä. Ruuhka-ajat vaativat kuitenkin palvelimeltasi paljon ja sivustosi täytyy ennen kaikkea olla hyvin koodattu. Liian monesti olen nähnyt verkkokauppoja, jotka ilmoittavat Facebookissa kellonajan milloin alennusmyynti alkaa. Kellon lyömänä ihmiset ryntäävät verkkokauppaan ja hupsista vaan, mikään ei toimi. Käy ilmi, että sivuston omistaja on säästänyt väärästä paikasta ja saitti lepää kahden puupennin palvelimella ja kyykkää heti kun kolme ihmistä selaa samaan aikaan. Samalla käy ilmi, että sivusto on ostettu kolmella puupennillä siskonpojalta ja sisältää 50 kpl hidastavaa WordPress-lisäosaa. Älä tee näin.
Ruuhka-aikoihin voi itse varautua, mutta sitä tärkeämpää on teetättää sivusto hyvin ja hommata hyvä ylläpito ja WordPress-optimoitu palvelin. Silloin välttyy ruuhkan aiheuttamilta hidastuksilta. Palvelunestohyökkäykset ovat toinen juttu, niissä generoidaan miljoonia kävijöitä sivustolle ja varmistetaan että palvelu pysyy nurin, silloin ei ole hirveästi tehtävissä ellei ole kunnolliset DDoS-estot olemassa (hyvillä tarjoajilla on).
Ruuhka-aikoina hyvä sivusto ja palvelin selviää niin, että kukaan ei huomaa ruuhkaa edes olevan. Valitettavasti liian usein maineikkaatkin yritykset ja sivustot kaatuvat heti kun tulee ylimääräistä kuormaa, tämä on tullut nähtyä liian monesti.
Vältä hidasteet, tee laatua
Räätälöidyllä kehityksellä välttää sudenkuopat. Jos salamannopeasti latautuvat sivut ja hyvä WordPress-ylläpito ja -palvelin kiinnostaa, pistä ihmeessä meille viestiä.
