Nopeuttaako CDN sivustoa?

 

 

CDN eli content deliver network on asia, jota mainostetaan joka puolella. Suunnilleen jokaikinen palvelu, joka liittyy mitenkään mediaan – kuva, video, ääni – myy oheistuotteena CDN.palvelua. Välillä tulee tunne, että jokin kuvasovellus on itseasiassa vain sisäänvetotuote, jonka kyljessä myydään se varsinainen asia: CDN ja pala pilveä. Se, että tarvitseeko moista aidosti, onkin oma juttunsa.

CDN:ää mainostetaan ensisijaisesti sivustoa nopeuttavana temppuna. Ensin peloitellaan kuinka kävijät poistuvat, jos sivu ei lataudu sekunneissa. Toiseksi maalataan uhkakuva, että Google rankaisee hakutuloksissa, jos sivu on hidas. Kolmantena tuodaan sitten ratkaisu: CDN.

Lyhyesti sanottuna, CDN eli sisällönjakoverkko on liuta servereitä enemmän tai vähemmän ympäri maapallon, joiden oletetaan olevan nopeampien yhteyksien päässä käyttäjästä kuin web-saittia hostaava palvelin. Oletetaan siksi, että se ei ole automaatio. Amazonilla on varmasti nopeat yhteydet, kuin myös CloudFlarella (ei, en tiedä onko heillä aidosti oma serveriverkko vai onko se lopulta Amazonin). Ajatuksena on siirtää kuvat (ja muu media, välillä myös osa ajettavasta koodista) CDN:ään, jolloin niitä ei ladata hitaamman yhteyden takana olevasta sivustosta, vaan CDN:n käyttäjää lähempää olevasta palvelimesta. Silloin latausajat lyhenevät ja sivusto nopeutuu.

Kaunis ajatus, mutta todellisuus on aivan toinen.

Tuo pätee ns. kansainvälisillä yhteyksillä – toisin sanoen kun sivulla käydään ympäri maailman. Kun suomalainen sivusto on ”fyysisesti” serverifarmissa Espoossa, ja CDN-serveri on Frankfurtissa, niin sillä turkulaisella, oululaisella ja rovaniemeläisellä on nopeampi yhteys Espooseen kuin Frankfurtiin. Oikeammin, heidän oma nettinopeutensa ylipäätään on rajoittavampi tekijä kuin Frankfurtin yhteys Espoon kautta käyttäjälle kuin yhteys Espoosta käyttäjälle.

Minulla kaikki sivustot ovat DigitalOceanin serverillä Frankfurtissa. CDN on rakennettu Amazonin CloudFlarelle Irlannin Dubliniin, mutta heillä on serveri Helsingissä, jonne saittieni kaikki mediatiedostot siirretään välimuistiin. Joten periaatteessa sivustojen kuvat latautuvat einen nopeammin suomalaisille (tai Ruotsin suomalaisille, koska Tukholmassa on myös datakeskus) kuin jos ne siirrettäisiin Saksanmaalta muun sivusisällön mukana. Ja nimenomaan periaatteessa, koska aidosti asiaan vaikuttaa pari muutakin asiaa: miten kuvien cacheaminen on rakennettu Amazonin CloudFlareen ja miten sivuston muu tekniikka toimii.

Jos CloudFlaressa sisältö vanhenee liian nopeasti, niin siinä vaiheessa kun käyttäjä lataa sivun, niin kuvaa ei löydykään Helsingistä. Käydään kysymässä isommalta keskukselta onko kuva muuttunut. Kun se ei tietenkään ole, niin sitten vasta kuva ladataan käyttäjälle. Tuo kyselykierros on toki nopea, mutta serverien miettimiset viivästyttävät. Korkeamman liikennemäärän sivustot ovat paremmassa asemassa, koska on oletettavaa, että sisältöä käydään kurkkimassa useammin. Mutta jos puhutaan normaalimmasta kotimaisesta saitista. jossa 20 yhtä aikaista käyttäjää on yleisöryntäys ja suurinta osaa vanhemmasta sisällöstä ei lueta edes joka vuosi, niin cachen aikarajat tulevat helpostikin vastaan.

Pysytään WordPressissä, mutta sama koskee aivan kaikkia sisällöntuottosysteemejä.

CDN nopeuttaa aniharvoin. Toki mittarit, vaikka Pingdom. saattavat löytää sekunnin kymmenyksen eroja, mutta eivät moiset koskaan käyttäjälle näy. Se mihin pitää nopeuden optimoinnissa kiinnittää huomiota, on sivuston muu tekniikka. Teema ja vekkulut lisäosat hidastavat merkityksellisesti ja suurin pullonkaula on page builderit. Toki gigan kokoinen kännykkäkuva tai kaksi hidastavat latausajoissa yksittäisenä tekijänä eniten, eikä kuvien optimointia saa todellakaan jättää tekemättä, mutta ei sitä CDN ratkaise. Kuva on edelleen gigan painoinen, tulee se sitten CloudFlaresta tai wordpressin upload-kansiosta.

