WordPress utgör runt 43% av webbens publika sajter och de flesta är onödigt långsamma. Den här guiden går igenom vad som faktiskt påverkar laddtider 2026, vilka riktvärden ni ska kräva av er hostingleverantör, och hur ni mäter att ni faktiskt får det ni betalar för.

Kort svar

Tre saker dominerar WordPress-prestanda 2026:

  1. PHP-version och OPcache — PHP 8.5 är 3–4x snabbare än PHP 7.4. OPcache aktiverad kan halvera CPU-tiden per request.
  2. Cache-stack — Redis object cache + full-page cache (LiteSpeed eller nginx FastCGI) eliminerar 80–95% av PHP- och databasarbete.
  3. Server-latens — En server i Stockholm svarar svenska besökare 30–80 ms snabbare än en server i Frankfurt eller London.

Allt annat (themes, plugins, bildoptimering) spelar också roll men hostingens grundval avgör taket.

Vad är “snabb” 2026?

Google Core Web Vitals och svensk användarförväntning definierar ribban:

  • TTFB (Time To First Byte): <200 ms från svensk besökare
  • LCP (Largest Contentful Paint): <2,5 s
  • INP (Interaction to Next Paint): <200 ms
  • CLS (Cumulative Layout Shift): <0,1

Riktig prestanda mäts från svenska användarens nätverk, inte från ett amerikanskt synthetic test. Använd PageSpeed Insights med Sverige som testpunkt, eller WebPageTest med “Stockholm — Cable” som lokation.

PHP-version och OPcache

PHP 8.5 är runt 3–4x snabbare än PHP 7.4 vid samma WordPress-arbete. WordPress 6.5+ är kompatibelt med PHP 8.5 utan plugin-konflikter.

Riktvärde att kräva av hosting: PHP 8.4 eller 8.5 som standard, OPcache aktiverad med rimliga inställningar:

  • opcache.memory_consumption: 256 MB (eller mer)
  • opcache.max_accelerated_files: 20 000+
  • opcache.validate_timestamps: 1 (eller 0 i ren produktion)
  • opcache.jit: tracing (PHP 8.0+, ger 10–15% extra speed)

Verifiera att OPcache faktiskt är på: skapa en phpinfo.php (ta bort efteråt) och leta efter “OPcache” — det ska stå “Up and Running”.

Cache-stack

Full-page cache är det enskilt största prestandahöjet för WordPress. Mekanismen är enkel: när en besökare hämtar en sida, sparas hela HTML-svaret. Nästa besökare får det direkt från cache i stället för att PHP+MySQL ska generera det igen.

Tre cache-lager som spelar roll

  1. Object cache (Redis eller Memcached) — WordPress hämtar 100–500 databas-rader per sidladdning. Object cache lagrar dem i RAM så samma rader inte hämtas om och om igen. Effekt: 30–60% snabbare även för dynamiska sidor (inloggad, kassa, admin).

  2. Full-page cache (LiteSpeed, nginx FastCGI-cache, eller Cloudflare APO) — Hela HTML-svaret cachas. Besökaren får svar på 30–80 ms i stället för 300–800 ms. Effekt: 5–10x snabbare för icke-inloggade.

  3. Browser/CDN-cache — Statiska resurser (bilder, CSS, JS) cachas på besökarens device och i CDN-noder nära besökaren. Effekt: andra och tredje sidladdning blir nästan instant.

Vad ska ni kräva?

  • Object cache via Redis, aktiverad och kopplad till WordPress via wp-redis eller Object Cache Pro.
  • Full-page cache på server-sidan (LiteSpeed Cache, nginx FastCGI, Varnish). Att enbart ha plugin-cache (WP Super Cache) räcker inte på riktigt snabb hosting.
  • Cache som invalideras automatiskt vid post-uppdatering. Manuell purge är 2010-mentalitet.

MariaDB / MySQL-tuning

WordPress databasen växer snabbt på två tabeller: wp_options och wp_postmeta. Slow queries där är den vanligaste prestandadödaren.

wp_options: Innehåller alla “autoloaded options” som hämtas vid varje sidladdning. Ett vanligt problem är plugins som lägger autoload-options på 1–10 MB. Lösning: kvartalsvis rensning av övergivna autoload-options.

wp_postmeta: Indexerad på post_id och meta_key. Tunga ACF-installationer eller WooCommerce kan ha miljoner rader här. Lösning: composite-index på (post_id, meta_key) och (meta_key, meta_value(20)) vid heavy WP_Meta_Query.

