Varför är min WooCommerce-butik långsam?

Det är nästan alltid en av sex saker, och jag går igenom dem i den ordning jag hittar dem hos kunder: ett webbhotell med gammal PHP och för få resurser, ingen sidcache eller objektcache, för många eller för tunga plugins, oskalade bilder, en databas full av autoload-options och gamla sessioner, och till sist WooCommerce eget cart fragments-skript. De två första står för den större delen av fallen.

Mät innan du ändrar något. Ett cacheplugin ovanpå ett överbelastat webbhotell döljer problemet för besökare utan varukorg, men kassan är lika långsam som förut.

Symtomen säger var felet sitter

Är hela sajten långsam, även startsidan utan något i varukorgen, ligger felet i servern eller i något som körs på varje sidladdning: PHP-version, saknad cache, ett tungt plugin. Är produktlistor och sök långsamma men enkla sidor snabba handlar det om databasen eller om bilder. Är det bara varukorg, kassa och Mitt konto som segar är det PHP och databasen, eftersom de sidorna aldrig cachas.

En butik som var snabb och blev långsam över tid har nästan alltid ett databasproblem eller ett plugin som uppdaterats. En butik som varit långsam från start har fel webbhotell eller fel tema.

Så mäter du

Jag använder tre verktyg och inget mer. Lighthouse i Chrome, eller PageSpeed Insights för samma sak via webben, ger värden för hur sidan upplevs: tid till största synliga element (LCP), layoutskiften och hur mycket JavaScript som laddas. Google räknar LCP under 2,5 sekunder som bra. Lighthouse visar också serverns svarstid, och är den över en sekund på en vanlig sida är det servern eller PHP-koden, inte frontend, som är problemet.

Query Monitor är ett plugin som visar vad som händer i PHP på varje sida: antal databasfrågor, vilka plugins som orsakar dem, långsamma frågor och hur lång tid PHP tar totalt. Det är det snabbaste sättet att hitta ett plugin som gör tjugo frågor på varje sida. Aktivera det bara medan du mäter.

WooCommerce, Status visar PHP-version, minnesgräns, databasens storlek per tabell och vilket tema och vilka plugins som är aktiva. Under fliken Verktyg finns knappar för att rensa transients och kundsessioner, vilket jag återkommer till.

Orsakerna i sannolikhetsordning

Webbhotellet och PHP-versionen

PHP 8.3 är vad WordPress rekommenderar som lägsta version. PHP 8.2 får bara säkerhetsfixar och slutar underhållas 31 december 2026. Hittar du 7.4 eller 8.0 under WooCommerce, Status har du både ett prestandaproblem och ett säkerhetsproblem. Byt version i webbhotellets kontrollpanel och testa kassan efteråt, för det är där gamla plugins brukar gå sönder.

Här skiljer sig delat webbhotell från managed WordPress-hosting. På ett delat konto hos Loopia, Oderland, Inleed eller Binero delar du server med många andra, du får ett begränsat antal PHP-processer och sällan någon objektcache. Det fungerar för en liten butik med få samtidiga kunder. Managed WordPress-hosting betyder att cache ligger i servern i stället för i ett plugin, att Redis eller Memcached ingår och att någon annan sköter PHP-uppgraderingarna. Oderland beskriver till exempel sin plattform som LiteSpeed med tillgång till både Memcached och Redis. Loopias produktsida säger inget om tekniken, så där får du fråga supporten vad som ingår innan du väljer paket.

Ingen sidcache och ingen objektcache

Sidcache sparar färdiga HTML-sidor så att PHP och databasen inte körs alls för besökare utan varukorg. Det är den enskilt största förbättringen för startsida, kategorier och produktsidor. WooCommerce ser själv till att varukorg, kassa och Mitt konto inte cachas, och de flesta cacheplugin känner igen WooCommerce-cookien som sätts när något läggs i varukorgen.

Objektcache är något annat. WordPress hämtar alla options, termer och mycket produktdata från databasen på varje sidladdning som inte träffar sidcachen. Med Redis eller Memcached ligger det i minnet i stället, och det är precis de sidorna, kassan och varukorgen, som vinner mest. Verktyg, Hälsa i WordPress flaggar när en persistent objektcache saknas och sajten är stor nog att behöva en. Webbhotellet måste erbjuda tjänsten; ett plugin ensamt räcker inte.

För många eller för tunga plugins

Det är inte antalet som spelar roll utan vad de gör på varje sidladdning. Öppna Query Monitor på en produktsida och sortera databasfrågor per komponent. Ett plugin som gör fler frågor än WooCommerce självt är ett problem oavsett hur litet det är. Vanliga syndare i mina mätningar är plugins för relaterade produkter, önskelistor, ”nyligen visade produkter” och äldre SEO-plugins som bygger sitemaps vid sidladdning. Avaktivera, mät igen, och ta beslutet på siffror.

Oskalade bilder

Produktbilder som laddas upp i 4 000 pixlar och visas i 300 är det vanligaste frontend-felet. WooCommerce skapar miniatyrer, men bara om temat registrerar bildstorlekar och om temat faktiskt använder dem. Lighthouse listar bilderna under ”Properly size images” och ”Serve images in next-gen formats”. Åtgärden är ett plugin som konverterar till WebP och begränsar uppladdningsstorleken, och därefter WooCommerce, Status, Verktyg, Regenerera miniatyrer.

Databasen: autoload-options, sessioner och transients

