Fra 40 til 98 PageSpeed: hvordan jeg transformerte en WooCommerce-butikk

Hvert sekund teller i e-handel. For en WooCommerce-butikk som behandler tusenvis av bestillinger per måned, betyr det direkte tapt inntekt. Denne casestudien dokumenterer hvordan jeg hos WPPoland transformerte en slitende europeisk møbel-e-handelsbutikk fra en PageSpeed-poengsum på 40 til 98 - og hva det betydde for bunnlinjen deres.

#Møbelbutikk på WooCommerce i Europa

Kunden min driver en mellomstor nettbutikk for møbler som betjener kunder over Sentral- og Vest-Europa. Med en katalog på over 3500 produkter og 12 000 produktbilder var innsatsen høy. WooCommerce-butikken deres hadde vokst organisk over fem år og akkumulert teknisk gjeld med hver plugininstallasjon, tematilpasning og tredjepartsintegrasjon.

Tidlig i 2026 blødde butikken inntekter. Konkurrenter med raskere nettsider ranket foran dem i søkeresultatene, og mobilbrukere - som utgjorde 64 prosent av trafikken - forlot nettstedet i flokk.

#Hvorfor WooCommerce-butikken var treg

Da jeg først reviderte nettstedet, fant jeg et kjent, men alvorlig mønster av ytelsesdegradering:

• 38 aktive plugins, mange med overlappende funksjonalitet
• Delt hosting uten caching på servernivå
• Uoptimalisert database med over 2,3 millioner utgåtte transients
• 12 000 produktbilder servert som ukomprimerte PNG- og JPEG-filer
• Ingen CDN - alle ressurser servert fra en enkelt opprinnelsesserver i Tyskland
• Render-blokkerende JavaScript fra 14 plugins som lastet på hver side
• 5-trinns kassaprosess med 22 skjemafelt

Resultatet var et nettsted som føltes ødelagt på mobil. Sider tok 8 sekunder å laste, layouten hoppet rundt når elementer rendret, og kassaprosessen var så tungvint at 68 prosent av besøkende forlot nettstedet før de fullførte et kjøp.

#WooCommerce-målinger før optimalisering

#Hvordan gjøre WooCommerce raskere i 7 faser

Jeg følger en systematisk, datadrevet tilnærming til WordPress-hastighetsoptimalisering. Hver fase bygger på den forrige, og jeg måler virkningen av hver endring isolert før jeg går videre til neste.

#Fase 1: Teknisk revisjon (dag 1-3)

Før jeg rørte en eneste kodelinje, brukte jeg tre dager på å profilere hvert aspekt av nettstedet:

• GTmetrix Waterfall-analyse for å identifisere de lengste forespørselskjedene
• WebPageTest multi-lokasjon tester fra Frankfurt, London og Warszawa
• Chrome DevTools Performance Panel for å profilere hovedtrådaktivitet
• Logging av databasespørringer med Query Monitor-pluginen for å finne trege spørringer
• Plugin-profilering for å måle hver plugins innvirkning på lastetiden

Revisjonen avdekket at 73 prosent av lastetiden kunne tilskrives tre faktorer: uoptimaliserte bilder (31 prosent), overdreven JavaScript (26 prosent) og trege databasespørringer (16 prosent).

#Fase 2: Serveroptimalisering (dag 4-7)

Fundamentet for ethvert raskt nettsted er serveren. Jeg migrerte kunden fra delt hosting til en dedikert VPS med følgende stack:

• LiteSpeed Web Server med HTTP/3- og QUIC-støtte
• Redis Object Cache for persistent WordPress object caching
• MariaDB 11.4 med optimalisert my.cnf-konfigurasjon
• PHP 8.3 med OPcache preloading aktivert

LiteSpeed-konfigurasjonen inkluderte spesifikk tuning for WooCommerce:

# LiteSpeed cache-regler for WooCommerce
<IfModule LiteSpeed>
  CacheLookup on
  RewriteRule .* - [E=Cache-Control:no-autoflush]
  RewriteRule ^/cart.* - [E=Cache-Control:no-cache]
  RewriteRule ^/checkout.* - [E=Cache-Control:no-cache]
  RewriteRule ^/my-account.* - [E=Cache-Control:no-cache]
</IfModule>

Redis-konfigurasjonen ble tilpasset for WooCommerce-sesjonshåndtering:

// wp-config.php tillegg for Redis
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_MAXTTL', 86400);
define('WP_REDIS_PREFIX', 'wc_store_');
define('WP_REDIS_SELECTIVE_FLUSH', true);

Virkning etter Fase 2: TTFB sank fra 2,4 sekunder til 180 millisekunder.

#Fase 3: Databaseopprydding (dag 8-11)

Fem års drift hadde etterlatt databasen i kritisk tilstand. Jeg gjennomførte en metodisk opprydding:

1. Fjernet 2,3 millioner utgåtte transients - wp_options-tabellen hadde vokst til 847 MB
2. Optimaliserte 47 trege spørringer identifisert under revisjonsfasen
3. La til manglende indekser på wp_postmeta- og wp_wc_order_stats-tabellene
4. Ryddet foreldreløse post-meta - 340 000 rader med metadata for slettede produkter
5. Konverterte tabeller til InnoDB der MyISAM fortsatt var i bruk

De tilpassede indeksene forbedret produktsøk og filtrering betydelig:

-- Tilpassede indekser for WooCommerce-produktsporringer
ALTER TABLE wp_postmeta ADD INDEX idx_meta_lookup (meta_key, meta_value(32));
ALTER TABLE wp_wc_product_meta_lookup ADD INDEX idx_price_stock (min_price, max_price, stock_status);
ALTER TABLE wp_woocommerce_order_items ADD INDEX idx_order_type (order_id, order_item_type);

Virkning etter Fase 3: Spørretiden i databasen sank med 84 prosent, og wp_options-tabellen krympet fra 847 MB til 12 MB.

#Fase 4: Bildeoptimalisering (dag 12-15)

Med 12 000 produktbilder hadde denne fasen størst individuell innvirkning på sidevekten:

• Konverterte alle bilder til AVIF med WebP-fallback for eldre nettlesere
• Implementerte responsivt srcset med breakpoints på 320, 640, 960, 1280 og 1920 piksler
• La til lazy loading med nativt loading="lazy" for alle bilder under den synlige delen
• Satt eksplisitte dimensjoner på hver <img>-tag for å eliminere CLS fra bildelasting
• Implementerte blur-up-plassholdere med Low Quality Image Placeholders (LQIP)

Bildebehandlingen ble automatisert med to WordPress-filtre og WP-CLI:

// AVIF-utdata for genererte bildestørrelser (WordPress 6.5+)
add_filter('image_editor_output_format', function ($formats) {
    $formats['image/jpeg'] = 'image/avif';
    $formats['image/png'] = 'image/avif';
    return $formats;
});

// AVIF-kvalitet 75, andre formater uendret
add_filter('wp_editor_set_quality', function ($quality, $mime_type) {
    return 'image/avif' === $mime_type ? 75 : $quality;
}, 10, 2);

wp media regenerate --yes

Virkning etter Fase 4: Gjennomsnittlig sidevekt sank fra 6,8 MB til 1,2 MB. LCP ble forbedret fra 5,1 sekunder (etter serveroptimalisering) til 1,4 sekunder.

#Fase 5: JavaScript-revisjon (dag 16-19)

JavaScript-revisjonen var kirurgisk. Jeg kategoriserte hvert skript på nettstedet:

For analyseskriptene implementerte jeg et forsinket lastemønster:

// Utsett ikke-kritiske skript til brukerinteraksjon
const loadDeferredScripts = () => {
  const scripts = document.querySelectorAll('script[data-defer-src]');
  scripts.forEach(script => {
    const newScript = document.createElement('script');
    newScript.src = script.dataset.deferSrc;
    newScript.async = true;
    document.body.appendChild(newScript);
  });
};

['mouseover', 'touchstart', 'scroll', 'keydown'].forEach(event => {
  window.addEventListener(event, loadDeferredScripts, { once: true });
});

Jeg eliminerte også render-blokkerende CSS ved å inline kritiske stiler og utsette det fullstendige stilarket:

<link rel="preload" href="/wp-content/themes/theme/style.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/wp-content/themes/theme/style.css"></noscript>

Virkning etter Fase 5: INP sank fra 680ms til 62ms. Total JavaScript-payload ble redusert med 78 prosent.

#Fase 6: Kassaoptimalisering (dag 20-23)

Et raskt nettsted betyr ingenting hvis kassen dreper konverteringer. Jeg bygde om hele kassaflyten:

• Reduserte fra 5 trinn til 2 (frakt + betaling på en side, bekreftelse på neste)
• Fjernet 14 unødvendige skjemafelt (firmanavn, telefon 2, faks osv.)
• La til ekspressbetaling (Apple Pay, Google Pay, Klarna)
• Implementerte adresseautofullføring med Google Places API
• La til sanntidsskjemavalidering for å forhindre feil ved innsending

// Fjern unødvendige WooCommerce-kassafelt
add_filter('woocommerce_checkout_fields', function ($fields) {
    unset($fields['billing']['billing_company']);
    unset($fields['billing']['billing_phone_2']);
    unset($fields['billing']['billing_fax']);
    unset($fields['order']['order_comments']);
    return $fields;
});

