Miksi WooCommerce-kauppa hidastuu ja miten se korjataan

WooCommerce-kauppa hidastuu yleensä vähitellen: lisäosia kertyy, tietokanta paisuu ja kävijämäärä kasvaa samalla palvelimella, jolla kauppa avattiin. Hitaus johtuu harvoin yhdestä asiasta, joten korjaus alkaa mittaamisesta, ei uuden välimuistilisäosan asentamisesta. Tässä artikkelissa käyn läpi yleisimmät löytämäni syyt ja niiden korjaukset.

Miksi verkkokauppa on hitaampi kuin tavallinen WordPress-sivusto?

Tavallisen sivuston sivut voi tallentaa välimuistiin kokonaisina. Verkkokaupassa se ei onnistu kaikkialla: ostoskori, kassa ja oma tili ovat jokaiselle kävijälle erilaisia, joten ne lasketaan joka kerta palvelimella. Lisäksi tuotteilla on paljon lisätietoja, varianteja ja hintoja, joita haetaan tietokannasta. Siksi kauppa paljastaa heikon palvelimen tai raskaan lisäosan nopeammin kuin esittelysivusto.

Lisäosat: montako on liikaa?

Lisäosien määrä ei ratkaise, vaan se, mitä ne tekevät jokaisella sivulatauksella. Yksi huonosti tehty lisäosa voi ajaa kymmeniä tietokantakyselyjä joka sivulla, kun taas kymmenen kevyttä ei näy missään.

Käytän mittaamiseen Query Monitor -lisäosaa testiympäristössä. Se näyttää, mikä lisäosa tekee eniten kyselyjä ja mitkä kyselyt ovat hitaita. Usein syyllinen löytyy nopeasti: unohtunut tilastolisäosa, raskas sivunrakentaja tai lisäosa, joka lataa omat tiedostonsa jokaiselle sivulle, vaikka sitä käytetään vain yhdellä.

Tietokanta paisuu huomaamatta

Kolme asiaa kasvattaa WooCommerce-kaupan tietokantaa eniten:

Tilausten tallennustapa. WooCommerce siirtyi versiossa 8.2 uuteen High-Performance Order Storage -tallennukseen (HPOS), jossa tilaukset ovat omissa tauluissaan. Uusissa kaupoissa se on oletuksena päällä, mutta vanhoissa kaupoissa se pitää ottaa käyttöön itse. Jos kauppasi on avattu ennen syksyä 2023, tarkista tilanne kohdasta WooCommerce → Asetukset → Lisäasetukset → Ominaisuudet.
Ajastettujen tehtävien loki. WooCommerce ja monet lisäosat käyttävät Action Scheduler -jonoa. Valmiiden tehtävien lokit jäävät tauluihin ja vilkkaassa kaupassa niitä voi olla satojatuhansia rivejä.
Automaattisesti ladattavat asetukset. WordPress lataa osan asetuksista jokaisella sivulatauksella. Kun lisäosat tallentavat sinne isoja tietoja, jokainen sivu hidastuu. WordPress 6.6 lisäsi Sivuston terveys -työkaluun tarkistuksen, joka varoittaa, kun näitä tietoja on yhteensä noin 800 kt.

Tietokannan siivoaminen tarkoittaa käytännössä rivien poistamista, joten se tehdään aina varmuuskopion kanssa ja ensin testiympäristössä.

Kuinka monta variaatiota on liikaa?

WooCommercessa jokainen tuotteen muunnelma, eli variaatio, on tietokannassa oma tuotteensa: sillä on oma rivi sekä omat hinta-, varasto-, tuotekoodi- ja ominaisuustietonsa. Kun paidalla on viisi kokoa ja kuusi väriä, variaatioita on 30. Kun mukaan tulee vielä materiaali ja painatus, määrä kasvaa nopeasti satoihin.

WooCommerce varautuu tähän itse. Sen ohjeiden mukaan tuotesivun käytös muuttuu, kun variaatioita on yli 30:

Enintään 30 variaatiota: valikot ovat dynaamisia. Kun T-paidalla on ominaisuudet Koko ja Väri ja asiakas valitsee koon, värivalikko päivittyy näyttämään vain ne värit, joita valitussa koossa on saatavilla.
Yli 30 variaatiota: valikot ovat staattisia. Värivalikko näyttää kaikki värit, vaikka osaa niistä ei olisi valitussa koossa. Asiakas huomaa sen vasta valittuaan, kun sivulle tulee ilmoitus, ettei yhdistelmää löydy ja pitää valita toinen.