Ensimmäiseksi poistetaan turhat roinat. Kannattaa miettiä aidostiko tarvitsee kaikka mahdollista hilavitkutinta vimpain-varastosta. Sen jälkeen mietitään, että voisiko sivurakennettaa keventää. Jos käyttää jotain magazine-teemaa ja tunkee kolmeen sivupalkkiin ja footerissa 3×3 ruudukkoon mahdollisimman paljon suosituksia muista jutuista sekä muuta tauhkaa, niin on unohtanut perusidean: suurin osa käyttäjistä liikkuu mobiililla eikä koskaan rullaa sitä 100 metrin pituista sivua ohi sisällön. jotta näkisi edes sivupalkkien sisällön.

Jetpackin tarpeellisuutta kannattaa miettiä tarkkaan. Se hidastaa, varsinkin hallinnan puolella – toki se ei näy taviksille. Woocommercessa ostoskorin ajax aiheuttaa sekuntien paussin ja on usein suurempi hidaste kuin kuvat. Aidosti reaaliaikaisesti päivittyvää ostoskoria tarvitsee todella harvoin.

Asiakkaan oma laite on se todellinen CDN, varsinkin uskollisemmilla kävijöillä, mutta myös heille, jotka eivät poistu heti yhdeltä sivulta. Serverillä täytyy olla sallittuna gzip, eli sisällön pakkaus. Samaten cache täytyy olla määriteltynä, jotta mahdollisemman paljon jatkuvasti näytettävää sisältöä, kuten logot ja muut vakiokuvat, tallennettaisiin käyttäjän laitteelle välimuistiin. Lisäksi kannattaa harkita serveritason välimuistin käyttöä. Varnish on tehokas (mutta sitä hypetetään vähintään yhtä paljon kuin CDN:ää), mutta ei yleensä mahdollinen web-hotelleissa. VPS-pilviä käyttäville varteenotettava lisä – kunhan ei pyöritä useampaa domainia samassa paikassa.

Sivujen hostaaja on se aito ja todellinen pullonkaula, eikä sitä pysty korjaamaan muutoin kuin vaihtamalla firmaa.

Kyse on siitä, että CDN ei ratkaise perustason ongelmia. Se on viritystä. CDN otetaan käyttöön kun kaikki muu kunnossa. Sisällönjakoverkko tuo hieman turvallisuutta tekniikkaan. Sitä ei kuitenkaan saa käyttää levytilan laajentimena, vaan mediatiedostot on pidettävä omalla serverillä. Jos tulee ongelmia, niin poistamalla median linkityksen tekevän pluginin, saadaan kuvat latautumaan taas omalta serveriltä. Jos pyörittää valokuvagalleriaa. niin ne eivät pääsääntöisesti tykkää CDN:stä, ainakaan jos se on joku kuin gallerian kyljessä myyty.

Jos päätät asentaa CDN:n, niin huomioi, että se lisää hivenen kulujasi. Itseasiassa vähintään kympin kuussa. Joten jos huokailet 9,90/kk maksavasta web-hotellista, tai joudut harkitsemaan pitkään uskallatko ostaa elämääsi helpottavat palikan, koska se maksaa 49,90 vuosi, niin ehkä 199/vuosi maksava sopimus siitä, että saat sekunnin nopeamman latauksen, ei ole sinun juttusi,

Jos sivusto maksaa muutoinkin pelkästään hostauksen osalta vähintään 500 euroa vuosi, niin CDN yhdessä cache-järjestelmän kanssa on asia, jota kannattaa harkita. Ei niinkään nopeuden takia, vaan koska saat hajautettua sivuelementtien latauksia ja tasattua mahdollisia serverien hidasteluja.

Takaisin alun uhkakuviin.

Google ei rankaise normaalisti latautuvia sivuja. Saittisi ei tarvitse sekunnin kellotusta, seitsemän sekuntia on ihan hyväksyttävä. Google palkitsee klikkauksista ja kävijöiden määristä. Jos on kaksi samanlaista sivustoa vastaavalla sisällöllä ja suosiolla, niin silloin Google saattaa nostaa nopeamman tuloksissa edelle. Tuosta selviää yhdellä tempulla: tee kunnollista sisältöä. Siksi toiseksi henkiläkohtaiset hakutulokset sotkevat koko pelikentän, mutta sitä SEO/nopeus-konsultit eivät vaivaudu kertomaan.

Eikä yksikään käyttäjä häivy 3-5 sekunnin odotuksesta. Ei ole koskaan häipynyt. Tuo urbaani legenda, jota virheellisesti jopa tutkituksi tiedoksi tituleerataan, oli vitsi jo silloin kun se tehtiin – niihin aikoihin pelkästään modeemien kättely vei äkkiä minuutin ja yleisesti surffausnopeudet olivat hitaampia kuin GSM:llä. Se siitä.