50
Jaa

Olemme vuosien varrella julkaisseet paljon tutoriaaleja, joiden avulla WordPressiä voi optimoida ja nopeuttaa. Mutta joskus on hankalaa, kun kaikkea tietoa ei löydy yhdestä paikasta. Joten tänään käymme läpi kaiken, mitä tiedämme WordPressin nopeuttamisesta – yli 15 vuotta kokemusta ja kantapään kautta opittuja asioita, kaikki yhdessä täydessä oppaassa! Olet sitten WordPress-aloittelija tai kokenut ohjelmistokehittäjä, lupaamme, että löydät tästä artikkelista jotain hyödyllistä!

Yli 34% koko internetistä on nykyään tehty WordPressillä. Tämä on hienoa, mutta se tarkoittaa myös sitä, että on olemassa tuhansia erilaisia teemoja, lisäosia ja teknologioita, joiden on tultava toimeen keskenään. WordPressin jokapäiväiselle käyttäjälle tästä voi muodostua oikea painajainen, kun sivuston toiminta takkuaa ja on lähes mahdotonta tietää, mistä sen korjaamisen voisi aloittaa.

Aikaisemmassa oppaassamme sivunopeuteen kävimme läpi suorituskyvyn perusteet ja vaikutuksen, joka sillä voi olla yrityksen kannattavuuteen. Tänään käymme läpi askeleet, jotka voit ottaa jo tänään parantaaksesi WordPress-sivustosi toimintaa. Jaamme myös resursseja, jotka ovat olleet meille erityisen arvokkaita.

WordPressin nopeuttamisen sisältö

WordPress-sivutyypit: Staattinen vai dynaaminen

Ennen kuin sukellamme täysillä optimointiin, on tärkeää ymmärtää, etteivät kaikki WordPress-sivustot ole samanlaisia. Tämä aiheuttaa usein päänvaivaa, koska kaikkia ongelmia ei voi ratkaista samalla tavalla. Me erottelemme WordPress-sivustot kahteen eri luokkaan: staattinen tai dynaaminen. Joten tutkitaanpa ensin näiden sivustotyyppien eroja.

Suurimmaksi osaksi staattiset sivustot

Staattisiksi sivustoiksi lasketaan yleensä blogit, pienyritysten sivut, pienempien kävijämäärien uutissivustot, henkilökohtaiset sivustot, valokuvaussivustot jne. Staattisella tarkoitamme, ettei data muutu kovin usein (ehkä pari kertaa päivässä). Jopa suurin osa Kinstan sivuista on staattisia. 

Tämä on tärkeää siksi, että moni kysely palautuu suoraan välimuistista palvelintasolla ja salamannopeudella! Älä huoli; käymme välimuistiin liittyvät asiat läpi myöhemmin. Tämä tarkoitaa, että tietokantaa kutsutaan harvemmin eikä yhtä paljon resursseja tarvita korkean suorituskyvyn saavuttamiseksi.

Erittäin dynaamisen sivustot

Toisaalta meillä on myös erittäin dynaamisia sivustoja. Näihin lukeutuvat esimerkiksi verkkokauppasivustot (WooCommerce tai Easy Digital Downloads), yhteisö- ja jäsensivustot, foorumit (bbPress tai BuddyPress), ja niin sanotut learning management system -sivustot (LMS). Dynaamisella tarkoitamme, että data muuttuu usein (palvelintasolla tapahtuu parin minuutin välein tai jopa joka sekunti). Näin ollen kaikkien kyselyjen kohdalla ei voida luottaa välimuistiin, vaan tarvitaan lisäresursseja ja -tietokantakyselyjä.

Näillä sivustoilla on yleensä enemmän yhtäaikaisia käyttäjiä. Suurimmaksi osaksi staattisella tieto- tai yrityssivustolla käyttäjä saattaa viipyä viidestä kymmeneen minuuttia, kunnes löytää etsimänsä (ja tämä on pitkä aika; yleensä kävijät lähtevät paljon nopeammin). Dynaamisilla sivustoilla käy päinvastoin: kävijät tulevat ottaakseen johonkin osaa. Esimerkiksi verkkokurssien kohdalla ei ole harvinaista, että sivustolla viivytään useita tunteja.

Ymmärrät varmaan, mihin tämä on menossa. Yhtäaikaisten käyttäjien määrä eli yhteyksien lukumäärä WordPress-isäntään kasvaa nopeasti. Mikä pahempaa, sinulla on paljon yhtäaikaisia kävijöitä sen lisäksi, ettei sisältöä voida säilöä välimuistiin.

You can't treat all WordPress sites the same when it comes to performance. Static and highly dynamic sites are two very different beasts! 🦖 Click to Tweet

Valitse korkean suorituskyvyn WordPress-hosting

WordPress-hostingin tarjoaja eli WordPress-isäntä on yritys, joka säilöö kaiken sivustosi tarvitseman datan. Tilaat yritykseltä tarpeisiisi sopivan datapaketin ja kaikki kuvasi, sisältösi, videosi jne. siirretään palvelimelle hosting-palveluntarjoajan datakeskukseen. WordPress-isäntä sallii sinun helposti päästä tiedostoihisi käsiksi, hallinnoida sitä ja jakaa sitä kävijöille. Aika yksinkertaista, vai mitä? No, ei ihan.

On olemassa kolme hyvin erilaista WordPerss-isäntää, joita netistä löytyy. Katsotaanpa kunkin hyviä ja huonoja puolia. On tärkeää, että valitset oikean heti aluksi, sillä muuten haaskaat paljon aikaa ja joudut painimaan turhien ongelmien kanssa.

1. Jaettu WordPress-hosting

Ensimmäinen ja suosituin WordPress-hostingin tyyppi on niin kutsuttu jaettu hosting (shared hosting). Näiden palvelujen tarjoajiin lukeutuvat alan suurimmat tekijät kuten EIG-yritykset Bluehost ja HostGator sekä Siteground, GoDaddy ja InMotion Hosting. Ne käyttävät yleensä cPanelia, ja keskivertoasiakkaan kuukausimaksu on $3-$25.

Kaikki, jotka käyttävät tämäntyyppistä hostingia, törmäävät ennemmin tai myöhemmin sivuston hitausongelmiin. Miksi? Koska jaettu hosting usein ylikuormittaa palvelimiaan, mikä vaikuttaa sivustojen tilaan. Sivujen käytettävyysongelmat ja toistuvat 500-virheilmoitukset ovat tavallisia, vaikka palveluntarjoajalla olisikin käytössään rajoituksia ja vararesursseja. Pahin ongelma on tietysti sivuston kaatuminen kokonaan. Vaikket tiedä sitä, WordPress-sivustosi saattaa sijaita samalla palvelimella eli 200 muun käyttäjän sivustojen kansa. Ja kaikki ongelmat, jotka sattuvat jollain muulla sivustolla, saattavat vaikuttaa sinun sivustosi toimintaan.

Laski tämän miten tahansa, kulujen jälkeen $3 per kuukausi ei yksinkertaisesti riitä tekemään hosting-tarjoajalle kunnollista tulosta. Erityisesti, jos ottaa huomioon asiakastukikulut. Yksikin asiakastukipyyntö saisi yrityksen tekemään tappiota. Nämä yritykset tekevät rahaa sillä, että heillä on ylimääräisiä ja piilokuluja. Ylimääräisiin kuluihin kuuluvat esimerkiksi sivumigraatiot, domain-rekisteröinnin, SSL-sertifikaatit jne. Toinen tavallinen taktiikka ovat valtavat rekisteröitymisalennukset, eli ensimmäisen kuukauden saa erittäin halvalla. Mutta kun tulee aika uusia palvelu, saapuu myös aivan uuden kokoluokan lasku.

Moni näistä palveluntarjoajista käyttää hosting-paketistaan termiä ”rajoittamattomat resurssit”. Olette varmasti kaikki nähneet tämän. No, oikeassa maailmassa rajoittamattomia resursseja ei olekaan. Se, mitä kulisseissa todellisuudessa tapahtuu, on, että isännät asettavat rajoituksia niille käyttäjilleen, jotka vievät paljon resursseja. Näin resursseja paljon tarvitsevat asiakkaat suuttuvat ja menevät muualle, jolloin tilaa on niille, jotka eivät tarvitse yhtä paljon resursseja. Lopputulos on noidankehä, jossa hosting-tarjoaja hamuaa halvoilla paketeilla asiakkaita, joiden toivotaan käyttävän vain vähän resursseja ja tarvitsevan paljon ylimääräisten kulujen palveluja.

Asiakaspalvelu ja -tuki jaetussa WordPress-hostingissa ovat lähes aina ala-arvoisia jo pelkästään siitä syystä, että asiakkaita on valtavasti asiakastukihenkilöihin verrattuna. Jaettujen isäntien täytyy saada vähäiset resurssit riittämään tehdäkseen voittoa, mikä johtaa asiakkaan kannalta huonoihin kokemuksiin.

When it comes to shared hosting, you usually get what you pay for. 😒 Click to Tweet

Paljon lisätietoja tarjoaa talouspäällikkömme artikkelissa totuus hosting-markkinoiden taloustieteestä.

2. DIY VPS -tyyppinen WordPress-hosting

Toinen yleinen tapa hoitaa WordPress-hosting on niin sanottu DIY VPS: “Do it yourself on a virtual private server”, eli tee se itse yksityisellä virtuaalipalvelimella. Tämän käyttäjät ovat yleensä esimerkiksi startup-yrityksiä tai kokeneempia käyttäjiä, jotka pärjäävät esimerkiksi palvelinhallinnan kanssa – tee-se-itse -porukka. Nämä tyypit yrittävät yleensä yhä säästää rahaa mutta tiedostavat tarvitsevansa myös kunnon suorituskykyä kasvattaakseen liiketoimintaansa. Usein nämä käyttäjät valitsevat ulkopuolisen VPS-tarjoajan kuten Digital Ocean, Linode tai Vultr, sekä ServerPilotin tapaisen työkalun, jolla sivustoa voi helpommin hallinnoida.

Pieni VPS DigitalOceanilta alkaa hinnasta $5 per kuukausi, ja ServerPilotin suosittu paketti maksaa $10 per kuukausi ja siitä ylöspäin. Joten valinnoistasi riippuen hinnat saattavat olla $5-$15 per kuukausi tai enemmän. Tee-se-itse -lähestymistapa laskee kustannuksia, mutta olet myös itse vastuussa kaiken ylläpidosta ja optimoinnista.

Tee-se-itse voi olla hienoa, mutta se voi myös käydä hankalaksi, jos et ole varovainen. Älä valitse tätä vaihtoehtoa, ellet ole tekniikkaan vihkiytynyt, tai siksi, että haluat vain puuhastella! Aikasi on arvokkaampaa ja sinun tulisi käyttää se yrityksesi kasvattamiseen.

3. Hallinnoitu WordPress-hosting

Kolmas tyyppillinen hosting-tapa on se, mitä me tarjoamme Kinstalla: hallinnoitu WordPress-hosting. Tämän kaltaiset isännät hoitavat kaikki backend-puolen hommat sinun puolestasi ja tarjoavat tukea, kun sitä tarvitset. Ne on yleensä hiottu toimimaan WordPressin kanssa yhdessä aj tarjoavat usein ominaisuuksia kuten yhden painalluksen testiympäristöjä ja automaattisia varmuuskopiotallennuksia. Niiden asiakastuki on yleensä asiantuntijatasoista, mitä tulee CMS:ään, koska he työskentelevät vain yhden alustan parissa joka päivä.

Jos haluat säästää rahaa, hallinnoitu WordPress-hosting on oikea ratkaisu sinulle! 👍

Hallinnoidun WordPress-hostingin paketit maksavat tyypillisesti $25-$150 tai enemmän per kuukausi riippuen sivuston koosta ja tarpeista. Suuret yritykset kuten jQuery, Intuit, Plesk, Dyn, NGINX ja jopa Valkoinen talo kaikki käyttävät WordPressiä sivustonsa pyörittämiseen. Suosittuja hallinnoituja WordPress-isäntiä, jotka saatat tuntea, ovat esimerkiksi WP Engine, Flywheel, Pressable, Media Temple, Pressidium ja Pagely.

Kinstan tapa on erilainen

Kinsta sen sijaan vie hallinnoidun WordPress-hostingin uudelle tasolla. Alustamme ei kuulu mihinkään perinteisistä hosting-kategorioista. Koko infrastruktuurimme on rakennettu Google Cloud Platformille eikä ole samanlainen kuin jaettu, VPS- tai yksityinen infrastruktuuri. 

Jokainen WordPress-sivusto alustallamme pyörii eristetyssä ohjelmistokontissa, joka sisältää kaikki sivuston pyörittämiseen tarvittavat ohjelmistoresurssit (Linux, NGINX, PHP, MySQL). Näin ollen ohjelmisto, joka sivustoa pyörittää, on täysin yksityinen eikä resursseja jaeta edes saman käyttäjän eri sivustojen välillä.

Kinstan arkkitehtuuri

Kinstan arkkitehtuuri

Kukin sivostukontti pyörii virtuaalikoneella yhdessä monista GC-datakeskuksista. Jokaisessa koneessa on jopa 96 CPU:ta ja satoja GB:itä RAM-muistia. Virtuaalikoneemme jakavat laitteistoresurssit (RAM/CPU) jokaiselle sivustokontille tarveperusteisesti (toiminto, josta käytämme termiä auto-scaling eli automaattinen skaalaus).

Joka vuosi Review Signal julkaisee tuloksensa suorittamistaan WordPress-hostingin suorituskykytesteistä, ja voimme ylpeinä kertoa, että viiden peräkkäisenä vuonna Kinsta on ollut paras yritys joka osa-alueella! Eikä tämä koske vain yhtä tai kahta pakettiamme vaan niitä kaikkia – Starter-paketista Enterpriseen. 🤘

Kinstalla on lähes täydellinen tulos LoadStorm- ja Blitz-testeissä. Muissakaan testeissä ei ollut ongelmia. En edes tiedä, kuinka kehua heidän suorituskykyään.
Kevin Ohashi
Kevin Ohashi
Perustaja ja WP-konsultti, ReviewSignal

Meillä ei myöskään ole tason 1 tai 2 asiakastukea, vaan koko asiakastukitiimimme koostuu WordPress-ohjelmistokehittäjistä ja Linux-insinööreistä. Monella heistä on omat palvelimensa ja he ovat luoneet teemoja ja lisäosia sekä osallistuneet WordPressin ytimen luomiseen ja ylläpitoon. Näin takaamme sen, että saat asiantuntevaa apua ihmiseltä, joka aktiivisesti käyttää ja kehittää WordPressiä.

Saat apua ihmisiltä, jotka auttavat myös Fortune 500 -yrityksiä ja muita isoja yritysasiakkaitamme. Me olemme niin tarkkoja asiakastukemme tasosta, että palkkaamme alle prosentin kaikista hakijoista. Parempaa asiakastukea et löydä mistään!

WP Enginellä perusongelmat hoituvat nopeasti. Mutta jos ongelmat ovat monimutkaisia, niiden ratkaisussa kestää ja se vaatii paljon yhteydenpitoa. Jos sinulla on korkealuokkainen WordPress-sivusto ja ongelma tarvitsisi ratkaista nopeasti, tämä voi muodostua ongelmaksi. Jos minulta kysytään yksinkertaisesti, kumpaa suosittelisin ennemmin, Kinsta on mielestäni parempi. He tarjoavat paljon enemmän kuin lupaavat. Heidän kanssaan ei tarvitse koskaan huolehtia sivuston hitaudesta, asiakastuen laadusta tai muista hosting-palveluun liittyvästä.
Harsh Agrawal
Harsh Agrawal
Palkittu bloggeri, ShoutMeLoud

Jos kaipaat lisätietoa siitä, miksi sinun kannattaisi valitan Kinstan hallinnoitu WordPress-hosting, lue artikkelimme miksi me – miten Kinsta eroaa muista. Mutta valitsit hosting-tarjoajaksesi kenet tahansa, sinun kannattaa aina kiinnittää huomiota seuraaviin palvelinominaisuuksiin, jotta sivusi pyörii mahdollisimman nopeasti.

PHP 7 tai uudempi takaa parhaan suorituskyvyn

PHP on avoimen lähdekoodin palvelinpuolen skriptaus- ja ohjelmointikieli, jota käytetään etupäässä internetin kehitykseen. Suurin osa WordPressin ydinohjelmistosta on kirjoitettu PHP:llä. Sama pätee moniin lisäosiin ja teemoihin. Näin ollen PHP on erittäin tärkeä kieli WordPress-yhteisössä. Sinun kannattaa varmistaa, että hosting-tarjoajallasi on käytössään vähintään PHP 7 tai uudenpi.

On olemassa eri PHP-versioita, joita isäntäsi saattaa tarjota palvelimellaan. Uusin, PHP 7.3, tarjoaa valtavia parannuksia suorituskykyyn.

Itse asiassa viimeiaikaisissa PHP-suorituskykytesteissä tulimme siihen tulokseen, että jos vertaan PHP 7.3:a PHP 5.6:een, se kykenee prosessoimaan kolme kertaa yhtä paljon kyselyjä (transaktioita) sekunnissa! PHP 7.3 on myös keskimäärin 9% nopeampi kuin PHP 7.2. Tämä saattaa vaikuttaa myös siihen, kuinka responsiivinen WordPress-hallintapaneelisi on.

WordPress 5.0:n PHP-testituloksia

WordPress 5.0:n PHP-testituloksia

Nopeampi toiminta ja parannettu turvallisuus – näiden takia Kinsta tarjoaa aina PHP:n uusinta versiota. Voit vaihtaa PHP-versioiden välillä yhdellä painalluksella. 

Vaihda PHP-versiota

Vaihda PHP-versiota

Ja varo WordPress-isäntiä, jotka tarjoavat HHVM:ää PHP:n vaihtoehtona. HHVM ei enää ole sopiva ratkaisu WordPress-hostingin kannalta.

Valitse palveluntarjoaja, jolla on NGINX

Kulissien takana jokainen WordPress-isäntä käyttää internetpalvelinta WordPress-sivustojen pyörittämiseen. Tavallisimmat valinnat ovat NGINX ja Apache.

Me suosittelemme vahvasti valitsemaan isännän, joka käyttää NGINX-vaihtoehtoa, koska se on erikoistunut suorituskyvyn parantamiseen. NGINX päihittää usein muut palvelimet suorituskykytesteissä erityisesti tilanteissa, joissa sisältö on staattista ja yhtäaikaisia kävijöitä on paljon. Näiden syiden takia Kisnta käyttää NGINXiä.

Nginx

Kuuluisia yrityksiä, jotka käyttävät NGINXiä: Autodesk, Atlassian, Intuit, T-Mobile, GitLab, DuckDuckGo, Microsoft, IBM, Google, Adobe, Salesforce, VMWare, Xerox, LinkedIn, Cisco, Facebook, Target, Citrix Systems, Twitter, Apple, Intel ja paljon muita. (lähde)

W3Techsin mukaan Apache on taustalla 45,9% kaikista internetsivustoista, mikä tekee siitä kaikkein käytetyimmän vaihtoehdon. Mutta jos katsotaan suosituimpia sivustoja, joilla on paljon kävijöitä (top 10 000), NGINX pyörittää niistä 64,2%:a. Sitä käyttävät monet sivustot, jotka tarvitsevat erityisen paljon resursseja, kuten Netflix, NASA ja jopa WordPress.com.

Lue lisää web-palvelimen esityksestä: NGINX vs Apache.

Isäntäsi verkolla on merkitystä

Kun valitset WordPress-isäntää, sinulle ei ehkä tule edes mieleen kysyä tai tutkiä sitä, millainen verkko kenelläkin on käytössä. Verkolla voi kuitenkin olla valtava merkitys sivuston suorituskyvyn kohdalla – se voi jopa vaikuttaa siihen, kuinka nopeasti WordPress-hallintapaneelisi toimii. Moni hosting-palvelun tarjoaja jättää tämän pois markkinoinnistaan, koska he itse käyttävät halvinta mahdollista pitääkseen kulut alhaisina.

Tässä muutama kysymys, jotka kannattaa esittää:

  • Mitä verkkoa käytätte datan siirtämiseen? Kulkeeko siitä suuren osa juklisten ISP:iden kautta vai yksityisessä infratruktuurissa kuten Google tai Microsoft? Näillä suurilla palveluntarjoajilla on verkostoja, jotka on rakennettu ja optimoitu alhaisia viiveaikoja ja suurta nopeutta varten. Niillä on omat internetkaapelinsa meren alla!
  • Ovatko käytössä olevilla verkoilla vaihtoehtoratkaisuja? Mitä tapahtuu, jos kaapeli katkaistaan vahingossa? Tätä tapahtuu enemmän kuin luulisi.

Vuonna 2017 Google julkisti standard-mallisen verkkonsa, joka on hitaampi mutta edullisempi. Me Kinstalla käytämme heidän premium-verkkoaan kaikissa hosting-paketeissamme. Se maksaa meille enemmän mutta takaa teille salamannopeat latausajat.

Kinsta uses Google Cloud Platform's premium tier network. Because your websites deserve the best. ⚡ Click to Tweet

Googlen mukaan premium-verkko parantaa suorituskykyä vähentämällä matkustusaikaa julkisessa internetissä: paketit tulevat ja lähtevät Googlen verkosta mahdollisimman lähellä käyttäjää ja kulkevat pitkin Googlen selkärankaa ennen pääsyä VM:ään. Standard-verkko kuljettaa lähtevän liikenteen GCP:stä internetiin julkista reittiä (ISP) Googlen oman verkon sijaan.

Google Cloud Platform -verkko premium-tasolla

Google Cloud Platform -verkko premium-tasolla (Kuvalähde: Google)

Esitetään asia helpommin ymmärrettävässä muodossa:

  • Premium-verkon paketit kulkevat Googlen verkossa pidemmän matkan, joten ne hyppivät paikasta toiseen vähemmän ja suoriutuvat tehtävästään paremmin (mutta maksavat enemmän).
  • Standard-verkon paketit kulkevat Googlen verkossa pienempiä matkoja ja viettävät enemmän aikaa sinkoillessaan julkisessa verkossa paikasta toiseen, joten ne suoriutuvat tehtävästään heikommin (mutta maksavat vähemmän).

Paljonko tämä todellisuudessa vaikuttaa? No, maanosasta toiseen kulkevan data kohdalla premium-verkko toimii keskimäärin noin 41% nopeammin kuin standard-verkko. Samalla mantereella paikasta toiseen siirtyvä data kulkee premium-verkossa noin 8% nopeammin. Vaikka verkko vaikuttaa vain pieneen osaan sivuston kokonaislatausajasta, jokaisella millisekunnilla on merkitystä!

For data traveling across continents, Google Cloud's premium tier network is on average 41% faster! 💥 Click to Tweet

On myös tärkeää, että varalla on vaihtoehtoja, minkä takia Googlella on vähintään kolme itsenäistä polkua (N+2 redundancy) minkä tahansa kahden pisteen välillä Googlen verkossa. Näin varmistetaan, että datansiirto jatkuu sijaintien välillä myös ongelmatilanteissa.

Kuten varmasti jo arvaat, kulissien takana verkkoasioissa tapahtuu paljon. Varmista siis, että WordPress-isäntäsi käyttää hyvämaineista verkkoa eikä alhaisempia vaihtoehtoja pitääkseen kulut matalina.

HTTP/2 on pakollinen

HTTP/2 on vuonna 2015 julkaista internetprotokolla, jonka on tarkoitus nopeuttaa sivustojen toimitusta. Selaintuen takia se vaatii HTTPS:n (SSL). Jos WordPress-palveluntarjoajasi ei tue HTTP/2:a, sinun kannattaa vaihtaa parempaan. Koko internetin on muuttumassa HTTPS:ksi, joten tämä ei enää ole mukava lisäominaisuus – se on tarpeellinen ominaisuus.

HTTP/2 parantaa suorituskykyä monesta syystä kuten: multiplexing, parallelismi, HPACK-pakkaus Huffman-koodauksella, ALPN-laajennus ja palvelimen pusku. Aikaisemmin TLS tuotti ongelmia HTTPS:n kanssa, mutta sitä tapahtuu yhä vähemmän HTTP/2:n ja TLS 1.3:n ansiosta. Kinsta tukee HTTP / 2: ta ja TLS 1.3: ta kaikissa palvelimissamme ja CDN: ssä.

HTTP/2:lle on myös suuri voitto, ettei useimpien WordPress-sivustojen tarvitse enää huolehtia seuraavista: concatentation (tiedostojen yhdistäminen) tai domain sharding. Näitä optimointeja ei enää tarvita.

Valitse palvelin, joka on lähellä kävijöitä

Yksi ensimmäisistä asioista, jotka WordPress-hostingin tarjoajaa valitessa kannattaa tehdä, on määritellä, mistä suurin osa kävijöistä tai asiakkaista tulee. Miksi tämä on tärkeää? Koska sijainti, jossa sivustosi on, vaikuttaa suuresti viiveaikoihin ja TTFB:hen. Se vaikuttaa myös SFTP:n nopeuteen ja WordPress-hallintapaneelin responsiivisuuteen.