Raja on olemassa suorituskyvyn takia. Jos saatavilla olevat yhdistelmät pitää laskea uudelleen jokaisen valinnan jälkeen, se hidastaa tuotesivua sitä enemmän, mitä enemmän variaatioita on.

Rajaa voi muuttaa suodattimella woocommerce_ajax_variation_threshold, esimerkiksi teeman functions.php-tiedostossa:

add_filter( 'woocommerce_ajax_variation_threshold', function ( $qty, $product ) {
	return 50;
}, 10, 2 );

WooCommerce neuvoo valitsemaan pienimmän arvon, joka kaupalle riittää, koska suurempi raja hidastaa tuotesivuja. Esimerkki nostaa rajan kaikille tuotteille. Suodatin saa parametrina myös tuotteen, joten rajan voi nostaa vain niille tuotteille, jotka sitä oikeasti tarvitsevat.

Muutama kymmenen variaatiota toimii hyvin. Satojen kohdalla tuotesivu ja tuotteen muokkaus hallintapaneelissa hidastuvat selvästi. Olen törmännyt kauppoihin, joissa yhdellä päätuotteella oli noin tuhat variaatiota. Silloin palvelin on kovilla jokaisella tuotesivun latauksella ja yksikin tuotteen tallennus voi kestää pitkään.

Ratkaisuja on useita:

Variaatio vain, kun se on tarpeen. Variaatio kannattaa tehdä vain silloin, kun yhdistelmällä on oma hinta, varasto tai tuotekoodi. Valinnat, jotka eivät vaikuta näihin, kuten kaiverrusteksti tai lahjapaketointi, kannattaa toteuttaa tuotteen lisäkenttinä.
Jaa tuote useaksi tuotteeksi. Esimerkiksi jokainen malli tai materiaali voi olla oma tuotteensa, jonka sisällä valitaan koko ja väri. Tuotteet linkitetään toisiinsa, jotta asiakas löytää vaihtoehdot.
Laske hinta säännöllä. Mittatilaustuotteissa ja konfiguraattoreissa jokaista yhdistelmää ei kannata luoda valmiiksi. Hinta lasketaan asiakkaan valintojen perusteella vasta, kun valinnat on tehty. Tähän sopivat esimerkiksi WooCommercen oma maksullinen Product Add-Ons tai ilmainen PPOM, joiden avulla tuotteeseen lisätään valintoja, joilla on oma hintansa, ilman että jokaisesta yhdistelmästä tulee variaatio.
Älä nosta rajaa sokeasti. Jos 30 variaation raja tulee vastaan, se on merkki tuoterakenteen tarkistamisesta, ei pelkästä asetuksen muuttamisesta.

Välimuisti: sivu, objektit ja selain

Välimuisteja on kolmea tasoa ja kauppa tarvitsee yleensä niitä kaikkia:

Sivuvälimuisti tallentaa valmiit sivut. Tuote- ja kategoriasivuille se sopii hyvin, mutta ostoskori, kassa ja oma tili pitää jättää sen ulkopuolelle.
Objektivälimuisti (esimerkiksi Redis) tallentaa tietokantakyselyjen tulokset muistiin. Siitä on eniten hyötyä juuri niillä sivuilla, joita ei voi tallentaa kokonaisina.
Selainvälimuisti ja kuvien optimointi huolehtivat siitä, ettei kävijän selain lataa samoja tiedostoja uudelleen.

Pelkkä välimuistilisäosa ei korjaa hidasta palvelinta. Se piilottaa ongelman etusivulta, mutta kassa on edelleen hidas ja juuri siellä kauppa tehdään.

Hosting ratkaisee enemmän kuin moni luulee

Halvassa webhotellissa kauppa jakaa palvelimen kymmenien muiden sivustojen kanssa. Kun naapurilla on ruuhkaa, sinunkin kassasi hidastuu. WordPressiin erikoistunut hallinnoitu hosting, kuten Seravo, hoitaa valmiiksi palvelimen välimuistin, PHP-version ja päivitykset. Ennen kuin kauppaa optimoidaan viikkoja, kannattaa tarkistaa, onko palvelin edes riittävä.

