# Installér
npm install --save-dev webpack-bundle-analyzer

# Tilføj til din webpack.config.js
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  plugins: [
    new BundleAnalyzerPlugin()
  ]
};

# Installér
npm install --save-dev vite-bundle-analyzer

# Tilføj til din vite.config.js
import { analyzer } from 'vite-bundle-analyzer';

export default {
  plugins: [
    analyzer()
  ]
};

import { lazy, Suspense } from 'react';
import { BrowserRouter, Routes, Route } from 'react-router-dom';

// Lazy-load hver side
const Forside = lazy(() => import('./pages/Forside'));
const Produkter = lazy(() => import('./pages/Produkter'));
const OmOs = lazy(() => import('./pages/OmOs'));
const Kontakt = lazy(() => import('./pages/Kontakt'));

function App() {
  return (
    
      Indlæser...

import { lazy, Suspense } from 'react';

// Tung chart-komponent loades kun når brugeren scroller til den
const SalesChart = lazy(() => import('./components/SalesChart'));

function Dashboard() {
  return (
    

      
Dashboard
      
      Henter diagram...
}>
        
      
    

Vendor splitting

Tredjepartsbiblioteker ændrer sig sjældnere end din egen kode. Ved at adskille dem i separate chunks kan browseren cache dem langt mere effektivt. I Vite sker det automatisk, men i Webpack skal du konfigurere det eksplicit:

// webpack.config.js
module.exports = {
  optimization: {
    splitChunks: {
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          chunks: 'all',
          maxSize: 200000, // Max 200 KB per chunk
        },
      },
    },
  },
};

En god tommelfingerregel: sigt efter 100–200 KB (gzippet) per chunk. Mindre chunks fører til for mange netværksanmodninger, mens større chunks modarbejder hele formålet med splitting.

Tree shaking: Fjern ubrugt kode automatisk

Tree shaking er en build-optimering, der automatisk fjerner ubrugt JavaScript fra din endelige bundle. Din bundler (Webpack, Rollup eller Vite) analyserer statisk, hvilke exports der importeres, og fjerner alt andet. Det lyder simpelt nok — men der er et par ting, du skal have styr på.

ES Modules er afgørende

Tree shaking fungerer kun med ES Module-syntaks (import/export). CommonJS-moduler (require/module.exports) er dynamiske og kan ikke analyseres statisk — og så er tree shaking umuligt.

// ✅ GØR DETTE — ES Modules tillader tree shaking
import { debounce } from 'lodash-es';

// ❌ UNDGÅ DETTE — CommonJS importerer hele biblioteket
const _ = require('lodash');
const debounce = _.debounce;

Forskellen er ret vild. En fuld lodash-import tilføjer cirka 72 KB minificeret kode til din bundle. Med lodash-es og tree shaking får du kun de funktioner, du rent faktisk bruger — typisk under 5 KB. Det er en besparelse på over 90%.

Tjek din package.json

Sørg for, at din package.json har sideEffects-feltet korrekt konfigureret. Det fortæller bundleren, hvilke filer der er sikre at tree-shake:

{
  "name": "min-app",
  "sideEffects": [
    "*.css",
    "*.scss"
  ]
}

Her angiver vi, at kun CSS-filer har sideeffekter (de skal altid inkluderes). Alt andet JavaScript kan tree-shakes frit. Uden dette felt kan bundleren blive tvunget til at beholde kode, den ellers ville have fjernet — og det er ærgerligt.

Erstat tunge afhængigheder med lette alternativer

Det her er et af de steder, hvor du kan gøre den største forskel med mindst arbejde. Mere end halvdelen af den gennemsnitlige JavaScript-bundles størrelse kommer fra tredjepartsafhængigheder. Og mange af dem er langt større, end de behøver at være.

Her er de mest almindelige syndere og deres letvægtsalternativer:

• moment.js (329 KB) → date-fns (tree-shakeable, typisk ~5 KB) eller dayjs (2 KB)
• lodash (72 KB) → lodash-es (tree-shakeable) eller native JavaScript-metoder
• jQuery (87 KB) → native DOM API (0 KB) eller Cash (6 KB)
• React (42 KB) → Preact (3 KB) for mindre projekter
• chart.js (62 KB) → uPlot (14 KB) for simple diagrammer

Brug Bundlephobia til at tjekke størrelsen af ethvert npm-pakke, før du installerer det. Det viser pakkens størrelse, download-tid og om den understøtter tree shaking. Det tager 10 sekunder — gør det til en vane.

Minificering og komprimering

Når du har fjernet unødvendig kode, er næste skridt at gøre den resterende kode så lille som overhovedet muligt.

Minificering med Terser eller SWC

Minificering fjerner whitespace, kommentarer, forkorter variabelnavne og udfører andre transformationer, der reducerer filstørrelsen uden at ændre funktionaliteten. I 2026 er de to mest populære minifiers:

• Terser — den etablerede standard, bruges som default i Webpack
• SWC — en Rust-baseret compiler, der er markant hurtigere (og bruges som default i Vite og Next.js)

Begge håndteres automatisk af din bundler i production mode. Sørg bare for, at du faktisk bygger med NODE_ENV=production:

# Webpack
npx webpack --mode production

# Vite
npx vite build

Brotli-komprimering: Bedre end Gzip

Brotli er lidt komprimeringens svar på en gratis opgradering — det leverer markant bedre resultater end Gzip uden ekstra omkostninger. For JavaScript-filer giver Brotli typisk 15–20% bedre komprimering end Gzip. Har du læst vores guide til TTFB-optimering, kender du allerede vigtigheden af korrekt komprimering.

Opsætning i Nginx:

# Nginx: Aktivér Brotli-komprimering
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/javascript application/json
             text/xml application/xml image/svg+xml;

En endnu bedre strategi er at prækomprimere dine filer ved build-time. Så slipper serveren for at komprimere on-the-fly ved hver request:

# Installér Vite-plugin til prækomprimering
npm install --save-dev vite-plugin-compression

# vite.config.js
import compression from 'vite-plugin-compression';

export default {
  plugins: [
    compression({
      algorithm: 'brotliCompress',
      ext: '.br',
    })
  ]
};

Reducér main thread-blokering

Her er noget, mange overser: selv en lille JavaScript-bundle kan ødelægge din INP-score, hvis koden eksekverer i lange, ubrudte opgaver, der blokerer main thread. Husk — enhver opgave over 50 ms blokerer brugerinteraktion.

Lad os se på, hvordan du bryder dem op.

Opdel lange opgaver med yield

Den simpleste teknik er at "yielde" til main thread mellem tunge operationer. Idéen er, at browseren får en pause til at håndtere brugerinput:

// Yield til main thread med scheduler.yield() (Chrome 129+)
async function processLargeList(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Yield hver 10. element for at holde main thread responsiv
    if (i % 10 === 0) {
      await scheduler.yield();
    }
  }
}