Verkon viiveajat: Tällä tarkoitetaan aikaa ja viivettä, joka datan siirton verkon yli kuluu. Toisin sanoen aika, jonka datapaketti kuluttaa siirtyessään paikasta toiseen. Nykyään tätä mitataan yleensä millisekunneissa, mutta se venyy helposti sekunneiksi verkosta riippuen. Mitä lähempänä se on nollaa, sitä parempi.

Lue lisää yksityiskohtaisesta artikkelistamme verkon viiveajoista.

TTFB: Tämä on lyhennelmä sanosita “time to first byte”. Yksinkertaisesti sanottuna sillä mitataan, kuinka kauan selaimen täytyy odottaa saadakseen ensimmäinen datatavu palvelimelta. Mitä kauemmin datan saamiseen menee, sitä kauemmin kestää, ennen kuin sivu on näkyvillä. Myös tässä mitä lähempänä luku on nollaa, sen parempi.

Lue lisää yksityiskohtaisesta artikkelistamme TTFB:stä.

Emme tylsistytä sinua tässä artikkelissa kaikilla teknisillä yksityiskohdilla. Tärkein, mitä sinun pitää tietää, on että viiveajan ja TTFB:n pitäisi olla mahdollisimman alhaisia. Yksi helpoimmista tavoista, joilla tähän pääsee, on valita palvelin mahdollisimman läheltä sivuston kävijöitä. Voit valita parhaan mahdollisen sijainnin seuraamalla alla olevia vinkkejä.

Vinkki 1 – Tarkista kävijöidesi maantieteellinen sijainti Google Analyticsistä

Yksi avian ensimmäisistä asioista, jotka kannattaa tehdä, on katsoa, mistä maantieteellisistä sijainneista kävijäsi tulevat. Näet tämän Google Analyticsistä kohdasta “Audience → Geo → Location.”

Alla olevassa esimerkissä näkyy, että yli 90% liikenteestä tulee Yhdysvalloista. Näin ollen yleisesti ottaen WordPress-sivusto kannattaa sijoittaa palvelimelle, joka sijaitsee Yhdysvalloissa. Dataa pystyy myös suodataamaan niin, että eri kaupungit erottuvat. Tämä on erityisen tärkeää paikallisille yrityksille. Mutta yleensä suorittelemme keskeistä sijaintia kuten Iowa, USA.

Google Analyticsin maantieteelliset sijaintitiedot

Google Analyticsin maantieteelliset sijaintitiedot

Vinkki 2 – Tarkistaa Ecommerce-data

Jos sinulla on verkkokauppa, varmista myös, mistä asiakkaasi tulevat. Tämä on loppujen lopuksi se, mistä saat tuloja, joten nämä ovat tärkeimmät sivustokävijät. Todennäköisesti data on samanlaista kuin yllä, mutta aina niin ei ole. Jos sinulla on eCommerce-data käytössäsi tai päämääriä Google Analyticsissä, saat asiakkaiden sijaintitiedot näkyviin ja voit niiden avulla tehdä parempia päätöksiä. Tai tarkista sijaintitiedot, jotka on tallennettu verkkokauppa-alustasi tietokantaan.

Vinkki 3 – Tee nopea viivetesti

On olemassa paljon käteviä työkaluja, joiden avulla voi mitata viivettä tämänhetkisestä sijainnista erilaisiin pilvipalvelujen tarjoajiin. Tämän avulla voit nopeasti päätellä, mikä aluea saattaisi olla paras vaihtoehto sivustollesi. 

  • GCP Ping (mittaa viivettä Google Cloud Platformin aluetietoihin Kinstan palvelimet mukaan lukien)
  • CloudPing.info (mittaa viivettä Amazon Web Servicesin aluetietoihin)
  • Azure Latency Test (mittaa viivettä Azuren aluetietoihin)

Alla olevasta esimerkistä näkyy, että Oregon, USA (us-west1) on nopein sieltä, missä olemme. Mutta jos asiakkaita on ympäri Yhdysvaltoja, saattaa olla parempi valita Iowa, USA (us-central1), jotta viiveajat ovat pieniä sekä itä- että länsirannikolta tuleville kävijöille. 

Mittaa Google Cloud Platformin viivnettä

Mittaa Google Cloud Platformin viivettä

Me Kinstalla tarjoamme 20 eri datakeskusta ympäri maapallon. Voit helpsti valita paikan, josta saat sekä alhaisen viiveen että alhaisen TTFB:n! Tämä auttaa myös vähentämään hyppäyksiä verkosta toiseen.

Google Cloudin datakeskusten sijainteja

Google Cloudin datakeskusten sijainteja

Muita tapoja vähentää viivettä ja TTFB:tä

Palvelimen valinnan lisäksi on muutamia tapoja, joilla viivettä voi vähentää.

  • Ota välimuistitallennus käyttöön WordPress-sivustollasi. Meidän testeissämme se vähensi TTGB:tä jopa 90%!
  • Käytä hyväksesi sisällönjakeluverkkoa (CDN) toimittaaksesi tietoja välimuisteistä POP-palvelimilta ympäri maailman. Näin vähennät veron viiveaikoja niiden osalta, jotka eivät ole lähelle palvelintasi.
  • Käytä HTTP/2-protokollaa minimoimaan pakettien ylimääräisen liikkumisen. http/2 on käytössä kaikilla Kinstan palvelimilla.
  • Vähennä ulkoisten HTTP-kyselyjen määrää. Jokaisella niistä saattaa olla oma lisäviiveaikansa palvelimen sijainnista riippuen.
  • DNS vaikuttaa TTGB:hen, joten kannattaa käyttää maksullista DNS-palveluntarjoajaa nopeaa toimintaa varten.
  • Käytä prefetch- ja prerender-toimintoja suorittamaan tehtäviä kulissien takana samalla, kun sivu latautuu.

Älä huoli: käymme kaikki yllä olevat suositukset yksityiskohtaisemmin läpi alempana tässä artikkelissa.

SFTP-nopeudet ja WordPressin järjestelmähallitsijan hallintapaneeli

Niiden, jotka käyvät sivustollasi ja ovat asiakkaitasi, tulisi aina olla tärkeimpiä. Mutta toinen suorituskykyyn liittyvä seikka on, että jotkut näistä päätöksistä saattavat vaikuttaa jokapäiväiseen työhön. Datakeskuksen sijainti vaikuttaa SFTP-latausaikoihin (tiedostojen siirtämiseen FTP:n avulla) sekä WordPress-hallintapaneelin responsiivisuuteen.

Joten vaikka haluat käyttää palvelinta, joka on mahdollisimman lähellä käyttäjiäsi, pidä mielessä myös, että se vaikuttaa sivuston hallintatoimiin. Toimet kuten tiedostojen tallentaminen WordPressin mediakirjastoon käyvät nopeammin, jos sivuston palvelin on datakeskuksessa lähellä sinua. 

Kuulemme Kinstan asiakkailta usein, että he ovat yllättyneitä siitä, kuinka paljon nopeammin heidän hallintapaneelinsa toimii meidän palvelimellamme. On monta tekijää, jotka vaikuttavat tähän, mutta yksi tärkeä on se, että meillä on 20 er datakeskusta! Valitse sijainti, joka hyödyttää sekä asiakkaitasi että sinua itseäsi! Loppujen lopuksi sinä olet se, joka saattaa käyttää tuhansia työtunteja sivuston parissa.

Maksullinen DNS on parempi kuin ilmainen DNS

DNS, lyhenne sanoista Domain Name System, on yksi netin tavallisimmista internetin komponenteista, mutta se ymmärretään usein väärin. Yksinkertaistettuna DNS auttaa ohjaamaan liikennettä internetissä yhdistämällä domain-nimet ja oikeat palvelimet. Periaatteessa DNS ottaa ihmisystävällisen kyselyn – domain-nimen kuten kinsta.com – ja kääntää sen tietokoneystävälliseksi IP-osoitteeksi – kuten 216.58.217.206.

Kuin DNS toimii

Kuin DNS toimii

On olemassa sekä ilmaisia että maksullisia DNS:iä. Kaikki Kinstan asiakkaat saavat käyttöönsä maksullisen DNS:n Amazon Route 53:n kautta. Ylipäätään uskomme, että maksullinen DNS on tarpeellinen nykymaailmassa.

Yksi suuri syy maksullisen DNS:n valintaan on nopeus ja luotettavuus. DNS-tietueiden tarkistaminen ja liikenteen ohjaaminen vie aikaa, vaikka kyse olisikin millisekunneista. 

Tavallisesti ilmainen DNS, jonka domain-palveluntarjoaja antaa, on verraten hidas, kun taas maksullinen DNS tarjoaa parempaa suorituskykyä. Esimerkiksi testeissämme kävi ilmi, että ilmainen NameCheapin DNS oli 33% hitaampi kuin Amazon Route 53 -niminen maksullinen DNS. Lisäksi maksullinen DNS tarjoaa usein parempaa turvallisuutta ja saatavuutta, erityisesti silloin, kun sivuston on DDoS-hyökkäyksen kohteena. 

Voit käyttää työkalua kuten SolveDNS speed test tarkistaaksesi, kuinka nopea DNS sinulla on. DNSPerf tarjoaa myös erinomaista data parhaista DNS-tarjoajista. 

Hyvä vaihtoehto on myös Cloudflare DNS, eräänlainen välimuoto ilmaisen ja maksullisen DNS:n välillä. Se on ilmainen palvelu, jonka kautta saa paljon maksullisen DNS:n etuja. Ja se on erittäin nopea – vastausaika alle 20 ms ympäri maailman (kuten alla näkyy). 

Cloudflaren ilmaisen DNS:n nopeustesti

Cloudflaren ilmaisen DNS:n nopeustesti

Yksi ongelma Cloudflarella kuitenkin on: se on usein alhaalla verrattuna moniin muihin palveluntarjoajiin. Jos kävijäsi ovat yleensä Yhdysvalloissa, DNS Made Easy on maksullinen DNS-palvelu, johon haluat ehkä tutustua. He ovat tunnettuja siitä, että heidän DNS-palvelunsa ei ole viimeisen kymmenen vuoden aikana käynyt alhaalla juuri ollenkaan muihin verrattuna. 

DNSPerf näyttää, että viimeisen 30 päivän aikana eri DNS-palveluntarjoajat ovat olleet pysyneet ylhäällä seuraavia aikamääriä:

Merkitsevätkö alhaallaoloajat todella niin paljon DNS-tarjoajille? Vastaus on sekä kyllä että ei. DNS yleensä tallennetaan ISP:n avulla välimuistiin käyttäen “time to live value” (TTL) -arvoa DNS-tietueessa. Näin olleen jos DNS-tarjoaja kaatuu 10 minuutiksi, tuskin tulet huomaamaan sitä. Alhaallaoloajat käyvät merkityksellisiksi silloin, kun palveluntarjoaja on alhaalla usein tai pitkiä aikoja, tai jos ISP- ja DNS-tietueet käyttävät todella alhaisia TTL-arvoja. 

WordPress-teemalla on merkitystä

Kaikki rakastavat upouusia WordPress-teemoja, mutta ole varovainen ennen kuin menet ja nappaat sen, jossa on kaikki uudet ihmeellisyydet. Ensin kannattaa lukea artikkelimme ilmaisten ja maksullisten teemojen eroista. Suorituskyvyn kannalta teeman jokainen elementti vaikuttaa jossain määrin sivuston koko nopeuteen. Ja valitettavasti, koska teemoja on tuhansia, niitä löytyy sekä hyviä että huonoja.

Your WordPress theme matters for performance. Choose the right one from the start. 💪 Click to Tweet

Joten kuinka sinun tulisi tietää, mikä niistä kannattaa valita? Me suosittelemme jompaakumpaa vaihtoehtoa:

  • Nopea ja kevyt WordPress-teema, jossa on vain tarvitsemasi ominaisuudet – ei mitään muuta
  • Ominaisuuksiltaan rikkaampi WordPress-teema, josta voit ottaa pois käytöstä ne ominaisuudet, joita et käytä

Asiat kuiten Google Fonts, Font Awesome -ikonit, sliderit, galleriat, videot, parallax-skriptit jne. Nämä ovat esimerkkejä asioista, jotka sinun tulisi voida ottaa pois päältä, jos et tarvitse niitä. Et halua yrittää tehdä näihin manuaalisesti muutoksia jälkikäteen. Me emme esittele 50 eri tapaa vähentää turhien määrää. Sen sijaan sinun kannattaa vaihtaa WordPress-teemaan, joka on joko alun perinkin kevytkäyttöinen tai jossa on nämä vaihtoehdot.

Alla on muutama WordPress-teema, joita suosittelemme ja joiden kanssa et voi mennä vikaan! Luota meihin, kiität meitä myöhemmin. 😉

Kukin tässä mainituista teemoista on täysin yhteensopiva WooCommercen ja Easy Digital Downloadsin, WPML:n, BuddyPressin ja bbPressin kanssa. Teemme pari nopeustestiä käyttäen alla olevaa konfiguraatiota:

  • Kinstam palvelimella, käytössä WordPress 4.9.8j
  • PHP 7.3 ja SSL (HTTPS)
  • Kinstan CDN
  • Imagify käytössä kuvien automaattista pakkausta varten.

GeneratePress

GeneratePress on nopea, kevyt (alle 1MB pakattuna), responsiivinen WordPress-teema, joka on rakennettu nopeutta, SEO:ta ja käytettävyyttä silmällä pitäen. Sen on tehnyt Tom Usborne, kanadalainen sovelluskehittäjä. Sitä päivitetään ja tuetaan aktiivisesti. Jopa jotkut Kinstan työntekijöistä käyttävät GeneratePressiä projekteissaan.

GeneratePressistä on olemassa sekä ilmainen että maksullinen versio. Jos katsot WordPressin hakemistoa, ilmaisversiolla on yli 100 000 aktiivista asennusta, 1,6+ miljoonaa latausta ja viisi tähteä viidestä (yli 700 käyttäjää on antanut sille 5 tähteä).

GeneratePress

GeneratePress

Yksi GeneratePressin hienouksista on, että sen kaikki asetukset tukevat alkuperäistä WordPess Customizeria, eli pystyt näkemään muukset heti – ennen julkaisunappulan painamista. Tämä tarkoittaa, ettei sinun tarvitse opetella käyttämään uutta hallintapaneelia.

Kuinka nopea se oikein on? Asensimme GeneratePressin tuoreeltaan, teimme viisi nopeustestiä Pingdomissa ja laskimme keskiarvon. Kokonaislatausaika oli 305 ms ja kokonaissivukoko vain 16,8 KB. On aina hyvä tehdä baseline-testi, jotta nähdään, millaiseen suorituskykyyn teema kykenee.

GeneratePressin tuoreen asennuksen nopeustesti

GeneratePressin tuoreen asennuksenl nopeustesti

Suoritimme sitten toisen koesetin käyttäen yhtä GeneratePress-kirjaston valmiista teemoista. Tähän sisältyi kuvia, taustavärejä, uusia osioita jne. Yksi GeneratePressin hyvistä puolista on, että sillä on paljon valmiita teemoja, jotka eivät vaadi sivunrakennuslisäosaa. Kuten näkyy, aikaa kesti silti alle 400 ms.

GeneratePressin täyden sivuston nopeustesti

GeneratePress full website speed test

Tosielämässä toki sivustolla pyörii muitakin nopeuteen vaikuttavia tekijöitä kuten esimerkiksi Google Analytics, Facebook-markkinointipikseli, Hotjar, jne. Mutta sinun pitäisi alittaa yksi sekunti latausajoissa helposti. Lue lisää yksityiskohtaisesta GeneratePress-arvostelustamme woorkupilla.

Alla näytämme lisää tapoja, joilla WordPressiä voi nopeuttaa ja optimoida.

OceanWP

OceanWP-teema on kevyt ja helposti laajennettava, ja sen avulla pystyy luomaan melkein minkätyyppisen sivuston tahansa – esimerkiksi blogin, portfolion, yrityssivuston tai WooCommerce-verkkokaupan, joka näyttää kauniilta ja ammattimaiselta. Sen on rakentanut Nicolas Lecocq, ja sitäkin päivitetään ja tuetaan aktiivisesti.

Ja kuten GeneratePressillä, myös OceanWP:llä on tarjolla sekä ilmainen että maksullinen versio. Ilmaisversiolla WordPress-hakemistossa on yli 200 000 aktiivista asennusta ja sama viiden tähden rating (yli 1 200 käyttäjää on antanut sille viisi tähteä).

OceanWP-teema

OceanWP-teema

Ja kuinka nopea se oikeastaan on? Asensimme OceanWP:stä tuoreen version, ajoimme viisi testiä Pingdomissa ja laskimem keskiarvon. Kokonaislatausaika oli 389 ms ja sivun koko vain 230,8 KB. OceanWP:n skriptit olivat hieman suurempia, mutta mitään merkittävää ei löytynyt.

OceanWP:n tuoreen asennuksen nopeustesti

OceanWP:n tuoreen asennuksen nopeustesti

Ajoimme uusia testejä käyttäen yhtä OceanWP-kirjaston demoteemoista. Siihen sisältyi kuvia, taustavärejä, uusia osioita. Se myös vaati Elementor-sivurakennustyökalun käytön. Kuten alla näkyy, aikaa kului silti alle 600 ms.

OceanWP:n täyden sivuston nopeustesti

OceanWP:n täyden sivuston nopeustesti

Lisätietoja löytyy blogistamme: OceanWP-arvostelu.

Astra

Astra on nopea ja kaunis teema, jonka voi täysin kustomoida. Se sopii blogeihin, henkilökohtaisiin blogeihin, yrityssivustoille ja WooCommerce-verkkokauppoihin. Se on erittäin kevyt (alle 50 KB frontend-puolella) ja tarjoaa todellista nopeutta. Sen on rakentanut Brainstorm Forcen tiimi ja sitä tuetaan ja ylläpidetään jatkuvasti. Saatat tunnistaa kehittäjät siitä, että he ovat tehneet myös suositun All In One Schema Rich Snippets -lisäosan, joka on ollut olemassa jo vuosia.

Kuten GeneratePress ja OceanWP, Astra tarjoaa sekä ilmaista että maksullista versiota. Jos katsot WordPress-hakemistoa, ilmaisversiolla on tällä hetkellä yli 100 000 asennusta, 1,6+ miljoonaa latausta ja viisi tähteä viidestä (yli 850 käyttäjää on antanut sille viisi tähteä).

Astran WordPress-teema

Astran WordPress-teema

Kuinka nopea se oikein on? Me otimme Astran tuoreen asennuksen, teimme viisi testiä Pingdomissa ja laskimme keskiarvon. Kokonaislatausaika oli 243 ms ja kokonaissivukoko vain 26m6 KB.

Astran tuoreen asennuksen nopeustesti

Astran tuoreen asennuksen nopeustesti

Teimme sitten toiset testit yhdellä Astran Starter kit -pakettiin kuuluvalla demoteemalla. Siihen sisältyy kuvia, taustaväri, uusia osioita ja vaadittu Elementor-sivunrakennuslisäosa. Kuten alla näkyy, aikaa kului silti alle 700 ms. Huomio: Demoversion kuvat oli täysin pakattu, mutta ne olivat korkean resoluution kuvia alun perinkin.

Astran täyden sivuston nopeustesti

Astran täyden sivuston nopeustesti

On tärkeää pitää mielessä, etteivät nämä nopeustestit eri teemojen välillä välttämättä kerro koko totuutta. Ongelma on se, että on lähes mahdotonta tehdä täysin vertailukelpoisia testejä. Halusimme kuitenkin osoittaa tärkeimmän eli sen, että kaikki nämä WordPress-teemat ovat erittäin nopeita – sekä perusversiot että täydet demot! 🚀

Varoituksen sana sivurakentajista

Kuten ehkä huomasit, sekä OceanWP että Astra vaativat sivurakennustyökalun teemoissaan. Tässä muutama asia, jotka kannattaa pitää mielessä sivurakennuslisäosaa käyttäessä:

  • Jotkin sivurakentajat saattavat lisätä sivuston latausaikaa. Tämä johtuu siitä, että ne joutuvat lataamaan ylimääräistä CSS:ää ja JS:ää toimiakseen ilman koodia. Näin kaikki hieno tapahtuu! Me suosittelemme tekemään nopeustestejä WordPress-sivustolla aina ennen ja jälkeen lisäosan asentamisen.
  • Joudut sitoutumaan valitsemasi sivurakentajan muotoiluun. Varmista, että valitsemaasi lisäosaa päivitetään jatkuvasti ja että se sisältää kaiken, mitä pitkällä tähtäimellä tarvitset. 

Nyt, kun tuo on sanottu, on jatkettava, että pidämme kovasti sivurakentajista kuten Elementor ja Beaver Builder. Ne on suurimmaksi osaksi rakennettu suorituskyky edellä ja heikentävät sivun toimivuutta vain pikkuisen. Suurin osa käyttäjistä kokee, että käytettävyys on sen arvoista, sillä näiden lisäosien avulla voit luoda suurin piirtein mitä vain! Ne saattavat myös käydä kevyemmiksi kuin 5+ muuta lisäosaa, joita saattaisit muussa tapauksessa joutua käyttämään.

Mutta jos et tarvitse sivurakennuslisäosaa, älä asenna sellaista turhaan. Tulee myös olemaan mielenkiintoista nähdä, miten uusi Gutenberg-editori tulee vaikuttamaan sivujen suunnitteluun seuraavien parin vuoden aikana.

WordPress-lisäosien tärkeimmät asiat

Nyt se kaikkein tärkein WordPress-lisäosista. Olet ehkä kuullut, että liian monen lisäosan asentaminen hidastaa sivustoa. Tämä on toisinaan totta, mutta se ei ole kaikkein kriittisin tekijä. Lisäosien määrä ei ole yhtä tärkeää kuin niiden laatu. Saimmepahan tuonkin sanottua. 😜

Kuten teemojenkin kohdalla, lisäosien merkitys määräytyy sen mukaan, miten se on kehitetty ja onko sen suorituskykyyn kiinnitetty erityistä huomiota. Kinstalla on monta asiakasta, joiden sivuilla on 30-40 lisäosaa ja heidän sivustonsa latautuvat silti alle sekunnissa.

Vaikka koodin lisääminen sivustolle on kivaa, se ei aina ole seuraavista syistä käytännöllistä:

  1. Sinun täytyy ylläpitää koodia itse ja päivittää sitä, kun muutoksia tapahtuu. Ihmiset ovat kiireisiä – mikset luottaisi fantastisiin ammattilaisiin, jotka tuntevat standardit ja niiden muutokset parhaiten?
  2. Useimmiten hyvin koodattu lisäosa ei hidasta sivua sen enempää kuin pelkkä koodikaan. 
  3. Tulee muistaa, ettei suurin osa WordPress-yhteisöstä ole teknisesti yhtä taitavaa kuin ohjelmistokehittäjät. Lisäosat ovat ratkaisuja ongelmiin.

On toki olemassa lisäosia, jotka eivät ole kehuttavia – ja niistä sinun kannattaa pysyä kaukana. Usko meitä: olemme nähneet Kinstalla todella pahoja tapauksia. Moni, muttei kaikki, kielletyistä lisäosista Kinstalla on sellaisia, joiden olemme todenneet aiheuttavan pahoja ongelmia. Me kerromme näistäkin lisää alempana. 

Ei kuitenkaan ole merkityksetöntä, että yksi WordPressin suosituimmista ominaisuuksista on sen massiivinen lisäosakirjasto. Mutta koska ilmaisia lisäosia on pelkästään WordPress.org-sivustolla 56 000+ ja tuhansia ympäri internetiä, on vaikea löytää juuri sitä, minkä tarvitset. Oikea neula heinäsuovassa! Vilkaise listaamme markkinoiden parhaista WordPress-lisäosista.

Me pyrimme jakamaan vain sellaisia, joita itse käytämme päivittäin. Ja kyllä, me käytämme WordPress-lisäosia sivustollamme kuten kaikki tekin. Monet Kinstan työntekijät jopa kehittävät ja myyvät lisäosia. 

Yksi suuri ongelma WordPress-lisäosien kanssa

WordPress-lisäosien suuri ongelma on asennuksen poistoprosessi. Aina, kun asennat WordPress-lisäosan tai -teeman, dataa tallennetaan tietokantaan. Ongelma on, että kun lisäosa poistetaan tavallisen prosessin avulla, se usein jättää turhaa dataa jälkeensä. Ajan mittaan tämä saattaa jopa alkaa hidastaa sivustoasi. Esimerkissämme poistimme Wordfence-turvallisuuslisäosan asennuksen, ja se jätti jälkeensä 24 taulukkoa. Vielä pahempaa on, jos dataa jää wp_options-taulukkoon.

WordFence-taulukoita

WordFence-taulukoita

