Hidas verkkosivusto menettää kävijöitä nopeammin kuin ehdit lukea tämän lauseen. Google totesi jo kauan sitten, että mobiilikäyttäjien kärsivällisyyden raja on 3 sekuntia. Sen jälkeen välitön poistumisprosentti nousee, konversiot laskevat ja hakusijoitukset kärsivät. WordPress tarjoaa joustavuutta, mutta joustavuus ilman kuria muuttaa sivuston paisuneeksi sekamelskaksi, jossa on 50 lisäosaa, optimoimattomia kuvia ja neljä eri fonttia yhdessä otsikossa.

Ongelma ei ole itse WordPress. Ongelma on se, että useimmat sivuston omistajat eivät mittaa nopeutta eivätkä tiedä, mistä optimoinnissa kannattaisi aloittaa. Samaan aikaan noin kahdellakymmenellä todistetusti toimivalla toimenpiteellä latausajan voi pudottaa 7 sekunnista sekunnin murto-osiin ilman alustan vaihtoa ja ilman toiminnallisuuden menettämistä.

Alla on 21 konkreettista tekniikkaa, joita käytämme omissa projekteissamme. Osa tuottaa välittömiä tuloksia, osa toimii yhdistelmänä. Kaikki on testattu tuotantosivustoilla oikealla liikenteellä.

💡 Nopea yleiskatsaus:

• Mittaa lähtötason nopeus GTmetrixillä, jotta saat vertailukohdan ja tunnistat pullonkaulat
• Aloita palvelimen perustasta: hosting, PHP 8.3, GZIP-pakkaus ja CDN tuottavat leijonanosan nopeushyödyistä
• Asenna välimuistilisäosa ja yhdistele skriptit ja tyylitiedostot vähentääksesi HTTP-pyyntöjä dramaattisesti
• Optimoi media: pakkaa kuvat, poista turhat fontit, koodaa favicon base64-muotoon
• Ota pois käytöstä kaikki, mitä et käytä: tarpeettomat lisäosat, pingbackit, WordPressin emojit, sivurakentajien päällekkäiset pyynnöt

Mistä aloittaa: nopeuden mittaaminen oikein

Ennen kuin korjaat mitään, tarvitset numerot näkyviin. Kätevimmät ilmaiset työkalut ovat GTmetrix ja Pingdom. Ne tarjoavat abstraktien pisteiden sijaan konkreettisia mittareita: kokonaislatausaika, sivun kokonaiskoko ja HTTP-pyyntöjen määrä. GTmetrix näyttää myös "vesiputouksen", visuaalisen kaavion, joka havainnollistaa, miten kukin elementti latautuu, ja tekee heti selväksi, mikä aiheuttaa hidastelua.

Toimituksemme suosii GTmetrixiä sen läpinäkyvän käyttöliittymän ja mahdollisuuden vuoksi testata eri alueilta (rekisteröitymisen jälkeen). Keskeiset parametrit, joita tarkastelemme:

• PageSpeed Score ja YSlow Score arvioivat frontend-optimointia. Korkea pistemäärä ei takaa välitöntä latautumista, mutta matala pistemäärä kertoo, että parantamisen varaa on.
• Fully Loaded Time on todellinen kokonaislatausaika. Tämä vaikuttaa käyttäjien käyttäytymiseen, ei pistemäärään. Euroopassa ja Yhdysvalloissa sijaitseville palvelimille ≤2 sekuntia on normi; Euroopasta testattuna Aasian alueille luku on korkeampi, joten huomioi yleisösi maantieteellinen sijainti.
• Total Page Size tulisi olla mahdollisimman pieni. Keskimääräiselle blogisivulle kannattaa tavoitella alle 1 Mt:n kokoa.
• Requests kertoo palvelinpyyntöjen määrän. Jokainen ylimääräinen pyyntö tarkoittaa viivettä. Hyvin optimoidulla kotisivulla voi olla vain 7-10 pyyntöä.

GTmetrixin välilehdet: mistä pullonkaulat löytyvät