// Legg til støtte for ekspressbetalingsgateway
add_action('woocommerce_review_order_before_payment', function () {
    if (class_exists('WC_Payment_Gateway')) {
        echo '<div id="express-checkout-buttons" class="express-payment-wrapper">';
        do_action('woocommerce_express_checkout_buttons');
        echo '</div>';
    }
});

Virkning etter Fase 6: Handlekurvavbruddsraten sank med 34 prosent. Gjennomsnittlig kassatid ble redusert fra 4 minutter 12 sekunder til 1 minutt 38 sekunder.

#Fase 7: CDN og edge caching (dag 24-28)

Det siste optimaliseringslaget sikret at ytelsesforbedringene var konsistente på tvers av alle europeiske markeder:

• Cloudflare Pro med tilpassede sideregler for WooCommerce
• Edge caching for statiske produktsider med 4-timers TTL
• Nettleserbufferheadere med cache-busting via innholdshashing
• Brotli-kompresjon aktivert på edge for alle tekstbaserte ressurser
• Early Hints (103) for kritiske ressurser

# Cloudflare-sideregler
URL: *example.com/product/*
Cache Level: Cache Everything
Edge Cache TTL: 4 hours
Browser Cache TTL: 1 hour

URL: *example.com/cart*
Cache Level: Bypass

URL: *example.com/checkout*
Cache Level: Bypass

Virkning etter Fase 7: Global TTFB sank til under 100 millisekunder. Brukere i Vest-Europa opplevde fullstendige sidelastetider under 800ms.

#WooCommerce PageSpeed før og etter

Etter fire uker med systematisk optimalisering var transformasjonen dramatisk:

#Hvordan lese Core Web Vitals for en WooCommerce-butikk

Vurderingskolonnen i tabellene over følger tersklene Google publiserer på web.dev. En god Largest Contentful Paint skjer innen 2,5 sekunder etter at siden begynner å laste, en god Interaction to Next Paint er 200 millisekunder eller mindre, og en god Cumulative Layout Shift er 0,1 eller mindre. Google vurderer hver måling ved 75. persentil av sidevisningene, delt i mobil og datamaskin, så en side består bare når tre av fire besøk når terskelen.

PageSpeed-poengsummene 40 og 98 er en annen type tall. De er laboratoriemålinger fra en simulert lasting, nyttige for å sammenligne én versjon av nettstedet med den neste i et prosjekt som dette. Den samme veiledningen på web.dev sier at laboratoriemåling ikke erstatter feltmåling, fordi Core Web Vitals er feltmålinger samlet inn fra ekte besøkende. Etter en lansering er det feltdataene i PageSpeed Insights og Core Web Vitals-rapporten i Search Console som teller, noen uker senere, når nok ekte besøk er registrert.

#Hvordan hastighet påvirker konvertering i nettbutikk

Tekniske metrikker er tilfredsstillende, men forretningsmetrikker rettferdiggjør investeringen:

• Konverteringsraten ble omtrent doblet
• Mobilinntektene økte - mobilbrukere kunne endelig handle uten frustrasjon
• Fluktraten ble omtrent halvert - besøkende ble og bla i stedet for å forlate
• Prosjektet betalte for seg selv på uker, ikke kvartaler
• Gjennomsnittlig bestillingsverdi økte - raskere produktsurfing førte til flere varer i handlekurven
• Organisk trafikk vokste - forbedrede Core Web Vitals bidro til bedre søkerangeringer innen 8 uker

#Lærdommer fra WooCommerce-optimalisering

Hvert optimaliseringsprosjekt lærer meg noe nytt. Her er de viktigste lærdommene fra dette oppdraget:

#1. Hvor mye påvirker hosting hastigheten i WooCommerce

Ingen mengde frontend-optimalisering kan kompensere for en treg server. Migreringen fra delt hosting til en optimalisert LiteSpeed VPS sto for 35 prosent av den totale ytelsesforbedringen.

#2. Hvorfor rydde WooCommerce-databasen jevnlig

WooCommerce-butikker genererer enorme mengder transientdata. Uten regelmessig opprydding blir wp_options-tabellen en flaskehals som påvirker hver eneste sidelasting. Automatisert ukentlig opprydding bør være standard for enhver WooCommerce-butikk.

#3. Hvordan plugins gjør WooCommerce-butikken treg

Av de 38 installerte pluginene var 14 enten ubrukte, overflødige eller erstattbare med lette kodebiter. Hver plugin legger til databasespørringer, JavaScript og CSS - selv når funksjonaliteten ikke er nødvendig på gjeldende side.

#4. Hvor mye AVIF-bilder reduserer sidevekten

Konvertering til AVIF og implementering av responsive bilder reduserte sidevekten med over 80 prosent. Denne enkeltendringen, som i stor grad kan automatiseres, gir den mest synlige forbedringen for sluttbrukere.

#5. Hvordan kassa-UX påvirker inntektene

Kassa-redesignet, selv om det ikke er en tradisjonell “ytelses”-optimalisering, hadde den mest direkte innvirkningen på inntektene. Å redusere friksjon i kjøpsprosessen er like verdifullt som å redusere lastetider.

#6. Hvordan måle effekten av hver optimalisering

Ved å implementere endringer i faser og måle etter hver enkelt, kunne jeg kvantifisere den nøyaktige virkningen av hver optimalisering. Denne datadrevne tilnærmingen forhindrer bortkastet innsats og bygger en klar fortelling for interessenter.

#Hvor lang tid tar WooCommerce-optimalisering

#Hvordan bruke disse metodene i WordPress og WooCommerce i 2026

Tre av metodene over bygger på funksjoner i WordPress, WooCommerce og Cloudflare som har endret seg siden mange veiledninger ble skrevet. Slik fungerer hver av dem ifølge leverandørenes egen dokumentasjon.

#Hvordan lage AVIF-bilder i WordPress

WordPress støtter AVIF fra versjon 6.5, slik det ble kunngjort på Make WordPress Core. Støtten avhenger av bildebiblioteket på serveren: WordPress fungerer med både Imagick og GD, og delen om mediehåndtering i informasjonen om nettstedets helse viser om AVIF er tilgjengelig. For å gjøre opplastede JPEG-filer om til AVIF dokumenterer kjerneteamet filteret image_editor_output_format. Filteret wp_editor_set_quality setter komprimeringen mellom 1 og 100 for en gitt MIME-type. Ifølge kunngjøringen er AVIF tapsbasert med kvalitet 82 som standard, og kvalitet 100 slår over til tapsfri modus.

wp media regenerate har ingen valg for format eller kvalitet. Valgene er vedleggs-ID-er, --image_size, --skip-delete, --only-missing, --delete-unknown, --update-attachment-refs (bare i nightly-bygg) og --yes (WP-CLI-dokumentasjon). Filtrene bestemmer format og kvalitet, og kommandoen lager bildestørrelsene på nytt. Derfor bruker eksempelet i fase 4 begge deler.

#Hvordan slette utløpte transients i WooCommerce

WP-CLI sletter utløpte transients med wp transient delete --expired, og wp transient delete --all fjerner alle (WP-CLI-dokumentasjon). Med en vedvarende objektbuffer som Redis kan transients ligge i bufferen i stedet for i tabellen wp_options, og håndboken for Transients API advarer om at kode aldri skal anta at en transient ligger i databasen. Kjernefunksjonen delete_expired_transients(), innført i WordPress 4.9, gjør ingenting når en ekstern objektbuffer er i bruk. Utløpte rader som ble skrevet før objektbufferen ble slått på, blir derfor liggende i tabellen til noe sletter dem direkte fra databasen. Det var dette fase 3 gjorde.

#Hvilke WooCommerce-sider og informasjonskapsler som skal holdes utenfor hurtigbufferen

Utviklerdokumentasjonen for WooCommerce sier at handlekurven, kundekontoen og kassen skal holdes utenfor sidebufferen, fordi disse sidene viser informasjon om den aktuelle kunden og handlekurven. Den lister også informasjonskapsler en buffer kan settes til å hoppe over: woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed og store_notice[notice id]. LiteSpeed-reglene i fase 2 holder alle tre sidene utenfor, og Cloudflare-eksempelet i fase 7 viser handlekurven og kassen.

Cloudflare erstatter Page Rules med en rekke egne Rules-produkter og migrerer eksisterende Page Rules automatisk (migreringsveiledning). Et nytt oppsett uttrykker den samme logikken med Cache Rules: å sette bufferkvalifisering til kvalifisert for buffer erstatter Cache Everything, innstillingene Edge TTL og Browser TTL tar TTL-verdiene, og en regel som treffer en informasjonskapsel og setter bufferkvalifisering til bypass holder besøkende med en aktiv handlekurvøkt utenfor den delte bufferen.

#Gratis ytelsesrevisjon for WooCommerce

Hvis butikken din scorer under 70 på PageSpeed Insights, mister du kunder hver eneste dag. Min WooCommerce-optimaliseringstjeneste følger den samme velprøvde metodikken beskrevet i denne casestudien, tilpasset din spesifikke butikk og infrastruktur.

Jeg tilbyr en gratis innledende ytelsesrevisjon - en detaljert rapport som viser nøyaktig hvor butikken din mister hastighet og hvor mye inntekt det koster deg. Ingen forpliktelser, ingen salgsargumenter, bare data.

Kontakt WPPoland for å planlegge din revisjon, eller les mer om mine tjenester for WordPress-hastighetsoptimalisering.

#Relaterte ressurser

• Oppnå 100/100 Core Web Vitals for WordPress i 2026
• WooCommerce-ytelsesoptimalisering
• WordPress-hastighetsoptimalisering