Webb & prestanda

Tre enkla sätt att snabba upp din webbplats prestanda

av Mattias Pettersson

En sekunds förbättring av laddningstiden ökar konverteringsgraden med 7%. Det är Amazons siffra, men riktningen stämmer för alla.

Google väger Page Experience — Core Web Vitals — i sin ranking. En långsam webbplats rankar sämre. Den konverterar sämre. Den stänger av mobilanvändare (som är majoritet på de flesta sajter) ännu snabbare.

Det finns femtio saker du kan göra för att förbättra prestanda. Här är de tre som ger störst effekt snabbast.

1 — Optimera bilderna

Bilder är den vanligaste orsaken till dålig webbplatsprestanda. Och det är det enklaste att åtgärda.

Varför bilder är problemet:

En typisk JPEG från en modern kamera är 3–8 MB. En typisk JPEG på en webbsida borde vara 50–200 KB. Om din webbsida laddar 2 MB bilder istället för 200 KB — det är 10x längre laddningstid bara för bilderna.

De tre åtgärderna:

Konvertera till WebP

WebP är Googles bildformat, stöds av alla moderna webbläsare, och är i genomsnitt 25–35% mindre än JPEG med samma visuella kvalitet.

Enklast: använd ett verktyg som Squoosh.app (gratis, webbläsarbaserat) för att konvertera enstaka bilder.

I större skala: automatisera konverteringen i er build-pipeline. Med ImageMagick:

# Konvertera JPEG till WebP
convert input.jpg -quality 80 output.webp

# Batch-konvertera alla JPEGs i en mapp
for f in *.jpg; do convert "$f" -quality 80 "${f%.jpg}.webp"; done

Servera WebP till webbläsare som stöder det, JPEG som fallback, via <picture>-elementet:

<picture>
  <source srcset="/assets/img/bild.webp" type="image/webp">
  <img src="/assets/img/bild.jpg" alt="Beskrivning" loading="lazy" decoding="async">
</picture>

Korrekt storlek

En bild som visas i 400 px bredd behöver inte vara 2 000 px bred. Korrekt dimensionerade bilder — "responsive images" — levererar rätt upplösning till rätt enhet.

<img
  src="/assets/img/bild-800.webp"
  srcset="/assets/img/bild-400.webp 400w, /assets/img/bild-800.webp 800w, /assets/img/bild-1200.webp 1200w"
  sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
  alt="Beskrivning"
  loading="lazy"
  decoding="async"
  width="800"
  height="450"
>

Lazy loading

Bilder utanför skärmens synfält behöver inte laddas vid sidöppning. loading="lazy" är ett standardattribut som alla moderna webbläsare stöder och som gör att bilder laddas när användaren scrollar mot dem.

<img src="bild.webp" alt="..." loading="lazy" decoding="async">

Undantag: Den primära hero-bilden — den som syns direkt vid sidladdning — ska inte ha loading="lazy". Lägg till fetchpriority="high" istället.

Förväntad förbättring: 40–70% reduktion av initial sidladdning för bildtunga webbplatser.

2 — Aktivera caching och komprimering

En webbserver kan leverera tillgångar snabbare på två sätt: komprimera dem och cachelagra dem. Båda är enkla att aktivera.

Gzip och Brotli-komprimering

Textbaserade tillgångar (HTML, CSS, JavaScript) är mycket komprimerbara. Aktivering av Brotli (modernare) eller Gzip (bredare stöd) reducerar storleken med 60–80%.

Apache (.htaccess):

# Brotli (om modulen är installerad)
<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript text/javascript application/json text/xml
</IfModule>

# Gzip (fallback)
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/css application/javascript application/json text/xml application/xml
</IfModule>

Nginx:

gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml;

brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml;

HTTP-caching

Statiska tillgångar — CSS, JavaScript, bilder, fonter — förändras inte ofta. Sätt cache-headers som berättar för webbläsaren hur länge den kan cachelagra tillgångarna lokalt.

Apache (.htaccess):

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/webp              "access plus 1 year"
    ExpiresByType image/jpeg              "access plus 1 year"
    ExpiresByType image/png               "access plus 1 year"
    ExpiresByType text/css                "access plus 1 month"
    ExpiresByType application/javascript  "access plus 1 month"
    ExpiresByType font/woff2              "access plus 1 year"