PageSpeed / YSlow -välilehti antaa konkreettisia frontend-suosituksia: mitä pakata, mitä lykätä, missä ottaa selaimen välimuisti käyttöön. Käy lista läpi ylhäältä alas ja korjaa jokainen kohta; yksi optimointi parantaa usein useita mittareita samanaikaisesti.

Waterfall-välilehti on tärkein diagnostiikkatyökalu. Täältä näet, kuinka kauan palvelin miettii ennen vastaamista (ensimmäinen tavu), mitkä skriptit ja tyylit latautuvat peräkkäin, latautuvatko fontit paikallisesti ja vetääkö jokin pieni elementti koko kaaviota alaspäin. Alla oleva esimerkki näyttää optimoimattoman sivuston vesiputouksen: kymmeniä pyyntöjä ja pitkiä odotuspalkkeja.

Timings-välilehti näyttää TTFB:n (Time to First Byte). Tämä on aika selaimen pyynnöstä palvelimen vastauksen ensimmäiseen tavuun. Google suosittelee pitämään TTFB:n alle 300 ms:ssa. Jos sinun lukemasi on 800-1000 ms, ongelma on hostingissa tai välimuistituksen puutteessa, ei kuvissa.

Palvelin ja infrastruktuuri: nopean latauksen perusta

Palvelinpuoli tuottaa leijonanosan kokonaisnopeuden parannuksista. Jos tämä on pielessä, muut tekniikat vain silottavat pintaa.

Hosting ja palvelimen sijainti

Hostingin valinta ei ole paikka, jossa kannattaa säästää. Palveluntarjoajat, kuten A2 Hosting ja SiteGround, pitävät vasteajat alhaisina ja tarjoavat palvelinkeskuksia Yhdysvalloissa, Euroopassa ja Aasiassa. Pääsääntö: palvelimen tulisi sijaita maantieteellisesti lähellä kohdeyleisöäsi. Eurooppaan eurooppalainen palvelinkeskus, Yhdysvaltoihin amerikkalainen. Jos yleisösi on maailmanlaajuinen, CDN tulee avuksi (katso alla).

PHP-versio

WordPress vaatii nykyään vähintään PHP 7.4:n, ja suositeltu vähimmäisversio vuodesta 2025 alkaen on PHP 8.3. Vaihto versiosta 7.4 versioon 8.3 tuo 1,5-2-kertaisen nopeuslisäyksen puhtaassa PHP-koodissa. Tämä on ilmaista kiihdytystä, jonka monet sivuuttavat. Vaihda PHP-versio hosting-paneelissasi (cPanel: Select PHP Version) tai ottamalla yhteyttä tukeen. Ennen vaihtoa varmista, että teemasi ja lisäosasi ovat yhteensopivia; vuonna 2026 valtaosa suosituista lisäosista tukee jo versiota 8.3.

GZIP-pakkaus

GZIP pakkaa HTML:n, CSS:n ja JavaScriptin palvelimella ennen niiden lähettämistä selaimeen, vähentäen siirrettävän datan määrää 60-80%. Ota se käyttöön yhdellä valintaruudulla välimuistilaajennuksessa (Swift Performance, WP Rocket) tai parilla rivillä .htaccess-tiedostossa Apachea varten. Tämä ei ole valinnainen juttu, vaan perusstandardi. Ilman GZIP:iä sivustosi ei läpäise PageSpeed Insights -tarkistuksia.

CDN: Cloudflare ja BunnyCDN

Sisällönjakeluverkko (CDN) tallentaa staattiset tiedostot (kuvat, CSS, JS) välimuistiin kymmenille palvelimille ympäri maailmaa ja palvelee käyttäjiä lähimmältä solmupisteeltä. Suosittelemme tätä yhdistelmää: Cloudflare (peruspaketti on ilmainen) yleisiin tehtäviin ja BunnyCDN mediatiedostojen kuorman purkamiseen. Yhdessä ne ratkaisevat maantieteelliset ongelmat, hotlink-suojauksen (Cloudflaren Scrape Shieldin kautta) ja staattisen välimuistituksen.

Lisäosat ja välimuistitus: järjestystä tekemiseen

Välimuistilaajennus

