Cachen lämmittäminen tarkoittaa jotain tapaa saada sivusisältö välimuistiin ennen kävijää. WordPressissä käytännössä jokainen sivucachen tekevä lisäosa, oli se sitten WP Rocket, WP Super Cache, W3 Total Cache, WP Fastest Cache jne., tekee sen luodessaan kopion WordPressin sisällöstä, joka sitten tarjotaan kävijälle. Varnish taasen tarjoaa ensimmäiselle ns. aidon ja tuoreen sisällön, ja sen jälkeen loput saavat sisältönsä suoraan cachesta. Cachen lämmittämisessä sivujen sisältö kerrotaan Varnishille, tai mille tahansa serveritason välimuistille, ennen kuin ensimmäisenkään kävijä saapuu paikalle. Cachen lämmittäminen tehdään käymällä jokaisella sivulla ja lataamalla koko sisältö, ja yleensä siihen käytetään jotain bottia tai spideria, mutta ulkoisiakin palveluita on.

Onko lämmittämisestä hyötyä?

Hyöty on suhteellinen käsitys, sillä kuten aina, niin se riippuu. Varsinaista yhtä ja ainutta oikeaa vastausta ei ole. Jos sivustolla on paljon liikennettä, niin kävijät itse pitävät cachen kuumana. Toki vähemmän suositut sivut jäävät syrjään ja kylmenevät, eli niiden ”parasta ennen” päiväys tulee vastaan ja ne on ensin haettava suoraan sivustolta, mutta kannattaa kysyä, että onko tuo aidosti ongelma. Niillä sivuillahan käydään harvoin. Toisaalta, ei kävijä tiedä onko urli suosittu vai ei ja hän näkee vain latausajan, joka on pidempi ilman cachea.

Jos sisällön TTL on lyhyt, niin lämmittämisestä ei ole suurtakaan käytännön hyötyä. TTL on se aika kuinka kauan asiat pysyvät välimuistissa, ennen kuin mennään Apachen tai muun webserverin kautta sivustolta kysymään, että löytyykö tuoreempaa versiota. Sanotaan, että sinulla on TTL vaikka joitain tunteja tai päiviä, niin cache pitäisi lämmittää aina tuon ajan kuluttua. Minulla Varnish on melkoisen aggressiivisilla asetuksilla, jotka pakottavat mahdollisimman paljon sisältöä pysymään cachessa mahdollisimman pitkään. joten voisin kuumentaa cachen vain silloin kun joudun tyhjentämään sen. Silloin botin ajaminen koko sisällön läpi saattaakin kannattaa. Ongelma on siinä, että se kuormittaa serveriä.

Kuorma kasvaa

Kun lämmitin isohkon sivuston Katiskan, pari tuhatta sivua, cachen, niin DigitalOceanin dropletin (kaikki saitit ovat samassa, tämäkin) prosessorin kuorma nousi prosessin ajaksi noin 70 prosenttiin ja muistia syötiin yli 60 prosenttia. Toki droplet ei ole suurimmasta päästä, kaksi CPU:ta ja 4 gigaa muistia (hintaan 20 USD/kk) ja muistin kuluminen on suora ja jopa haluttu seuraus, koska sinne Varnish välimuistinsa sijoittaa, mutta kyse on silti kuormasta. Jo pelkkä spiderin ajaminen työllisti prosessoripuolta niin paljon, että jos samalla hetkellä olisi tullut jokin kävijäryntäys vaikka verkkokursseille, niin droplet olisi ollut polvillaan.

Tuosta selviäisi rahalla, kun ostaisi enemmän ja isompaa, mutta kysymys kuuluu, että onko pelkkä cachen lämmittäminen siksi, että osa kävijöistä saa sivupyyntönsä pari sekuntia nopeammin, sen arvoista, että siitä kannattaisi maksaa ekstraa toiset 20 taalaa kuukaudessa? Minulle ei ole.

Toki tuon saa kierrettyä. Lämmittää cachen silloin kun on hiljaista.

Koko ajan palataan perussyyhyn: sivuston hitauteen. Se kannattaa yrittää korjata, niin sen jälkeen cachen lämmittäminen poistuu asialistalta. Kun sivusto on riittävän nopea ilman välimuisteja, niin warm up -kysymys keskittyy vain hyvän parantamiseen. Ja silloin on helpompi miettiä, että onko rahallinen panostus hyödyn kanssa jossain suhteessa.

Realismi vastaan hype