Ja tietokannan lisäksi moni lisäosa jättää jälkeensä myös turhia kansioita ja tiedostoja. Meidän kokemuksemme mukaan näin käy erityisesti turvallisuus- ja välimuistitallennuslisäosien kohdalla, sillä ne luovat omia logejaan. Esimerkiksi Wordfence-lisäosan poistamisen jälkeen meille jäi kansio nimeltä “wflogs” wp-content-hakemistoon. Emmekä yritä kiusata Wordfenceä – suurin osa markkinoiden lisäosista ja teemoista toimii tällä tavalla.

WordFencen logeja

WordFencen logeja

Miksi kehittäjät tekevät näin?

Mietit varmaan – mikseivät kehittäjät luo siivousmetodeja, joiden avulla lisäosien poistaminen olisi helppoa? Kyllä niinkin tehdään. Mutta tässä pari syytä mikseivät ne ehkä ole ilmiselviä.

  1. He haluavat säilyttää käyttäjien asetukset. Jos poistat WordPress-lisäosan ja päätät kokeilla sitä uudelleen myöhemmin, kaikki asetukset ja data löytyvät uudestaan. Tämä on todella kätevää muttei kaikkein tehokkainta.
  2. He eivät välitä suorituskyvystä. Jotkut kehittäjät saattavat väittää, etteivät ylimääräiset taulukot vaikuta suorituskykyyn. Mutta kuvittele, mitä sivustolle tapahtuu vaikka kymmenen vuoden aikana, kun sillä on käytetty satoja lisäosia, jotka ovat saattaneet luoda tuhansia rivejä tai taulukoita. Tietokantakyselyt vaikuttavat WordPress-sivuston suorituskykyyn, ja lisäosat saattavat joissain tapauksissa tehdä näitä kyselyjä paljon. Yleisesti ottaen hyvin tehty lisäosa suorittaa kyselyjä ainoastaan taulukoissa ja riveillä, joihin se on sidottu, mutta näin ei aina ole. Olemme nähneet Kinstalla, kuinka pitkät kyselyt hidastavat sivuston toimintaa siksi, että wp_options-taulukkoon on automaattisesti tallennettu turhaa dataa.
  3. He tekivät virheen. WordPress-lisäosien käsikirja jopa sanoo, että “kokemattomat ohjelmistokehittäjät joskus käyttävät niin sanottua deactivation hookia”. 
  4. even says that “less experienced developers sometimes make the mistake of using the deactivation hook for this purpose.”

Hyvät uutiset? On olemassa tapoja puhdistaa tiedostoja ja hävittää lisäosa kunnolla. 👏 Lue lisää seuraavista tutoriaaleista:

Vaihda WordPressin sisäänkirjautumisosoite

Puhutaanpa seuraavaksi optimaalisista WordPess-asetuksista. Tässä on pari muutosta, joiden tekeminen voi auttaa nopeuttamaan WordPress-sivustoasi. Moni näistä on pieni muutos, mutta kaikki lasketaan!

Vaihda WordPressin sisäänkirjautumisosoite

Oletusasetuksena URL, josta kirjaudut WordPress-sivustollesi sisään, on domain.com/wp-admin/. Yksi tämän ongelmista on, että kaikki botit, hakkerit ja skriptit tietävät tämän. URL:ää vaihtamalla saat tehtyä itsestäsi näkymättömämmän ja vähentää kaistaa, jota tätä osoitetta käyttävät botit muuten vievät.

WordPress-sisäänkirjautumisosoitteen vaihtaminen voi myös vähentää virheilmoituksia kuten “429 Too Many Requests”. Kaikkea tämä ei korjaa, mutta se on yksi pieni temppu, jonka avulla voit suojella itseäsi ja vähentää sivuston kuormitusta. 

WordPress-sisäänkirjautumisosoitteen muuttamiseen suosittelemme seuraavia lisäosia:

  • WPS Hide Login (ilmainen)
  • Perfmatters (maksullinen, mutta sisältää myös muita suorituskykyoptimoiteja. Luonut Kinstan työntekijä)
WordPress-sisäänkirjautumisosoitteen muuttaminen Perfmattersilla

WordPress-sisäänkirjautumisosoitteen muuttaminen Perfmattersilla

Ota pois käytöstä tai tee muutoksia lisäosien ja teemojen päivityksiin

Hidas WordPress-hallintapaneeli saattaa johtua verkosta, datakeskuksen sijainnista ja jopa käytössä olevasta PHP-versiosta. Mutta monesti ihmiset eivät tule ajatelleeksi, että siihen vaikuttaa myös WordPressin päivitysohjelma, joka pyörii taustalla. Tässä tilanteessa se, jos lisäosia ja teemoja on paljon, saattaa haitata suorituskykyä. WeForsterilla on asiasta erinomainen kirjoitus, jossa he käyttävät asiasta sanontaa “Third Party Plugin Update Check Syndrome” eli TPPUCS.

