WordPress-sivun hitaus ei yleensä johdu yhdestä asiasta. Syynä voi olla raskas teema, huonosti toimiva lisäosa, liian suuret kuvat, puutteellinen välimuisti tai hosting-ympäristö, joka ei riitä sivuston tarpeisiin.
Siksi nopeutta ei kannata yrittää parantaa asentamalla satunnaisesti lisää optimointilisäosia. Parempi tapa on selvittää ensin, missä kohtaa sivun lataus hidastuu. Kun ongelman lähde on tiedossa, myös korjaus on usein paljon yksinkertaisempi.
Tässä oppaassa käydään läpi vaiheittainen vianrajausmalli, jolla erotat toisistaan teema- ja lisäosaongelmat, palvelinresurssit, välimuistin, kuvat ja selaimessa tapahtuvan renderöinnin.
Aloita mittaamalla, älä arvaamalla
Testaa sivustoa vähintään kahdella tavalla:
- työpöytäkoneella ja mobiililaitteella
- kirjautuneena ja uloskirjautuneena
- välimuisti käytössä ja tyhjennettynä
- useammalla sivulla, kuten etusivulla, blogissa ja yhteydenottosivulla
Yksi PageSpeed Insights -testi ei vielä kerro koko totuutta. Laboratoriotesti näyttää yhden testihetken tilanteen, kun taas todellisten käyttäjien mittaukset kertovat, miten sivusto toimii eri laitteilla ja verkkoyhteyksillä.
Kiinnitä erityisesti huomiota kolmeen Core Web Vitals -mittariin:
| Mittari | Mitä se kertoo? | Tyypillinen ongelman lähde |
|---|---|---|
| Largest Contentful Paint eli LCP | Milloin sivun suurin pääsisältö näkyy käyttäjälle | Palvelimen hitaus, suuri hero-kuva tai renderöintiä estävät resurssit |
| Interaction to Next Paint eli INP | Kuinka nopeasti sivu reagoi käyttäjän toimintaan | Raskas JavaScript, lisäosat tai kolmannen osapuolen skriptit |
| Cumulative Layout Shift eli CLS | Liikkuuko sisältö odottamatta latauksen aikana | Mitattomat kuvat, fontit, mainokset tai dynaamiset elementit |
Vaihe 1: selvitä, onko palvelin hidas
Ensimmäinen kysymys kuuluu: odottaako selain palvelinta vai lataako selain liikaa sisältöä?
Tähän auttaa Time to First Byte eli TTFB. Se mittaa aikaa sivupyynnön alusta siihen, kun selain saa palvelimelta ensimmäisen tavun vastauksesta. TTFB ei ole oma Core Web Vitals -mittarinsa, mutta se vaikuttaa kaikkeen, mitä sivun latauksessa tapahtuu sen jälkeen. (web.dev)
Jos TTFB on jatkuvasti korkea, syy voi olla esimerkiksi:
- palvelin käyttää kaikki käytettävissä olevat resurssit
- WordPress joutuu suorittamaan paljon PHP-koodia
- tietokantakyselyt ovat hitaita tai niitä on liikaa
- sivulla ei ole toimivaa palvelintason välimuistia
- hosting-ympäristö on jaettu liian monen raskaan sivuston kanssa
- kävijämäärä tai verkkokaupan samanaikaiset käyttäjät ylittävät nykyisen kapasiteetin
Testaa samaa sivua useita kertoja ja eri ajankohtina. Jos vasteaika vaihtelee paljon, kyse voi olla resurssien hetkellisestä loppumisesta tai palvelimen kuormasta. Jos TTFB on tasaisesti hidas myös kevyellä sivulla, syy löytyy todennäköisemmin palvelinympäristöstä tai WordPressin taustalla tapahtuvasta työstä.
Palvelimen nopeus ei kuitenkaan yksin ratkaise LCP-tulosta. LCP koostuu muun muassa palvelimen vastauksesta, pääsisällön resurssien latauksesta ja elementin renderöinnistä. Siksi hidas LCP voi johtua palvelimesta, kuvasta, fonteista tai selaimen työmäärästä. (developer.chrome.com)
Vaihe 2: testaa teema ja lisäosat erikseen
Jos sivu on hidastunut WordPress-päivityksen, uuden teeman tai lisäosan asentamisen jälkeen, aloita ohjelmistojen vianrajauksesta.
Tee testi mieluiten testi- tai staging-ympäristössä. Jos käytät tuotantosivustoa, ota ensin varmuuskopio ja tee muutokset vaiheittain.
Näin rajaat ongelman
- Mittaa sivusto nykyisellä teemalla ja lisäosilla.
- Ota käyttöön WordPressin oletusteema.
- Poista lisäosat käytöstä.
- Mittaa sama sivu uudelleen.
- Ota lisäosat käyttöön yksi kerrallaan.
- Mittaa jokaisen muutoksen jälkeen.
WordPressin oma vianmääritysmalli perustuu juuri muuttujien vähentämiseen. Kun teema ja lisäosat poistetaan testin ajaksi käytöstä, voit selvittää, esiintyykö ongelma myös WordPressin kevyessä perusversiossa. Troubleshooting-tila mahdollistaa testauksen niin, että muut kävijät näkevät edelleen normaalin sivuston. (learn.wordpress.org)
Hidas lisäosa ei aina näy suurena tiedostona selaimen Network-välilehdellä. Se voi hidastaa sivustoa esimerkiksi tekemällä paljon tietokantakyselyitä, lisäämällä hallitsemattomia skriptejä tai suorittamalla raskasta työtä jokaisella sivulatauksella.
Erityistä huomiota kannattaa kiinnittää lisäosiin, jotka:
- rakentavat visuaalisia sivuja tai liukuvia elementtejä
- hakevat sisältöä ulkoisista palveluista
- seuraavat kävijöitä tai lisäävät markkinointiskriptejä
- käsittelevät verkkokaupan tuotteita, tilauksia tai suodattimia
- luovat reaaliaikaisia hakuja tai suosituksia
- lisäävät useita fontteja, tyylitiedostoja tai JavaScript-tiedostoja
Jos ongelma katoaa oletusteemalla, teema on todennäköinen syyllinen. Jos ongelma katoaa yhden lisäosan poistamisella, olet saanut vianrajauksen kannalta tärkeän tuloksen. Seuraavaksi kannattaa etsiä lisäosalle päivitys, kevyempi vaihtoehto tai valmistajan korjaus.
Vaihe 3: tarkista välimuisti ennen suurempia muutoksia
Välimuisti tallentaa sivusta valmiin version, jonka selain tai palvelin voi tarjota seuraavalle kävijälle ilman, että WordPress rakentaa sivua joka kerta uudelleen.
Jos välimuisti ei toimi, jokainen kävijä voi aiheuttaa uuden PHP-suorituksen ja tietokantakyselyiden sarjan. Tämä näkyy usein korkeana TTFB:nä ja hitaana palvelinvasteena.
Tarkista ainakin nämä asiat:
- Onko sivuvälimuisti käytössä?
- Tyhjentyykö välimuisti päivitysten jälkeen?
- Ohitetaanko välimuisti kirjautuneilta käyttäjiltä?
- Ohitetaanko välimuisti verkkokaupan ostoskorissa ja kassalla?
- Käytätkö useita välimuistilisäosia päällekkäin?
- Onko palvelimen ja WordPress-lisäosan välimuisti synkronoitu?
Useampi välimuistiratkaisu ei automaattisesti tarkoita parempaa nopeutta. Päällekkäiset asetukset voivat jopa aiheuttaa vanhentunutta sisältöä, rikkinäisiä toimintoja tai vaikeasti jäljitettäviä ongelmia.
Zonerin WP.one-palvelussa käytetään sivuvälimuistia, jonka tarkoitus on nopeuttaa sivujen latautumista kävijöille. Välimuistin hallinta kannattaa kuitenkin aina tarkistaa oman sivuston asetuksista, etenkin jos sisältö muuttuu usein tai käytössä on WooCommerce. (tuki.zoner.fi)
Vaihe 4: tutki kuvat ja LCP-elementti
Suuri kuva etusivun yläosassa on yksi tavallisimmista LCP-ongelmien syistä. Tämä koskee erityisesti hero-kuvia, taustakuvia ja liukusäätimiä, jotka näkyvät heti sivun alussa.
Tarkista PageSpeed Insightsista, mikä elementti toimii sivun LCP-elementtinä. Se voi olla:
- suuri kuva
- otsikko
- tekstikappale
- video
- taustakuvallinen osio
Jos LCP-elementti on kuva, tarkista seuraavat asiat:
- Onko kuva oikean kokoinen käyttötarkoitukseensa?
- Onko kuva pakattu?
- Käytetäänkö nykyaikaista WebP- tai AVIF-muotoa?
- Ladataanko kuva heti, jos se näkyy ensimmäisessä näkymässä?
- Ladataanko kuva vahingossa viivästetysti?
- Käytetäänkö kuvassa sopivaa leveyttä mobiililaitteella?
Ensimmäisessä näkymässä näkyvää pääkuvaa ei yleensä kannata laiskalata. Sen sijaan sivun alempana olevat kuvat voidaan ladata vasta, kun niitä tarvitaan.
Kuvan optimointi ei kuitenkaan korjaa hidasta palvelinta. Jos kuvapyyntö alkaa vasta pitkän odotuksen jälkeen, ongelma voi olla renderöintiä estävissä tyylitiedostoissa, JavaScriptissä tai korkeassa TTFB:ssä.
Vaihe 5: tarkista fontit ja renderöinti
Sivu voi olla teknisesti ladattu, mutta käyttäjälle sisältö näkyy vasta myöhemmin. Syynä voivat olla renderöintiä estävät CSS-tiedostot, fontit tai JavaScript.
Fonttien kanssa yleisiä ongelmia ovat:
- useita fonttiperheitä ja leikkauksia
- liian monta fonttitiedostoa
- fonttien lataaminen ulkoisesta palvelusta
- tekstin piilottaminen ennen fontin latautumista
- fonttien puuttuvat mitat, jotka aiheuttavat sisällön liikkumista
Käytä vain niitä fonttipainoja, joita sivusto oikeasti tarvitsee. Jos sivustolla käytetään esimerkiksi normaalia ja lihavoitua leikkausta, kaikkia mahdollisia painoja ei tarvitse ladata.
CLS-arvoa voi heikentää tilanne, jossa kuvan, mainoksen tai fontin vaatimaa tilaa ei varata etukäteen. Kun selain saa resurssin myöhemmin ja muuttaa elementin kokoa, muu sisältö siirtyy. Tämä heikentää käyttökokemusta, vaikka sivu olisi muuten nopea.
Vaihe 6: etsi kolmannen osapuolen skriptit
Kolmannen osapuolen skriptejä ovat esimerkiksi analytiikka, evästehallinta, chatit, mainokset, sosiaalisen median upotukset ja maksupalveluiden komponentit.
Ne voivat hidastaa sivua kahdella tavalla:
- selain joutuu lataamaan lisää ulkoisia tiedostoja
- JavaScript varaa selaimen pääsäikeen aikaa ja hidastaa renderöintiä tai käyttäjän toimintaan reagointia
Jos INP on heikko, ongelma voi liittyä siihen, että selain käsittelee liian suuria JavaScript-tehtäviä. Tällöin sivu näyttää ehkä latautuneelta, mutta valikko, painike tai lomake reagoi viiveellä. Laboratoriotesteissä Total Blocking Time eli TBT voi auttaa tunnistamaan vastaavaa ongelmaa, vaikka INP mitataan varsinaisesti käyttäjän vuorovaikutuksesta. (web.dev)
Poista käytöstä sellaiset skriptit, joita et tarvitse. Lataa chat, video, kartta tai some-syöte vasta silloin, kun käyttäjä avaa kyseisen toiminnon. Tarkista myös, lisätäänkö sama skripti sivulle useamman lisäosan kautta.
Vaihe 7: selvitä tietokantakyselyt
Jos sivun TTFB on korkea, mutta selaimessa ladattavaa sisältöä on vähän, WordPressin taustalla tehtävä työ voi olla hidasta.
Tyypillisiä syitä ovat:
- liian suuri ja huoltamaton tietokanta
- paljon vanhoja revisioita ja tilapäisiä tietoja
- raskaat WooCommerce-kyselyt
- tuotteiden suodatus ja monimutkaiset haut
- lisäosien tekemät kyselyt jokaisella sivulatauksella
- ulkoiset API-kutsut, jotka odottavat vastausta
- puutteellinen objektivälimuisti
Tietokantaongelmaa ei kannata yrittää korjata poistamalla tietoja summittaisesti. Tee ensin varmuuskopio ja selvitä, mitkä taulut, kyselyt tai lisäosat aiheuttavat kuormaa.
Pienellä yrityssivulla tämä voi olla yksittäinen huonosti toimiva lisäosa. Verkkokaupassa syy voi olla tuotehaku, suodatus, tilaushistoria tai raportointi, joka käyttää paljon palvelimen resursseja.
Miten erotat optimointiongelman hosting-ongelmasta?
Seuraava taulukko auttaa tulkitsemaan havaintoja:
| Havainto | Todennäköinen syy | Ensimmäinen toimenpide |
|---|---|---|
| TTFB on korkea kaikilla sivuilla | Palvelin, välimuisti tai WordPressin taustatyö | Tarkista palvelinlokit, välimuisti ja resurssien käyttö |
| Vain yksi sivu on hidas | Sivun sisältö, kyselyt tai yksittäinen lisäosa | Testaa sivu ilman raskaita elementtejä |
| Sivusto hidastui uuden lisäosan jälkeen | Lisäosa tai lisäosien välinen ristiriita | Poista lisäosa käytöstä ja testaa uudelleen |
| LCP-elementti on suuri kuva | Kuvan koko tai latausjärjestys | Pakkaa kuva ja tarkista latausprioriteetti |
| INP on heikko | JavaScript tai kolmannen osapuolen skriptit | Vähennä ja viivästytä skriptejä |
| CLS on heikko | Fontit, kuvat tai dynaamiset elementit | Varaa elementeille tila etukäteen |
| Sivusto on nopea vähäisen liikenteen aikana mutta hidas ruuhkassa | Resurssit eivät riitä kuormaan | Seuraa kuormaa ja harkitse resurssien skaalausta |
| Välimuistin tyhjentäminen nopeuttaa sivua vain hetkeksi | Välimuistin asetukset tai palvelinresurssit | Selvitä, miksi välimuisti ei pysy tehokkaana |
Etene tässä järjestyksessä:
- Onko TTFB normaali, mutta LCP, INP tai CLS heikko?
Keskity kuviin, fontteihin, JavaScriptiin, teeman rakenteeseen ja kolmannen osapuolen skripteihin. - Paraneeko sivu selvästi oletusteemalla tai ilman lisäosia?
Korjaa tai vaihda ongelmallinen teema tai lisäosa. Hosting-ympäristön vaihtaminen ei poista sovelluksen sisäistä ongelmaa. - Onko TTFB korkea myös kevyellä sivulla ja toimivalla välimuistilla?
Selvitä palvelimen kuormitus, PHP-suoritus, tietokantakyselyt ja hosting-ympäristön rajoitukset. - Hidastuuko sivu liikenteen, kampanjan tai verkkokaupan käytön aikana?
Nykyiset resurssit eivät ehkä riitä samanaikaiseen kuormaan. Harkitse tehokkaampaa WordPress-hostingia, omaa virtuaalipalvelinta tai resurssien skaalausta. - Onko sivusto optimoitu, mutta hitaus jatkuu?
Tällöin hosting-ympäristön vaihtaminen voi olla perusteltua. WordPressille optimoitu palvelu, toimiva sivuvälimuisti ja riittävät palvelinresurssit vähentävät ympäristöstä johtuvia pullonkauloja.
Zonerin WP.one on WordPressille optimoitu hosting-ratkaisu, joka on suunnattu sekä yrityssivustoille että WooCommerce-verkkokaupoille. Palveluun kuuluu muun muassa WordPress-ympäristöön suunniteltuja suorituskyky- ja ylläpito-ominaisuuksia. (zoner.fi)
Yhteenveto
WordPress-sivun hitaus kannattaa tutkia ketjuna:
- palvelin vastaa
- WordPress rakentaa sivun
- välimuisti tarjoilee sisällön
- selain lataa kuvat, fontit ja tyylit
- JavaScript käsitellään
- pääsisältö renderöidään käyttäjälle
Kun mittaat jokaisen vaiheen erikseen, näet nopeasti, onko ongelma teemassa, lisäosassa, kuvissa, välimuistissa, tietokannassa vai hosting-ympäristössä.
Usein nopein ratkaisu on pieni ja tarkka muutos. Joskus sivusto on kuitenkin kasvanut siihen pisteeseen, että nykyinen hosting ei enää riitä. Silloin optimoinnin ja resurssien lisäämisen yhdistelmä, tai siirtyminen WordPressille optimoituun ympäristöön, antaa sivustolle paremman perustan kasvaa.