WPML: monikielisyyden superhidastaja

Monikielinen kauppa on oma lukunsa. Omassa työssäni WPML on toistuvasti ollut yksi suurimmista yksittäisistä hidastajista. Se on monipuolinen ja kattaa lähes kaiken, mutta se tuo mukanaan omat tietokantataulunsa, merkkijonojen käännökset ja lisää kyselyjä jokaiselle sivulle. WooCommercen kanssa tarvitaan vielä erillinen WooCommerce Multilingual -lisäosa, joka lisää kuormaa entisestään.

Mittaukset vaihtelevat sivustoittain, eikä riippumatonta vertailua ole. WPML:n oma tuki on myös kiistänyt joissakin tapauksissa merkittävän hidastuksen. Siksi mittaan aina kyseisen kaupan omilla tuotesivuilla, enkä luota yleistyksiin.

Miksi suosittelen Polylangia?

Uusiin monikielisiin kauppoihin suosittelen Polylangia. Se käyttää WordPressin omia rakenteita kielten ja käännösten tallentamiseen, joten se on kevyempi ja ennustettavampi. WooCommerce-kauppaan tarvitaan maksullinen Polylang for WooCommerce -lisäosa, joka kääntää kaupan sivut, sähköpostit ja tuoteominaisuudet sekä synkronoi muun muassa varastosaldot kieliversioiden välillä.

Polylangilla on omat rajoituksensa: siinä ei ole valmista valuutanvaihtoa ja hyvin monimutkaisissa tuotevalikoimissa WPML:n laajemmat työkalut voivat olla tarpeen. Vaihto WPML:stä Polylangiin on lisäksi aina oma projektinsa, koska käännökset pitää siirtää. Siksi teen vaihdon vain, kun mittaus osoittaa, että hyöty on todellinen.

Mistä aloittaa?

Mittaa nykytila: sivun latausaika, palvelimen vasteaika ja kassan nopeus.
Katso Sivuston terveys -työkalusta, onko varoituksia. Tarkista myös, onko HPOS käytössä.
Etsi Query Monitorilla raskaimmat lisäosat ja hitaimmat kyselyt testiympäristössä.
Tarkista, onko kaupassa tuotteita, joilla on satoja variaatioita.
Varmista, että palvelin ja objektivälimuisti ovat kunnossa.
Vasta sitten optimoi kuvat, skriptit ja muut yksityiskohdat.

Jos kauppasi kaipaa tällaista läpikäyntiä, se kuuluu WordPress- ja WooCommerce-työhöni. Nopeus ja tekninen rakenne käydään läpi myös SEO- ja GEO-auditissa, jos haluat arvion koko sivustosta.

Usein kysyttyä

Nopeuttaako välimuistilisäosa WooCommerce-kauppaa?

Osittain. Se nopeuttaa tuote- ja kategoriasivuja, mutta ostoskoria, kassaa ja omaa tiliä ei voi tallentaa välimuistiin. Niiden nopeus riippuu palvelimesta, tietokannasta ja lisäosista.

Pitäisikö HPOS ottaa käyttöön vanhassa kaupassa?

Yleensä kyllä, kunhan kaikki käytössä olevat lisäosat tukevat sitä. WooCommerce näyttää yhteensopimattomat lisäosat asetuksissa. Siirto tehdään ensin testiympäristössä ja tilaukset synkronoidaan vanhan ja uuden tallennuksen välillä, kunnes kaikki toimii.

Montako variaatiota yhdellä tuotteella voi olla?

Teknistä ylärajaa ei ole, mutta WooCommerce käsittelee tuotesivulla oletuksena dynaamisesti vain 30 variaatiota. Muutama kymmenen toimii hyvin. Jos variaatioita on satoja, tuoterakenne kannattaa miettiä uudelleen.

Kannattaako WPML vaihtaa Polylangiin?

Ei automaattisesti. Jos kauppa on hidas ja mittaus osoittaa WPML:n olevan suuri osa ongelmaa, vaihto voi kannattaa. Uudessa monikielisessä kaupassa valitsen yleensä Polylangin alusta asti.