Riktvärde att kräva av hosting:

  • InnoDB buffer pool: 30–40% av server-RAM, eller minst 2 GB för en seriös WP-sajt
  • innodb_io_capacity: 2000+ på SSD
  • tmp_table_size / max_heap_table_size: 64 MB+ (annars spillar tunga queries till disk)
  • slow_query_log: aktiverad med threshold 1–2 sekunder

Latens och datacenter-plats

Latens (RTT, round-trip time) mellan WordPress-server och besökare lägger sig direkt på TTFB. Varje request behöver typiskt 3–5 round trips (TCP, TLS, HTTP/2 streams).

Riktvärden för svenska besökare:

  • Server i Stockholm via STHIX/SONIX: 2–5 ms RTT till svenska konsument-ISP:er
  • Server i Frankfurt: 25–35 ms RTT
  • Server i Dublin (Kinsta default EU): 30–50 ms RTT
  • Server i Helsingborg eller Köpenhamn: 10–15 ms RTT

Skillnaden mellan Stockholm och Frankfurt är ~150–250 ms total page-load om sidan gör 5–10 sekventiella request. Det är skillnaden mellan en “snabb” och “trög” sajt.

För internationell publik kompletteras detta med CDN (Cloudflare, Bunny, KeyCDN). Men för B2B med övervägande svensk publik är server-närhet > CDN-närhet eftersom CDN inte cachar inloggade och dynamiska sidor.

Disk-IO

SSD är standard sedan länge. Men det finns SSD och SSD:

  • NVMe SSD med direkt PCIe-anslutning: 200 000+ IOPS, latens <100 µs. Standard 2026.
  • SATA SSD: 50 000–100 000 IOPS, latens ~500 µs. Acceptabelt för låg-trafik WP.
  • Nätverks-lagring (Ceph, NFS): 5 000–20 000 IOPS, latens 1–5 ms. Vanligt på enterprise/managed och fungerar för de flesta WP-användningar tack vare cache.

Riktvärde att kräva: NVMe SSD lokal eller hög-prestanda nätverkslagring för Business-tier WP. Slow disk-IO märks framförallt på admin-sidan och vid plugin-uppdateringar.

CDN — när behövs det?

CDN hjälper när:

  • Ni har internationell publik (utanför Sverige/Norden)
  • Sajten är bildtung (e-handel, magasin)
  • Ni vill ha DDoS-skydd (Cloudflare/Bunny ingår free DDoS-mitigering)

CDN hjälper inte (eller bara marginellt) när:

  • Allt trafik är svensk och ni redan har server i Stockholm
  • Allt innehåll är dynamiskt (inloggat, personaliserat)
  • Sajten är textbaserad (blogg, B2B-företag)

För svensk B2B-publik på en well-cachad WP-sajt gör CDN sällan mätbar skillnad. För e-handel med globala kunder eller riktigt bildtunga sajter är det däremot självklart.

Verifiera prestanda

Konkret mätning från svensk besökare:

# TTFB från svensk fiber
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}\n" https://er-sajt.se/

# Detta körs upprepat (10+ gånger) för att få varians
for i in {1..10}; do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://er-sajt.se/
done

Bra siffror för icke-cachat:

  • TTFB: <250 ms
  • Total page load: <1,5 s för en typisk WP-sida (text + 5–10 bilder)

Bra siffror för cachat:

  • TTFB: <100 ms
  • Total page load: <800 ms

Om TTFB är >500 ms är det ett tecken på att antingen serverns latens eller PHP/databas-arbete bromsar. Då är det dags att byta hosting eller stack.

Sammanfattning

För snabb WordPress hosting 2026 bör ni kräva:

KomponentRiktvärde
PHP-version8.2 eller 8.3
OPcacheAktiverad, 256 MB+
Object cacheRedis aktiverad
Full-page cacheLiteSpeed eller nginx FastCGI
MariaDB buffer pool2 GB+ eller 30% av RAM
DiskNVMe SSD
DatacenterStockholm (för svensk publik)
TTFB-mål<200 ms cachat, <500 ms icke-cachat

På Adminor managed WordPress hosting är allt detta förinställt och ingår i prislistan. Servrar i Stockholm (Solna och Västberga) ger 2–5 ms latens till svenska konsument-ISP:er via STHIX/SONIX-peering.

Vidare läsning