Prestanda och hastighet — ordlista

Apache HTTP Server är en av de äldsta och mest spridda webbservrarna i världen — släppt 1995 och har drivit en majoritet av internet under största delen av 2000-talet. Dess största styrka är .htaccess-systemet som låter dig konfigurera webbserverbeteende per mapp utan att ändra huvudkonfiguration. Det gjorde Apache perfekt för delat webbhotell där varje kund behöver egen konfiguration.

Apache har dock tappat mark till Nginx och LiteSpeed de senaste åren, särskilt på servrar med hög trafik. Apaches process-per-request-modell kräver mer minne och CPU än Nginx events-baserade arkitektur. LiteSpeed är Apache-kompatibel men upp till 50 procent snabbare för WordPress tack vare sin cachemotor.

I Sverige 2026 används Apache fortfarande hos många traditionella webbhotell (Loopia, Miss Hosting, Wopsa), men premium-leverantörer som Inleed och HostUp har bytt till LiteSpeed. För egen VPS är Nginx + PHP-FPM den mest använda kombinationen. Apache är fortfarande ett bra val för enklare delade hostingmiljöer där .htaccess-flexibiliteten uppskattas.

Bandbredd mäter datamängden som överförs mellan server och besökare. Enheten är vanligen gigabyte per månad (GB/mån) eller terabyte per månad (TB/mån). En typisk företagssajt med 10 000 besökare per månad förbrukar cirka 10–50 GB bandbredd; en webbutik med mycket bilder eller video kan förbruka 200+ GB.

Många webbhotell marknadsför "obegränsad bandbredd" men har i praktiken en fair-use-klausul som sätter gränsen någonstans — ofta runt 500 GB/månad för grundplaner. Om din sajt plötsligt får viral trafik eller drabbas av DDoS-attacker kan obegränsad bandbredd visa sig vara mer begränsad än du trodde. Läs alltid det finstilta.

För större behov (streaming-tjänster, nedladdningsajter, video-baserade kurser) blir bandbredden en reell kostnad. Svenska VPS-leverantörer inkluderar typiskt 500–2 000 GB bandbredd per månad; internationella leverantörer som DigitalOcean inkluderar 1–2 TB per plan. För enkla WordPress-sajter räcker dock standardplanernas bandbredd gott.

Brotli är en komprimeringsalgoritm som utvecklades av Google och som nu stöds av alla moderna webbläsare. När servern skickar HTML, CSS och JavaScript komprimeras filerna först — Brotli når typiskt 15–25 procent mindre filstorlek än den äldre gzip-standarden, särskilt för textbaserat innehåll.

Mindre filer betyder färre byte att överföra och därmed snabbare laddning, vilket direkt påverkar Core Web Vitals-måttet LCP. Effekten är störst för besökare på långsammare mobiluppkopplingar. Servern förhandlar automatiskt med webbläsaren om vilken komprimering som ska användas via HTTP-headern Accept-Encoding.

De flesta moderna webbservrar (LiteSpeed, nginx, Apache) och CDN-tjänster stöder Brotli. På LiteSpeed-baserade webbhotell är det ofta aktiverat som standard, medan du på vissa miljöer kan behöva slå på det i konfigurationen.

Caching innebär att du sparar resultaten av tidsintensiva operationer så att de kan återanvändas nästa gång. På en webbserver cachelagras ofta: (1) databas-queries (via Redis eller Memcached), (2) färdiga HTML-sidor (via page cache som LiteSpeed Cache eller WP Rocket), (3) statiska tillgångar som bilder, CSS och JS (via browser cache och CDN).

För WordPress är page cache den enskilt största prestanda-vinsten du kan göra. Utan cache genererar WordPress varje sida från grunden vid varje besök — PHP körs, databas-queries läser data, HTML byggs. Med page cache sparas den färdiga HTML-sidan och levereras direkt på millisekunder.

Moderna svenska webbhotell har caching inbyggt. Inleed och HostUp använder LiteSpeed-webbservern med LiteSpeed Cache som är branschledande för WordPress-prestanda. Kinsta har egen custom cache-lösning. På VPS konfigurerar du cache själv — Varnish eller Nginx FastCGI cache är populära val.