Välimuistilaajennus luo sivuista staattisia HTML-kopioita ja tarjoilee niitä sen sijaan, että PHP ajaisi jokaisella käynnillä. Ero on kuin lukisi valmista kirjaa verrattuna siihen, että kirjoittaisi sen uudelleen käsin jokaiselle lukijalle.

Swift Performance -laajennus hoitaa useita listamme kohtia kerralla: välimuistitus, skriptien ja tyylien yhdistäminen ja minifiointi, tietokannan optimointi, lazy loading, kriittinen CSS ja fonttien paikallinen hostaus. Voit asentaa ja määrittää sen 10 minuutissa; perus "Auto"-tila tuottaa 80% tuloksista ilman manuaalista parametrien säätöä.

Skriptien minifiointi ja yhdistäminen

Jokainen WordPress-lisäosa voi ladata oman CSS:nsä ja JavaScriptinsä, mikä johtaa kymmeniin HTTP-pyyntöihin tyhjästä. Yhdistämistyökalut liittävät hajallaan olevat tiedostot yhdeksi, kun taas minifiointi poistaa tyhjätilat ja kommentit. Lopputulos: 15-20 skriptipyynnön sijaan sinulla on 1-2. Swift Performance hoitaa tämän Scripts & Styles Optimization -osiossa; käyttöönoton jälkeen muista tarkistaa sivuston etupuoli, sillä harvinaiset lisäosat voivat hajota ja vaatia poissulkemista yhdistämisestä.

Käyttämättömien lisäosien poistaminen käytöstä

Ota pois käytöstä kaikki, mikä ei ole aktiivisessa käytössä. Jokainen aktiivinen lisäosa on potentiaalinen pyyntö, taustalla oleva cron-tehtävä tai ylimääräinen skripti. Mene kohtaan "Lisäosat → Asennetut" ja käy lista läpi: se lomakerakentaja, jonka asensit yhtä sivua varten vuosi sitten? Ota se pois käytöstä. Se kokeellinen SEO-lisäosa, joka tekee samaa kuin pääasiallinen lisäosasi? Poista se.

Tietokannan optimointi

Ajan myötä tietokantoihin kertyy artikkelien aiempia versioita, vanhentuneita transienttitietueita, roskakommentteja ja metatietojen kaksoiskappaleita. Swift Performancen Database-osio poistaa tämän sotkun yhdellä painikkeella. Säännöllistä siivousta varten aseta aikataulu (kerran viikossa riittää).

Lazy loading

YouTube-upotukset ja Google Maps latautuvat raskaasti: yksi video voi vetää satoja kilotavuja ennen kuin käyttäjä edes vierittää sen kohdalle. Ota lazy load käyttöön iframeille, niin videot latautuvat vasta, kun ne tulevat näkyviin vieritettäessä. Kuville lazy load tuo maltillisempia hyötyjä, mutta auttaa silti.

Media ja fontit: turhan kuorman karsiminen

Kuvien optimointi

Kuvat ovat yleensä sivun raskainta sisältöä. Ennen kuin lataat ne sivustollesi, pienennä niiden fyysisiä mittoja: 2400 px leveä kuvakaappaus sivustolla, jonka sisältöalue on 800 px, tarkoittaa turhia kilotavuja. Käytä Adobe Photoshopia tai ilmaista GIMPiä rajataksesi kuva tarvittavaan leveyteen.

Aja kuvat latauksen jälkeen optimoijan läpi. Swift Performance (Media-välilehti) pakkaa PNG- ja JPEG-tiedostot hallitulla laatuhäviöllä (ei näkyvää eroa, mutta tiedostokoko pienenee huomattavasti).

Fontit: vähemmän, nopeammin

Google Fonts latautuu oletuksena ulkoiselta palvelimelta, mikä lisää ylimääräisen DNS-haun ja viiveen. Ratkaisu on hostata fontit paikallisesti lataamalla ne teemakansioosi. Swift Performance lataa Google Fontsit palvelimellesi automaattisesti (Fonts-välilehti).

Rajoita leikkausten määrää: yksi perhe + kaksi leikkausta (regular ja bold) = 2 pyyntöä. Kolme perhettä, joista jokaisessa neljä leikkausta = 12 pyyntöä. Nopeusero on huomattava.