</IfModule>

Viktigt: Använd cache-busting för CSS och JavaScript — lägg till en versionssträng i filnamnet eller query string när filen ändras. Annars kan gamla versioner ligga kvar för länge hos användaren.

<!-- Med versionssträng -->
<link rel="stylesheet" href="/assets/css/style.min.css?v=20250218">

Förväntad förbättring: 60–80% reduktion i transferstorlek för textbaserade tillgångar. Återbesök laddar snabbare eftersom tillgångarna är cached.

3 — Eliminera render-blockerande resurser

Webbläsaren renderar sidan uppifrån och ner. Om den stöter på ett externt CSS- eller JavaScript-fil — stannar den och laddar den filen innan den fortsätter. Det är vad "render-blocking" betyder.

Typiska render-blockerande resurser:

  • <link rel="stylesheet"> i <head> som pekar på externa CSS-filer
  • <script src="..."> utan defer eller async

CSS — kritisk CSS inline

Den enklaste lösningen: extrahera den CSS som behövs för "above the fold" (det synliga vid sidladdning) och lägg den inline i <head>. Resten laddar du asynkront.

<head>
  <!-- Kritisk CSS inline -->
  <style>
    /* Minimal CSS för ovanför mitten — navigation, hero */
    body { margin: 0; font-family: sans-serif; background: #1c1c1c; }
    nav { display: flex; /* ... */ }
    .hero { padding: 4rem 0; /* ... */ }
  </style>

  <!-- Resten av CSS laddas icke-blockerande -->
  <link rel="preload" href="/assets/css/style.min.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/assets/css/style.min.css"></noscript>
</head>

JavaScript — defer och async

defer: laddar scriptet parallellt men kör det efter att DOM är parsad. Bäst för de flesta scripts.

async: laddar och kör scriptet parallellt med parsing. Bäst för oberoende scripts (analytics, etc.).

<!-- Blockerande (undvik) -->
<script src="/assets/js/main.js"></script>

<!-- Icke-blockerande (använd detta) -->
<script src="/assets/js/main.js" defer></script>

<!-- För analytics och oberoende scripts -->
<script src="https://analytics.example.com/script.js" async></script>

Fonter — undvik FOUT

Self-hostade fonter (WOFF2) laddar snabbare än Google Fonts. Preconnect till externa fontservrar om du måste använda dem.

<head>
  <!-- Preconnect till Google Fonts -->
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

  <!-- Eller ännu bättre: self-hosta fontfiler och deklarera dem med font-display: swap -->
  <style>
    @font-face {
      font-family: 'Montserrat';
      src: url('/assets/fonts/montserrat-700.woff2') format('woff2');
      font-weight: 700;
      font-style: normal;
      font-display: swap;
    }
  </style>
</head>

Förväntad förbättring: 0,5–2 sekunder snabbare LCP (Largest Contentful Paint) — ett av Googles viktigaste Core Web Vitals-mått.

Mät resultatet

Innan och efter: kör Google PageSpeed Insights (pagespeed.web.dev) och WebPageTest (webpagetest.org).

Fokusera på:

  • LCP (Largest Contentful Paint) — bör vara under 2,5 sekunder
  • CLS (Cumulative Layout Shift) — bör vara under 0,1
  • INP (Interaction to Next Paint) — bör vara under 200 ms
  • Time to First Byte (TTFB) — bör vara under 800 ms

PageSpeed Insights ger dig ett konkret betyg (0–100) och listar specifika förbättringsmöjligheter med estimerad effekt.

Bonus: vad du inte behöver göra (ännu)

Det finns saker som är tekniskt intressanta men som de flesta webbplatser inte behöver börja med:

  • CDN — värdefullt för globala sajter, onödigt för en B2B-sajt med 95% svenska besökare
  • HTTP/3 — LiteSpeed och nginx har stöd, men skillnaden är marginal för de flesta
  • Service Workers och PWA — ökar komplexiteten avsevärt

Börja med de tre åtgärderna ovan. De ger 80% av prestandaförbättringen med 20% av arbetet.

Behöver du hjälp med en prestandaanalys av din webbplats eller vill ha en sajt som är Lighthouse 100 från start? Kontakta oss.

Tillbaka till bloggen Prata med oss

Relaterad tjänst

Behöver du hjälp med webbutveckling?

Webbutveckling