Core Web Vitals är Googles uppsättning av tre mätbara prestandamått som direkt påverkar hur högt din sajt rankar i sökresultaten. LCP (Largest Contentful Paint) mäter när huvudinnehållet syns — bra under 2,5 sekunder. INP (Interaction to Next Paint) mäter hur snabbt sidan svarar på klick och knapptryck — bra under 200 millisekunder. CLS (Cumulative Layout Shift) mäter visuell stabilitet — bra under 0,1.

CWV är inte bara en ranking-faktor utan också en konverteringsdrivare. Studier från bland annat Google visar att sajter som möter alla tre trösklar har betydligt bättre bounce rate och säljkonvertering. En webshop som förbättrar LCP från 4 till 2 sekunder ser typiskt 10-20 procents ökning i konvertering. För SEO är det nästan obligatoriskt 2026 att passera alla tre trösklar.

För svenska webbhotellskunder är CWV starkt kopplat till val av host och CMS. Svenska datacenter ger lägst latens (bra LCP), LiteSpeed-baserade webbhotell ger bättre caching (bra LCP och INP), och moderna CMS som Next.js eller optimerad WordPress med LiteSpeed Cache ger lågt CLS. Mät din egen sajts CWV via PageSpeed Insights (PSI) eller Google Search Console Core Web Vitals-rapport.

HTTP/2 standardiserades 2015 och löste flera flaskhalsar i den gamla HTTP/1.1. Den viktigaste nyheten är multiplexering: i stället för att öppna många parallella anslutningar och skicka en fil i taget kan servern skicka flera resurser samtidigt över en enda TCP-anslutning, vilket kraftigt minskar laddningstiden på sidor med många filer.

Andra förbättringar är header-komprimering (HPACK), binär överföring i stället för text, och server push som låter servern skicka resurser innan webbläsaren hunnit be om dem. Sammantaget ger detta snabbare sidladdning, särskilt märkbart på mobila uppkopplingar med hög latens.

HTTP/2 stöds av alla moderna webbläsare och de flesta webbhotell aktiverar det automatiskt så länge sajten körs över HTTPS. Efterföljaren HTTP/3 bygger vidare på samma idéer men över det snabbare QUIC-protokollet.

HTTP/3 är den tredje stora versionen av HTTP-protokollet och släpptes som standard 2022. Till skillnad från HTTP/1.1 och HTTP/2 som körs över TCP, använder HTTP/3 QUIC över UDP. Det löser flera prestandabegränsningar i TCP, särskilt vid paketförlust — en situation som är mycket vanligare på mobila nätverk.

Praktisk effekt: HTTP/3 ger typiskt 10-30 procent snabbare sidladdning på instabila anslutningar. Bästa effekten märks på mobila enheter där signalstyrkan varierar. För stabila fiberanslutningar märks skillnaden mindre. HTTP/3 stöds av alla moderna webbläsare (Chrome, Firefox, Safari, Edge) och CDN-leverantörer som Cloudflare, Fastly och Akamai.

För svenska webbhotellskunder är HTTP/3 typiskt inte något du aktiverar själv — det är din CDN eller webbserver som hanterar protokoll-valet. Om du använder Cloudflare som reverse proxy får du HTTP/3 automatiskt. LiteSpeed och Nginx (senaste versionerna) stöder HTTP/3 men kräver ofta kompileringsflaggor. Inga svenska webbhotell har ännu HTTP/3 aktiverat som standard 2026 — men det kommer inom ett par år.

INP mäter responsiviteten under hela besöket genom att titta på fördröjningen mellan att användaren interagerar (klick, tryck, tangenttryck) och att sidan hinner rita om något som svar. Måttet ersatte First Input Delay (FID) som Core Web Vitals i mars 2024 eftersom det ger en mer heltäckande bild av upplevd responsivitet.

Ett bra INP-värde är under 200 millisekunder, medan över 500 ms räknas som dåligt. Vanliga orsaker till hög INP är tungt JavaScript som blockerar huvudtråden, ineffektiva event-lyssnare och stora DOM-träd. Google använder Core Web Vitals som rankningssignal, så INP påverkar både användarupplevelse och SEO.