Ongelma on pohjimmiltaan se, että sisäänrakennettu WordPressin päivitysohjelma tekee ulkoisen GET-kyselyn kulissien takana (https://third-party-plugin/update-check.php). oskus se tekee näin silloin tällöin ja joskus eriättin usein. Jos näin käy jatkuvasti, se saattaa hidastaa hallintapaneelia huomattavasti.

Ongelma liittyy siihen, miten WordPressin päivitysohjelma on rakennettu. Jos hallintapaneelisi hitaus aiheuttaa ongelmia, voit kokeilla tätä. Lääke ongelmaan on automaattisten päivitysten ottaminen pois päältä. Varoitus: Tee tämä vain, jos aiot päivittää ohjelman manuaalisesti. Moniin päivityksiin sisältyy turvallisuuspäivityksiä ja muita korjauksia.

Päivitysten ottamiseen pois päältä suosittelemme jompaakumpaa näistä lisäosista:

Voit asettaa muistutuksen kalenteriin, ottaa lisäosan pois käytöstä kerran viikossa, tehdä päivitykset ja ottaa se takaisin käyttöön.

Ota pingbackit pois käytöstä

Pingback on automaattinen kommentti, jonka kone luo silloin, kun toisesta blogista tehdään linkki sivustollesi. Kun luot linkin artikkeliin, joka on omassa blogissasi, tätä kutsutan self-pingbackiksi. 

Suosittelemme yksinkertaisesti ottamaan nämä pois päältä, sillä ne luovat turhia kyselyjä ja ylimääräistä spämmiä sivustollesi. Muista: mitä vähemmän kutsuja WordPress-sivustosi joutuu tekemään, sen parempi, erityisesti suuren liikenteen sivustoilla. Puhumattakaan siitä, että itse-pingback on todella ärsyttävä. Alla ohjeet, joita seuraamalla pingbackit voi ottaa pois käytöstä.

Askel 1 – Ota pingbackit muilta sivustoilta pois käytöstä

WordPress-hallintapaneelista paina “Settings → Discussion”. Asetuksista ota pois päältä vaihtoehto “Allow link notifications from other blogs (pingbacks and trackbacks) on new articles”.

Ota pingbackit pois käytöstä WordPressissä

Ota pingbackit pois käytöstä WordPressissä

Askel 2 – Ota self-pingbackit pois käytöstä

Self-pingbackien poistamisessa käytöstä on pari eri vaihtoehtoa. Voit käyttää ilmaista No Self Pings -lisäosaa. Tai voit käyttää maksullista lisäosaa kuten Perfmatters.

Ota self-pingbackit pois käytöstä Perfmattersin avulla

Ota self-pingbackit pois käytöstä Perfmattersin avulla

Tai sitten voit ottaa self-pingbackit pois käytöstä lisäämällä alla olevan koodin WordPress-teemasi functions.php-tiedostoon. Varoitus: WordPress-teeman koodin muuttaminen voi rikkoa sivuston, jos sen tekee väärin. Vinkki: Voit helposti lisätä tämän kaltaisi PHP-paloja ilmaisella Code Snippets -lisäosalla. Näin sinun ei tarvitse koskea teemaasi.

function wpsites_disable_self_pingbacks( &$links ) {
  foreach ( $links as $l => $link )
        if ( 0 === strpos( $link, get_option( 'home' ) ) )
            unset($links[$l]);
}

add_action( 'pre_ping', 'wpsites_disable_self_pingbacks' );

Rajoita feedissäsi näkyvien postausten määrää

Oli blogisyötteesi sitten kotisivu tai joku sivustosi toinen sivu, et tarvitse 50 pikkukuvaa lataamaan yhtä aikaa. Niille, joilla on korkean liikenteen sivusto, kotisivu on kaikkein tärkein sivu ja sen on latauduttava nopeasti. Mitä vähemmän kyselyjä ja mediaa sivulla on, sitä parempi suorituskyky.

Ja juuri tätä varten keksittiin pagination (kuten alla näkyy). Pagination on se, mitä näkyy blogisyötteen alla – se, minkä avulla pääsee seuraavalle sivulle. Yleensä ne ovat numeroita tai ”edellinen/seuraava” -postauksia. WordPress-teemassasi on todennäköisesti jonkinlainen pagination sisäänrakennettuna.

Pagination

Pagination

Oletusasetuksena tuoreissa WordPress-sivustoissa raja on 10, mutta olemme nähneet tämän muutettuna lukemattomia kertoja. Kannattaa siis tarkistaa, mikä arvo on käytössä. Suosittelemme jotain kahdeksan ja kahdentoista väliltä. Jos olet utelias, Kinstan blogin kotisivu käyttää kahtatoista.

Löydät tämän vaihtoehdon WordPress-hallintapaneelista kohdasta “Settings → Reading”. Voit vaihtaa “Blog pages show at most” -kohdan arvoa.

Rajoita syötteen määrää WordPressissä

Rajoita syötteen määrää WordPressissä

Miksi välimuisti on niin tärkeä

Välimuistin käyttö on ehdottomasti tärkeimpiä ja helpoimpia tapoja nopeuttaa WordPressin toimintaa! Mutta ennen kuin näytämme, miten sitä kannattaa käyttää, on ensin tärkeää ymmärtää, miten se toimii ja mitä eri vaihtoehtoja on tarjolla.

Mikä on välimuisti?

Lyhyesti sanottuna jokainen sivu, jolla WordPress-sivustollasi käydään, vaatii kyselyn palvelimelle, prosessoinnin (mukaan lukien tietokantakyselyt) ja lopullisen tuloksen lähettämisen palvelimelta käyttäjän selaimeen. Tulos on sivustosi kaikkine tiedostoineen ja elementteineen, joiden takia se näkyy haluamallasi tavalla. 

Sinulla saattaa esimerkiksi olla header, kuvia, navigointimenu ja blogi. Koska palvelimen on käsiteltävä kaikki nuo kyseltyt, kestää hetken, ennen kuin koko sivusto on saatu toimitettua käyttäjälle – erityisesti, kun kyseessä on kömpelö tai kookas sivusto. 

Tässä WordPressin välimuistitallennusta varten tehty lisäosa astuu kuvaan! Välimuistitallennus eli caching neuvoo palvelinta säilömään osan tiedostoista tallennuslevylle tai RAM-muistiin konfiguraatiosta riippuen. Näin ollen se muistaa ja toistaa saman sisällön, jota se on jakanut aikaisemmin. Periaatteessa se vähentää työtä, joka sivun näyttämiseen vaaditaan. Tuloksena on, että sivusto latavutuu nopeammin, suoraan välimuistista.

Välimuistitallennuksen muita etuja:

  • Palvelin kuluttaa vähemmän resursseja – Tämä vaikuttaa nopeuteen, koska mitä vähemmän resursseja, sitä nopeampi sivusto. Sen lisäksi palvelimesi kuormitus on kevyempi. Se kannattaa muistaa erittäin dynaamisilla sivuistoilla kuten jäsensivustoilla sekä päätettäessä, mitä välimuistista voidaan jakaa ja mitä ei.
  • Matalampi TTFB – Välimuistitallennus on yksi helpoimmista tavoista laskea TTFB:tä. Itse asiassa testimme näyttävät, että välimuistitallennus voi alentaa TTGB:tä jopa 90%!

Erilaisia välimuistitallenuksen muotoja

On olemassa kaksi tyypillistä lähestymistapaa välimuistitallennukseen:

  1. Palvelintason välimuistitallennus
  2. Välimuistitallennus lisäosalla

1. Palvelintason välimuistitallennus

Palvelintason välimuistitallennus on ehdottomasti yksi loppukäyttäjän kannalta helpoimmista lähestymistavoista. Se tarkoittaa, että WordPress-hostingin tarjoaja hoitaa kaiken puolestasi. Kinstalla me käytämme seuraavia neljää välimuistitallennusmuotoa, jotka kaikki tehdään automaattisesti palvelintasolla:

Tämä tarkoittaa, ettei sinun tarvitse sotkeentua monimutkaisiin välimuistitallennuksen lisäosiin. Sinun ei tarvitse enää googlata “vuoden 2019 parhaat välimuistitallennuksen lisäosat” ja voit keskittyä tuottavampiin tehtäviin. 👏

Sivuvälimuisti on konfiguroitu toimimaan automaattisesti tavallisessa WordPressissä. Sinun ei tarvitse tehdä mitään! Käynnistä WordPress-sivusto ja sivuvälimuistitallennus vain tapahtuu.

Sivuvälimuisti on konfiguroitu toimimaan automaattisesti tavallisessa WordPressissä. Sinun ei tarvitse tehdä mitään! Käynnistä WordPress-sivusto ja sivuvälimuistitallennus vain tapahtuu.
Meillä ei ole välimuistitallennussääntöjä verkkokauppasivustoja kuten WooCommerce tai Easy Digital Downloads varten. Oletusasetuksena sivuja, joita ei koskaan kannattaisi tallentaa välimuistiin, kuten ostoskoria, omaa tiliä, checkout-sivu, ei tallenneta välimusitin. Käyttäjät välttävät välimuistitallennuksen automaattisesti, kun woocommerce_items_in_cart -eväste tai edd_items_in_cart huomataan, jotta checkout-sujuu mahdollisimman sujuvasti.

Voit tyhjentää WordPress-sivuston välimusitin helposti milloin tahansa järjestelmählalitsijan työkalupalkista.

Tyhjennä WordPressin välimuisti työkalupalkista

Tyhjennä WordPressin välimuisti työkalupalkista

Se on integroitu myös MyKinsta-hallintapneeliin. Valitse “Tools” ja paina “Clear Cache”.

Tyhjennä WordPressin sivuvälimuisti

Tyhjennä WordPressin sivuvälimuisti

2. Välimuistitallennus lisäosalla

Jos hosting-isäntäsi ei tarjoa välimustitallennusta, voit käyttää kolmannen osapuolen WordPress-välimuistitallennuslisäosaa. Kokemuksemme perusteella suosittelemme seuraavia:

  1. WP Rocket (maksullinen)
  2. Cache Enabler (ilmainen)
  3. W3 Total Cache (ilmainen)

Lisävaihtoehtoja löytyy yksityiskohtaisesta artikkelistamme WordPress-välimuistitallennuksen lisäosista.

Me myös tuemme WP Rocketia Kinstalla! Yleensä emme salli välimuistitallennuksen lisäosia ympäristössämme, koska ne saattavat aiheuttaa yhteensopivuusongelmia sisäänrakennetun välimuistiratkaisumme kanssa. WP Rocketin välimuistitallennus versiosta 3.0 lähtien kuitenkin otetaan automaattisesti pois päältä, kun se pyörii Kinstan palvelimella.

Näin Kinstan asiakkaat voivat käyttää nopeaa palvelintason välimuistitallennusta ja hyödyntää samalla kaikkia optimointiominaisuuksia, joita WP Rocket tarjoaa.

Ei välimuistitallennusta vs. välimuistitallennus

Kuinka paljon välimuistitallennus auttaa? Tiedämme kokemuksesta. 

Teimme muutaman testin Kinstan palvelintason välimuistitallennuksella, jotta näet sen tuomat erot sekä kokonaisnopeuden että TTFB:n kohdalla.

Ei välimuistitallennusta

Ajoimme viisi testiä Pingodmissa ilman välimuistitallennusta ja laskimme keskiarvon.

Nopeustesti ilman välimuistia

Nopeustesti ilman välimuistia

TTFB ilman välimuistia

On tärkeää huomata TTFB:n ero välimuistilla ja ilman. TTFB näkyy Pingdomissa keltaisena odotuspalkkina. Kutan alla näkyy, ilman välimustitallennusta TTFB on 192 ms. Välimuistitallennuksen puute näkyy kohdassa x-kinsta-cache, jossa sen arvo on MISS.

TTFB ilman välimuistia

TTFB ilman välimuistia

Välimuistitallennuksella

Otimme palvelintason välimuistitallennuksen käyttöö, teimme Pingdomissa viisi testiä ja laskimme keskiarvon.

Nopeustesti välimuistitallennuksella

Nopeustesti välimuistitallennuksella

Kuten näkyy, palvelintason välimuistitallennus vähensi sivun latausaikaa 33,7%! Eikä se vaatinut ylimääräistä työtä. Sivusto, jota tstasimme, on jo optimoitu melko hyvin, joten isommilla sivustoilla vaikka optimointeja näkyy todennäköisesti paljon suurempi ero.

TTFB välimuistitallennuksella

Kuten alla näkyy, TTFB välimuistitallennuksella on alle 35 ms. Välimuistitallennus näkyy siinä, että kohta x-kinsta-cache saa arvon HIT.

TTFB välimuistitallennuksella

TTFB välimuistitallennuksella

CDN-välimuisti on aivan yhtä tärkeää kuin WordPress-isännnän tarjoama palvelintason välimuistitallennus. Käymme CDN:n läpi tarkemmin alapuolella.

WordPress caching can easily decrease your page load times by over 33%! ⚡ Check out the results. Click to Tweet

Jäsensivustojen ja välimuistitallennuksen ongelmat

Jäsensivustoilla on paljon sisältöä, jota ei voida tallentaa välimuistiin, sekä sivuja, jotka muuttuvat koko ajan. Sivut kuten sisäänkirjautumissivu (jolla saattaa sivuston koosta riippuen olla paljon kävijöitä koko ajan), checkout-sivustot digitaalisille tuotteille sekä keskustelufoorumit ovat tyypillisiä ongelmakohtia, koska niitä ei voida tallentaa välimuistiin.

Ongelmat eivät kuitenkaan pääty siihen. Tavallisilla WordPress-sivustoilla hallintapaneelia ei tallenneta välimuistiin “logged in” -käyttäjien kohdalla. Tämä toimii hyvin, kun paikalla on vain muutama kirjoittaja ja järjestelmävalvoja, mutta jos tuhannet jäsenet käyttävät hallintapaneelia yhtä aikaa, suorituskykyongelmat nostavat heti päätään, koska mitään datasta ei voida tallentaa välimuistiin. Näin ollen tarvitaan voima ja arkkitehtuuri, joka pysyy mukana. Jaetun hostingin tarjoajat yleensä kaatuvat tässä tilanteessa.

Oliovälimuistitallennus erittäin dynaamisilla sivustoillta

Mitä tulee WordPressin jäsensivustoihin, tavallisimmat välimuistitallennuksen vaihtoehdot eivät yleensä riitä, koska ne eivät ole tarpeeksi tehokkaita. Tässä oliovälimuistitallennus astuu kuvaa. 

Oliovälimuistiin tallennetaan tietokantakyselyjen tuloksia, jotta seuraavan kerran, kun sitä pyydetään, sitä ei tarvitse hakea tietokannasta asti. Tämä nopeuttaa PHP-prosessien toimintaa ja vähentää tietokannan kuormaa. Jäsensivuistoilla tämä on erityisen hyödyllistä! WordPressissä olivovälimuistitallennuksen voi ottaa käyttöön muutamalla eri tavalla:

  1. Kolmannen osapuolen välimuistitallennusratkaisu kuten W3 Total Cache
  2. Redis (suositeltu)
  3. Memcached

Tarjoamme Redis-lisäosaa Kinstalla, jotta voit käyttää olivälimuistitallennusta hyväksesi jäsensivustoillasi.

Välimuistin analysointi

Muistatko x-kinsta-cache-tiedon, josta yllä puhuttiin? Hostingin tarjoajasta ja välimuistitallennuksen muodosta riippuen sillä saattaa olla jokin muu nimi. Joka kerta, kun WordPress-sivustoltasi lähtee kysely, tiedolla on jokin arvo, kuten HIT, BYPASS, MISS tai EXPIRED. Näin voit seurata, kuinka hyvin välimuistitallennuksesi toimii.

WordPress-sivun välimuistin HIT-arvojen lisääminen on tärkeää, koska mitä enemmän tietoja pystytään tarjoamaan välimuistista, sitä nopeammin sivusto pyörii. Kinstalla voit analysoida dataa MyKinsta analytics -työkalulla sekä Kinstan välimuistilogeilla päätelläksesi, mikäli sivustolla on BYPASS-arvon saavia GET-kyselyjä, jotka tulisi tallentaa välimuistiin, tai POST-kyselyjä, joista tulisi päästä eroon. 

Välimuistin komponenttipino (cache component stack, kuvattu alla) demonstroi kunkin kyselyn statusta, HIT, BYPASS, MISS tai EXPIRED. Dataa voi katsoa viimeiseltä 24 tunnilta, 7 päivältä tai 30 päivältä.

Kinstan välimuistitallennuksen komponenttipino

Kinstan välimuistitallennuksen komponenttipino

Komponenttipinosta näkyy välimuistitallennuksen osuus yhdellä silmäyksellä. Mitä enemmän kyselyt suuntautuvat välimuistiin, sen parempi. Kuten alla näkyy, tällä WordPress-sivustolla on 96,2% HIT-tulos. Mikä on hyvä!

Kinstan välimuistin komponenttipino

Kinstan välimuistin komponenttipino

Kyselyt, jotka eivät suuntaudu välimuistiin, näkyvät kohdasta “top cache bypasses”. Yleensä tässä saattaa näkyä CRON-ajoja, admin-ajax-kyselyjä, verkkokauppojen checkout-sivuja, string-merkkisiä kyselyjä, UTM-parametrejä jne.

WordPressin “top cache bypasses”

WordPressin “top cache bypasses”

Kuvat on optimoitava

Kuvien optimointi on yksi selkeä asia, jonka avulla sivuston kokonaislatausaikaa voi pienentää huomattavasti. Tämä ei ole vapaavalintaista, vaan jokaisen sivuston tulisi tehdä näin!

Suuret kuvat hidastavat sivustojasi ja tarjoavat käyttäjälle huonon kokemuksen. Kuvien optimointi tarkoittaa niiden koon pienentämistä joko lisäosalla tai skriptillä, mikä nopeuttaa latausaikoja. Käytössä on yleensä kaksi pakkaustapaa: häviöllinen ja häviötön. 

HTTP Archiven mukaan marraskuussa 2018 kuvien osuus koko sivuston painosta on keskimäärin 21%. Joten videoiden – jotka on paljon vaikeami optimoida – kuvista kannattaa aloittaa! Ne ovat tärkeämpiä kiuin JavaScript, CSS ja fontit. Ja vaikka kuvien optimointi on helposti toteutettavissa, moni nettisivun omistaja jättää sen silti tekemättä.

Sivun keskimääräinen koko (KB)

Sivun keskimääräinen koko (KB)

Joulukuussa 2017 kuvien keskimääräinen osuus koko sivuston koosta oli 54%. Näyttää siltä, että internet kokonaisuutena on parantanut kuvaoptimointia! 21% on kuitenkin yhä liian suuri luku. Jos sinulla ei ole videosisältöä sivustollasi, kuvat ovat todennäköisesti sivustosi koon suurin kipukohta. 

Images make up on average 21% of a web page's overall weight. 😮 Optimize them! Click to Tweet

Tasapainon löytäminen (tiedoston koko ja laatu)

Kuvien muokkauksen tärkeintä tehtävä on löytää oikea tasapaino pienimmän kuvakoon ja hyväksyttävän laadun välillä. Lähes kaikki optimoinnit voi tehdä monella tavalla. Yksi tavallisimmista tavoista on pakata ne ennen niiden tallentamista WordPressiin. Tämän voi thedä esimerkiksi Adobe Photoshopilla tai Affinity Photolla. Internetissä on myös uusi Squoosh-sovellus Googlelta. Tämän voi kuitenkin tehdä myös automaattisesti lisäosaa käyttämällä. Kerromme tästä alla lisää. 

Tiedostomuoto ja pakkaustyyppi kannattaa ottaa huomioon. Oikealla yhdistelmällä voit pienentää kuvan koko jopa viidennekseen. Sinun täytyy kokeilla jokaisen kuvan tai tiedostomuodon kanssa nähdäksesi, mikä toimii parhaiten.

Ennen kuvien muokkaamista kannattaa varmistaa, että käytössä on paras tiedostomuoto. Valittavana on erilaisia:

  • PNG – korkeampilaatuisia kuvia mutta myös suuremmat tiedostokoot. Alun perin häviötön kuvaformaatti, mutta voi olla myös häviöllinen. 
  • JPEG – kättää häviötöntä ja häviöllistä optimointia. Laadun tasoa voi säätää, jotta kuvan laadun ja koon saa hyvään tasapainoon.

Ideaalitilanteessa JPEG-muotoa (käytetään myös lyhennettä JPG) kuviin, joissa on paljon väriä, ja PNG-muotoa yksinkertaisempiin kuviin.

Entä GIF-tiedostot? Animoidut GIT-tiedostot ovat aina hauskoja, mutta ne tappavat suorituskyvyn. Monet GIF-tiedostot ovat kooltaan yli 1 MB per kappale. Suosittelemme pitämään ne sosiaalisessa mediassa ja Slackissa. Jos blogikirjoituksessasi on sellainen, jota ilman et pysty elämään, kannattaa lukea, kuinka animoituja GIF-tiedostoja voi pakata.

Pakkaus: laatu vs. koko

Alla on esimerkki siitä, mitä tapahtuu, jos kuvaa pakkaa liikaa. Ensin on käytetty alhaista pakkausta, jolloin kuvan laatu on parempi (mutta tiedostokoko usurempi). Sitten on käytetty korkeampaa pakkaussuuretta, jolloin kuvan laatu on heikompi (mutta tiedostokoko pienempi). Huomio: alkuperäisen kuvan koko oli 2,06 MB.

Alhaienn pakkaus (korkea laatu) JPG – 590 KB

Alhaienn pakkaus (korkea laatu) JPG – 590 KB

Korkea pakkaus (alhainen laatu) JPG – 68 KB

Korkea pakkaus (alhainen laatu) JPG – 68 KB

Kuten näkyy, ensimmäisen kuvan koko on 590 KB. Se on aika paljon yhdeltä kuvalta! Yleisesti ottaen koko sivun paino kannattaa pitää alle 1 tai 2 MB:ssä. 590 on jo yli neljännes siitä. Toinen kuva sen sijaan näyttää kamalalta, mutta sen koko on vain 68 KB. Se, mitä haluamme, on hyvä tasapaino pakkausmäärän (laadun) ja tiedostokoon välillä.

Pakkasimme kuvan siis uudestaan medium-tasolla, ja kuten alla näkyy, laatu on nyt hyvä ja koko 151 KB, joka on hyväksyttävä korkean resoluution kuvan kohdalla. Se on vain noin neljännes alkuperäisen kuvan korkealaatuisesta pakkauksesta. Pyrimme pitämään suurimman osan kuvistamme alle 100 KB parhaan suorituskyvyn takaamiseksi.

Medium-tason pakkaus (hyvä laatu) JPG – 151 KB

Medium-tason pakkaus (hyvä laatu) JPG – 151 KB

Häviöllinen vs. häviötön optimointi

On tärkeää myös ymmärtää, että pakkauksen voi tehdä kahdella tavalla: häviötön (lossy) ja häviöllinen (lossless).

Häviöttömässä pakkauksessa osa kuvan datasta poistetaan. Näin ollen kuvan laatu saattaa kärsiä (joskus puhutaan pikselimössöstä). Kannattaa siis olla varovainen kuvia pakatessa. Ei pelkästään kuvan laadun takia vaan myös siksi, ettei kuvaa enää saa entiselleen. Häviöllisen pakkauksen suurin etu on toisaalta se, että se pienentää tiedostokokoa huomattavasti. 

Häviöllisen pakkauksen vertailukuvia

Häviöllisen pakkauksen vertailukuvia

Häviötön pakkaus sen sijaan ei heikennä kuvan laatua. Miten se on mahdollista? Yleensä se tehdään poistamalla turha metadata (data, jonka kuvanottolaite luo automaattisesti). Metodin suurin ongelma on, että tiedostokoko ei välttämättä pienene merkittävästi.  Toisin sanoen pitkällä tähtäimellä se vie paljon tallennustilaa.

Kannattaa kokeilla eri tapoja, jotta löydät sinulle parhaiten sopivan. Suurinta osaa käyttäjistä kannustamme käyttämään häviöllistä pakkausta siksi, että se pystyy helposti pienentämään kuvan kokoa yli 70% (joskus jopia yli 90%) ilman laadun merkittävää heikkenemistä. Jos sivulla on vaikka 15 kuvaa, niiden häviöllisellä pakkaamisella on suuri rooli kokonaislatausajan nopeuttamisessa.

Kuvapakkauslisäosia

Hyvät uutiset: on olemassa erinomaisia WordPress-lisäosia, joilla kuvia voi pakata automaattisesti. Tässä muutama, joita suosittelemme:

  • Imagify (häviöllinen ja häviötön – optimoi kuvat ulkoisesti)
  • WP Smush (häviöllinen ja häviötön – optimoi kuvat ulkoisesti)
  • EWWW Cloud (häviöllinen ja häviötön – optimoi kuvat ulkoisesti)
  • ShortPixel (lhäviöllinen ja häviötön – optimoi kuvat ulkoisesti)

Tärkein asia, mikä lisäosaa valitessa kannattaa pitää mielessä, on se, että lisäosan tulee pakata ja optimoida kuvat ulkoisesti omilla palvelimillaan. Näin sivustosi kuormitus pienenee. Kaikki yllä olevat toimivat näin.

Mikäli olet utelias, voimme kertoa, että Kinstan sivustolla käytämme Imagifyä. Se pakkaa kuvat automaattisesti, kun tallennamme ne WordPressin mediakirjastoon. Meidän ei tarvitse huolehtia mistään. Ajan kanssa oppii näkemään helposti, minkä tason pakkausta kannattaa käyttää. Imagifyn tarjoamat vaihtoehdot ovat Normal, Aggressive ja Ultra.

Käytämme Aggressive-vaihtoehtoa Kinstalla ja näemme yleensä noin 60-70% vähennyksiä kuvasta riippuen. Huomio: me käytämme paljon enemmän PNG-tiedostoja kuin JPEG-tiedostoja johtuen siitä, että yleensä kuvamme ovat ikoneja ja visuaalisia demonstraatioita, eivät valokuvia.

Kuvapakkauksen säästämä tila

Kuvapakkauksen säästämä tila

Kuinka paljon sivustosi nopeutuu, jos käytät kuvapakkausta? Kaikki riippuu alkuperäisten kuvien koosta verrattuna siihen, mitä se on pakkauksen jälkeen. Joka tapauksessa teimme joitakin nopeustestejä, ja tuloksista näkyy, että korkealaatuinen kuvanpakkausratkaisu voi laskea sivun kokonaislatausaikoja jopa yli 80%!

Niin sanottu lazy loading

Jos kuvia on paljon, kannattaa harkita niiden näyttämistä käyttäjälle vähän kerrallaan (lazy loading). Kyseessä on optimointitekniilla, joka lataa kaiken näkyvillä olevan sisällön heti mutta paljastaa vanhemman sisällön vasta tarvittaessa.

Meillä on opas siihen, miten lazy loading -tekniikan voi ottaa käyttöön WordPress-sivustolla. Erityisen tärkeä tämä on blogikirjoituksissa, joissa on paljon kommenttien gravatar-ikoneita. Google on myös vastikään julkaissut omat suosituksensa lazy loadingista.

Lisävinkkejä kuvien optimointiin

Vielä loppuun muutama vinkki.

  • Kuvia ei kannata enää sovittaa kolumnin tai DIV:n kokoon. Responsiiviset kuvat toimivat WordPressissä automaattisesta (versiosta 4.4 alkaen) ja näkyvät automaattisesti pienempinä mobiilikäyttäjille.
  • SVG:t voivat toimia kuvien sijasta loistavasti. Kaikki käsin piirretyt illustraatiot, joita Kinstan sivustolla näkyy, ovat SVG:itä (vektoreita). SVG:t ovat yleensä paljon pienempiä tiedostoja, tosin poikkeuksia on. Lue lisää tutoriaalistamme kuinka käyttää SVG:itä WordPress-sivustolla.
  • Sen sijaan, että laittaisit kuviin tekstiä, käytä ikonifontteja. Ne näyttävät paremmalta skaalattuina ja vievät vähemmän tilaa. Ja fonttigeneraattorilla voit optimoida niitä vielä enemmän. Lule lisää siitä, kuinka pienensimme ikonifonttien kokoa jopa 97.59% fonttigeneraattorin avulla.

Hienosäädä tietokantaasi

Seuraavaksi käymme läpi vinkkejä, joiden avulla WordPress-tietokantaa voi hienosäätää. Auton tavoin tietokanta kaipaa huoltoa, koska ajan saatossa sinne saattaa jäädä turhaa tavaraa tukkeeksi.

Jäsensivustot ovat erityisen hankalia, koska ne luovat monimutkaisempia kyselyjä, mikä lisää viiveaikoja tietoa haettaessa MySQL-tietokannasta. Iso osa tästä johtuu kaikista liikkuvista osista sekä datan suuresta määrästä, joita tällaisilla sivustoilla on. Tähän usein vaikuttavat myös sivustot, jotka käyttävät navigaatiossa paljon hakukyselyjä tai joilla on käytössään WP_Query.

Puhumattakaan siitä, että sivustolla saattaa olla paljon samanaikaisia käyttäjiä tekemässä tietokantakyselyjä.

Käytä InnoDB:n MySQL-varastointikonetta

Moni vanhempi sivusto käyttää yhä MyISAM-varastointikonetta tietokannassaane. Viime vuosina InnoDB on suoriutunut paremmin ja luotettavammin.

InnoDB is like synthetic oil, whereas MyISAM is settling for regular. ⛽ Click to Tweet

Tässä muutama InnoDB:n etu MyISAM:iin verrattuna:

  • InnoDB:llä on rivikohtainen lukitus. MyISAM:lla on ainoastaan koko taulukon laajuinen lukitus. Näin kyselyt prosessoidaan nopeammin.
  • InnoDB:llä on niin sanottu referential integrity, joka toimii myös viiteavainten (RDBMS) ja suhderajoitusten kanssa, kun taas MyISAM:lla ei ole (DMBS).  
  • InnoDB tukee transaktioita, mikä tarkoittaa, että voit perua tekemäsi muutokset. MyISAM ei tee niin.
  • InnoDB on luotettavampi, koska se käyttää transaktiologeja automaattiseen palauttamiseen. MyISAM ei tee niin.

Saatat joutua miettimään, onko käytössäsi InnoDB vai MyISAM. Jos WordPress-sivustosi on uuden puoleinen, se käyttää todennäköisesti InnoDB:n konetta. Vanhempien WordPress-sivustojen kohdalla asia kannattaa kuitenkin taristaa. Joillain sivuilla saattaa olla jopa niin, että MyISAM- ja InnoDB-taulukoita on käytetty sekaisin, jolloin niiden yhtenäistäminen saattaisi parantaa suorituskykyä.

Seuraa alla olevia yksinkertaisia ohjeita tarkistaaksesi, mitä taulukoita sinulla on käytössäsi.

Askel 1

Kirjaudu sisään phpMyAdminiin ja paina MySQL-tietokantaa.

phpMyAdmin-tietokanta

phpMyAdmin-tietokanta

Askel 2

Tee nopea skannaus tai järjestä tyypin (“Type”) mukaan. Näet, mitä varastointikonetta taulukkosi käyttävät. Alla olevassa esimerkissä näkyy, että taulukoista kaksi käyttää yhä MyISAM:ia.

MyISAM-tietokantataulukoita

MyISAM-tietokantataulukoita

Jos MyISAM:ia löytyy, kannattaa vaihtaa ne InnoDB:ksi. Suosittelemme, että otat yhteyttä hosting-palveluntarjoajaan ja pyydät hoitamaan asian. Kinstalla jokaisen asiakkaan tietokannan muuttavat InnoDB:ksi migraatiotiimimme jäsenet automaattisesti.

Voit myös vaihtaa MyISAM:n InnoDB:ksi manuaalisesti seuraavien tutoriaalien avulla:

Poista sivun vanhat versiot ja rajoita niiden määrää

Aina, kun tallennat sivun tai postauksen WordPressin avulla, järjestelmä luo revision-nimisen version sivusta. Tämä tapahtuu sekä draft-mallisissa sivuissa että jo julkaistuissa sivuissa, joita päivitetään. Nämä vanhat versiot ovat avuksi silloin, kun on tarpeen käyttää sivusisällön edellistä versiota.

WordPressin revision: sivun vanha versio

WordPressin revision: sivun vanha versio

Versioiden suuri määrä voi kuitenkin häiritä WordPress-sivuston suorituskykyä. Suuremmilla sivustoilla käy helposti niin, että tietokantaan jää tuhansia riviä tietoja, joita ei välttämättä tarvita. Ja mitä enemmän rivejä on, sitä suurempi on tietokannan koko, ja se vie tallennustilaa. Vaikka indeksit on kehitetty korjaamaan juuri tämä ongelma, olemme silti nähneet, että se voi käytännössä tuhota WordPerss-sivustoja. Muutaman asian voit tehdä.

1. Poista vanhat sivuversiot

Jos sinulla on vanhempi WordPress-sivusto, jolla on paljon sivuja ja postauksia, on ehkä aika siivota pois vanhat sivuversiot. Sen voi tehdä MySQL:llä, mutta koska netissä on paljon vääriä koodinpätkiä, suosittelemme tekemään sivustosta varmuuskopion ja käyttämään ilmaista lisäosaa kuten WP-Sweep.

Myös eräs tonen lempilisäosistamme, WP Rocket, sisältää tietokannan optimointiin keskittyvän ominaisuuden, jolla vanhoja sivuversioita voi poistaa.

WP Rocketin tietokantaoptimointi

WP Rocketin tietokantaoptimointi

Jos olet tottunut käyttämään WP-CLI:tä, voit käyttää tämän tekemiseen paria eri komentoa.

Kirjaudu palvelimellesi sisään SSH:n avulla ja aja seuraava komento nähdäksesi, paljon vanhoja versioita tietokannassa on:

wp revisions list

WP-CLI:n lista vanhoista versioista

WP-CLI:n lista vanhoista versioista

Jos saat virheilmoituksen, sinun täytyy ehkä asentaa wp-revisions-cli -paketti seuraavan komennon avulla:

wp package install trepmal/wp-revisions-cli

Seuraavalla komennolla voit tyhjentää sivuversiot:

wp revisions clean

2. Sivuversioiden määrän rajoittaminen

Yksi hyvä strategia – sellainen, jota myös me Kinstalla käytämme – on yksittäisen sivun tai postauksen tallennettujen tervioiden määrän rajoittaminen. Jopa arvon asettaminen kymmeneen pitää versioiden määrän hallinnassa, erityisesti jos päivität sivuja paljon.

Määrän rajoittamiseksi voit lisätä seuraavan koodin wp-config.phptiedostoon. Alla oleva koodi tulee syöttää kohdan ‘ABSPATH’ yläpuollelle, jotta se toimii. Voit muuttaa arvoa, joka määrittelee tietokannassa säilytettävien sivuversioiden määrän.

define('WP_POST_REVISIONS', 10);

Versioiden määrän rajoittaminen wp-config.php-tiedostossa

Versioiden määrän rajoittaminen wp-config.php-tiedostossa

Voit käyttää tähän myös lisäosaa kuten Perfmatters.

Versioiden määrän rajoittaminen Perfmatters-lisäosalla

Versioiden määrän rajoittaminen Perfmatters-lisäosalla

3. Ota versioiden tallentaminen pois päältä

Viimeisenä mutta ei vähäisimpänä – voit myös ottaa sivuversioiden tallennuksen kokonaan pois päältä. Jos päätät tehdä näin, suosittelemme ensin seuraamaan ohjeita kohdassa yksi ja poistamaan kaikki vanhat sivuversiot ennen niiden ottamista pois käytöstä. Näin tietokanta tyhjenee sivuversioista eikä uusia enää tule. 

Ottaaksesi sivuversioiden tallentamisen pois päältä lisää seuraava koodinpätkä wp-config.phptiedostoon. Alla oleva koodi tulee syöttää kohdan ‘ABSPATH’ yläpuolelle, jotta se toimii.

define('WP_POST_REVISIONS', false);

Versioiden tallentamisen ottaminen pois päältä wp-config.php-tiedostossa

Versioiden tallentamisen ottaminen pois päältä wp-config.php-tiedostossa

Voit käyttää myös lisäosaa kuten Perfmatters.

Versioiden tallentamisen ottaminen pois päältä Perfmatters-lisäosan avulla

Versioiden tallentamisen ottaminen pois päältä Perfmatters-lisäosan avulla

Siivoa wp_options-taulukko ja automaattisesti latautuva data

wp_options-taulukko unohtuu usein, kun puhutaan WordPressin ja tietokannan suorituskyvystä. Se voi kuitenkin usein olla syypää hitaisiin kyselyihin erityisesti vanhemmilla ja suuremmilla sivustoilla. Automaattisesti latautuvaa dataa jättävät jälkeensä kolmannen osapuolen lisäosat ja teemat. Luota meihin – näemme tätä joka päivä!

wp_options-taulukkoon tallennetaan paljon WordPress-sivustoon liittyvää data kuten:

  • Sivuston URL, kotisivun URL, järjestelmähallitsijan sähköpostiosoite, oletuskategoria, postausta per sivu, aikaformaatti jne.
  • Lisäosien, teemojen ja pienoissovellusten asetukset
  • Väliaikaisesti puskurimuistiin tallennettu data
wp_options-taulukko WordPress-tietokannassa

wp_options-taulukko WordPress-tietokannassa

Tässä taulukossa on seuraavat kentät (sarakkeet):

  • option_id
  • option_name
  • option_value
  • autoload (tämä on suorituskyvyn kannalta merkityksellinen)
Autoload-merkitty data

Autoload-merkitty data

wp_options-taulukossa tärkeä on autoload-kenttä. Se pitää sisällään arvon kyllä (yes) tai ei (no), joista käytetään myös nimitystä flag eli lippu. Kenttä hallinnoi sitä, lataako  wp_load_alloptions()-funktio kyseisen sivun. Tällä tavoin automaattisesti latautuva (autoloaded) data on dataa, joka latautuu WordPress-sivuston jokaiselta sivulta. Sama idea, jota käytimme  tiettyjen skriptien ottamiseen pois käytöstä niin, ettei niitä ladata joka sivulle, käy tässä. Autoload-attribuutti on asetettu kyllä-kohtaan oletusasetuksena, mutta kaikkien lisäosien ei tarvitse tuoda dataansa joka sivulle.

Ongelmia syntyy, kun WordPress-sivustolla on paljon automaattisesti latautuvaa dataa wp_options-taulukossa. Näin käy yleensä seuraavien asioiden seurauksena:

  • Dataa tuo lisäosa, jonka tulisi olla asetettu kohtaan ei. Hyvä esimerkki tästä on yhteydenottolomaketta tarjoava lisäosa. Täytyykö kyseisen datan latautua joka sivulle vai ainoastaan yhteydenottosivulle?
  • Lisäosa tai teema on saatettu poistaa WordPress-sivustolta, mutta asetukset ovat silti olemassa wp_options-taulukossa. Tällöin turhaa dataa saatetaan käsitellä joka pyynnön kohdalla.
  • Lisäosien ja teemojen kehittäjät lataavat dataa wp_options-taulukkoon omien taulukoidensa sijaan. Tästä voidaan olla monta mieltä, koska jotkut kehittävät pitävät enemmän lisäosista, jotka eivät luo ylimääräisiä taulukoita. Toisaalta wp_options-taulukkoa ei ole suunniteltu sisältämään tuhansia rivejä.

Kuinka paljon on liikaa, kun kyse on automaattisesti latautuvasta datasta? Riippuu toki sivustosta, mutta yleensä sopiva määrä on noin 300 KB – 1MB. Kun 3-5 MB:n raja alkaa lähestyä, käy entistä todennäköisemmäksi, että optimoitavaa on. Mikäli määrä on yli 10 MB, asiaan kannattaa paneutua välittömästi. Aina tämäkään ei tarkoita, että ongelmia tulee, mutta siitä on hyvä aloittaa.

Koska tämä on niin suuri ongelma, olemme koonneet erikseen tutoriaalin siitä, kuinka automaattisesti latautuvasta datasta voi etsiä ongelmakohtia, sekä siitä, miten sitä voi siivota.

When was the last time you cleaned up your wp_options table? Ya... we thought so. 😉 Get on it! Click to Tweet

Siivoa lyhytaikaiset tiedot (transients)

Jollet käytä oliovälimuistia, WordPress tallentaa wp_options-taulukkoon lyhytaikaisia tietoja. Yleensä näihin on merkitty aika, jolloin ne katoavat, mutta aina niin ei käy. Olemme nähneet tietokantoja, joissa on tuhansia vanhoja tilapäisiä tietoja. Itse asiassa yhdellä sivustolla hoidimme korruptoituneita tilapäisiä tietoja joiden takia yli 695 000 riviä oli luotu in the wp_options-taulukkoon. Hui!

Korruptoituneita lyhytaikaisia teitoja wp_options-taulukossa

Korruptoituneita lyhytaikaisia teitoja wp_options-taulukossa

Kannattaa myös huomioida, etteivät lyhytaikaiset tiedot oletusasetuksena lataudu automaattisesti. Voit käyttää alla olevaa kyselyä nähdäksesi, onko taulukossa sellaisia.

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'

Parempi ja turvallisepi vaihtoehto on käyttää ilmaista lisäosaa kuten Transient Cleaner tai Delete Expired Transients, jonka avulla voit poistaa wp_options-taulukosta vain pois käytöstä jääneet lyhytaikaiset tiedostot. Näyttää kuitenkin siltä, että WordPressissä on nyt funktio, joka on lisätty versiossa 4.9 ja jonka tarkoitus on siivota turhat lyhytaikaiset tiedot automaattisesti. Joten toivottavasti se on sivustollasi jo hoidossa.

Myös WP Rocketilla on ominaisuus, jonka avulla lyhytaikaisia tiedostoja voi siivota. Se löytyy tietokantaoptimointien (database optimization) alta.

Siivoa lyhytaikaisia tetoja WP Rocketilla

Siivoa lyhytaikaisia tetoja WP Rocketilla

Siivoa WordPress-istunnot

Yksi yleinen ongelma on, että joskus cron-ajot eivät sykronoidu tai toimi oikein, jolloin istuntoja ei putsata normaaliin tapaan. Lopulta sinulla saattaa olla valtavasti _wp_session_-rivejä tietokannassasi. Alla olevassa esimerkissä sivustolla oli lopulta  yli 3 miljonaa riviä in their wp_options -taulukossa, jonka koko oli kasvanut yli 600 MB:iin.

wp_options-taulukko, jossa on miljoonia rivejä

wp_options-taulukko, jossa on miljoonia rivejä

Voit käyttää alla olevan tyyppistä kyselyä, jos törmäät tähän ongelmaan:

SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'
wp_sessionin rivejä

wp_sessionin rivejä

Yleensä nämä voi turvallisesti poistaa (kuten cron-ajo olisi tehnyt) seuraavalla komennolla:

DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

Kun kaikki turhat _wp_session_ rows oli poistettu, taulukossa oli alle 1 000 riviä ja sen koko oli vain 11 MB.

WP sessions cleaned up

WP sessions cleaned up

Tämä korjasi myös ongelman, jossa MySQL:n käytössä näkyi piikkejä.

MySQL:n internetin transaktiot

MySQL:n internetin transaktiot

Lisää indeksi autoload-kohtaan

Jos wp_options -taulukon siivoaminen ei riittänyt, voit lisätä indeksin autoload-kenttään. Tämä periaatteessa auttaa tekemään hakutoiminnoista tehokkaampia. 10upin mahtava tiimi suoritti joitakin testejä wp_options-taulukolla, jossa oli tavallinen määrä automaattisesti latautuvia tietoja. Alla olevasta graafista näkyy, kuinka indeksin lisääminen wp_options-kyselyihin voi parantaa suorituskykyä.

wp_optionsin kyselyaika

wp_optionsin kyselyaika (Img src: 10up)

Suosittelemme myös tutustumaan näihin resursseihin, jotka on tehnyt WP Bullet:

Käytä Redisiä WordPressin jatkuvana oliovälimuistina

Redis on avoimen lähdekoodin datastruktuurisäilö. WordPressin kohdalla sitä voi käyttää WordPressin oman oliovälimuistin luomien arvojen tallennuspaikkana, jotta tallennettuja oliota voi käyttää uudelleen sivulatausten välillä. 

Jatkuvan oliovälilimuistin (persistent object cache) kuten Redis käyttäminen sallii välimuistiin tallennettujen olioiden uudelleenkäytön sen sijaan, että ne haettaisiin joka kerta MySQL-tietokannasta. Näin Redis voi vähentää MySQL-tietokannan kuormaa, laskea vasteaikaa ja lisätä sivuston kykyä skaalautua.

Redis

Erittäin dynaamisen sivustot (WooCommerce, jäsensivustot keskustelu- ja muut foorumit, erittäin paljon kommentteja keräävä blogi), jotka eivät pysty käyttämään sivuvälitallennusta sujuvasti, saattavat hyötyä Redisin kaltaisesta ratkaisusta.

Jos olet Kinstan asiakas, tarjoamme sinulle Redis-lisäosaa. Lue lisää siitä, kuinka voit lisätä Redisin hosting-pakettiisi.

Käytä Elasticsearchia nopeuttamaan WordPress-hakua

Elasticsearch on avoimen lähdekoodin hakukone. Sitä käytetään siihen, että se indeksoi datan ja etsii datasta erittäin nopeasti.

WordPressin kohdalla Elasticsearchia voi käyttää WordPress-tietokannan kyselyjen nopeuttamiseen. Tämä tehdään rakentamalla indeksi sivuston tietokannasta ja käyttämällä Elasticsearchia indeksin läpi käymiseen. Elasticsearch tekee tämän paljon nopeammin kuin MySQL-kysely. 

Elasticsearch

Jos sinulla on aikaa ja osaamista, voit integroida Elasticsearching WordPress-sivustolle. Jos sivustosi WP_Query-käyttö on tavanomaista, Elasticsearchin voi integroida myös asentamalla ElasticPressin. Se on 10upin luoma ilmainen WordPress-lisäosa, saatavilla WordPress.orgista, ja se toimii automaattisesti WP_Queryn kanssa luomaan kyselytuloksia Elasticsearchilla MySQL:n sijaan.

Sivusto, joka käyttää WP_Queryä paljon, hyötyy Elasticsearchistä. Esimerkkejä tällaisista sivustoista:

  • Sivustot, joissa haku on yleisin navigaatiotapa.
  • WooCommerce-sivustot, joissa järjestelmähallitsijat joutuvat tekemään paljon hakuja tilauslistoista.
  • Sivusto, jolla on paljon postauksia, joissa MySQL-kyselyiden tulokset ovat liian hitaita.

Samoin kuin Redisin kohdalla, tarjoamme käyttäjille Elasticsearchin lisäosaa. Lue lisää siitä, kuinka voit lisätä Elasticsearchon hosting-pakettiisi.

Ota pois käytöstä ominaisuudet, jotka kuormittavat tietokantaa mutta eivät ole välttämättömiä

Tämä saattaa vaikuttaa itsestään selvältä, mutta sellaisten lisäosien ja teemojen ominaisuuksien, jotka käyttävät tietokantaa paljon, ottaminen pois päältä voi vaikuttaa paljon.

  • Pienoisohjelmat ja lisäosat, jotka näyttävät sivulla suosittuja ja asiaan kuuluvia postauksia, ovat hirveitä. Ne käyttävät usein raskaita koko sivuston kyselyjä.
  • Kuvien optimointilisäosat, jotka pakkaavat kuvia sinun palvelintasi käyttäen. Kannattaa aina käyttää kuvaoptimointityökalua, joka optimoi kuvat ulkoisesti.

Jos käyt Kinstan blogissa ja luet postauksen loppuun asti, näet, että meillä on ”käsin poimittuja” asiaan liittyviä artikkeleita. Me valitsemme ne manuaalisesti ja merkitsemme ne postaukseen. Tämä vähentää kyselyjen määrän lähes nollaan eikä häiritse sivuston suorituskykyä. Vaatiiko se enemmän työtä? Kyllä, mutta se voi olla vieläkin parempi, koska voit valita, mitä haluat lukijoidesi näkevän.

WordPressin aiheeseen liittyviä postauksia

WordPressin aiheeseen liittyviä postauksia

Joten miten teimme tämä? Me käytämme erinomaista Advanced Custom Fields -lisäosaa ja merkitsemme sen kentät blogipostauksen tyyppiin. Näin voimme etsiä ja liittää mitä tahansa sisältöä jokaiseen blogikirjoitukseemme (kuten alla näkyy).

Liitä postauksia

Liitä postauksia

Suosittelemme myös välttämään lisäosia, jotka lisäävät sivustolle laskurin, ellei sellaisen käyttö ole todella tarpeellista. Kannattaa esimerkiksi karttaa ”792 kirjoitusta” käyttäjän avatarkuvan vieressä foorumikirjoituksissa tai ”5 243 lukukertaa” foorumikirjoitusten listauksissa. Pitkien keskustelujen yhteydessä nämä laskurit rasittavat tietokantaa huomattavasti. Kaiken kaikkiaan kannattaa pitää laskureiden määrä minimissä ja käyttää niitä vain pakon edessä.

Sama pätee sosiaalisiin laskureihin. Esimerkiksi alla oleva sivustoesimerkki näyttää, että suositun Social Warfar -lisäosan vastausaika on 30 yhtä paljon kuin sen alla olevan lisäosan vastausaika. Välimuistitallennus on käytössä, mutta ilmiselvästi tämä lisäosa vaikuttaa suorituskykyyn merkittävästi. Kun lisäosa otettiin pois käytöstä, latausajat sekä WordPressin hallintapaneelin responsiivisuus paranivat heti. 

Social Warfaren latausaikoja

Social Warfaren latausaikoja

Käytä sisällönjakelujärjestelmää (CDN)

CDN tulee sanoista content delivery network eli sisällönjakelujärjestelmä. Kyse on palvelinverkosta (käytetään myös lyhennettä POP), jonka palvelimet sijaitsevat eri puolilla maapalloa. Ne on suunniteltu säilömään ja toimittamaan kopioita WordPress-sivuston staattisesta (ja joskus dynaamisesta) sisällöstä, kuten kuvista, CSS:stä, JavaScriptistä ja videostriimeistä.

Ensinnäkin CDN:ää ei kannata sotkea WordPress-hostingin tarjoajaan. Kyseessä on kaksi eri palvelua. CDN ei korvaa hosting-tarjoajaa vaan tapa lisätä sivuston nopeutta. Vaikka Kinstalla tarjoamamme hosting on poikkeuksellisen nopeaa, CDN:n käyttö voi nopeuttaa sivulatausaikoja entisestään.

Kuinka CDN toimii

Miten CDN tarkkaan ottaen toimii? No, esimerkiksi, kun otat Kinstan sivustosi isännäksi, saat itse valita fyysisen datakeskuksen sijainnin kuten USA, Eurooppa, Aasian ja Tyynenmeren alue tai Etelä-Amerikka. 

Sanotaan, että valitset kohteen US Central. Se tarkoittaa, että sivustosi tallennetaan ”isäntäpalvelimelle” Council Bluffsissa, Iowassa. Kun Euroopassa olevat ihmiset käyvät sivustolla, sen lataus kestää kauemmin kuin niillä, jotka käyvät sivustolla vaikka Dallasista, Teksasista.

Miksi? Koska datan täytyy suoriutua pitemmästä välimatkasta. Tämä tunnetaan nimellä viiveaika tai latenssi. Viiveajalla tarkoitetaan aikaa tai viivettä, joka kuluu datan siirtämiseen verkon yli.

CDN-tyyppejä

Sisällönjakelujärjestelmiä on kahta erilaista:

  1. Perinteinen pull (Traditional Pull CDN)
  2. Käänteisproxy (Reverse Proxy CDN)

Perinteinen pull-tyyppinen CDN tallentaa välimuistiin kaiken sisällön ja median, mutta pyyntö tulee asiakkaalta silti suoraan hosting-tarjoajalle. Esimerkkejä tästä ovat KeyCDN ja CDN77.

Käänteisproxy-CDN on hieman erilainen. Vaikka se toimii kuin CDN, se sieppaa kaikki tulevat pyynnöt ja toimii välityspalvelimena asiakkaan ja isännän välillä. Esimerkkejä tästä ovat Cloudflare ja Sucuri. Tämä on yksi syistä, miksi DNS täytyy ohjata suoraan näille tarjoajille isännän sijaan.

Näiden etu on, että koska ne toimivat välityspalvelimena, ne tarjoavat vahvoja sovelluspalomuureja, jotka estävät huonoa liikennettä pääsemästä WordPress-sivustolle tai hosting-tarjoajalle. Huono puoli on, että niiden tarjoamat paketit ovat usein tiukempia kuin perinteisten CDN-palveluiden. Mutta suorituskykyyn ja turvallisuuteen liittyviin parannuksiin verrattuna voisi sanoa, ettei sillä ole kovin paljon väliä.

Alla on esimerkki siitä, mitä tapahtui, kun Sucuri otettiin asiakkaan sivustolla käyttöön. Kuten näkyy, se vaikutti huonon liikenteen määrään dramaattisesti. Loppujen lopuksi tällaiset palvelut voivat auttaa sinua säästämään hosting-kuluista.

Resurssit Sucuri WAF:n jälkeen

Resurssit Sucuri WAF:n jälkeen

CDN-nopeustestejä

Aiemmin puhuimme WordPress-välimuistitallennuksen valtavista eduista. No, CDN-välimuistitallennus on myös supertehokasta. Tämä johtuu siitä, että CDN:illä on yleensä useampia palvelinsijainteja kuin hosting-palveluntarjoajilla. Näin ollen ne voivat tallentaa kaiken tarpeellisen (kuvat, JS, CSS) lähemmäs asiakkaita ja tarjoilla ne salamannopeasti.

Tehdään pari nopeaa testiä, jotta näemme, kuinka paljon CDN voisi nopeuttaa sivustoasi.

Ilman CDN:ää

Testissä käytetty sivusto on Kinstan palvelimella ja sen fyysinen sijainti on Iowassa, Yhdysvalloissa sijaitseva datakeskus. Teimme ensin viisi testiä Pingdomissa (ilman CDN:ää) ja laskimme keskiarvon. Tärkeää: Me käytämme Eurooppa – Yhdistyneet kuningaskunnat – Lontoo -sijaintia Pingdomissa demonstroidaksemme, kuinka vahva CDN voi olla. Kokonaislatausaika oli 1,03 s.

Nopeustesti ilman CDN:ää

Nopeustesti ilman CDN:ää

CDN:n kanssa

Otimme CDN:n sitten käyttöön ja teimme toiset viisi nopeustestiä Pingdomissa. Kokonaislatausaika oli nyt 585 ms testisijainnista Eurooppa – Yhdistyneet kuningaskunnat – Lontoo. Joten käyttämällä CDN:ää laskimme sivunlatausaikaa 43,2%! Se on valtava ero.

Nopeustesti CDN:n kanssa

Nopeustesti CDN:n kanssa

Syy niin suureen muutokseen on, että CDN:llä on datakeskus Lontoossa. Se tarkoittaa, että kaikki tieto on tallennettu Lontoossa olevaan välimuistiin ja voidaan tarjoilla minimaalisella viiveajalla.

TTFB ilman CDN:ää

Muistat, että keltainen palkki Pingdomissa tarkoittaa odotusaikaa, joka ensimmäiseen tavuun kuluu (time to first byte, TTFB). Nopeustesteissä ilman CDN:ää keskimääräinen TTFB olin noin 98 ms.

TTFB ilman CDN:ää

TTFB ilman CDN:ää

TTFB CDN:n kanssa

Kun otimme CDN:n käyttöön, keskimäärinen TTFG putosi keskimäärin arvoon 15 ms. Joten käyttämällä CDN:ää keskimääräinen TTFB putosi 84,69%. Tämä johtuu ensisijaisesti siitä, että tarvittavat tiedot jaettiin suoraan CDN:n välimuistista.

TTFB CDN:n kanssa

TTFB CDN:n kanssa

A CDN decreased our page load times by 43.2%! Check out why you should be using one. 🚀 Click to Tweet

Kuinka ottaa CDN käyttöön

CDN:n ottaminen käyttöön WordPress-sivustolla ei ole välttämättä vaikeaa – se on itse asiassa aika helppoa! Seuraa vain näitä askeleita.

Askel 1

Valitse CDN-palveluntarjoaja ja heiltä sopiva paketti. Yleensä niistä laskutetaan kuukausittain tai datakäytön mukaan. Useimmilla on laskin, jonka avulla voit arvioida kulujen määrää.

  • Jos ajattelit ottaa itse KeyCDN:n käyttöön, suosittelemme lukemaan tämän artikkelin: CDN vasta-alkajille. Jokaisella CDN-palveluntarjoajalla pitäisi myös olla oma dokumentaatio, jonka avulla pääset alkuun.
  • Meillä on myös yksityiskohtaiset artikkelit Cloudflaren ja Sucurin asentamisesta

Askel 2

Jos käytät perinteistä CDN:ää, voit käyttää ilmaista lisäosaa kuten CDN EnablerWP Rocket or Perfmatters integroidaksesi sen WordPress-sivuston kanssa. Nämä lisäosat linkittävät tarvittavat tiedot CDN:ään automaattisesti, eikä sinun tarvitse tehdä sen enempää saadaksesi sisältösi sinne. Käänteisproxyä käyttävät CDN:t eivät yleensä vaadi lisäosan käyttöä, mutta välillä niiden avulla voidaan hallinnoida ylimääräisiä ominaisuuksia.

Ota CDN käyttöön WordPressissä Perfmattersin avulla

Ota CDN käyttöön WordPressissä Perfmattersin avulla

Kinstan CDN:n ottaminen käyttöön

Piditkö nopeustesteistä, jotka teimme yllä? Käytämme niissä KeyCDN:ää. Kinstan CDN:n taustalla on juuri KeyCDN. Se on http/2- ja IPv6-yheiskäyttöinen sisällönjakeluverkko, jolla on 34 sijaintia ja jonka avulla sisällön voi toimittaa minne tahansa maailmassa. Tämänhetkiset sijainnit ovat Amerikassa, Etelä-Amerikassa, Euroopassa, Afrikassa, Aasiassa ja Australiassa.

Kinstan CDN-verkosto

Kinstan CDN-verkosto

Jos olet Kinstan asiakas, jokaiseen pakettiimme sisältyy ilmainen CDN-kaista. Voit ottaa Kinstan CDN:n käyttöön kahdella helpolla askeleella.

Askel 1

Kirjaudu ensin sisään MyKinsta-hallintapaneeliin. Klikkaa sivustoasi ja CDN-välilehteä.

Kinstan CDN

Kinstan CDN

Askel 2

Paina sitten “Enable”. Parin minuutin kuluttua CDN on automaattisesti tehnyt kaiken ja tiedot jaetaan seuraavaksi eteenpäin eri välimuisteista ympäri maapallon. Muuta ei tarvita. 😄

Ota käyttaöön Kinstan CDN

Ota käyttöön Kinstan CDN

Muita CDN-optimointeja

Tässä vielä muutama CDN-optimointi, joita haluat ehkä harkita.

  • Jos saat paljon kommentteja, gravatarit saattavat luoda paljon kyselyjä. Ne latautuvat osoitteesta secure.gravatar.com. Tämän tutoriaalin avulla voit tuoda gravatarit CDN:stä sen sijaan. Käytämme tätä Kinstan sivustolla. 👍
  • Voit tuoda kustomoidut tai Googlen fontit CDN:ltä. Lue lisää tutoriaalista paikallisista fonteista.
  • Varmista, että favicon latuatuu CDN:stä. Vaikka se on pieni, jokainen kysely on merkityksellinen!

Vie sähköposti ja media tarvittaessa muualle (offloading)

Kaikki, mikä luo kyselyjä, vaikuttaa sivuston suorituskykyyn tavalla tai toisella. Sivustojen, joilla on satoja tuhansia tiedostoja tai paljon suuria mediatiedostoja, kannattaa usein viedä tämä kokonaan muualle. Offloading on eri asia kuin CDN:stä jakeleminen. CDN:n avulla alkuperäinen data on yhä omalla isäntäpalvelimellasi; CDN:llä on vain siitä monta kopiota.

Kun välimuistitallennus päättyy CDN:n tiedoisa, se pyytää päivitetyt versiot isäntäpalvelimelta. CDN:t tallentavat sivuja välimuistiinsa pitkiksi ajoiksi. Mutta koska heillä on niin paljon POP-arvoja, voi olla paljon uudelleenhakua, koska välimuisti päättyy eri alueilla.

Kun viet tiedostoja muualle (offloading), se tarkoittaa niiden fyysisen sijainnin siirtämistä pois hosting-tarjoajan palvelimelta. Eli vakka näyttää siltä, että ne tulevat sivustoltasi, ne ovat oikeasti jossain aivan muualla. Sen lisäksi, että tämä vähentää isäntäpalvelimen kyselyjä, se myös säästää tallennustilaa.

Vie media Amazon S3:een

Yksi suosituimmista offloading-ratkaisuista on Amazon S3. Se on varastointijärjestelmä ja osa Amazon Web Serviceä. Usein sitä käyttävät suuret sivustot, jotka joko tarvitevat lisäkopioita tai tarjoavat suuria tiedostoja (latauksia, ohjelmistoja, pelejä, äänitiedostoja, PDF:iä, jne.). Amazon on todistanut olevansa erittäin luotettava ja massiivisen infrastruktuurinsa takia se pystyy tarjoamaan palveluitaan edullisesti. S3:n asiakkaisiin kuuluvat muun muassa Netflix, Airbnb, SmugMug, Nasdaq, jne.

Koska S3 tarjoaa vain varastotilaa, sen hinnat ovat lähes poikkeuksetta halvemmat kuin WordPress-hostingin tarjoajilla. Median vieminen AWS:ään on erinomainen tapa säästää rahaa ja on ensimmäisen vuoden ajan ilmainen (5 GB asti). Ja koska mediatiedostojen pyynnöt tulevat suoraan Amazonille, se kuormittaa WordPress-sivustoa vähemmän ja auttaa latausaikojen nopeuttamisessa.

Lue lisää yksityiskohtaisesta tutoriaalistame WordPress-median lataamisesta Amazon S3:een. Voit käyttää CDN:ää myös muualle viedyn median kanssa maksimoidaksesi hyödyt.

Vie media Google Cloud Storageen

Toinen suosittu offloading-ratkaisu on Google Cloud Storage. Koska Google Cloud Platform on Kinstan palvelun takana, me pidämme heidän teknologiastaan ja infrastruktuuristaan valtavasti. Googlen massiivisen infrastruktuurin takia heidän hintansa ovat erittäin alhaiset. Heidän asiakkaisiinsa kuuluvat muun muassa Spotify, Vimeo, Coca-Cola, Philips, Evernote ja Motorola.

Google Cloud storage

Lue lisää yksityiskohtaisesta tutoriaalistamme WordPress-median siirtämisestä Google Cloud Storageen.

Vie toiminnalliset ja markkinointisähköpostit muualle

Sähköpostiviesteillä on yllättävän suuri vaikutus palvelimeen ja sen resursseihin. Joidenkin hosting-palveluntarjoajien – erityisesti niiden, jotka tarjoavat jaettua hostingia – tämän väärinkäyttö voi johtaa palvelun katkeamiseen. Tämä on ongelma erityisesti niille, jotka lähettävät suuria määriä sähköposteja. Tämä on syy siihen, miksi kolmannen osapuolen toiminnalliset sähköpostipalvelut ovat olemassa, ja siihen, miksi moni hosting-tarjoaja blokkaa sähköpostitoimitukset kokonaan. Me emme suosittele käyttämään hosting-palveluntarjoajaa sähköpostitarkoituksiin.

Jos lähetät uutiskirjeitä tai muita sähköpostiviestejä, joita lähtee suuria määriä, suosittelemme seuraavia vaihtoehtoja:

  • Käytä kolmannen osapuolen ammattikäyttöön tarkoitettua sähköpostimarkkinointijärjesetlmää, joka ei ole osa WordPressiä
  • Käytä toiminnaisten sähköpostiviestien tarjoajaa (HTTP API tai SMTP) WordPressin rinnalla

Kolmannen osapuolen palvelun käytön etuihin kuuluvat myös:

  • Sähköpostien luotettavampi toimitus. Anna sähköpostiosaajien tehdä se, minkä he tekevät parhaiten!
  • Pienempi riski joutua mustalle listalle.
  • DMARC-tietueen käyttäminen hosting-palveluntarjoajan kanssa ei aina ole mahdollista.

Sähköpostimarkkinointityökalut

Esimerkkeinä uutiskirjeet, tuote- ja ominaisuusilmoitukset, alennusmyynnit, tapahtumakutsut, muistutukset jne. Tässä esimerkkejä työkaluista, joita suosittelemme: 

Toiminnallisten sähköpostieviestien palvelut

Esimerkkejä toiminnallisista sähköpostiviesetistä: ostokuitit WooCommercelta tai EDD:ltä, tilinluonti-ilmoitukset, postitusilmoitukset, sovellusten virheilmoitukset, salasanojen resetoinnit, jne. Jos olet Kisntan asiakas, me luotamme kolmannen osapuolen SMTP-palveluntarjoajaan taataksemme toimituksen. Mutta volyymistä riippuen suosittelemme aina viemään tämän muualle. Tässä muutama palvelu, joita suosittelemme:

Pullonkaulojen ja hitaiden lisäosien löytäminen

Nyt käymme läpi vinkkejä, joiden avulla voit löytää WordPress-sivustoltasi pullonkauloja ja korjata ongelmia.

Käytä New Relic -lisäosaa löytämään hitaita lisäosia ja tietokantakyselyjä

Markkinoilla on erinomaisia työkaluja, joiden avulla löydät helposti hitaita tietokantakyselyjä ja lisäosia, jotka vievät paljon aikaa. Pidämme Kinstalla kovasti New Relic -lisäostasta ja käytämme sitä päivittäin. New Relic on PHP-monitorointityökalu, jonka avulla saat yksityiskohtaisia suorituskykytietoja sivustostasi.

Jos olet Kinstan asiakas, voit jopa lisätä oman New Relic -lisenssiavaimesi MyKinsta-hallintapaneeliin.

New Relic-tietoja

New Relic-tietoja

New Relicin käytössä kannattaa kuitenkin olla varuillaan, sillä se saattaa vaikuttaa sivuston suorituskykyyn. Se lisää JavaScriptiä sivustolle. Me suosittelemme ottamaan sen käyttöön, kun ongelmakohtia etsitään, ja ottamaan sen pois käytöstä jälkikäteen.

Hitaiden lisäosien löytäminen

Kun WordPress-lisäosa aiheuttaa sivustolla hitautta, se näkyy eri tilanteissa riippuen siitä, mitä lisäosa tekee. Kuitenkin monessa tapauksessa käy niin, että hidas lisäosa vaikuttaa WordPress-sivuston jokaiseen sivuun. Alla olevassa esimerkkitilanteessa kokonaishitautta näkyi jokaisen sivun käytössä. Näin New Relic kuvaili lisäosan toimintaa sivustolla.

Hitaita lisäosia

Hitaita lisäosia

Heti näkyy, että adinjector-lisäosa vie 15 kertaa saman ajan kuin seuraavaksi hitain lisäosa.

Aina, kun tällaista näkyy, on helppo ajatella, että lisäosa on huonosti tehty tai ainakin tehoton. Vaikka tämäkin pitää joskus paikkansa, se ei tee sitä aina. Lisäosan huono konfigurointi, tietokannan hitaus tai hitaat ulkoiset resurssit saattavat häiritä lisäosan toimintaa.

Joten kun jokin lisäosa vastaa hitaasti, kannattaa New Relicistä hakea lisätietoja. Transaktiot, tietokannat ja ulkoiset resurssit kannattaa käydä läpi, ennen kuin lisäosan ottamisesta pois käytöstä tehdään päätöstä.

Ylikuormittuneen tietokannan aiheuttama kokonaishitaus

Huonosti optimoitu tietokanta voi hidastaa koko WordPress-sivuston toimitaa. Aikaisemmin kävimme läpi eri asioita, joiden avulla tämän voi korjata New Relicissä tietokantaan liittyvä hitaus näkyy todennäköisesti kahdessa paikassa:

  • Ensinnäkin MySQL-toimintaa on erikoinen määrä (overview-välilehti).
  • Toiseksi näet, että yksi tai useampi tietokannan taulukoista viel paljon aikaa (databases-välilehti).

Jos aloitamme overview-välilehdestä, tietokannan kanssa kamppaileva sivusto saattaa palauttaa seuraavaa muistuttavia tietoja:

Internetin transaktioajat

Internetin transaktioajat

Tämän jälkeen databases-välilehdeltä saa lisätietoja siitä, mikä tietokantataulukko tai -kysely saattaa olla syypää.

MySQL-yleisnäkymä

MySQL-yleisnäkymä

Databases-välilehdeltä näkyy, mikä taulukko ja minkälainen kysely vievät eniten aikaa. Jos valitset jonkun listassa olevista vaihtoehdoista, saat yksityiskohtaisempaa tietoa sekä esimerkkikyselyjä.

Hidas kysely – wp_options-taulukko

Hidas kysely – wp_options-taulukko

Tässä tapauksessa datan syyttävä sormi osoittaa automaattisesti latautuvaa dataa wp_options-taulukkoa. Muistatko, että tämä on käyty jo läpi? Todellakin, nopea wp_options-taulukon analyysi vahvistaa, että lähes 250 MB dataa latautuu tästä taulukosta automaattisesti. Näin ollen on selvää, että tässä on todennäköisesti tietokantahuollon ja -optimoinnin paikka.

Olemme koonneet yksityiskohtaisen tutoriaalin New Relicin käyttämisestä suorituskykyongelmien ratkaisemiseen WordPress-sivustolla.

Käytä ilmaista Query Monitor -lisäosaa

Voit käyttää myös ilmaista Query Monitor -lisäosaa. Käytä sitä etsimään ja ratkaisemaan ongelmia, jotka koskevat tietokantakyselyjä, AJAX-kutsuja, REST API -pyyntöjä ja paljon muuta. Lisäksi lisäosa tarjoaa ylimääräisiä tietoja kuten skriptien riippuvuuksia, sivun luonnin aikana toiminnassa olleita WordPress-koukkuja, hosting-ympäristön yksityiskohtia, sivun konditionaalisia kyselytageja ja paljon muuta.

WordPress-kyselyjä Query Monitor -lisäosassa

WordPress-kyselyjä Query Monitor -lisäosassa

Lisäosan on kehittänyt John Blackbourn, WordPressin ytimen teossa mukana oleva ohjelmistokehittäjä Human Madelta. Hän oli aikaisemmin töissä WordPress.com VIP:ssä ja on näin ollen ihminen, joka taatusti tuntee WordPressin läpikotaisin. Query Monitor lisättiin WordPress-lisäosaluetteloon vuonna 2013 ja sillä on tällä hetkellä yli 10 000 aktiivista asennusta – mikä on huomattava määrä lisäosan tyypin huomioon ottaen. Sillä on myös viisi tähteä viidestä, mikä selittää sen suosiota kehittäjien keskuudessa.

Meillä on täysi tutoriaali Query Monitorin käyttämiseen.

Käytä testiympäristöjä koskematta tuotantosivustoon

Emme tiedä, mitä tekisimme ilman testiympäristöjä. Ne ovat erityisen arvokkaita, kun sivustolta etsitään suorituskykyongelmia. Onneksi Kinstalle on yhden painalluksen kehitysympäristöjä. Jos WordPress-isäntäsi ei tarjoa testiympäristöä, voit myös käyttää lisäosaa kuten WP Staging, vaikka se ei olekaan helppoa.

WordPressin testiympäristö

WordPressin testiympäristö

Hetki, kun sinulla on testisivu käytössäsi, ensimmäiseksi kannattaa ottaa kaikki lisäosat pois käytöstä. Koska kyseessä on julki olevan sivuston kopio, sinun ei tarvitse pelätä, että rikot jotain. Tämä on yksi helpoimmista tavoista löytää ongelmakohtia. Siirry kohtaan Plugins, valitse ne kaikki ja valitse “Deactivate” kohdasta Bulk Actions.

Ota kaikki WordPress-lisäosat pois käytöstä

Ota kaikki WordPress-lisäosat pois käytöstä

Tämän jälkeen voit pitää vastausaikoja silmällä New Relicissä tai Query Monitorissa nähdäksesi, mitä tapahtuu. Alla olevassa esimerkissä vastausajat putosivat normaaliksi heti, joten tiesimme, että jokin lisäosista aiheutti ongelmia. Ota lisäosat yksi kerrallaan takaisin käyttöön ja näet tuloksista, mikä aiheuttaa ongelmia.

Normaalit vastausajat

Normaalit vastausajat

Tässä esimerkki siitä, mitä tapahtui, kun otimme takaisin käyttöön ongelmia aiheuttavan lisäosan. Latausajat (web transactions time) nousivat heti.

Jälleen pitkä vastausaika

Jälleen pitkä vastausaika

Mitä kannattaa tehdä, kun hitautta aiheuttava lisäosa on löydetty? Tässä ohjeemme:

  1. Päivitä lisäosat ja teemat uusimpiin versioihin, jos et ole sitä vielä tehnyt.
  2. Ota yhteyttä lisäosan tai teeman kehittäjään ja pyydä apua. 
  3. Etsi korvaava lisäosa, joka tarjoaa samoja ominaisuuksia.
  4. Ehkä PHP-versio aiheuttaa ongelmia. Vaihda PHP-kone alempaan versioon ja katso, toimiiko lisäosa tai teema sitten.

Voit palkata myös WordPress-ohjelmistokehittäjän korjaamaan ongelma. Jos kyse on suorituskykyongelmasta, meidän on mainittava WP Bulletin Mike Andreason. Hän on täysipäiväinen Codeable-ohjelmistokehittäjä, jonka erikoisalaa on suorituskyvyn optimointi. Hän on auttanut monta Kinstan asiakasta, joiden monimutkaiset sivustot hän on saanut toimimaan aivan uudella tavalla.

WP Bullet: ennen ja jälkeen

WP Bullet: ennen ja jälkeen

Käy läpi virheilmoitukset

Virheilmoituksia säilövien error-logien läpikäyminen ei ole koskaan hauskaa, mutta sieltä voi saada paljon tietoa WordPress-lisäosien suorituskykyongelmista. Jos olet Kinstan asiakas, pääset error-, välimuisti- ja pääsylogeihin sisään suoraan MyKinsta-hallintapaneelista.

Virheilmoitusten error-logi MyKinstassa

Virheilmoitusten error-logi MyKinstassa

Voit ottaa virheilmoituslogit käyttöön myös lisäämällä vähän koodia wp-config.php-tiedostoon. Ensin sinun täytyy ottaa sivustoosi yhteys SFTP:llä. Lataa sitten wp-config.php, jotta voit muokata sitä. Huomio: Luo tiedostosta varmuuskopio ensin!

Lataa wp-config.php-tiedosto

Lataa wp-config.php-tiedosto

Etsi rivi, jossa lukee  /* That's all, stop editing! Happy blogging. */ a juuri ennen sitä lisää seuraava (kuten alla näkyy):

define( 'WP_DEBUG', true );
WP_DEBUG

WP_DEBUG

Jos alla oleva koodi on jo olemassa wp-config.phptiedostossa mutta sen arvo on ”false”, vaihda siihen ”true”. Näin ongelmakohtien etsintä on käynnissä. Huomio: Näet varoituksia ja virheilmoituksia myös WordPress-adminissa, jos niitä on.

Voit sitten asettaa login lähettämään kaikki virheilmoitukset tiedostoon lisäämällä seuraavan koodin (kuten alla näkyy) WP_DEBUG-rivin alle:

define( 'WP_DEBUG_LOG', true );
WP_DEBUG_LOG

WP_DEBUG_LOG

Tallenna muutokset ja siirrä tiedosto palvelimelle. Virheilmoitukset kirjoitetaan debug.log-tiedostoon, joka sijaitsee /wp-content/ -kansiossa. Jos tiedostoa ei jostain syystä näy, voit luoda sellaisen.

Käytä MyKinsta Analytics -tietoja

Jos olet Kinstan asiakas, voit aina käyttää hyväksesi suorituskykytietoja, jotka olemme sisäänrakentaneet MyKinsta Analytics -työkaluun.

Seurantakohdasta (monitoring) näkyvät keskimääräiset PHP- ja MySQL-vasteajat, PHP-läpimenotiheys, AJAX-käyttö sekä keskimääräisen upstream-ajan huiput ja maksimi.

Keskimääräiset PHP- ja MySQL-vasteajat

Aina kun käyt WordPress-sivustollasi, PHP:tä ja MySQL:ää käytetään näkyvän datan kyselemiseen ja järjestämiseen. Alla oleva näkymä kertoo, mikä PHP- ja MySQL-koneiden keskimääräinen vasteaika on ollut dynaamisissa pyynnöistä, joita ei ole suoritettu välimuistista. Näiden vasteaikojen tietäminen voi auttaa hitauden syyn selvittämisessä.

Suorituskyky – keskimääräiset PHP- ja MySQL-vasteajat

Suorituskyky – keskimääräiset PHP- ja MySQL-vasteajat

PHP-läpimenotiheys

Läpimenotiheys (throughput) tarkoittaa sovelluksen käsittelemien transaktioiden maksimimäärää per sekunti. Tässä raportissa sillä tarkoitetaan PHP:n suorituskykyä WordPress-sivustolla. Toisin sanoen se näyttä, kuinka monta kertaa yhtä PHP-yksikköä on pyydetty.

Suorituskyky – PHP-läpimenotiheys

Suorituskyky – PHP-läpimenotiheys

AJAX-käyttö

AJAX on asiakkaan puoleinen skripti, jonka kanssa palvelin tai tietokanta kommunikoi ilman, että sivua täytyy päivittää. WordPressin kohdalla moni on nähnyt tämän nopeustesteissään. AJAXin käytön kaksi merkittävintä ongelmaa ovat yleensä lisäosat, jotka aiheuttavat piikkejä, ja backend-puolen CPU-ongelmat.

Admin-AJAX-käyttö

Admin-AJAX-käyttö

Lue lisää tutoriaalistamme, kuinka suurta Admin-AJAX-käyttöä voi diagnosoida WordPress-sivustolla.

AJAX-käytön raportti MyKinsta Analytics -osiossa voi auttaa suuresti, kun tällaisten ongelmien syitä etsitään, koska se näyttää tietyt AJAX-piikit tiettyinä ajankohtina. Alla oleva esimerkki näyttää admin-ajax-pyyntöjen määrän. Voit käyttää tässä artikkelissa mainittuja vinkkejä löytääksesi niihin syyllisen.

AJAX-käyttö

AJAX-käyttö

Keskimääräiset PHP- ja MySQL-vasteaikahuiput

Tuskailetko kaatuilevan sivuston tai muiden WordPress-ongelmien kanssa? Kinsta on hosting-ratkaisu, joka säästää aikaasi! Tutustu ominaisuuksiin

Alla oleva lista näyttää PHP:n ja MySQL:n vasteaikojen keskimääräiset huiput. Kyseiset numerot saattavat olla kertaluontoisia, joten niitä kannattaa verrata upstream-aikojen huippuihin.

Keskimääräiset PHP- ja MySQL-vasteaikahuiput

Keskimääräiset PHP- ja MySQL-vasteaikahuiput

Upstream-aikojen huiput

Upstream-ajalla tarjoitetaan kokonaisaikaa, joka NGINXiltä (ja upstream-palvelimilta) kestää pyynnön prosessoimiseen ja vastauksen lähetämiseen. Aikaa mitataan sekunneissa millisekunnin tarkkuudella. Lue lisää NGINXin metriikasta.

Upstream-aikojen huiput

Upstream-aikojen huiput

Sivustollesi on ehkä hakkeroiduttu

Jos sinun on vaikea löytää syytä suorituskykyongelmaa, on mahdollista, että sivustollesi on hakkeroiduttu, se on saanut haittaohjelmatartunnan tai sitä vastaan on käynnissä DDoS-hyökkäys. Tämä voi vaikuttaa sivustosi nopeuteen ja jopa WordPress-hallintapaneelin responsiivisuuteen. Näissä tapauksissa suosittelemme seuraavaa:

  1. Ota käyttöön proxypalvelin ja WAF kuten Cloudflare tai Sucuri.
  2. Blokkaa huonot IP-osoitteet yllä olevia palveluita käyttäen. Jos olet Kinstan asiakas, voit myös blokata IP-osoitteita MyKinsta-hallintapaneelista.
  3. Voit ottaa myös käyttöön niin sanotun geo-blockingin. Joidenkin maiden kohdalla käy niin, että sieltä tuleva liikenne on huonolaatuista. Jos sinua vastaan hyökätään, saatat joutua blokkaamaan kokonaisen maan, joko tilapäisesti tai pysyvästi.

Ongelmakohtien löytäminen virheilmoitusten avulla (http-statuskoodit)

HTTP-statuskoodit ovat kuin lyhyitä muistiinpanoja internetpalvelimelta, ja niitä laitetaan joka sivun yläosaan. Se ei ole osa sivua. Sen sijaan se on viesti palvelimelta. Se kertoo, mitä tapahtui, kun palvelin sai pyynnön näyttää sivu. Nämä voivat olla kultaakin kalliimpaa ongelmia etsiessä!

Koodeja on yli 40 erilaista. Alla tavallisimmat, joiden kanssa näemme WordPress-käyttäjien taistelevan.

429: “Too many requests” eli liian monta pyyntöä. Palvelin luo tämän virheilmoituksen, kun käyttäjä on lähettänyt liian monta pyyntöä liian lyhyessä ajassa (rate limiting). Joskus näin käy, kun botti tai skripti yrittää pääsyä sivustolle. Tässä tilanteessa kannattaa muuttaa WordPress-sisäänkirjautumisen URL-osoitetta.

429 liian monta pyyntöä

429 liian monta pyyntöä

500: “There was an error on the server and the request could not be completed” eli palvelimella tapahtui virhe eikä pyyntöä voitu täyttää. Yleisluontoinen koodi, joka tarkoittaa sisäistä palvelinvirhettä. Jokin meni palvelimella vikaan eikä pyydettyä resurssia voitu toimittaa. Usein tämän virheilmoituksen aiheuttaa kolmannen osapuolen lisäosa, huono PHP tai se, että yhteys tietokantaan katekaa. Lue lisää tutoriaaleistamme tietokantayhteyden korjaaminen sekä muita tapoja 500-virheilmotus korjaaminen: sisäinen palvelinvirhe.

Ongelmia tietokantayhteydessä

Ongelmia tietokantayhteydessä

502: “Bad Gateway”eli huono portti. Tällä yleensä tarkoitetaan, että yksi palvelin on saanut toiselta epäkelvon vastauksen. Joskus kyselyssä tai pyynnössä kestää liian pitkään, joten palvelin keskeyttää sen ja yhteys tietokantaan katkeaa. Lue lisää yksityiskohtaisesta artikkelistamme 502 Bad Gateway -virheilmoituksesta.

502 Bad Gateway -virheilmoitus selaimessa

502 Bad Gateway -virheilmoitus selaimessa

503: “The server is unavailable to handle this request right now” eli palvelinta ei saada juuri nyt käsittelemään pyyntöä. Pyyntöä ei siis voida viedä loppuun. Tämä koodi saattaa tulla silloin, kun palvelin on ylikuormittunut eivätkä sen resurssit riitä lisäpyyntöjen käsittelyyn.

504: “The server, acting as a gateway, timed out waiting for another server to respond” eli välikätenä toimiva palvelin ei saanut toiselta palvelimelta vastausta tarpeeksi nopeasti. Tämä koodi tulee silloin, kun pyynnön käsittelemiseen tarvitaan ja kahta palvelinta eikä ensimmäinen saa toiselta vastausta tarpeeksi nopeasti. Lue lisää siitä, kuinka 504-virheilmoituksen voi korjata.

504 gateway timeout -virheilmoitus selaimessa

504 gateway timeout -virheilmoitus selaimessa

Nämä http-vastauskoodit löytyvät myös MyKinsta Analytics -työkalusta. Vastauskoodien raportista näet, mitä http-vastauskoodeja pyydetyt resurssit lähettävät eniten.

Vastauskoodien raportti

Vastauskoodien raportti

“Response Stats” -kohdasta näet seuraavat: uudelleenohjausten ja virheilmoitusten määrät, onnistumisprosentin ja virheilmoitusten suhteutetun märän. Jokainen WordPress-sivusto tuottaa pienen määrän virheilmoitusia; se on täysin normaalia.

Vastausten tilastoja

Vastausten tilastoja

Sen jälkeen erilaisista virheilmoituksista näkyy lisätietoja – 500- tai 400-alkuiset virheilmoitukset, uudelleenohjaukset jne.

500-virheilmoitusten lisätietoja

500-virheilmoitusten lisätietoja

Suosituksia backend-puolen optimoinneiksi

Nyt käymme läpi tapoja, joilla voit nopeuttaa WordPressin toimintaa optimoimalla sitä backend-puolelta. Siihen sisältyy yleensä asiat, jotka palvelin hoitaa kokonaan, kuten PHP, http-välimuistiotsikot, GZIP-pakkaus, jne.

Luo kevyt 404-sivu

Olemme itse nähneet, että erittäin dynaamiset sivustot yleensä luovat paljon 404-virheilmoituksia. Sinunkin sivustosi saattaa luoda niitä enemmän kuin uskokaan! MyKinsta Analytics -työkalun avulla voit päätellä tarkan määrän (kuten alla näkyy).

404-virheilmoituksia

404-virheilmoituksia

Syy, miksi nämä virheilmoitukset ovat vahingoksi, on se, että moni 404-virheilmoitussivu on vie paljon resursseja. Erityisesti erittäin dynaamisella WordPress-sivustolla kannattaa välttää raskasta 404-sivua. Luo yksinkertainen 404-sivu, joka ei turhaan tee tietokantakyselyjä. Ja totta kai kannattaa käyttää aikaa myös 404-virheiden korjaamiseen, koska se ei ole pelkästään resursseja vievä asia vaan myös käyttäjän kannalta epämiellyttävää. 

Lisää PHP-työläisten määrää

PHP-työlaiset (PHP workers) saattaa olla termi, josta et ole koskaan kuullutkaan. Moni isäntä, myös Kinsta, käyttää niitä pyyntöjen rajoittamiseen (sen sijaan, että rajoitettaisiin CPU:ta tai RAM:ia, kuten jaetun hostingin tarjoajat yleensä tekevät).

PHP-työläisten määrän mukaan määräytyy, montako samanaikaista pyyntöä sivusto pystyy prosessoimaan. Yksinkertaisesti sanottuna kukin pyyntö, jota ei pystytä tarjoilemaan välimuistista, tulee PHP-työläisen hoidettavaksi. Jos esimerkiksi sivustolle tulee täsmälleen samalla hetkellä 4 pyyntöä ja sillä on 2 PHP-työläistä, kaksi pyynnöistä käsitellään, ja toiset kaksi joutuvat sen aikaa odottamaan jonossa. 

Ehkä muistat, että puhuimme aikaisemmin siitä, että yksi WordPress-jäsensivustojen suurimmista ongelmista ovat kyselyt, joita ei voida hoitaa välimuistista. Tämän takia PHP-työläiset ovat tärkeitä, sillä niiden täytyy tehdä työtä kunkin pyynnön eteen. Näin ollen tämänkaltaiset sivustot vaativat yleensä enemmän PHP-työläisiä varmistamaan, että jotainen kysely prosessoidaan nopeasti ja viedään onnistuneesti loppuun.

Mitä tapahtuu, jos PHP-työläisillä on koko ajan liikaa työtä? Periaatteessa jono alkaa työntää ulos vanhempia kyselyjä, mikä johtaa sivuston luomiin 500-virheilmoituksiin. Kukin Kinstan hosting-paketeista sisältää tietyn määrän PHP-työläisiä. Jos sinulla on vaikeuksia sen arvioimisessa, montako sivustosi todennäköisesti tarvitsee, voit aina ottaa yhteyttä myynti- tai asiakastukitiimiimme.

Hyödynnä GZIP-pakkausta

GZIP on tiedostomuoto ja ohjelmistosovellus, jota käytetään tiedoston pakkaamiseen ja purkamiseen. GZIP-pakkaus on käytössä palvelintasolla ja sallii HTML-, stylesheet- ja JavaScript-tiedostojen koon pienentämisen.

Kun selain käy sivustolla, se tarkistaa, onko palvelimella GZIP käytössä katsomalla, onko content-encoding: gzip HTTP-otsikkotieto olemassa. Jos otsikkotieto löytyy, tiedostot tulevat pakattuina ja pienempinä. Jos ei, käytetään pakkaamattomia tiedostoja. Jos sinulla ei ole GZIP:iä käytössä, saat todennäköisesti virheilmoituksia nopeustestityökaluilta kuten Google PageSpeed Insights ja GTmetrix.

content-encoding: gzip

content-encoding: gzip

GZIP-pakkauksen käyttöönotto voi auttaa sivuston koon pienentämisessä, mikä taas voi vaikuttaa resurssien latausnopeuteen, vähentää asiakkaan datankäyttöä ja parantaa latausaikoja. Se on nykyään melko yleinen useimmilla hosting-palveluntarjoajilla, mutta mikään ei enää yllätä meitä.

Otta käyttöön hotlink-suojaus

Termillä hotlinking tarkoitetaan seuraavaa: Kun löydät jonkun kuvan jostakin internetistä ja haluat käyttää sitä omalla sivullasi, kopioit sen URL-osoitteen sivustollesi. Se näkyy sivustollasi, vaikka se sijaitsee alkuperäisessä sijainnissa. Tämä on osoitteen kopioijan kannalta kätevää, mutta oikeastaan kyse on varkaudesta – kuva näet käyttää alkuperäisen sivuston resursseja. Vähän sama, kuin jos nousemme autoomme ja ajamme pois naapurilta varastetulla bensalla.

Hotlinking is like driving away with gas you siphoned off from your neighbor's car. 🚗 Click to Tweet

Hotlinking voi olla todellinen resurssisyöppö. Kuvittele, että käytössäsi on jaettu WordPress-hosting ja Huffington Post yhtäkkiä ohjaa ihmisiä kuviisi. Muutamasta sadasta kyselystä per tunti mennään hetkessä satoihin tuhansiin. Tämä voi johtaa jopa siihen, että hosting-palveluntarjoajasi keskeyttää palvelunsa. Tämän takia kannattaa näyttää korkeaan suorituskykyyn kykenevää hosting-palvelua (joka pärjää näissä tilanteissa), mutta kannattaa myös suojautua hotlinking-tilanteilta.

Lue lisää tutoriaalistamme: kuinka hotlinkingin voi estää.

Minimoi uudelleenohjaukset ja lisää ne palvelintasolle

Kannattaa aina varoa, ettei uudelleenohjauksia synny liikaa. Yksinkertaiset uudelleenohjaukset kuten 301, http:stä https:ään ja www-osoitteesta osoitteeseen ilman www-tunnusta toimivat kyllä. Usein näiden käyttö kannattaa sivuston jollain osuudella. Niillä on kuitenkin vaikutuksensa sivuston suorituskykyyn. Ja jos alat pinota uudelleenohjauksia toistensa päälle, on tärkeää ymmärtää, kuinka suuri tuo vaikutus on. Tämä koskee sivu- ja postausuudellen ohjauksia, kuvauudelleenohjauksia, kaikkea.

Uudelleenohjaus luo 301- tai 302-otsikkotietovastauksen.

Minimoi uudelleenohjaukset – 301

Minimoi uudelleenohjaukset – 301

Paljonko uudelleenohjaukset vaikuttavat sivustoosi? Tehdäänpä pieni testi. Ensin teemme nopeustestin pota yhteyttä -sivulla: https://perfmatters.io/contact/. Kuten alla näkyy, kokonaisulatausaika on 417 ms.

Nopeustesti sivustolla ilman uudelleenohjauksia

Nopeustesti sivustolla ilman uudelleenohjauksia

Teemme sitten URL-osoitteeseen pienen muutoksen ja ajamme uuden nopeustestin nähdäksemme, miten useat uudelleenohjaukset vaikuttavat. http://www.perfmatters.io/contact. Kuten näkyy, sivun lataus kestää nyt 695 ms. Kasvua on 66%. Hui!

Sivuston nopeustesti useilla uudelleeohjauksilla

Sivuston nopeustesti useilla uudelleeohjauksilla

Ilmaisten WordPress-lisäosien käyttö uudelleenohjausten tekemiseen saattaa toisinaan aiheuttaa ongelmia suorituskyvyn kanssa, sillä moni niistä käyttää wp_redirect-funktiota, mikä puolestaan toteuttaa enemmän koodia ja vie resursseja. Moni lisää myös automaattisesti latautuvaa dataa wp_options-taulukkoon, mikä suurentaa sen kokoa. Uudelleenohjaukset tulisi lisätä palvelintasolla. Voit tehdä sen MyKinstassa Redirect Rules -työkalun avulla.

Lisää 301-uudelleenohjaus

Lisää 301-uudelleenohjaus

MyKinsta Analytics-työkalun avulla voit pitää kirjaa siitä, paljonko uudelleenohjauksia sivustollasi tapahtuu. Ne on merkitty luokkiin 301, 302 tai 304.

Uudelleenohjauksien luokkia

Uudelleenohjauksien luokkia

Meillä on yksityiskohtainen artikkeli WordPressin uudelleenohjauksista ja suorituskyvyn kannalta parhaista toimintotavosita.

Älä anna cron-ajojen päästä käsistä

CRON-ajoja (WP-Cron) käytetään toistuvien toimintojen aikatauluttamiseen. Ajan kuluessa niiden määrä saattaa kuitenkin päästä käsistä ja aiheuttaa suorituskykyongelmia. Voit käyttää ilmaista WP Crontrol -lisäosaa otaaksesi kaikki sivustolla tapahtuvat cron-ajot haliintaan.

Olemme nähneet myös sen, että WordPressin sisäänrakennettu cron-ajojen hallinnointitoiminto, WP-Cron, aiheutta ongelmia. Jos sivustolla ei ole tarpeeksi PHP-työläisiä, pyyntö saattaa tulla läpi, jolloin WordPress luo cron-ajon, joka joutuu odottamaan työläistä ja jää roikkumaan. Parempi tapa on ottaa WP-Cron pois käytöstä ja käyttää järjestelmän cronia sen sijaan. Tätä suositellaan jopa virallisessa lisäosakäsikirjassa.

WP-Cronin poistaminen käytöstä tapahtuu niin, että lisäät alla olevan koodin wp-config.php-tiedoston “That’s all, step editing! Happy blogging.” -rivin ylle. Huomio: Tämä ottaa sen pois käytöstä sivun latautuessa, ei silloin, kun sitä kutsutaan suoraan wp-cron.php:llä..

define('DISABLE_WP_CRON', true);
Ota WP-Cron pois käytöstä

Ota WP-Cron pois käytöstä

Tämän jälkeen sinun täytyy ajastaa wp-cron.php palvelimeltasi. Jos olet Kinstan asiakas, järjestelmän cronit ovat jo käytössä ja ajetaan 15 minuutin välein oletusasetuksena. Jos haluat niitä ajettavan useammin, voit ottaa yhteyttä asiakastukeemme. Jos tunnet SSH:ta, voit hallinnoida palvelimen cron-ajoja komentoriviltä..

Ota käyttöön välimuistihallinta ja vanhentumistiedot (eli määrittele välimuistitallennuksen kesto)

WordPress-sivustolla jokainen skripti tarvitseen HTTP-välimuistiotsikkotiedon. Se on aina liitetty skriptiin (tai sen pitäisi olla). Se määrittelee, milloin tiedoston välimuistitallennus päättyy. Korjataksesi tämän varmista, että WordPress-isännälläsi on käytössä otsikkotiedot cache-controlja expires. Jos näin ei ole, näet todennäköisesti varoituksia siitä, että ne pitää lisätä, tai ilmoituksia niin sanotusta leverage browser -välimuistitallennuksesta nopeustestityökaluja käyttäessäsi.

cache-control-otsikkotieto ottaa käyttöön asiakkaan puoleisen välimuistitallennuksen ja määrittelee, kauanko resurssia pidetään siellä expires-otsikkotietoa sen sijaan käytetään määrittelemään ajankohta, jolloin resurssi ei enää ole validi. Molempia otsikkotietoja voidaan käyttää yhdessä, mutta se ei ole pakollista. cache-control on uudempi, ja sitä yleensä suositellaan.

Kinsta lisää HTTP-välimuistiotsikkotiedot kaikkiin palvelinpyyntöihin, ja jos käytät CDN:ää, se todennäköisesti lisää otsikkotiedot myös sinun puolestasi.

Leverage browser -välimuistitallenus: otsikkotiedot

Leverage browser -välimuistitallenus: otsikkotiedot

Jos nämä otsikkotiedot puuttuvat palvelimeltasi, voit lisätä ne manuaalisesti.

Cache control -otsikkotiedon lisääminen Nginxiin
Voit lisätä cache-control-otsikkotiedot Nginxiin lisäämällä seuraavan koodin palvelimen konfiguroinnin palvelinsijaintiin tai -blokkiin.

location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
 expires 30d;
 add_header Cache-Control "public, no-transform";
}