Tiedän. On helppo sanoa, että tehkää sivustoista nopeita. Se on WordPress-maailmassa helppo sanoa, ja useimmiten vaikea toteuttaa. Vaikka kuvat olisivat järkevän kokoisia, eikä tietokanta ole paisunut megalomaanisiin mittoihin, niin jo yksistään page builderit ja jokainen toiminnallisuus hidastaa. Kannattaa huomata, että käytännössä jokainen sekunnin tai nopeampaa wordpress-toteutusta hypettävät esittelevät aina 2012-tyylin oletusetusivun hello-world sisällöllä ilman mitään toiminnallisuuksia. Jos siihen lyötäisiinkin mukaan tuhat 6000 sanan artikkelia, verkkokoulutus, verkkokauppa ja podcastit, puhumattakaan some-syötteestä, niin todellisuus olisikin paljon raadollisempi ja hehkutetut 160 ms latausajat olisivat 5 sekunnin luokkaa.

Yksikään kävijä ei lähde sivulta alle 7 sekunnin latausajoilla. Voidaan kylläkin huokailla, että lagaako oma nettiyhteys vai onko sivusto hitaanlainen, mutta ei sisällöstä poistuta. Sen takia ei tarvitse panostaa. Aivan samoin Googlen hakutuloksissa kukaan ei mieti, että ohhoh tämä olikin se hitaampi saitti, niin klikkaan sen sijaan toista linkkiä. Google ei myöskään page rankissä piittaa pätkääkään alle 7 sekunnin latauksista ja senkin jälkeen alkaa vasta herätä kysymysmerkin. Kun mennään reippaammin yli 10 sekunnin, niin sitten saattaa hävitä nopeammalle –  tai ei, koska edelleenkin käyntimäärät, sisältö ja linkitykset ovat oleellisempia. Mutta sitä ei yksikään SEO-optimointi-konsultti sinulle kerro.

Syy siihen miksi yritetään saada nopeampia latausaikoja, on käyntikokemus ja siitä syntyvä alitajuntainen positiivinen asenne sivustoa ja siten myös sen sisältöä kohtaan. Tuo tietysti edellyttää, että on sisältöä, joka vastaa kysyntään. Jos tekee pelkkää silkkoa, niin on aivan se ja sama latautuuko sonta sekunnissa vain kolmessa.

Nopeus on suhteellista

Jokainen tietänee mitä lazy load tarkoittaa? Sisältöä ladataan vasta kun kävijä tarvitsee sitä eli ruudun ulkopuolella olevaa ei ladata, ennenkuin sinne on scrollattu. Jokainen tietänee myös, että tällä hetkellä on muotia tehdä kilometrin mittaisia etusivuja tai landing pageja ja lyödä sitten markkinointi-, mainos- ja myyntimateriaalia isoissa lohkoissa ilmavalla koko ruudun layoutilla. Ja kaikki ladataan lazy loadina, koska nopeammat latausajat. Samaan tapaan on muotia olla kertomatta oleellisia asioita, vaan tehdä sivuasioilla toinen toistaan seuraavia mainoskatkoja ja piilottaa sitten oleelliset asiat, kuten vaikka toimitus tai hinnat, alapalkin valikkoon. Tämä on hyvin tyypillinen tapa SEO.markkinoinnissa nykyään, koska asiakas on tyhmä reaktiivinen olento, joka tekee ostopäätöksen vain siksi, että tusinannen kerran samalla sivulla tarjotaan osta-nyt-heti nappulaa.

Tämä tarkoittaa sitä, että se tolkuton header-kuva ja mahdollisesti ensimmäinen mainoslohko latautuu siedettävän nopeasti – paitsi jos joku edelleen kuvittelee, että headerissa pyörivä slider on jotenkin fiksu ja kannatta toteutus; kerron uutisen, kukaan ei katso niitä, joten ne ovat pelkkää painolastia. Sitten kun lähtee scrollaamaan alaspäin yrittäessään löytää joten hyödyllistä, niin lazy load pysäyttää ja pakottaa odottamaan jokaisen lohkon kohdalla. Ei suurikaan ongelma, jos olet valokuidun päässä, mutta suurin osa liikkuu nykyään mobiileilla. Silloin lazy load, jonka piti nopeuttaa latausaikoja, itseasiassa hidastaa niitä.

Mietitään tavallista kävijästä riippuvaa cachea. Siinä välimuistiin menee vain se sisältö, jonka kävijä on ladannut – tietysti oletuksella, että webmaster on ylipäätään tehnyt toteutuksen niin, että se on välimuistitettavissa. Kun lazy load sivulla ei edetä, niin latausta vaativia komponentteja ei laiteta cacheen. Silloin seuraava kävijä ei hyödykään siitä, että joku oli jo käynyt sivulla.

Tuo saa fiksattua parillakin tavalla, ja yksi on cachen lämmittäminen ja kuvien pitäminen niin nopeiden yhteysien päässä kuin mahdollista – joka ei sitten todellakaan tarkota aina CDN:n käyttöä.

Välimuistien marssijärjestys

Kun käytetään välimuisteja, vaikka WP Rocketia sivutason välimuistiksi ja Varnish on reverse proxy, niin…

1. Ensimmäiselle kävijälle järjestys on tämä:

• Varnish päästää läpi sellaisenaan, koska mitään ei ole välimuistissa
  • Sivu tallennetaan välimuistiin, kun kävijä on saanut sen
• WP Rocket tarjoaa sisällön ja jos sitä ei ole, niin WordPress tekee sen, mutta ei tallenna sitä WP Rocketille
  • sisällöstä iso osa tallennetaan kävijän selaimeen

2. Kun seuraava saapuu samalle sivulle, niin

• Varnish antaa välimuistista kopion, eikä mennä muualle
  • sisällöstä iso osa tallennettaan kävijän selaimeen

3. Kun sama ihminen saapuu uudestaan

• Selaimen välimuisti antaa ison osan sisällöstä
• Varnish antaa loput

Kun cache lämmitetään, niin ensimmäinen käynti siirtyykin kohtaan 2 ja piipahdus webserverillä ja WordPressistä jää pois. Silloin myös WP Rocket jää eräällä tavalla sivurooliin ja palvelee enemmältikin spideria. Varnish, joka ei hae sisältöä webserverin ja tietokannan kautta, on aina nopeampi tapa.

Välimuistin lämmittäminen

Muistutan vielä, että jos sinulla on sivutason välimuisti, niin tämän tekemisessä ei ole mitään mieltä. Käytä pluginisi toimintoja. Esimerkiksi WP Rocketissa se on kohta ”esilataa välimuisti”. Sen sijaan jos sinulla on käytössä Varnish tai vastaava reverse proxy, niin silloin homma onnistuu.

Koska koko sisällön saaminen cacheen vaatii jokaisella sivulla käymisen, niin se tehdään ns. spiderilla. Tai botilla, jos pidät siitä nimestä enemmän. Tehdään siis sama kuin mitä googlebot, mutta kahdella erolla:

• sisältöä ei erikseen tallenneta mihinkään
• käydään todellakin kaikilla sivuilla

Tuohon on olemassa useampi työkalu, mutta se mitä etsit, on nimeltään wget. Se on tietääkseni valmiina kaikissa distroissa, mutta jos se puuttuu, niin Ubuntussa se asentuu kuten (melkein) kaikki muukin:

apt update

apt install wget

wget komennetaan kahlaamaan annettu sivusto läpi, poistamaan tekemänsä väliaikaiskopiot (senhän täytyy ladata sisältö ja johonkin se on laitettava) ja tekemään kaiken käyttämättä Varnishin välimuistia:

wget --spider -o wget.log -e robots=off -r -l 5 -p -S -T3 --header="X-Bypass-Cache: 1" -H --domains=example.com --show-progress www.example.com

• tehdään logi mm. latausajoista
• robots.txt komennoista ei piitata
• haku on rekursiivinen, eli edetään linkkejä pitkin haluuttuun syvyyteen, joka on 5
• asetetaan header, jolla ohitetaan Varnishin cache
  • koska olen kieltänyt pääsyn tyhjällä User-Agent tiedolla, niin jouduin lisäämään myös tämän:
    --header="User-Agent:CacheWarmer"
• asetetaan domain, jolloin ryömitään läpi myös alidomainit (jos niitä on)
• näytetään shellissä eteneminen
• osoite. josta aloitetaan

Tässä on samasta laajempi selitys. Tosin englanniksi, mutta eiköhän se siitä aukene kuitenkin.

Kannattaa huomata, että wget etenee vain löytämiensä linkkin kautta. Se ei tiedä sitemapin olemassaolosta.

404

wget antaa yhden edun lisää: se löytää samalla sivuston sisäiset rikkinäiset linkit. Ei siihen hommaan tuon kummallisempaa pluginia tarvita. Jos käytät jotain monitoria, joka seuraa error 404 osumia, kuten Rank Math SEO-lisäosaa, niin sinulla on valmis lista korjauksia varten.

Cron

Voit myös ajastaa koko homman. Tämä tulee muuten vastaan varsinkin webhotelleissa. Niissä on aina cron käytössä ja useimmiten wget, vaikka shell-yhteyttä ei olisikaan. Joten kun laittaa yllä olevan rotlan croniin, niin lämmitys pitäisi onnistua ilman sen kummempia ongelmia. Tuo tosin edellyttää, että sinulla on webhotellissa Varnish asettuna, eikä sellaisia taida olla Suomessa yhtään ainutta. Maailman mittakaavassakin taitaa löytyä vain muutama.

Avataan cron.

crontab -u www-data -e

Minä itse kylläkin käytän rootin cronia, koska sen on luotettavampi.

Lisää sinne tämä:

0 3 * * * wget --spider -o /tmp/wget.log -e robots=off -r -l 5 -p -S -T3 --header="X-Bypass-Cache: 1" -H --domains=example.com --quiet www.example.com

Cron ajetaan joka päivä kello 3.00 ja logi löytyy hakemistosta /tmp.