För att förbättra INP delar man upp långa JavaScript-uppgifter, minskar mängden kod som körs vid interaktion och avlastar arbete till bakgrundstrådar. Snabb hosting hjälper indirekt genom att sidan levereras och blir interaktiv tidigare.

En lastbalanserare sitter framför flera servrar och fördelar inkommande förfrågningar mellan dem. Om du har 3 kopior av din webbapplikation skickar lastbalanseraren förfrågan till den som är minst belastad, har snabbast svarstid, eller enligt en round-robin-regel. Om en server kraschar märker lastbalanseraren detta och skickar all trafik till de överlevande.

Populära lastbalanserare: Nginx (open source, enkel setup), HAProxy (äldre, mycket snabb, fortfarande standard för TCP-lastbalansering), AWS ELB/ALB (managed), Cloudflare Load Balancer (DNS-baserat, global). På Linux-VPS används Nginx ofta som både lastbalanserare och reverse proxy i samma instans.

För svenska småföretag blir lastbalansering relevant när (a) en enskild server inte klarar trafiken, (b) du behöver zero-downtime-deploys där nya versioner rullas ut sekventiellt, (c) du har krav på hög tillgänglighet med minst 99,99 procent uptime. För de flesta standard-webbplatser räcker en enda välkonfigurerad server med CDN — lastbalanserare introducerar komplexitet som ska tjänas in.

LCP (Largest Contentful Paint) är Googles mått på hur snabbt huvudinnehållet dyker upp på sidan. Det mäter tiden från att sidan börjar laddas till att det största synliga elementet (oftast en hero-bild eller rubrik) är färdigrenderat. Under 2,5 sekunder anses bra, 2,5-4 sekunder behöver förbättring, över 4 sekunder dåligt.

LCP påverkas av många faktorer: serverns svarstid (TTFB), nätverksanslutning, bildoptimering, renderblocking CSS och JavaScript, och huruvida kritisk CSS är inline. För svenska webbhotellskunder är server-geografi en stor faktor — en sajt hostad i Sverige har typiskt 3-5 gånger bättre LCP för svenska besökare än en i Litauen eller Tyskland.

Konkreta åtgärder för bättre LCP: (1) välj svenskt datacenter för svensk målgrupp, (2) använd LiteSpeed eller Nginx med caching aktiverat, (3) optimera hero-bilder (WebP/AVIF, rätt storlek, modern Next.js Image-komponent), (4) preload kritiska resurser, (5) använd CDN (Cloudflare, Bunny). Mät din LCP i PageSpeed Insights eller Google Search Console Core Web Vitals-rapport.

NVMe SSD är nuvarande generations snabbaste lagringsteknik för servrar. NVMe (Non-Volatile Memory Express) är ett kommunikationsprotokoll designat specifikt för flashminne, medan äldre SSD använde SATA-protokollet som var begränsat av designval gjorda för mekaniska hårddiskar.

Praktiska effekten: NVMe SSD är typiskt 5-10 gånger snabbare än SATA SSD för slumpmässiga läsningar, vilket är den viktigaste operationen för databaser och WordPress. En databas-query som tar 50 ms på SATA SSD kan ta 5 ms på NVMe. Användarupplevelsen blir märkbart snappy.

2026 är NVMe SSD standard hos alla seriösa svenska webbhotell och VPS-leverantörer. Inleed, HostUp, GleSYS, Loopia — alla har NVMe på alla planer. Om du stöter på en leverantör som fortfarande marknadsför "SSD" utan att specificera NVMe, anta att det är äldre SATA-teknik och jämför prestanda innan du väljer.

Object storage lagrar varje fil som ett objekt tillsammans med metadata och en unik identifierare, i stället för i mappar och filträd som traditionella filsystem. Objekten samlas i så kallade buckets och nås via ett API — oftast S3-kompatibelt, den de facto-standard som Amazon S3 etablerat.

Modellen är byggd för att skala horisontellt: du kan lagra allt från gigabyte till petabyte utan att strukturen blir en flaskhals, och du betalar typiskt per lagrad mängd och trafik. Det gör object storage idealiskt för mediaarkiv, backuper, statiska webbtillgångar och som lagringslager bakom CDN.

