WordPress-blogin nopeusoptimointia

Vaihteeksi täysin tekninen kirjoitus, WordPress-blogin tehostamisesta. Tämä blogi, samoin kuin Opettajan tekijänoikeus, pyörivät omalla serverilläni WordPress-blogiohjelmistolla. Kun taannoin kirjoittelin vähän kiinnostavampia juttuja, huomasin, että blogini palvelivat tosi tahmaisesti, kun kymmenet lukijat vierailivat sivuilla samanaikaisesti. Ei hyvä, joten tuunaamaan.
Oman WordPress-palvelimen käytössä on se ilo, että blogin säätömahdollisuuksia on huomattavasti enemmän kuin vaikkapa Bloggerin tai WordPressin maksuttomissa palveluissa. Enemmän osaamistahan siihen käyttöönottoon vaaditaan, mutta esimerkiksi tämäkin blogi osaa lähettää automaattisesti twiittejä ja Facebook-viestejä uusista kirjoituksista juuri siksi, että voin asentaa tähän kaikenlaisia lisätoimintoja ja virittää ne näkymään kuten haluan. Haittapuolena on se, että maksuttomassa blogipalvelussa suorituskyky on palveluntarjoajan ongelma, ei blogaajan päänsärky.
Mutta joo, käytännössä helpoimmaksi ratkaisuksi osoittautui W3 Total Cache -niminen WordPress-laajennos (tästä eteenpäin W3TC). Ennen sen käyttöä blogini palveli etusivun 8 sekunnissa ja toistolatauksen (jolloin suuri osa sisällöstä voisi olla jo valmiiksi selaimen muistissa) 5 sekunnissa. Ihan toivottoman hidasta.
Laajennoksen käyttöönotto aktivoi jo heti joitain nopeutuksia, mutta täysi teho edellyttää melkoisesti teknistä säätöä. Asennuspuolella tarvitaan PHP:hen Alternative PHP Cache -kirjasto (debianissa php-apc), jonka tarjoama opcode-välimuisti nopeuttaa php:n suoritusta noin yleisesti ottaen kymmenkertaisesti (vaihtoehto olisi xcache-kirjasto). W3TC tarjoaa kätevän compatibility checkin, joka tarkistaa, mitä kaikkia nopeutukseen tarvittavia juttuja on säädetty kuntoon ja mitä voisi vielä tehdä.
Perusasennusten jälkeen alkaa itse W3TC:n säätäminen, jota voi aluksi tehdä preview-tilassa ja vasta sen hyväksi havaittuaan ottaa todella käyttöön. Seuraavat päätoiminnot kytketään päälle: Page Cache, Minify, Object Cache, Browser Cache. Jokaiseen cache-tavaksi opcode-välimuisti, kun kyseessä on yhdellä serverillä pyörivä blogi. Jos blogia ajaa palvelinklusteri, lienee levyvälimuisti yhteiselle levylle järkevämpi. Ja sitten jokainen osio säädetään erikseen kuntoon.
Page Cache menee oletusasetuksilla aika hyvin, samoin Object Cache. Browser Cachesta kannattaa pyörittää sopivat headerit käyttöön ja tarkistaa, että säilytysajat erityyppisillä tiedoilla ovat järkevät (kuvilla yms. pysyvillä lähes ikuinen, css-tiedostoilla yms. useita päiviä, sivujen sisällöllä joistain minuuteista päivään, tilanteen mukaan).
Eniten työtä teettää Minify, mutta se tarjoaa ehkä myös eniten säästöjä. Lopultahan kyse on siitä, että vähentämällä lähetettyä dataa mutta etenkin vähentämällä erillisien ladattavien tiedostojen määrää saadaan blogi sutjakammaksi. Minify-osiossa kerrotaan kaikki css-tiedostot, joita blogisivulle liitetään, sekä kaikki js-tiedostot. W3TC osaa sitten poimia ne pois, yhdistää ja tiivistää yhdeksi tiedostoksi ja palvella tämän eteenpäin. Tällöin kymmenten js- ja css-tiedostojen sijaan tulee vain yksi kumpaakin ladattavaksi.
Lopputulos: blogin etusivun lataamiseen menee nyt 4 sekuntia ja toistolatauksella 0,7 sekuntia. Ja tästäkin ajasta melko suuri osa tulee itse asiassa Facebookin ja Twitterin palveluista, joita etusivulle ladataan erilaisiin widgetteihin.
Eli mitä? Jos sinulla on oma WordPress, asenna W3TC-plugini ja lähde sen asetuksia plaraamaan. Jos homma menee yli hilseen, apua löytää googlaamalla. Voi minuunkin ottaa yhteyttä.
Lopuksi vielä dataa sanojen taakse. Tässä on tarkat tiedot blogini etusivun latauksesta optimoinnin jälkeen.