Tabellen wp_options läses i sin helhet på varje sidladdning för alla rader med autoload. Plugins som avinstallerats lämnar ofta kvar sina options, och en del lagrar stora värden där. WordPress 6.6 slutade autoladda nya options över 150 KB, men gamla rader påverkas inte. Mät med wp option list --autoload=on --format=total_bytes över SSH. Ligger du över någon megabyte är det värt att gå igenom vad som finns där.

WooCommerce lagrar kundsessioner i en egen tabell, wc_sessions, och städar den var tolfte timme via Action Scheduler. I butiker där WP-Cron inte går som den ska växer tabellen ändå till hundratusentals rader. Under WooCommerce, Status, Verktyg finns knappar för att rensa kundsessioner och utgångna transients. Kör dem och se om tabellen krymper, och kontrollera samtidigt att WP-Cron faktiskt körs.

Cart fragments-skriptet

På varje sidladdning i en klassisk butik gör skriptet wc-cart-fragments ett AJAX-anrop till servern för att hämta minivarukorgens innehåll. Anropet går förbi sidcachen, så varje besökare belastar PHP även på en cachad startsida. I WooCommerce 11.2 registreras skriptet i WC_Frontend_Scripts och köas av varukorgswidgeten, WC_Widget_Cart, när den renderas. Många klassiska teman köar det dessutom själva för sidhuvudets varukorgsikon. Blockteman med Mini-Cart-blocket använder inte skriptet alls; blocket bygger på Interactivity API och hämtar varukorgen via Store API.

Koden nedan gäller den klassiska varukorgen och minivarukorgen i klassiska teman. Den tar bort skriptet på alla sidor utom varukorg och kassa och ligger i child-temats functions.php eller i ett eget litet plugin.

PHP<?php
/**
 * Plugin Name: WPU Cart Fragments Off
 * Description: Removes the wc-cart-fragments script outside cart and checkout. Classic cart widget/mini-cart only; the Mini-Cart block does not use this script.
 * Requires Plugins: woocommerce
 */

defined( 'ABSPATH' ) || exit;

// Priority 20: WooCommerce registers its scripts at 10 on the same hook, and classic themes enqueue the handle at 10 as well.
add_action( 'wp_enqueue_scripts', 'wpu_cart_fragments_off', 20 );
function wpu_cart_fragments_off() {
	if ( ! function_exists( 'is_cart' ) || is_cart() || is_checkout() ) {
		return;
	}

	// Deregister as well, so a late enqueue from the cart widget (which renders after wp_enqueue_scripts) has nothing to print.
	wp_dequeue_script( 'wc-cart-fragments' );
	wp_deregister_script( 'wc-cart-fragments' );
}

Priset är att en minivarukorg i sidhuvudet inte uppdateras av sig själv på en cachad sida. Efter ett AJAX-köp uppdateras den ändå, eftersom svaret från ”lägg i varukorg” innehåller fragmenten. Har du en butik där kunderna lägger i varor och går vidare till kassan direkt märker ingen skillnad. Visar du antal varor i sidhuvudet på alla sidor får du testa i din butik om det stör.

Fallgropar

Det vanligaste misstaget är att installera ett cacheplugin först och mäta sedan. Startsidan blir snabb, kunden är nöjd, och tre veckor senare kommer klagomål på kassan. Mät alltid kassan med något i varukorgen, för det är den sidan som avgör om kunden handlar.

Det näst vanligaste är att byta webbhotell för tidigt. En butik med 40 MB autoload-options och ett plugin som gör 300 databasfrågor per sida blir långsam på vilket webbhotell som helst. Städa först, flytta sedan om siffrorna fortfarande är dåliga.

Två cacheplugin samtidigt, till exempel LiteSpeed Cache från webbhotellet och WP Rocket från en tidigare byrå, ger dubbla regler för vad som inte ska cachas. Det slutar med att en kund ser en annan kunds varukorg. Välj ett.

Vanliga frågor

Räcker det med ett cacheplugin?

För besökare som inte har något i varukorgen gör sidcache störst skillnad av allt. Men kassan, varukorgen och Mitt konto cachas aldrig, och där hjälper bara snabbare PHP, objektcache och färre plugins.

Hur många plugins är för många?

Antalet säger lite. Ett plugin som kör tjugo databasfrågor på varje sida gör mer skada än tio små som bara lägger till ett filter. Mät med Query Monitor i stället för att räkna.

Blir butiken snabbare av HPOS?

Ja i admin och vid orderfrågor, inte på produktsidorna. High-Performance Order Storage lägger ordrar i egna tabeller, vilket märks i butiker med tiotusentals ordrar. Små butiker märker ingen skillnad i frontend.

Kan jag stänga av cart fragments helt?

Ja, om du inte visar någon minivarukorg i sidhuvudet. Visar du antal varor i sidhuvudet och kör sidcache kan antalet visa fel tills kunden lägger något i varukorgen. Mini-Cart-blocket i blockteman berörs inte alls.

Ska jag byta webbhotell?

Först när du mätt. Är svarstiden från servern över en sekund på en okomplicerad sida och webbhotellet varken erbjuder nyare PHP eller Redis är det dags. Annars löser du oftast mer med cache och plugin-städning.

Källor

• Troubleshooting a slow site, WooCommerce-dokumentationen
• WC_Frontend_Scripts registrerar wc-cart-fragments (class-wc-frontend-scripts.php)
• WC_Widget_Cart köar wc-cart-fragments (class-wc-widget-cart.php)
• Options API: disabling autoload for large options, WordPress 6.6
• Systemkrav och rekommenderad PHP-version, WordPress.org
• Supported versions, php.net
• Largest Contentful Paint, web.dev
• WordPress-hosting hos Oderland (LiteSpeed, Memcached, Redis)