// Fallback til ældre browsere
function yieldToMain() {
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

async function processLargeListFallback(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    if (i % 10 === 0) {
      await yieldToMain();
    }
  }
}

scheduler.yield() er det moderne API i 2026, designet specifikt til dette formål. Det giver browseren mulighed for at håndtere ventende brugerinput og derefter genoptage din kode. Det er mere effektivt end setTimeout(0), fordi det bevarer opgavens prioritet.

Flyt tungt arbejde til Web Workers

For virkelig CPU-intensive opgaver — sortering af store datasæt, billedbehandling, kryptering, den slags — er Web Workers den bedste løsning. En Web Worker kører i en separat tråd og blokerer slet ikke main thread:

// worker.js
self.onmessage = function(e) {
  const data = e.data;

  // Tungt arbejde her — blokerer IKKE main thread
  const result = heavyComputation(data);

  self.postMessage(result);
};

// main.js
const worker = new Worker('./worker.js');

worker.postMessage(largeDataset);

worker.onmessage = function(e) {
  updateUI(e.result);
};

Tredjepartsscripts: Brug Partytown

Analytics, tracking-pixels og chatwidgets er notoriske performance-syndere. Den gennemsnitlige webside har over 35 tredjepartsscripts, og de bidrager i gennemsnit med 1,4 sekunders blokeringstid til main thread. Det er voldsomt.