Exempel på tjänster är Backblaze B2, Amazon S3 och Cloudflare R2. För enklare fillagring och backup i Sverige räcker ofta traditionell NVMe-baserad lagring med FTP/SFTP, som Inleeds molnlagring, medan object storage passar utvecklare som behöver programmatisk åtkomst och massiv skala.

PHP-FPM (FastCGI Process Manager) är det moderna sättet att köra PHP på en webbserver. I stället för att starta en ny PHP-process för varje förfrågan håller PHP-FPM en pool av färdiga arbetsprocesser redo, vilket minskar overhead och ger betydligt bättre prestanda under belastning.

Lösningen frikopplar PHP från webbservern, så att nginx eller LiteSpeed kan skicka PHP-förfrågningar till PHP-FPM medan statiska filer levereras direkt. Poolen kan finjusteras med inställningar för antal processer och minne, vilket gör att en server kan hantera fler samtidiga besökare utan att köra slut på resurser.

På moderna svenska webbhotell är PHP-FPM standard, ofta i kombination med OPcache och en LiteSpeed- eller nginx-server. För WordPress- och WooCommerce-sajter är rätt konfigurerad PHP-FPM en av de viktigaste faktorerna för snabb serverrespons.

RAID (Redundant Array of Independent Disks) slår ihop flera fysiska diskar så att de framstår som en enda logisk enhet. Beroende på RAID-nivå prioriteras redundans, prestanda eller en kombination. RAID 1 speglar data identiskt över två diskar, så att en disk kan gå sönder utan att data förloras. RAID 10 kombinerar spegling och striping för både säkerhet och hastighet.

Poängen är att en enskild disk alltid kan haverera — med RAID fortsätter systemet fungera medan den trasiga disken byts ut, ofta utan avbrott (hot swap). Det är därför seriösa webbhotell och lagringstjänster kör RAID i botten och beskriver det som "speglad" eller "redundant" lagring.

Viktigt att förstå: RAID är redundans, inte backup. Det skyddar mot hårdvarufel men inte mot att en fil raderas av misstag, drabbas av ransomware eller skrivs över — det kopieras då direkt till spegeldisken. Kombinera därför alltid RAID med riktig backup enligt 3-2-1-regeln.

En reverse proxy sitter framför en eller flera webbservrar och tar emot all inkommande trafik. Besökaren pratar bara med proxyn, som i sin tur avgör vilken bakomliggande server som ska svara. Till skillnad från en vanlig (forward) proxy som representerar klienten, representerar en reverse proxy servrarna.

Användningsområdena är många: lastbalansering mellan flera servrar, caching av innehåll för snabbare svar, SSL-terminering (kryptering hanteras på proxyn), komprimering och som ett skyddande lager mot attacker eftersom de riktiga servrarnas adresser döljs. Nginx, HAProxy och Cloudflare är vanliga exempel.

För en typisk sajt körs reverse proxy ofta osynligt hos webbhotellet eller via ett CDN. Effekten märks som snabbare laddning, bättre motståndskraft mot trafiktoppar och ett extra säkerhetslager framför applikationen.

TTFB mäter fördröjningen mellan att en förfrågan skickas och att den allra första byten av svaret tas emot. Måttet fångar summan av flera steg: DNS-uppslag, upprättande av anslutning, tid för servern att bearbeta förfrågan och nätverkslatens tillbaka. Ett lågt TTFB innebär att servern och infrastrukturen svarar snabbt.

Riktvärdet är under cirka 200 millisekunder för en bra upplevelse. Hög TTFB beror ofta på långsam serverbearbetning — otillräcklig hosting, ocachad PHP-kod, tunga databasfrågor eller långt avstånd till servern. Eftersom TTFB inträffar innan något ritas ut påverkar det direkt Core Web Vitals-måttet LCP.

Förbättras med snabbare hosting (LiteSpeed, PHP-FPM, NVMe), server-side caching, en databas nära applikationen och ett CDN som kortar avståndet till besökaren. För svenska besökare hjälper en server i Sverige eller Norden.