Font Awesome ilman jättitiedostoa

Koko Font Awesome -paketti painaa noin 120 kt, vaikka sivustosi käyttää todellisuudessa 3-5 kuvaketta. Swift Performancen Critical Font -toiminto rakentaa räätälöidyn tiedoston, joka sisältää vain sivusi koodissa esiintyvät kuvakkeet. Koko putoaa noin 120 kt:sta 5-10 kt:uun.

Favicon Data URI:n avulla

Pieni sivustokuvake jää usein latausketjun viimeiseksi elementiksi, mikä viivästyttää "täysin ladattu" -tapahtumaa 200-400 ms. Ratkaisu on upottaa kuvake suoraan HTML:ään base64-koodauksella, mikä poistaa ylimääräisen HTTP-pyynnön.

Koodaa .ico-tiedosto base64-muotoon Data URL Makerilla ja lisää koodi functions.php-tiedostoon:

1
function add_favicon() {
2
    echo '<link rel="shortcut icon" type="image/x-icon"
3
    href="data:image/vnd.microsoft.icon;base64,AAABAAEAQEAAAAEAIAAo.......=" />';
4
}
5
add_action('wp_head', 'add_favicon');

Poista tämän jälkeen alkuperäinen favicon mukauttajasta: Ulkoasu → Mukauta → Sivuston identiteetti → Sivustokuvake → Poista.

Älä ylikuormita teemaasi kuvilla

Kevyt teema on perusta. WP Astra, jonka asennettu koko on alle 50 kt eikä jQuery-riippuvuutta ole, latautuu huomattavasti nopeammin kuin monet kilpailijat. Ennen teeman valintaa testaa se GTmetrixin kautta demopalvelimella.

Loppusiivous: hienosäätö

Pingbackien ja trackbackien poistaminen käytöstä

Pingbackit ovat vanhentunut mekanismi, jota käyttävät nykyään lähes yksinomaan roskapostittajat. Jokainen pingback luo ylimääräisen HTTP-pyynnön ja sotkee tietokantaa. Poista käytöstä kahdessa paikassa:

Tulevia kirjoituksia varten: Asetukset → Keskustelu → poista valinta kohdasta "Salli linkki-ilmoitukset muista blogeista (pingbackit ja trackbackit) uusissa kirjoituksissa."

Olemassa olevia kirjoituksia varten: Artikkelit → Kaikki artikkelit → valitse kaikki → Massatoiminnot: Muokkaa → Käytä → Pingit → Älä salli → Päivitä.

Turhien WordPress-ominaisuuksien poistaminen käytöstä

WordPressin emoji lisää DNS-esihaun ja ylimääräisen skriptin (wp-emoji-release.min.js) jokaiselle sivulle. Gravatar-pyynnöt aiheuttavat ulkoisia kutsuja kommentoijien avatareille. Molemmat voi poistaa käytöstä Swift Performancen kautta (Tweaks-välilehti) parilla valintaruudulla. Säästö: miinus 2-3 HTTP-pyyntöä ja useita kymmeniä kilotavuja.

Yksi sivusto, yksi hosting-tili

Usean sivuston hostaaminen jaetulla paketilla tarkoittaa suoritinajan, muistin ja levy-I/O:n jakamista niiden kesken. Kun yksi projekti saa paljon liikennettä, muut kärsivät. Jos budjetti sallii, anna jokaiselle sivustolle oma tilinsä.

Päällekkäiset HTTP-pyynnöt sivunrakentajilta

Elementor ja muut sivunrakentajat saattavat monistaa Google Fonts- ja Font Awesome -pyyntöjä silloinkin, kun fontit on jo hostattu paikallisesti. Kun olet määrittänyt paikallisen fonttihostauksen, tarkista GTmetrixin Waterfall uudelleen: etsi ylimääräisiä kutsuja osoitteisiin fonts.googleapis.com ja fontawesome.com. Jos niitä löytyy, mene sivunrakentajan asetuksiin ja poista fonttien/kuvakkeiden lataus liitännäistasolla.

