Metodik för enkla självtester

Denna guide är helt redaktionell och oberoende. Senast granskad av Christian Bolstad, januari 2026.

Sammanvägda prestandabetyg döljer var problemet sitter. Fyra enkla terminalkommandon ger en objektiv bild av hur infrastrukturen presterar — isolerat från frontendkod, tredjepartsskript och webbläsarens renderingsarbete.

1. Isolera TTFB med curl

TTFB (tid till första byte) är det mest rättvisande måttet på infrastrukturens effektivitet. Det mäter tiden från HTTP-förfrågan till att servern börjar leverera data — utan inblandning av webbläsarens rendering.

Kör följande kommando i terminalen:

curl -o /dev/null -s -w 'Connect: %{time_connect}\nTTFB: %{time_starttransfer}\nTotal: %{time_total}\n' https://dinwebbplats.se

Tolkning: Skillnaden mellan time_connect och time_starttransfer visar serverns bearbetningstid. Om den överstiger 200 millisekunder ligger flaskhalsen i CMS-exekveringen (PHP eller .NET) eller databasskiktet — inte i nätverket. Under 100 millisekunder innebär att servern arbetar effektivt.

Baslinje: Testa först mot en statisk HTML-fil på samma server. Det visar infrastrukturens maximala kapacitet. Testa sedan mot den tyngsta landningssidan för att se hur mycket overhead CMS-lagret adderar.

2. Kartlägg tredjepartsanrop

Varje externt skript, typsnitt eller spårningstjänst adderar DNS-uppslagning och TLS-handskakningar. Resurser som hämtas från servrar utanför Norden passerar transatlantiska kablar med oundviklig latens.

Metod: Öppna webbläsarens DevTools (F12), gå till fliken Network och sortera efter kolumnen Remote Address. Identifiera IP-adresser som inte tillhör din hosting eller ett nordiskt nätverk.

Åtgärd: Dokumentera alla resurser från domäner som organisationen inte kontrollerar. Prioritera att flytta kritiska skript (CSS, JavaScript som blockerar rendering) till den egna infrastrukturen. Tredjepartstjänster som chatbotar, rekommendationsmotorer och analysskript bör laddas asynkront eller villkorligt.

3. Analysera nätverksvägen med traceroute

En server som marknadsförs som ”svensk” kan i praktiken nås via omvägar genom Frankfurt eller London. Varje extra nätverkssteg (hop) adderar latens och utgör en potentiell felpunkt.

mtr --report dinwebbplats.se

Tolkning: Granska routingvägen. Om trafiken passerar knutpunkter utanför Norden för att nå en server som ska stå i Sverige lider infrastrukturen av ineffektiv routing. Direktanslutning via svenska knutpunkter som Netnod ger lägst latens för svenska besökare.

4. Verifiera caching via HTTP-headers

Caching avlastar CMS-lagret genom att leverera färdigrenderade svar. Om cachningen inte fungerar genererar servern sidan på nytt vid varje besök — onödig belastning som ökar svarstiden.

curl -sI https://dinwebbplats.se | grep -iE 'cache|x-cache|cf-cache|x-litespeed'

Tolkning: Sök efter headers som indikerar cacheträff:

  • X-Cache: HIT — generisk cacheträff (Varnish, Nginx)
  • x-litespeed-cache: hit — LiteSpeed-serverns inbyggda cache
  • cf-cache-status: HIT — Cloudflare CDN-cache

Om statusen visar MISS vid upprepade anrop till samma URL fungerar inte cachestrategin. Första besöket ger alltid MISS — det är det andra och tredje som räknas. Se cachingguiden för konfiguration.

Systematisk testordning

Utför testerna i denna ordning för att isolera varje lager:

  1. Statisk fil — curl mot en HTML-fil utan CMS. Visar serverns rena kapacitet.
  2. CMS-sida utan cache — rensa cacheminnet, kör curl. Visar CMS-exekveringens overhead.
  3. CMS-sida med cache — kör curl igen. Visar cachelagrets effekt.
  4. Tredjepartsaudit — kartlägg externa anrop via DevTools.
  5. Nätverksväg — traceroute för att verifiera routing.

Differensen mellan steg ett och steg två visar exakt hur mycket tid CMS-lagret kostar. Differensen mellan steg två och steg tre visar cachens effekt. Steg fyra och fem avslöjar om nätverket eller tredjeparter undergräver infrastrukturens kapacitet.

Fördjupning