Artikel

Performance budgets — Grænser der forhindrer regressioner

Et performance budget er en eksplicit grænse for performance-metrics. Overskrides budgettet stopper CI/CD-pipelinen. Det er den eneste måde at forhindre at performance langsomt forringes over tid.

Sidst opdateret:

Uden performance budgets forringes performance langsomt og umærkeligt — et nyt script her, et større billede der. Ingen enkeltændring er nok til at trigge alarm, men de akkumulerer. Et performance budget sætter eksplicitte grænser og gør regressioner synlige inden de rammer brugerne.

Typer af performance budgets

Filstørrelses-budgetter er de nemmeste at implementere og håndhæve:

  • Maksimalt JavaScript-bundle: f.eks. 300 KB (komprimeret)
  • Maksimal total sidestørrelse: f.eks. 1 MB
  • Maksimal billedstørrelse per billede: f.eks. 200 KB

Timing-budgetter er tættere på brugeroplevelsen:

  • LCP under 2,5 sekunder
  • Total Blocking Time under 150ms
  • Time to Interactive under 3,5 sekunder

Kvantitets-budgetter kontrollerer antallet af ressourcer:

  • Maksimalt 50 HTTP-requests per side
  • Maksimalt 3 tredjeparts-scripts

Implementering i CI/CD

Performance budgets er kun effektive hvis de håndhæves automatisk. Manuel review ser ikke alle regressioner.

Lighthouse CI er Google’s officielle tool til at køre Lighthouse i CI-pipelines og sammenligne mod budgetter:

# .lighthouserc.yml
ci:
  collect:
    url: ['http://localhost:3000/']
  assert:
    assertions:
      largest-contentful-paint:
        - error
        - maxNumericValue: 2500
      total-blocking-time:
        - error
        - maxNumericValue: 200
      'resource-summary:script:size':
        - error
        - maxNumericValue: 307200  # 300 KB

Bundlesize er et NPM-tool der tjekker bundle-størrelse mod budgetter og kan konfigureres til at fejle PR-checks.

Webpack Bundle Analyzer visualiserer hvad der fylder i bundlet — nyttigt til at forstå hvor budgettet bruges.

Sæt realistiske budgetter

Budgetter der aldrig overholdes ignoreres. Start med at måle den aktuelle performance, og sæt budgetter tæt på det nuværende niveau — måske 10% bedre. Stram til over tid.

Brug Performance Budget Calculator eller referér til Googles anbefalinger:

  • Mobilbrugere på 3G: budgettér 150-170 KB kritisk JavaScript (unkomprimeret)
  • God LCP: under 2,5 sekunder på 75. percentil af rigtige brugere

Budget-typer og hvornår de er nyttige

Budget-typeFordeleUlempe
FilstørrelseLet at måle, deterministiskKorrelerer ikke direkte med brugeroplevelse
Timing (lab)Direkte brugeroplevelseVarierer med testmiljø
Timing (field/RUM)Afspejler rigtige brugereLangsommere feedback-loop

Det bedste setup kombinerer filstørrelses-budgetter i CI (hurtig feedback) med timing-budgetter baseret på CrUX-data (sanity check mod virkeligheden). → Denne artikel er en del af Web Performance — Core Web Vitals og teknisk hastighed.

Del af: Web Performance — Core Web Vitals og teknisk hastighed →

Andre artikler i samme emne

Relaterede begreber

Emne Web Performance — Core Web Vitals og teknisk hastighed Web performance er en direkte SEO-rankingfaktor — Core Web Vitals, hastighed og responsivt design påvirker din placering. Artikel Core Web Vitals — LCP, INP og CLS forklaret Core Web Vitals er Googles tre performance-signaler: LCP (hastighed), INP (interaktivitet) og CLS (layout-stabilitet) — alle er rankingfaktorer. Artikel LCP-optimering — Sådan forbedrer du Largest Contentful Paint LCP-optimering handler om at identificere LCP-elementet og fjerne det der forsinker dets indlæsning — billeder, TTFB og render-blocking ressourcer er de hyppigste syndere. Artikel Startup performance — Hurtig app-start og time to interactive Startup performance er kritisk: de første sekunder afgør brugerens første indtryk og påvirker bounce rate. JavaScript-parsing og tung initialisering er de hyppigste årsager til langsom start. Artikel RUM vs. syntetisk monitoring — To syn på web performance RUM måler hvad rigtige brugere oplever. Syntetisk monitoring måler i kontrollerede testmiljøer. Google bruger RUM (CrUX) som rankinggrundlag — ikke Lighthouse-scores.

Ofte stillede spørgsmål

Hvad er et performance budget?
Et performance budget er en defineret grænse der ikke må overskrides — f.eks. maksimalt 200 KB JavaScript, LCP under 2,5 sekunder, eller Total Blocking Time under 200ms. Når en ændring overskrider budgettet, fejler build-processen og ændringen skal optimeres inden deployment.
Hvilke metrics er typisk inkluderet i et performance budget?
Filstørrelses-budgetter (total sidestørrelse, JavaScript bundle størrelse, billede-størrelse), timing-budgetter (LCP, TTI, TBT) og kvantitetsbudgetter (antal HTTP-requests, antal tredjeparts-scripts). Vælg metrics der er direkte relateret til brugeroplevelsen på dit specifikke site.
Hvad er Lighthouse CI og hvordan integreres det i en CI/CD pipeline?
Lighthouse CI er Googles open source tool til at køre Lighthouse-audits automatisk ved hvert commit eller deploy. Det kan konfigureres med budgetgrænser der bryder build-processen hvis de overskrides. Integreres som et step i GitHub Actions, GitLab CI eller CircleCI. Resultaterne gemmes og kan sammenlignes over tid for at spore performance-trends.
Hvad er forskellen på lab-performance og field-performance i performance budget-kontekst?
Lab-performance (Lighthouse, WebPageTest) er deterministisk og reproducerbar — den samme test under de samme betingelser. Field-performance (CrUX, RUM) afspejler rigtige brugeres oplevelse på tværs af enheder, netværkshastigheder og geografi. Performance budgets i CI/CD typisk bruger lab-metrics fordi de er hurtige og reproducerbare. Google bruger field-data (CrUX) som rankinggrundlag — så budgetter bør kalibreres mod CrUX-data for at have reel SEO-relevans.
Hvad sker der når et performance budget overskrides i CI/CD?
Når en ændring overskrider et defineret performance budget, fejler build-processen og deployment stoppes automatisk. Udvikleren ser en fejlbesked med information om hvilken metric der er overskredet og med hvilken margin. Ændringen skal optimeres — reducer JavaScript-bundle, optimer billeder, eller revurdér om featuren er nødvendig — inden den kan merges. Det er det præcise formål med performance budgets: at gøre regressioner synlige og handlekraftige, ikke blot monitorerbare.

Placering i ordbogen

Kode — Webkode og teknisk SEO
Web Performance — Core Web Vitals og teknisk hastighed
Performance budgets — Grænser der forhindrer regressioner