⁉️🤔 Usein kysytyt kysymykset

Mikä hosting kannattaa valita nopeaa WordPressiä varten?

A2 Hosting ja SiteGround näyttävät testeissä johdonmukaisesti matalaa TTFB:tä eurooppalaisilla ja amerikkalaisilla palvelimilla. Ratkaiseva kriteeri on, että palvelinkeskus sijaitsee yleisösi alueella. Jos budjetti on vähintään 15 $/kk, harkitse hallittua WordPress-hostingia: palveluntarjoaja hoitaa välimuistituksen, PHP-version ja palvelimen optimoinnin puolestasi.

Tarvitsenko välimuistilisäosaa, jos hostingini tarjoaa palvelinpuolen välimuistin?

Palvelinvälimuisti (Varnish, Nginx FastCGI) ja välimuistilisäosat toimivat eri tasoilla; ne täydentävät toisiaan eivätkä ole päällekkäisiä. Palvelinvälimuisti on nopeampi (ei PHP-suoritusta lainkaan), mutta se ei hallitse skriptien yhdistämistä, lazy loadingia tai tietokannan siivousta. Lisäosa kuten Swift Performance hoitaa nämä tehtävät, joten asenna molemmat.

Onko realistista ladata WordPress 0,5 sekunnissa?

Kyllä, mutta vain hyvin optimoidulle kevyelle sivulle nopealla hostingilla, välimuistilla ja CDN:llä, kun testataan maantieteellisesti läheltä. Keskiverto sivusto kaupallisella teemalla, tusinalla lisäosia ja mediakontenttia saavuttaa tyypillisesti 1,5-2,5 sekuntia kaikkien 21 kohdan optimoinnin jälkeen. Tämä on erinomainen tulos, joka ei haittaa hakukoneoptimointia eikä käyttökokemusta.

Pitäisikö PHP päivittää uusimpaan versioon?

Kyllä, mutta tarkista yhteensopivuus. PHP 8.3 tarjoaa noin 30% parannuksen verrattuna versioon 7.4 raa'assa koodin suorituksessa. Ennen päivitystä päivitä kaikki lisäosat ja teemat uusimpiin versioihinsa ja tee varmuuskopio. Jos sivustosi nojaa vanhentuneeseen lisäosaan, jota ei ole päivitetty vuoden 2022 jälkeen, korvaa se ensin vaihtoehdolla ja vaihda sitten PHP.

Entä jos nopeus on edelleen alhainen kaikkien näiden vinkkien noudattamisen jälkeen?

Palaa GTmetrix Waterfalliin ja käy ketju läpi ylhäältä alas. Etsi: (1) hidas TTFB (hosting- tai välimuistiongelma); (2) pitkät latausajat tietyille skripteille (todennäköisesti ulkoinen resurssi on hidas, harkitse paikallista hostausta); (3) suuri määrä pyyntöjä (skriptit/tyylit kaipaavat yhdistämistä); (4) raskaat kuvat (tarkista, että kaikki on pakattu eikä niitä ladata täydellä resoluutiolla). Yleensä yksi näistä neljästä kohdasta poistaa suurimman osan jäljellä olevasta hidastelusta.

Onko vaivan arvoista: mitä nämä 21 askelta tuottavat

Sivuston nopeus ei ole kertaluonteinen korjaus, vaan hygieniaa. Näistä 21 tekniikasta kolme tuottaa välittömiä tuloksia: välimuistilisäosa (10 minuuttia konfigurointiin), GZIP-pakkaus (yksi valintaruutu) ja CDN (perus Cloudflare käyttöön puolessa tunnissa). Tee nämä tänään, ja huomenna GTmetrix näyttää perustavanlaatuisesti erilaisia lukuja.

Loput askeleet tuovat asteittaisia parannuksia. Kuvien optimointi, paikalliset fontit ja tietokannan siivous eivät yksinään mullista mitään, mutta yhdessä ne leikkaavat huomattavia murto-osia jäljellä olevasta latausajasta. Suorita koko lista, ja sivustosi on nopeampi kuin useimmat WordPress-kilpailijat.