Expires-otsikkotiedon lisääminen Nginxiin

Voit lisätä expires-otsikkotietoja Nginxiin lisäämällä alla olevan koodin palvelinblokkiin. Tässä esimerkissä näet, miten voit määritellä ajat tiedostotyyppien perusteella.

Cache control -otsikkotiedon lisääminen Apacheen

Voit lisätä cache-control-otsikkotietoja Apacheen lisäämällä seuraavan .htaccess-tiedostoon. Koodinpaloja voi lisätä tiedoston alkuun tai loppuun (ennen kohtaa # BEGIN WordPress tai kohden # END WordPress jälkeen).


Header set Cache-Control "max-age=84600, public"

Expires-otsikkotietojen lisääminen Apacheen

Voit lisätä expires-otsikkotietoja Apacheen lisämällä seuraaan .htaccess-tiedostoon.

## EXPIRES HEADER CACHING ##

ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"

## EXPIRES HEADER CACHING ##

On myös tärkeä huomata, että voit lisätä http-välimuistiotsikkotietoja vain niihin resursseihin, jotka sijaitsevat palvelimellasi. Jos saat varoituksia siitä, että sinun täytyy ottaa käyttöön leverage browser caching kolmannen osapuolen kohdalla, et voi tehdä asialle mitään, koska et pysty vaikuttamaan heidän palvelimeensa. Usein syypää ongelmiin on esimerkiksi Google Analyticsin skripti tai markkinointipikselit kuten Facebook tai Twitter.

Jos yrität korjata tätä Google Analyticsin skriptillä, voit ottaa sen omalle palvelimellesi tai CDN:llesi (vaikka tätä ei virallisesti tueta) lisäosalla kuten Perfmatters tai WP Rocket.

Lisää otsikkotieto Last-Modified tai ETag (välimuistin varmentaminen

Seuraavaksi käymme läpi kaksi otsikkotietoa last-modified ja etag.

Kuten yllä kävimme läpi cache-control ja expires-otsikkotiedot kertovat selaimelle, onko tiedostoa muutettu sen jälkeen, kun sitä viimeksi pyydettiin (tai pikemminkin ne vahvistavat välimuistin). last-modified ja etag-otsikot vahvistavat ja määrittävät välimuistinc pituuden ja ne olisi sisällytettävä jokaisen alkupalvelimen vastaukseen. Jos nämä tiedot eivät ole kunnossa, saatat saada virheilmoituksen, joka antaa ohjeen ”Specify a cache validator” eli varmenna välimuisti.

Last-modified- ja ETag-otsikkotietoja

Last-modified- ja ETag-otsikkotietoja

Jos otsikkotietoja ei löydy, resurssista luodaan joka kerta uusi pyyntö, mikä lisää palvelimen kuormaa. Välimuistitallennusta koskevien otsikkotietojen käyttö varmistaa, ettei samaa resurssia tarvitse ladata palvelimelta monta kertaa, mikä säästää kaistaa ja parantaa suorituskykyä käyttäjän kannalta.

Kinsta lisää yllä mainitut otsikkotiedot kaikkiin palvelinkyselyihin, ja jos käyty CDN:ää, se todennäköisesti lisää ne myös. Ja kuten otsikkotietojen cache-control ja expires kohdalla, et voit lisätä http-otsikkotietoja ulkoisiin resursseihin.

Otsikkotieto: Last-Modified

Otsikkotieto nimeltä last-modified lähetetään yleensä palvelimelta automaattisesti. Tätä sinun ei pitäisi joutua lisäämään manuaalisesti. Se lähetetään, jos selaimen välimuistissa olevaa tiedostoa on muutettu sen jälkeen, kun sitä on viimeksi pyydetty. Voit käyttää Pingdomia tai Chrome DevToolsia nähdäksesi, mikä otsikkotiedon arvo on

Otsikkotieto: ETag

ETag-otsikkotieto on samankaltainen kuin last-modified. Sitä käytetään välimuistissa olevan tiedoston varmentamiseen. Jos käytössäsi on Apache 2.4 tai uudempi, ETag lisätään automaattisesti käyttäen FileETag-direktiiviä. Mitä tulee NGINXiin, ETag on ollut oletusasetuksena päällä vuodesta 2016 alkaen.

Voit ottaa ETag-otsikkotiedon manuaalisesti käyttöön Nginxissä seuraavaa koodia käyttäen:

etag on

Lisää otsikkotieto: “Vary: Accept-Encoding”

vary: Accept-Encoding -otsikkotiedon tulisi olla mukana jokaisessa lähdepalvelimen vastauksessa, sillä se kertoo selaimelle, kykeneekö asiakas ottamaan vastaan pakattuja sisältömuotoja. Jos otsikkotietoa ei ole laitettu kuntoon, saatat saada seuraavan virheilmoituksen: ”Specify a Vary: Accept-Encoding Header.”

Sanotaan esimerkiksi, että käytössäsi on vanhempi selain ilman gzip-pakkausta ja uudempi selain, jossa sellainen on. Jos et käytä vary: Accept-Encoding  -otsikkotietoa, palvelimesi tai CDN-palveluntarjoajasi saattaa tallentaa välimuistiin pakkaamattoman version tiedostosta ja toimittaa sen vahingossa uuteen selaimeen. Tämä haittaa WordPress-sivuston suorituskykyä. Otsikkotietoa käyttämällä varmistat, että palvelimesi ja CDN-palveluntarjoajasi toimittavat oikean version.

vary: Accept-Encoding HTTP header

vary: Accept-Encoding HTTP header

Kinsta lisää yllä mainitut otsikkotiedot kaikkiin palvelinkyselyihin, ja jos käytät CDN:ää, se todennäköisesti lisää ne myös. Kuten muutkin välimuistiotsikkotiedot, joista olemme yllä puhuneet, kyseessä on asia, johon ei manuaalisesti pysty vaikuttamaan ulkoisten resurssien kohdalla.

Lisää “Vary: Accept-Encoding” -otsikkotieto Apachessa

Voit lisätä “vary: Accept-Encoding” -otsikkotiedon Apachessa lisäämällä seuravan koodin .htaccess-tiedostoon.

  
    Header append Vary: Accept-Encoding

Lisää “Vary: Accept-Encoding” -otsikkotieto Nginxissä

Voit lisätä “vary: Accept-Encoding” -otsikkotiedon Nginxissä lisäämällä alla olevan koodin config-tiedostoon. Kaikki Nginxin konfigurointitiedostot löytyvät kansiosta /etc/nginx/ Ensisijainen konfiguraatiotiedosto on /etc/nginx/nginx.conf.

gzip_vary on

WordPress-muistirajoituksen muuttaminen wp-config.php-tiedostossa

Kuten WordPress Codexissa sanotaan, WordPressin versiosta 2.5 lähtien WP_MEMORY_LIMIT-vaihtoehto sallii käyttäjän asettaa maksimimuistimäärä, joka PHP:llä on käytössään. Tämä saattaa olla tarpeellinen, mikä saat ilmoituksia kuten “Allowed memory size of xxxxxx bytes exhausted”.

Oletusasetuksena WordPress yrittää nostaa PHP:lle sallitun muistin määrän 40 MB:hen yhden sivuston kohdalla ja 64 MB:hen, jos kyseessä on monisivusto. Muistirajoitukset määritellään tiedostossa ./wp-includes/default-constants.php riveillä 32 – 44 (lähde).

PHP:n muistirajoitus eli memory_limit saattaa olla käytössä myös hosting-palveluntarjoajasi palvelimella. Nämä ovat kaksi eri asiaa. Kinstalla memory_limit-oletusmäärä on to 256 MB. Jos törmäät virheilmoitukseen, jonka mukaan muistia on liian vähän, kokeile PHP-muistirajoituksen nostamista WordPressissä.

Lisää alla oleva koodi wp-config.php-tiedostoon juuri sen rivin yläpuolelle, jossa lukee: “That’s all, step editing! Happy blogging.”

define( 'WP_MEMORY_LIMIT', '256M' );

Jan Reilink on kirjoittanut erinomaisen blogikirjoituksen, joka käy läpi WordPressin muistirajoitusongelmia yksityiskohtaisemmin. Hän tarjoaa myös vaihtoehtoista koodia, jota voi käyttää. Sen sijaan, että asettaisit määrän manuaalisesti, voit asettaa sen käyttämään PHP:n memory_limit

define( 'WP_MEMORY_LIMIT', ini_get( 'memory_limit' ) );

Vinkkejä frontend-puolen optimointiin ja ulkoisiin palveluihin

Nyt käymme läpi tapoja, joilla voit nopeuttaa WordPressin toimintaa frontend-puolelta. Frontendillä yleensä tarkoitetaan kaikkea, jonka asiakkaanpuoleinen selain hoitaa, kuten CSS, JavaScript, kuvat, jne. Tähän sisältyy sivun käyttämien ulkoisten palveluiden analysointi ja sen päätteleminen, paljonko ne vaikuttavat kokonaislatausaikoihin.

Kaksi tärkeintä päämäärää, jotka frontend-optimoinnin kohdalla kannattaa pitää mielessä, ovat:

  • Sivun kokonaiskoon pienentäminen. CSS:n, JavaScriptin ja kuvien koolla on väliä. Sivusto, jonka koko on 4 MB, latautuu yleensä paljon hitaammin kuin sivusto, jonka koko on 1 MB. Paul Calvano on kirjoittanut loistavan artikkelin siitä, paljonko sivun paino vaikuttaa latausaikoihin. Kannatta varmistaa, ettei se ole ainut asia, mihin kiinnität huomiota, sillä se saattaa johtaa harhaan.
  • HTTP-pyyntöjen ja ulkoisten palveluiden vähentäminen. HTTP/2:ssa useita pyyntöjä ja vastauksia voidaan nyt lähettää samanaikaisesti yhden TCP-yhteyden ylitse. Suorituskyvyn kannalta se on hienoa, mutta http-pyyntöjen määrän vähentäminen voi silti nopeuttaa WordPress-sivustoasi. Myös ulkoisten pyyntöjen ja palveluiden määrää kannattaa vähentää. Jokainen niistä lisää viiveaikoja kuten DNS-tarkistukset, TLS-yhteydet ja verkon latenssi.

Tee WordPress-sivustollesi nopeustesti vertailuarvon saamiseksi

Kun puhutaan frontend-puolen optimoinneista, kannattaa aina ensimmäiseksi hankkia vertailuarvo. Yleensä tämä kannattaa tehdä nopeustestillä. On monta eri tapaa suorittaa nopeustesti. Olemme listanneet 15 erinomaista internetsivuston nopeustestityökalua.

Pingdomin nopeustesti

Pingdomin nopeustesti

Meillä on yksityiskohtainen opas Pingdomin käyttöön ja GTmetrixin käyttöön. Alla muutama asia, jotka kannattaa nopeustestejä tehdessä pitää mielessä: 

1. Valitse yksi työkalu ja pidä se

Suosikkeihimme kuuluvat Pingdom, GTmetrix, WebPageTest, PageSpeed Insights ja Chrome DevTools. Sillä ei ole valtavasti väliä, mitä työkalua käytät, kunhan käytät sitä aina. Eri työkalut käyttävät eri tapoja nopeuden mittaamiseen ja laskemiseen, joten kannattaa valita yksi ja käyttää sitä optimoinnin eri vaiheissa. Myös Google käskee valitsemaan yhden.

The speed test tool you choose doesn't matter as much as picking one and sticking with it throughout all of your tests. 🚀 Click to Tweet

2. Älä tuijota pelkkää numeroa

Moni työkalu kuten Google PageSpeed Insights tarjoaa jonkin sortin suorituskykytulosta. On tärkeä muistaa, ettei tulos aina merkitse yhtä paljon kuin sivuston nopeus ja asiakkaan kokema suorituskyky. Tulos on olemassa sitä varten, että sen avulla voi seurata ja arvioida tilanteen muuttumista. Jos kiinnität huomiota vain siihen, että sivustosi saa täydellisen tuloksen kuten 100/100 tai A, se on toisinaan pelkkää ajanhukkaa. Ja suuret sivustot, joilla on paljon ulkoisia skriptejä ja mainoksia, eivät koskaan saavuta täydellistä tulosta. Se on OK.

3. Testin sijainnilla on väliä

Sijainta, josta teet testin, merkitsee aika paljon. Kuten aikaisemmin oli puhetta, kyse on datakeskuksen sijainnista. TTFB, verkon viiveajat ja kaikki muut vaikuttavat. Joten kannattaa suorittaa testit kahdesta sijainnista: sellaisesta, joka on lähellä datakeskustasi, ja sellaisesta, joka on kaukana siitä. Näin näet myös, millainen vaikutus CDN:llä on WordPress-sivustoosi.

4. Testaa useita kertoja välimuistitallennuksen takia

Kuten välimuistitallennusta käsittelevässä osiossa oli puhetta, jos välimuistissa olevat tiedostot on pyyhitty tai ne ovat menneet vanhaksi joko WordPress-isännällä tai CDN:llä, http-otsikkotiedon arvoksi tulee ”MISS”. Se tarkoittaa, etteivät sivustosi tiedostot tule välimuistista.

MISS-arvo http-otsikkotiedossa

MISS-arvo http-otsikkotiedossa

Nähdäksesi sivuston nopeuden kokonaisuudessaan sinun täytyy varmistaa, että kaikki latautuu välimuistista: aloitussivun ja kaikkien tiedostojen tulee saada arvo ”HIT”. Joskus tämä vaatii, että nopeustesti tehdään monta kertaa. Laske sitten keskiarvo.

HIT-arvo http-otsikkotiedossa

HIT-arvo http-otsikkotiedossa

Puhutaanpa sitten frontend-puolen optimoinneista, jotka voit WordPress-sivustollasi tehdä.

Poista kyselymerkkijonot

Yleinen varoitus tai kehotus, jonka nopeustestityökalu antaa, koskee kyselymerkkijonojen poistamista (remove query strings). Mistä on kyse? No, periaatteessa se toimii niin, että CSS- ja JavaScript-tiedostoissa on tiedosto versio URL-osoiteen lopussa, esimerkiksi https://domain.com/file.min.css?ver=4.5.3. Jotkut palvelimet ja proxy-palvelimet toimivat niin, etteivät ne pysty tallentamaan kyselymerkkijonona välimuistiin. Joten poistamalla ne pystyy toisinaan parantamaan välimuistitallennusta.

On olemassa WordPress-lisäosia kuten Remove Query Strings From Static Resources tai Perfmatters, jotka pystyvät tekemään tämän automaattisesti. Tai voit tehdä sen manuaalisesti koodilla.

Kyselymerkkijonojen kanssa

Tässä esimerkki skriptistä, joka latautuu kyselymerkkijonojen kanssa.

Kyselymerkkijonojen kanssa

Kyselymerkkijonojen kanssa

Ilman kyselymerkkijonoja

Tässä esimerkki skripteistä, joista kyselymerkkijonot on poistettu.

Ilman kyselymerkkijonoja

Ilman kyselymerkkijonoja

Ennen kuin poistat kaikki kyselymerkkijonot sivustoltasi, on kuitenkin tärkeä tietää, mihin niitä käytetään. Tiedostojen versiot merkitään yleensä näkyviin, jotta WordPress-kehittäjät pystyvät välttämään välimuistitallennukseen liittyviä ongelmia. 

Jos esimerkiksi lisäosan kehittäjä julkaisee päivityksen ja muuttaa tiedoston style.css versiosta ?ver=4.6 versioon ?ver=4.7, siihen suhtaudutaan kuin täysin uuteen URL-osoitteeseen eikä sitä tarjoilla välimuistista. Jos poistat kyselymerkkijonon ja päivität lisäosan, saattaa olla, että välimuistiin tallennettua versiota tarjotaan käyttäjälle jatkossakin. Joissain tapauksissa tämä saattaa rikkoa sivuston ulkoasun, kunnes välimuistiin tallennettu tiedosto poistuu tai poistetaan.

Myös jotkut CDN:t käyttävät kyselymerkkijonoja välimuistitallennuksessa. Kinstan CDN tekee näin oletusasetuksena. Jos olet Kinstan asiakas, kyselymerkkijonot ovat siis jo käytössä.

Lue lisää yksityiskohtaisesta tutoriaalistamme: kyselymerkkijonojen poistaminen staattisista resursseista.

Poista niin sanottu ”render-blocking”-tyyppinen JavaScript ja CSS

Jos jotkut tiedostot estävät sivua latautumasta mahdollisimman nopeasti saatat saada virheilmoituksen JavaScriptistä tai CSS:stä, joka on niin sanotusti render-blocking. Tietty JS- tai CSS-sisältö on konditionaalista, eli niiden käyttäminen ei välttämättä ole pakollista sisällön näyttämisen kannalta. Render-blockingin voi estää attribuuteilla async ja defer.

Poista render-blockingin tyyppiset resurssit

Poista render-blockingin tyyppiset resurssit

Poistaaksesi kyseisen JavaScriptin ja CSS:n tee seuraava:

Tyhjennä CS polulta

JavaScriptin poistaminen kriittiseltä polulta tehdään yleensä lisäämällä attribuutti defer taiasync niihin script -HTML:n elementteihin, jotka kutsuvat JavaScript-resursseja.

  • Async-attribuutti käskee selaimen aloittaa resurssin lataaminen heti hidastamatta HTML:n jäsentämistä. Kun resurssi on käytössä, HTML-jäsennys keskeytetään resurssin lataamiseksi.
  • Defer-attribuutti käskee pitäytymään resurssin lataamisesta, kunnes HTML-jäsennys on valmis. Kun selain on saanut HTML-toiminnot suoriettua, se lataa kaikki defer-attribuutilla merkityt skriptit siinä järjestyksessä, jossa ne dokumentissa esiintyvät.

Optimoi CSS-resurssien toimitus

CSS-toimituksen optimointi tarkoittaa periaatteessa sitä, että siitä on poistettava render-blocking.

  • Etsi tyylit, jotka ovat välttämättömiä sisällön näyttämisen kannalta, ja toimita ne inline-tyyppisesti HTML:n kanssa.
  • Käytä CSS:ää konditionaalisesti vain tarvittaessa.
  • Lataa jäljelle jäävä CSS epäsynkronoidusti.

Kaiken yllä mainitun tekeminen saattaa joskus olla monimutkainen prosessi, ja se vaatii hiomista sivulle latautuvista skripteistä riippuen. Tässä muutama WordPress-lisäosa, jotka voivat auttaa:

Yksityiskohtaisempaa selitystä ja neuvoja varten suosittelemme tutustumaan artikkeliimme render-blocking-tyyppisen JavaScriptin and CSS:n poistaminen.

Yhdistä ulkoinen CSS ja JavaScript WordPressissä

Varoitus, jossa käsketään yhdistämään ulkoinen CSS, näkyy yleensä CDN:ää käytettäessä, kun CSS-tiedostoja säilytetään ulkoisessa domainissa kuten cdn.domain.com. Aikaisemmin ongelman pystyi korjaamaan yhdistämällä CSS-tiedostot niin, että ne latautuvat yhdessä pyynnössä.

Jos kuitenkin käytät HTTPS:ää ja palveluntarjoajaa, joka tukee HTTP/2:a, tämä varoitus ei enää ole yhtä tärkeä kuin aikaisemmin. HTTP/2:n avulla useita CSS-tiedostoja voidaan nyt ladata yhtä aikaa saman yhteyden kautta. Ja yli 86% selaimista tukee HTTP/2:a.

Se ei kuitenkaan tarkoita, että optimointi on kokonaan kuollut. Jossain tilanteissa olemme yhä nähneet tämän nopeuttavan WordPress-sivustoja. Riippuu tiedostojen koosta ja määrästä. Näin ollen tämä on optimointi, jota suosittelemme sinun testaavan sivustollasi. 

Yksi helpoimmista tavosita yhdistää ulkoisia CSS- ja JavaScript-tiedostoja on ilmaisen Autoptimize-lisäosan käyttö. Yhdistämisen jälkeen näet “autoptimize_xxxxx.css” tai “autoptimize_xxxxx.js” -nimisen tiedoston. Ne voi ladata myös CDN:stä. Myös WP Rocket-lisäosaa voi käyttää tähän tarkoitukseen.

Yhdistetut CSS- ja JavaScript-tiedostot

Yhdistetut CSS- ja JavaScript-tiedostot

Lue lisää yksityiskohtaisesta artikkelistamme ulkoisten CSS- ja JavaScript-tiedostojen yhdistämisestä WordPressissä.

Käytä minifikaatiota HTML:ssä, CSS:ssä ja JavaScriptissä

Voimme vähentää sen datan määrää, joka selaimen täytyy ladata, minimoimalla HTML-, CSS- ja JavaScript-resurssit. Minifikaatio (minification) tarkoittaa prosessia, jolla turhat merkit kuten kommentit ja tyhjä tila poistetaan lähdekoodista. Yleensä kyseiset merkit ovat kehityksen kannalta merkityksellisiä, mutta selain ei tee niillä mitään.

HTML ilman minifikaatiota

Alla esimerkki minifoidusta HTML-koodista.

HTML-koodia ilman minifikaatiota

HTML-koodia ilman minifikaatiota

Minifoitu HTML

Alla esimerkki minifoidusta HTML-koodista.

Minifoitu HTML-koodi

Minifoitu HTML-koodi

Voit käyttää ilmaista Autoptimize-lisäosaa tai WP Rocketia minifoidaksesi tiedostosi helposti.

Yleisesti ottaen kun sisältöä kuten kuvia, JacaScriptiä ja CSS:ää ladataan, se ei tarvitse mukaansa HTTP-evästettä, joka vie tilaa. Kun palvelin on kerran luonut evästeen tietyn domainin kohdalla, kaikkien http-pyyntöjen sitä domainia koskien tulee sisältää kyseinen eväste. Tämä varoitus näkyy usein sivustoilla, joilla on paljon pyyntöjä. 

Meillä on yksityiskohtainen artikkeli siitä, kuinka ”serve static content from a cookieless domain” (tuo staattista sisältöä evästeettömästä domainista) -virheilmoituksen voi korjata. Usein sen voi jättää huomiotta, sillä uudet protokollat kuten HTTP/2 ovat vähentäneet sen merkitystä. Uuden yhteyden hinta on usein suurempi kuin kaiken striimaaminen samaa yhteyttä käyttäen.

Helppo tapa korjata tämä virheilmoitus on sellaisen CDN-palveluntarjoajan käyttäminen, joka kykenee sekä jättämään evästeet huomiotta että riisumaan ne, mikä estää asiakasta saamasta Set-Cookie -vastausotsikkotietoa. KeyCDN on esimerkki CDN-palveluntarjoajasta, jolla on tämä ominaisuus. Oletusasetuksena alla olevat kaksi vaihtoehtoa ovat käytössä. Tämä on helppo vaihtoehto, sillä sen avulla ei tarvitse siirtää ja konfiguroida sivustoa niin, että se toimittaa staattista sisältöä erillisestä alidomainista. 

CDN: evästeiden riisuminen

CDN: evästeiden riisuminen

Jos käytät CloudFlarea, et voi ottaa evästeitä pois käytöstä niistä resursseista, jotka kulkevat heidän verkossaan. Kuten sanottu, nämä evästeet ovat erittäin pieniä ja niiden vaikutus on minimaalinen. Mutta jos käytät CloudFlarea, et pääse mitenkään tästä varoituksesta eroon.

Toinen vaihtoehto on uudelleenkonfiguroida WordPress-sivusto siten, että se toimittaa staattisen sisällön joko alidomainista tai kokonaan uudesta domainista.

Ota upotukset pois käytöstä WordPressissä

WordPress 4.4:n julkaisuajankohtana ydinkoodiin lisättiin oEmbed-ominaisuus. Sen avulla käyttäjät voivat upottaa sivustolleen YouTube-videoita, twiittejä ja monia muita resursseja pelkän URL-osoitteen avulla. WordPress upottaa videon automaattisesti ja näyttää siitä esikatselun visuaalisessa editorissa. Päivityshetkellä myös WordPressistä tuli oEmbedin tarjoaja.

Moni pitää tätä ominaisuutta hyödyllisenä ja saatat haluta pitää sen päällä. Se tarkoittaa kuitenkin, että ominaisuus luo ylimääräisen http-pyynnön WordPress-sivustollesi ladatakseen wp-embed.min.js-tiedoston. Ja se latautuu koko sivustolla. Tiedoston on kooltaan vain 1,7 KB, mutta juuri tämäntyyppiset asiat kasaantuvat ajan kuluessa. Kysely itsessään saattaa olla isompi juttu kuin ladattavan tiedoston koko. 

wp-embed.min.js-tiedossto

wp-embed.min.js-tiedossto

Tiedoston latautumisen voi estää helposti. On kolme eri vaihtoehtoa:

Ota emojit pois käytöstä WordPressissä

Upotuksien tapaan  WordPress 4.2_ään lisättiin vanhempien selainten emoji-tuki. Ongelma on siinä, että se luo WordPress-sivustolle ylimääräisen http-pyynnön, joka lataa wp-emoji-release.min.js-tiedoston. Ja tämä tiedosto latautuu koko sivustolle. Sen koko on ehkä vain 10,5 KB, mutta se on turha, jos et käytä emoji-kuvia sivuillasi.

wp-emoji-release.min.js

wp-emoji-release.min.js

On pari eri tapaa ottaa emojit pois käytöstä WordPressissa. Voit tehdä sen ilmaisen lisäosan tai koodin avulla. 

WordPress-kommenttien nopeuttaminen tai poistaminen käytöstä

Jos kommenttiosiossa on paljon vilinää, se saattaa aiheuttaa suorituskykyongelmia. Ajattelepa kaikkia niitä resursseja, joita kommenttiosio vaatii:

  • Tietokantaan lähetetään kysely, joka tuo näkyviin olemassa olevat kommentit.
  • Tietokantaan lisätään tietoa jokaisen uuden kommentin kohdalla.
  • Selain ottaa vastaan kommentit ja niiden metadatan sekä prosessoi kaiken.
  • Ulkoiset resurssit kuten Gravatarit pyydetään, ladataan ja esitetään (mikä vaatii DNS-kyselyn erikseen).
  • Monesa tapauksessa suuret JavaScript- ja jQuery-resurssit joudutaan lataamaan ja prosessoimaan, jotta kommenttiosio toimii halutulla tavalla.

Tässä neljä eri vaihtoehtoa, joiden avulla WordPressin kommentteja voi nopeuttaa:

Vaihtoehto 1 – Ota kommentit pois käytöstä

Jos sivustosi ei kerää paljon kommentteja eivätkä ne sinusta tuo paljon lisäarvoa, saattaa olla parempi ottaa kommentit kokonaan pois käytöstä. Muista myös, että kommentit voivat vaikuttaa SEO:hon, sillä Google käy läpi myös ne. Tämän takia kannattaa sallia vain korkeatasoiset kommentit. Tässä kolme helppoa tapaa ottaa kommentit pois käytöstä:

Vaihtoehto 2 – Optimoi WordPressin natiivit kommentit

Toinen vaihtoehto on optimoida WordPressin natiivi kommenttijärjestelmä. Yksi tapa on vähentää heti aluksi latautuvien kommenttien määrää.

  1. Mene kohtaan Settings → Discussion WordPressin järjestelmähallinnassa.
  2. Etsi kohta Other comment settings.
  3. Valitse vaihtoehto kohdassa Break comments into pages with ja lisää kerralla latautuvien kommenttien määrä.
Eli jaa kommentit usealle sivulle

Eli jaa kommentit usealle sivulle

Yksi vaihtoehto on tuoda Gravatorit CDN:lle. Näin toimimme Kinstalla.

Oletusasetuksena on niin, että kun WordPress-kommentit latautuvat, kukin Gravatar vaatii http-pyynnön. Joten jos sivulla on kommentteja 50 eri kommentoijalta, 50 http-pyyntöä vaaditaan kaikkien Gravatarien lataamiseksi. Voit kuvitella, että tämä saattaa vaikuttaa sivun nopeuteen. Puhumattakaan siitä, että olemme nähneet ulkoisen DNS-pyynnön gravatar.comiin toimivan toisinaan niin hitaasti, että yhteys voi jopa katketa.

Jos katsot Kinstan blogissa olevia Gravatar-ikoneja, huomaat, että ne latautuvat osoitteesta Kinsta.com (mukaan lukien käyttämämme CDN). Lue lisää siitä, kuinka saat gravatarit latautumaan CDN:ltä.

Tuo Gravatarit omalle tai CDN:n palvelimelle

Tuo Gravatarit omalle tai CDN:n palvelimelle

Vaihtoehto 3 – Käytä kolmannen osapuolen kommenttijärjestelmää

Kolmas vaihtoehto on käyttää kolmannen osapuolen kommenttijärjestelmää. Jos sivustosi hostingin hoitaa halpa, resursseja jakava palvelin, kolmannen osapuolen kommenttijärjestelmän käyttäminen saattaa nopeuttaa huomattavasti sivustoja, joilla on paljon kommentteja. Mutta jos käytät Kinstan tai jonkun muun korkeatasoisen hosting-tarjoajan palveluita, ulkopuoliseen kommenttijärjestelmään vaihtaminen tuskin nopeuttaa sivustosi latautumisnopeutta – itse asiassa se voi jopa hidastaa sitä.

Disqusin ulkoiset pyynnöt

Disqusin ulkoiset pyynnöt

Muista aina tehdä nopeustestejä, jos käytät ulkopuolista kommenttijärjestelmää. Tarkista kaikki pyynnöt, jotka Disqus luo (kuten alla näkyy). Vaikka suurin osa pyynnöistä ei lataudu samanaikaisesti, Disqus silti aiheuttaa hieman pitempiä latausaikoja.

Vaihtoehto 4 – Käytä “lazy load” -lataustapaa kommenteissa

Neljäs vaihtoehto on käyttää niin sanottua lazy loadingia kommenttien latauksessa, jotta sivuston ensilatautuminen ei hidastu. Alla pari lisäosaa, joihin ehkä haluat tutustua:

  • Lazy Load for Comments: Tämän lisäosan avulla voit käyttää lazy loading -lataustapaa yhdessä natiivien WordPress-kommenttien kanssa.
  • Disqus Conditional Load: Jos tahdot käyttään Disqus-kommenttijärjestelmää, tämä on lähes pakollinen lisäosa lazy loading -tavan käyttämiseen.

Ota pois käytöstä WordPressin RSS-syötteet

Jos et käytä WordPressin bloggausominaisuutta WordPress-sivustoltasi, voit ottaa RSS-syötteet pois päältä. Se ei vaikuta suorituskykyyn valtavasti, mutta vähäkin auttaa. Sitä paitsi sitten sinulla on taas yksi asia vähemmän huolehdittavana.

Tässä pari erilaista tapaa ottaa RSS-syötteet pois käytöstä WordPressissä:

Käytä prefetchiä ja preconnectia

Resurssivinkit ja -direktiivit kuten prefetch ja preconnect voivat auttaa nopeuttamaan WordPressiä kulissien takana. KeyCDN:llä on erinomainen artikkeli resurssivinkeistä.

Prefetch

DNS prefetch sallii domain-nimien selvittämisen eli DNS-tietojen hakemisen taustalla, ennen kuin käyttäjä klikkaa linkkiä. Tämä auttaa parantamaan suorituskykyä. Se tehdään lisäämällä rel=”dns-prefetch” -merkintä WordPress-sivuston otsikkotietoon.

DNS prefetch -toimintoa voi käyttää esimerkiksi CDN:n URL-osoitteen, Google Fontsin, Google Analyticsin, jne. kohdalla.

 
 
 

Lähes kaikki modernit selaimet tukevat prefetch-toimintoa. Lue lisää tutoriaalistamme kuinka lisätä koodia WordPress-otsikkotietoihin.

Tai voit helposti ottaa toiminnon käyttöön lisäosalla kuten Perfmatters. Paina vain “Extras”-välilehteä Perfmattersissa ja lsiää domaineja. Muoto: //domain.tld (yksi per rivi)

Prefetch

Prefetch

Preconnect

Preconnect sallii selaimen luoda yhteyden ennen http-pyyntöä, mikä vähentää viiveaikaa ja säästää käyttäjien aikaa. 

Preconnect on tärkeä optimointityökalu… se pystyy eliminoimaan monta kallista edestakaisin kulkevaa signaalia pyyntöpolulta. Jossain tapauksissa se voi vähentää viiveaikaa satoja tai jopa tuhansia millisekunteja.– lya Grigorik (lähde)

Se tehdään lisäämällä rel=”preconnect” WordPress-sivuston otsikkotietoon.

Esimerkkejä käyttötavoista, CDN:n URL-osoite ja Google Fonts.

 
 

Preconnectia tukevat lähes kaikki modernit internetselaimet – pois lukien Internet Explorer, Safari, IOS Safari ja Opera Mini. Tässä tutoriaalimme, jonka avulla voit lisätä koodia WordPressin otsikkotietoon.

Tai voit ottaa preconnectin käyttöön lisäosalla kuten Perfmatters. Paina vain “Extras”-välilehteä Perfmattersissa ja lisää domaineja. Muoto: scheme://domain.tld (yksi per rivi).

Preconnect

Preconnect

Poista skriptit käytöstä per sivu/postaus

Yksi erittäin toimiva tapa WordPressin nopeuttamiseen on se, että käy läpi jokaisen kyselyn, joka latautuu sivuille ja postauksiin. Löydät todennäköisesti skriptejä, jotka turhaan latautuvat koko sivustolle.

Voit käyttää lisäosaa kuten Perfmatters, jossa on sisäänrakennettuna “Script Manager” -ominaisuus. Sen alla voit ottaa pois käytöstä skriptejä (CSS ja JavaScript) eri sivuilla tai postauksissa – tai joka koko sivustolla, pelkästään yhdellä painalluksella. Kuten jo sanottu, tämän lisäosan on kehittänyt yksi Kinstan työntekijöistä.

Esimerkkejä siitä, mihin lisäosaa voi käyttää:

  • Suosittu Contact Form 7 -lisäosa latautuu joka sivulle ja postaukseen. Voit ottaa sen helposti pois päältä kaikkialla vain yhdellä painalluksella, ja ottaa sen takaisin käyttöön pelkästään yhteydenottosivulla.
  • Sosiaalisen median jakolisäosien pitäisi latautua vain postauksissa. Voit helposti ottaa sen pois päältä kaikkialla ja ladata sen vain postaustyypeissä, myös kustomoiduissa. 
  • Table of contents -lisäosa (TOC) latautuu joka sivulle ja postaukseen. Script Managerilla voit helposti hallinnoida sitä, mihin haluat sen latautuvan.

Miksi jotkut lisäosat koodataan näin?

Saatat ihmetellä, mikseivät lisäosien kehittäjät yksinkertaisesti lataa skriptejä vain silloin, kun lisäosa löytyy sivulta. No, juttu on hieman monimutkaisempi. Jos sinulla on esimerkiksi lisäosa kuten Contact Form 7, siinä on lyhytkoodeja, joiden avulla sen voi laittaa minne vain. Esimerkiksi pienoisohjelmaan eli widgetiin. WordPressissä on paljon hankalampi tehdä niistä kyselyjä, kun skriptit ovat poissa jonosta, verrattuna data kyselyyn postauksen tai sivun metadatasta.

Näin ollen tämä johtuu usein käytettävyysongelmista. Mitä vähemmän lisäosalla on rikkoutumismahdollisuuksia, sitä vähemmän käyttäjät tarvitsevat asiakastukea. Toisaalta moni markkinoilla oleva lisäosa pystyisi välttämään tämän ja tekemään koodista sellaisen, että sen suorituskyky olisi maksimaalinen. Valitettavasti joskus käyttäjien ja latausten suuret määrät sanelevat sen, että koodia kirjoitetaan käytettävyys edellä.

Tietoja Script Managerista

Katsotaanpa Script Manageria. Kun olet painanut sitä työkalupalkissa, näet, mitkä skriptit latautuvat kyseisessä URL-osoitteessa – sekä JavaScript- että CSS-tiedostot. Voit sitten valita seuraavista vaihtoehdoista:

  1. Status On (oletusasetus)
  2. Status Off: Disable Everywhere eli ota pois käytöstä kaikkialla (tämän jälkeen voit valita, minkä tyyppisissä postauksissa haluat käyttää sitä, mukaan lukien tämänhetkinen URL)
  3. Status Off: Disable only on current URL eli ota pois käytöstä vain tässä URL-osoitteessa (tämä on erityisen kätevää pääsivulla)
  4. Status Off: Exceptions eli poikkeukset (tämänhetkinen URL, postaustyyppi, arkisto)
Perfmattersin Script Manager -ominaisuus

Perfmattersin Script Manager -ominaisuus

Kaikki on ryhmitelty lisäosan tai teeman nimen mukaan. Näin on todella helppoa ottaa käytöstä kokonainen lisäosa kerralla. Tyypillisesti WordPress-lisäosa pitää sisällään sekä JavaScript- että CSS-tiedoston. WordPress-teema saattaa sisältää 10+ tiedostoa.

Kun olet valinnut ja muuttanut asetuksia, muista painaa ”Save” sivun alareunasta. Voit sitten ajaa nopeustestejä varmistaaksesi, etteivät skriptit enää lataudu sivulle. Muista ensin tyhjentää välimuisti! Ja jos jokin menee sivustollasi visuaalisesti pieleen, voit aina ottaa sen uudelleen asetuksista käyttöön, jolloin kaikki palaa normaaliksi.

WoorkupIin nopeustestissä näkyi, että sivulatausaika laski 20.2%. Pelkästään kotisivulla http-pyyntöjen määrä laski 46:sta 30:een. Koko pieneni 506,3 KB:stä 451,6 KB:hen.

On muitakin tapoja ottaa skriptejä pois käytöstä. Lisätietoa saat blogikirjoituksestamme kuinka WordPress-lisäosan latautumisen voi estää.

Kolmansien osapuolten suorituskyvyn analysointi

Periaatteessa kaikki, jota kutsut ulkoisesti sivustoltasi, vaikuttaa latausaikoihin. Tästä tekee ongelman se, että osa niistä hidastelee vain silloin tällöin, mikä tekee ongelmakohtien löytämisestä haastavaa.

Kolmannen osapuolen ulkoinen palvelu on käytännössä mikä tahansa taho, joka kommunikoi WordPress-sivustosi kanssa oman palvelimesi ulkopuolelta. Tässä muutama tavallinen esimerkki, joihin törmäämme usein:

  • Sosiaalisen median alustat kuten Twitter, Facebook ja Instagram (widgetit eli pienoisohjelmat tai konversiopikselit)
  • Kolmannen osapuolen mainosverkostot kuten Google Adsense, Media.net, BuySellAds, Amazon Associates
  • Sivustoanalyytiikka- ja tracking-skriptit kuten Google Analytics, Crazy Egg, Hotjar, AdRoll
  • A/B-testaustyökalut kuten Optimizely, VWO, Unbounce
  • WordPress-kommenttijärjestelmät kuten Disqus, Jetpack, Facebook-kommentit
  • Varmuuskopiointi- ja turvallisuustyökalut kuten VaultPress, Sucuri, CodeGuard
  • Sosiaaliset jakotyökalut kuten SumoMe, HelloBar
  • CDN-verkostot kuten KeyCDN, Amazon CloudFront, CDN77 ja StackPath
  • Ulkoisesti isännöity Javascript

Kuinka paljon nämä ulkoiset tekijät vaikuttavat suorituskykyyn? Omassa tapaustutkimuksessamme näimme, että kolmannen osapuolen skriptit lisäsivät sivulatausaikoja 86.08%.

Myös Ghostery on mitannut 500 käytetyintä domainia Yhdysvalloissa Alexassa, ja tulokset olivat hurjia – mutta eivät yllättäneet meitä. Sivustot olivat 2x hitaampia, kun trackereita ei blokattu lainkaan. Mikä tarkoittaa, että nämä kolmannen osapuolen tracking-skriptit ovat yksi suurimmista syistä sivujen hitaaseen latautumiseen.

Latausajat trackerien kanssa

Latausajat trackerien kanssa (Kuvalähde: Ghostery)

Sinun on oltava erittäin varovainen WordPress-sivustollasi. Yksikin huono kolmannen osapuolen API-kutsu saattaa sotkea koko sivuston! Niin, sen ei pitäisi toimia siten, mutta monesti niin käy kuitenkin. Olemme nähneet sen tapahtuvan lukemattomia kertoja. 

New Relic tarjoaa erinomaisen ja helpon tavan, jonka avulla voit pitää kirjaa ulkoisista palveluista ajan kuluessa. Alla olevassa esimerkissä näkyy, että ulkoisia kutsuja tehdään kohteisin twitcount.com, graph.facebook.com ja widgets.pinterest.com.

Sosiaalisen media ulkoisten kutsujen vasteajat

Sosiaalisen media ulkoisten kutsujen vasteajat

On tärkeää muistaa aina uutta ominaisuutta tai lisäosaa lisätessä, että kannatta tarkistaa, mitä ulkoisia resursseja se lataa. Mitä vähemmän, sen parempi!

Optimoi aina mobiililaitteita silmällä pitäen

Google alkoi julkaista mobile-first-indeksiään 26.3.2018. Aikaisemmin Googlen crawling-, indeksointi- ja ranking-järjestelmät ovat käyttäneet sivustojen pöytäkoneversioita. Mobile-first-indeksointi tarkoittaa, että Googlebot käyttää nyt WordPress-sivuston mobiiliversiota indeksointia ja rankingia varten. Näin hakutoiminto parantuu mobiilikäyttäjien kohdalla.

Käytännössä mobile-first tarkoittaa, että nopeus on yksi tärkeimmistä tekijöistä, joihin kannattaa keskittyä. Nopeudella on suuri merkitys kaikkeen käyttäjäkokemuksesta välittömiin poistumisiin sekä siihen, palaako mahdollinen ostaja sivustolle. Itse asiassa nopeus on nyt yksi landing page -tekijöistä Google-hakujen ja -mainosten mobiilihauissa.

Huono kokemus mobiililaitteella johtaa yleensä siihen, ettei suurin osa käyttäjistä palaa koskaan. Googlen sivunopeistestin mukaan mobiilisivuston keskimääräinen latausaika vuonna 2018 oli 15 sekuntia. Voitko kuvitella, että joutuisit odottamaan yhtä ainutta sivua noin pitkään? Uskomatonta.

Käyttäjät vaativat (ja ansaitsevat) parempaa. Saman nopeustestiraportin mukaan 53% mobiilisivusojen kävijöistä lähtee pois, jos lataaminen kestää kauemmin kuin kolme sekuntia.

Hitaat mobiilikokemukset eivät tapa konversioiden määrä – ne estävät konversiomahdollisuudet jo ennen niiden alkamista. Jos sivulatauksessa kestää pari sekuntia kauemmin, välittömän poistumisen todennäköisyys kasvaa eksponentiaalisesti. Alla muutama asia, jotka kannattaa pitää mielessä mobiililaitteita varten optimoidessa.

Tarkista mobiililiikenteesi

On aina tärkeä kiinnittää huomiota siihen, kuinka paljon mobiiliikennettä sivustollasi on, sillä se saattaa vaikuttaa asioiden tärkeysjärjestykseen. Pääset näkemään tarpeellisia tietoja Google Analyticsistä kohdasta “Audience → Mobile → Overview.” Alla olevassa esimerkissä näkyy, että yli 67% kaikesta sivuston liikenteestä tuli mobiililaitteista. Se on paljon!

Mobiiliikenne Google Analyticsissa

Mobiiliikenne Google Analyticsissa

Jos olet Kinstan asiakas, näet erilaisten laitteiden käytön myös MyKinsta Analyticsista. Alla näkyy sivusto, jossa yli 88% liikenteestä tuli pöytäkoneelta. Vaikka koko ajan puhutaan siitä, että mobiililaitteiden käyttö on yhä kasvussa, se ei välttämättä koske sinun sivustoasi. Katso dataa.

Mobiililaite vs. pöytäkone – MyKinsta Analytics

Mobiililaite vs. pöytäkone – MyKinsta Analytics

Varmista, että sivustosi on responsiivinen

Vuonna 2019 sivustosi olisi parempi olla responsiivinen! Sillä tarkoitetaan sivustoa, joka automaattisesta skaalaa asiat pienemmiksi mobiililaitteissa. Jos et ole vielä tehnyt tätä, olet todennäköisesti kilpailijoistasi jäljessä. Kaikki aiemmin mainitut WordPress-teemat ovat responsiivia ja näyttävät upeilta kaikissa laitteissa.

Voit käyttää Googlen Mobile-Friendly -työkalua kokeillaksesi, täyttääkö sivustosi kaikki vaatimukset.

Mobile-Friendly -testi

Mobile-Friendly -testi

Varmista, että srcset toimii

Aikaisemmin oli tärkeää, että kuvat tallennettiin skaalautumaan eikä CSS saanut muuttaa niiden kokoa. Tämä ei kuitenkaan ole enää tärkeää, sillä versiosta 4.4 lähtien WordPress on tukenut responsiivisia kuvia (CSS ei skaalaa niitä pienemmiksi). WordPress luo automaattisesti monta kokoversiota kuvasta, joka on tallennettu mediakirjastoon. Selaimet voivat nyt valita, minkä kokoisen kuvan ne haluavat ladata, tallentamalla haluamansa kokotiedot srcset-attribuuttiin. Alla esimerkki koodista.

WordPressin srcset

WordPressin srcset

Johtuen kaikista kolmannen osapuolen lisäosista ja kustomoinneista olemme nähneet, ettei tämä aina toimi oikein. Näin ollen on tärkeää varmistaa, että kuvat saavat srcset-attribuutin oikein eri kokoisten kuvien kohdalla. Kuvien optimointi tulee tästä lähtien aina olemaan tärkeää.

Google AMP voi olla sinulle hyvä ratkaisu

 

Google AMP (Accelerated Mobile Pages Project) julkaistiin alun perin lokakuussa 2015. Projektin pohjana on AMP HTML, uusi avoimen koodin kehys, jonka avulla sivustot voivat rakentaa kevyitä internetsivuja. Yksinkertaistettuna: sen avulla voi tarjota kävijälle pelkistettyä versiota sivusta.

Meillä on viha-rakkaussuhde Google AMPiin, kuten monella muullakin yhteisössä. Olemme testanneet sitä emmekä pitäneet tuloksista. Se ei kuitenkaan tarkoita, ettetkö sinä ehkä hyötyisi siitä. Jokainen sivusto on erilainen ja Google AMPia parannetaan koko ajan. 

Pääset Google AMPin kanssa alkuun WordPress-sivustollasi esimerkiksi jommallakummalla seuraavista lisäosista:

Lue lisää yksityiskohtaisesta tutoriaalistamme kuinka ottaa Google AMP käyttöön. Ja jos on tarpeen, kuinka ottaa Google AMP pois käytöstä. Sen käytöstä pois ottaminen voi olla odotettua vaikeampaa.

Yhteenveto

Olet ehkä jo päätellyt, että WordPressin nopeuttaminen on meille pakkomielle. Nopea sivu tarkoittaa parempia sijoituksia, hakukoneiden suurempaa tehokkuutta, isompia konversiolukuja ja vähemmän niitä, jotka lähtevät sivustolta välittömästi. Puhumattakaan siitä, että nopealla sivustolla on mukavampi käydä! 

Toivomme, että tämä nopeutusopas oli hyödyllinen ja että pystyit ottamaan siinä mainittuja vinkkejä WordPress-sivustollasi käyttöön. Jos näin oli, jaathan sen.

Jäikö meiltä jotain tärkeää huomiotta? Jos niin kävi, kerrothan meille. Kerro meille myös omat vinkkisi WordPressin nopeuttamiseksi alla olevissa kommenteissa.