Partytown er et bibliotek, der flytter tredjepartsscripts til en Web Worker:

Resultatet? Google Tag Manager, Facebook Pixel og lignende kører i baggrunden uden at påvirke din INP-score. Ærligt, det føles nærmest som magi første gang, man ser det virke.

Dynamisk import og prefetching

Dynamisk import (import()) er motoren bag code splitting. Men du kan gøre det endnu smartere med prefetching — hent koden, før brugeren har brug for den:

// Prefetch en chunk når brugeren hoverer over et link
function NavLink({ to, children }) {
  const handleMouseEnter = () => {
    // Starter download af chunken i baggrunden
    if (to === '/produkter') {
      import('./pages/Produkter');
    }
  };

  return (
    
      {children}
    
  );
}

Webpack understøtter også magic comments til prefetching:

// Webpack prefetch — downloader chunken i idle-tid
const Produkter = lazy(() =>
  import(/* webpackPrefetch: true */ './pages/Produkter')
);

// Webpack preload — downloader chunken med det samme
const KritiskKomponent = lazy(() =>
  import(/* webpackPreload: true */ './components/KritiskKomponent')
);

Forskellen mellem prefetch og preload er vigtig at forstå: prefetch henter ressourcen med lav prioritet i browserens idle-tid (perfekt til kommende navigationer), mens preload henter den med høj prioritet (brug kun til ressourcer, der er nødvendige på den aktuelle side). Forveksler du de to, kan det faktisk gøre tingene værre.

Sæt performance-budgetter

Al den optimering er spild, hvis nogen merger en ny feature med et 200 KB-bibliotek i næste sprint. Vi har alle været der. Performance-budgetter fungerer som guardrails, der forhindrer regression.

Webpack performance budgets

// webpack.config.js
module.exports = {
  performance: {
    maxEntrypointSize: 250000, // 250 KB
    maxAssetSize: 200000,      // 200 KB per fil
    hints: 'error',            // Fejl i stedet for advarsel
  },
};

bundlesize i CI/CD

For automatisk kontrol i din CI-pipeline kan du bruge bundlesize:

// package.json
{
  "bundlesize": [
    {
      "path": "./dist/js/*.js",
      "maxSize": "170 kB",
      "compression": "brotli"
    },
    {
      "path": "./dist/css/*.css",
      "maxSize": "30 kB"
    }
  ]
}

Overstiger en pull request budgettet, fejler buildet automatisk. Det er den mest pålidelige måde at holde din bundle i skak over tid. Sigt efter under 170 KB komprimeret JavaScript til den kritiske rendering path.

Framework-specifikke tips til 2026

React 19 og Server Components

Med React 19 håndterer React Compiler automatisk memoization, hvilket eliminerer behovet for useMemo, useCallback og React.memo i de fleste tilfælde. Men den virkelige game changer er React Server Components (RSC): de renderer på serveren og sender nul JavaScript til klienten for server-renderede sektioner. Det er ret vildt, når man tænker over det.

// Server Component — sender INGEN JavaScript til browseren
async function ProduktListe() {
  const produkter = await db.produkter.findMany();

  return (
    

      {produkter.map(p => (
        
{p.navn} — {p.pris} kr.
      ))}
    
  );
}

// Client Component — kun dette sendes som JavaScript
'use client';
function AddToCartButton({ productId }) {
  return (
     addToCart(productId)}>
      Læg i kurv
    
  );
}

Next.js App Router

Next.js med App Router giver dig code splitting, server components og streaming out of the box. Brug next/dynamic for client-side lazy loading af tunge komponenter:

import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('../components/HeavyChart'), {
  loading: () => 
Henter diagram...
,
  ssr: false, // Render kun på klienten
});

Vue og Nuxt

Vue 3 understøtter defineAsyncComponent til lazy loading, og Nuxt 3+ leverer automatisk route-baseret code splitting:

// Vue 3 — async komponent
import { defineAsyncComponent } from 'vue';

const AsyncChart = defineAsyncComponent(() =>
  import('./components/ExpensiveChart.vue')
);

Tjekliste: JavaScript-optimering i 10 trin

Okay, lad os samle det hele i en handlingsorienteret tjekliste, du kan printe ud og hænge op ved dit skrivebord:

1. Auditér — Kør bundle analyzer og Chrome Coverage for at forstå din nuværende situation
2. Fjern ubrugt kode — Identificér og fjern JavaScript, der aldrig eksekveres
3. Implementér code splitting — Route-baseret som minimum, komponent-baseret for tunge elementer
4. Aktivér tree shaking — Brug ES Modules overalt og konfigurér sideEffects
5. Erstat tunge afhængigheder — Moment.js ud, date-fns ind. Tjek Bundlephobia
6. Komprimér med Brotli — 15–20% bedre end Gzip for JavaScript
7. Bryd lange opgaver op — Brug scheduler.yield() eller setTimeout(0)
8. Flyt tredjepartsscripts — Brug Partytown eller defer/async attributter
9. Sæt performance budgets — Maks 170 KB komprimeret JS til critical path
10. Monitorér løbende — Brug RUM-data til at fange regressioner tidligt

FAQ: Ofte stillede spørgsmål om JavaScript-optimering

Hvordan reducerer jeg JavaScript bundle size?

Start med at analysere din bundle med et værktøj som webpack-bundle-analyzer eller vite-bundle-analyzer. Identificér de største afhængigheder og overvej, om de kan erstattes med lettere alternativer. Implementér derefter code splitting, aktivér tree shaking ved at bruge ES Modules, og sørg for, at Brotli-komprimering er aktiveret på din server. De her trin reducerer typisk bundlen med 40–60%.

Hvad er forskellen mellem code splitting og lazy loading?

Code splitting er en build-teknik, der opdeler din JavaScript i separate filer (chunks). Lazy loading er en runtime-strategi, der udskyder indlæsningen af en chunk, indtil den faktisk er nødvendig. De to teknikker arbejder sammen: code splitting skaber de separate chunks, og lazy loading bestemmer, hvornår de indlæses. Uden code splitting giver lazy loading ingen mening, da al koden allerede er i én fil.

Påvirker JavaScript-størrelse min Google-ranking?

Ja — indirekte, men mærkbart. Google bruger Core Web Vitals (herunder INP og LCP) som rankingfaktorer. Store JavaScript-bundles øger blokeringstiden på main thread, hvilket forværrer INP. De forsinker også rendering af visuelt indhold, som påvirker LCP. Når to sider er nogenlunde ens i indholdskvalitet, vil den med bedre Core Web Vitals ranke højere.

Er Vite bedre end Webpack til bundle-optimering i 2026?

For de fleste nye projekter — ja. Vite bruger Rollup til production builds, som generelt producerer mindre bundles end Webpack. Vites code splitting er mere aggressiv som standard, og det understøtter automatisk CSS code splitting. Udvikleroplevelsen er desuden dramatisk hurtigere — op til 24 gange hurtigere HMR. Webpack har dog stadig fordele i store enterprise-projekter med behov for Module Federation eller meget specialiserede plugins. Så det afhænger af konteksten.

Hvad er et godt performance budget for JavaScript?

En god rettesnor er maks 170 KB komprimeret JavaScript til den kritiske rendering path (det brugeren ser ved første sidevisning). Individuelle chunks bør holdes under 200 KB gzippet. For den samlede JavaScript-payload anbefales under 300 KB komprimeret. Sæt disse grænser som automatiske checks i din CI-pipeline, så de ikke kan overskrides ved nye deployments.