Core Web Vitals optimering
Hurtigere sites. Højere ranking.
LCP
Hero-rendering
INP
Main-thread-trim
CLS
Layout-stabilitet
TTFB
Edge-caching
Performance vi har leveret for
Performance er ikke en feature, det er fundamentet
Google ranker langsommere sites lavere, og brugerne forlader dem hurtigere. Core Web Vitals er ikke længere en nice-to-have, det er et minimumskrav for at være konkurrencedygtig i organisk søgning. Et site der scorer "Poor" på LCP eller INP tilbringer mindre tid i SERP'en og taber både ranking og konverteringer.
Vi har optimeret performance på sites bygget i Next.js, WordPress og headless CMS. Tilgangen er den samme uanset stack: mål, prioriter, implementer, verificer. Vores eget site er bygget i Next.js og fungerer som demonstration, kør Lighthouse mod webworq.dk og sammenlign med vores tal længere nede.
Real proof, webworq.dk målt nu
Mål kan skrives op. Vores site kan ikke. Kør PageSpeed Insights på webworq.dk og sammenlign med tallene herunder.
Lighthouse Desktop
Largest Contentful Paint
Total Blocking Time
Cumulative Layout Shift
Mobile Lighthouse-scoren er typisk lavere for danske sites med lovpligtigt cookie-samtykke, og ja, også for vores. Vi optimerer løbende, både på desktop og mobil. Real-user CrUX-data giver det mest retvisende billede.
De fire metrics, forklaret
LCP, INP, CLS er Googles tre Core Web Vitals. TTFB er en stærk indikator der bestemmer hvor godt de tre kan blive.
LCP
≤ 2,5sLargest Contentful Paint
Hvor hurtigt det største synlige element render. Typisk hero-billede, H1 eller hero-tekst. LCP > 4s er "Poor" og taber både ranking og konverteringer. Mest almindelige problem: LCP-elementet er hidden bag opacity-0 animationer eller venter på font-loading.
Vores fix: Identificer LCP-elementet i Lighthouse → render det i første frame → fjern animation-blockers → preload font.
INP
≤ 200msInteraction to Next Paint
Hvor responsivt sitet føles ved klik, tap eller tastatur. Erstattede FID i marts 2024. Måler den værste interaktion på siden. Typisk problem: tunge JavaScript-handlere, event listeners der blokerer main thread.
Vores fix: Reducer main-thread-arbejde → code-split tunge komponenter → defer tredjepart-scripts → brug requestIdleCallback for ikke-kritisk arbejde.
CLS
≤ 0,1Cumulative Layout Shift
Hvor meget elementer hopper rundt under indlæsning. Frustrerende for brugere når en knap rykker sig lige før de klikker. Typisk problem: billeder uden width/height, fonts der swapper og ændrer linjehøjde, tilføjede elementer (banners, ads) uden reserveret plads.
Vores fix: Sæt eksplicit width/height på alle billeder → reserver højde til ads og bannere → brug font-display: optional eller size-adjust descriptors.
TTFB
≤ 800msTime to First Byte
Hvor hurtigt server svarer. Ikke en officiel CWV-metric men en stærk indikator: hvis TTFB er høj, kan LCP aldrig blive god. Typisk problem: tung WordPress uden caching, database-queries i hovedrenderingen, server placeret langt fra brugerne.
Vores fix: CDN foran origin (Cloudflare) → Edge-caching for statiske og semi-statiske sider → query-optimering eller ISR/SSG i stedet for SSR.
Performance som disciplin, ikke en engangsoptimering
Vi måler før og efter, dokumenterer pre-/post-tal i Lighthouse og CrUX, og sætter et performance-budget op i jeres CI/CD så regressioner fanges automatisk. Det er forskellen mellem en sprint der holder, og en sprint der eroderer over tid.
- ✓Lighthouse + CrUX målt på 5 sider, mobile + desktop
- ✓Prioriteret fix-roadmap med impact-estimering
- ✓Pre-/post-rapport så I ser præcist hvad hver fix gav
- ✓Performance-budget i CI/CD, fanger regressioner før deploy
Hvornår skal I investere i Core Web Vitals?
Performance-arbejde betaler sig ikke altid. Her er hvornår det er den rigtige investering, og hvornår der er bedre prioriteringer.
Invester nu hvis
Konkrete signaler I kan tjekke i dag
- PageSpeed Insights viser "Poor" eller "Needs Improvement" på mobil
- Search Console rapporterer Core Web Vitals-fejl på flere URL'er
- Bounce rate er over 60% på mobile landing pages
- I konkurrerer på trafik-tunge keywords hvor små ranking-ryk betyder meget
- Sitet skal nå et stort eller globalt publikum (CrUX vægter mobil tungt)
- I bruger penge på Google Ads, langsom landing page = højere CPC
Vent, hvis
Andre prioriteringer betaler sig først
- Sitet allerede passer Core Web Vitals (Search Console viser "Good" på 75%+ af URL'er)
- I står foran en større rebuild, så optimer den nye stack i stedet
- Trafikken er primært direkte/branded, hvor CWV påvirker ranking mindst
- I har ikke konfigureret Google Search Console eller Analytics endnu, mål først
- Konvertering er primært drevet af content eller pris, ikke speed
- Budget er begrænset, og indhold/SEO eller annoncering vil give større ROI
Ikke sikker? Book en gratis 30-min snak hvor vi sammen kører Lighthouse og PageSpeed Insights mod jeres site og giver en ærlig vurdering. Hvis der ikke er noget at hente, siger vi det.
Hvad vi rent faktisk fikser i en sprint
De seks områder vi typisk arbejder igennem, prioriteret efter impact pr. ændring.
LCP-element og hero-rendering
Vi finder LCP-elementet, sikrer at det render i første frame, fjerner opacity-0 entrance-animationer der blokkerer paint, og preloader hero-billede med fetchpriority="high".
Image format og sizing
Konvertering til AVIF (50% mindre end JPEG) med WebP fallback, responsive sizes via srcset, lazy-loading for below-fold, og eksplicit width/height så CLS holdes på 0.
JavaScript bundle-trim
Code-splitting af tunge komponenter (charts, editors, video players), tree-shaking af ubrugte exports, dynamic imports for non-critical UI, og removal af duplikerede dependencies.
Tredjepart-scripts
Audit af analytics, tag manager, consent-tools, chat widgets og pixels. Defer/async, Partytown for web-worker-isolering hvor muligt, og facade-mønster for embedded video og maps.
Font-loading
Preload af kritiske fonts, font-display: swap eller optional, subsetting til kun de glyphs der bruges (Glyphhanger), og size-adjust descriptors så font-swap ikke skaber CLS.
Render-blocking ressourcer
Critical CSS inline eller tidligt loadet, async/defer af ikke-kritisk JS, fjernelse af render-blocking webfonts og tredjeparts-stylesheets der ikke bruges above the fold.
Sådan kører en Core Web Vitals-sprint hos os
Fire faser, ugentlige demos, dokumenteret resultat. Fra første måling til sidste verifikation tager en sprint typisk 3-4 uger.
Diagnose
2-3 dage
Plan
2-3 dage
Implementering
2-3 uger
Verifikation
1 uge
Diagnose
Måling og bottleneck-identifikation
- →Lighthouse audit (5 sider, mobile + desktop)
- →CrUX real-user data
- →LCP-element analyse
- →Bundle og script audit
Diagnose
Måling og bottleneck-identifikation
Aktiviteter:
Plan
Prioriteret roadmap
Aktiviteter:
Implementering
Sprint med ugentlige demos
Aktiviteter:
Verifikation
Måling, dokumentation, overlevering
Aktiviteter:
← Swipe for at navigere mellem faser →
Hvad koster en Core Web Vitals-optimering?
Tre niveauer, fra one-time audit til continuous performance engineering. Audit-prisen modregnes hvis I vælger en sprint.
Performance Audit
Diagnostisk audit + roadmap
Field-data audit og prioriteret fix-liste, til teams der selv har udviklere men vil vide præcis hvad der skal løses
ekskl. moms
- Lighthouse + WebPageTest på 5 nøglesider (mobile + desktop)
- Lab-data og field-data adskilt
- CrUX real-user data fra Search Console (28-dages aggregeret)
- LCP-element identificeret og forklaret
- INP-analyse (vigtigste metric mange overser efter marts 2024)
- CLS-kortlægning per side
- JavaScript bundle-analyse (unused JS, duplicates)
- Image og font-loading audit
- Tredjepart-script-audit (analytics, consent, tag manager)
- Prioriteret roadmap med impact pr. fix og effort-estimat
- PDF-rapport + 60-min gennemgang med jeres team
- Implementering af fixes
- Løbende monitoring
Performance Sprint
Audit + 2-3 ugers implementering
Audit kombineret med 2-3 ugers implementering. Vi løser de højest-prioriterede LCP/INP/CLS-problemer og dokumenterer effekten med før/efter-tal
ekskl. moms
- Alt fra Performance Audit
- 2-3 ugers implementering, ugentlige demos
- Hero/LCP-element optimering
- Image-format konvertering (AVIF/WebP) + responsive sizes
- JavaScript code-splitting og bundle-trim
- Tredjepart-scripts: defer, async, Partytown-evaluering
- Font-loading: preload, font-display, subsetting, size-adjust
- Critical CSS + fjernelse af unused rules
- Før/efter Lighthouse + CrUX dokumentation
- Performance-budget defineret og dokumenteret
- 60 dages support efter sprint
- Løbende monitoring og kvartalsvise sprints
Continuous Performance Engineering
Sprint + RUM + CI/CD performance-budget + månedlig optimering
Performance som løbende disciplin, ikke et engangsprojekt. Opstart-sprint plus månedlig retainer med RUM, CI/CD-gating og kvartalsvise sprints
ekskl. moms
- Opstart: Performance Sprint scope (45.000,- engangs)
- RUM-opsætning (CoreDash, SpeedCurve, DebugBear eller Calibre)
- Performance-budget i CI/CD (12.500,-/md)
- Custom dashboard med CWV per side, per device
- Månedlig performance-rapport med handlingspunkter
- Kvartalsvis optimization-sprint inkluderet (ca. 25 timer)
- Eskalations-support hvis CWV regression i produktion
- Dedikeret performance-engineer på jeres projekt
- Onboarding for jeres team (4 timer + dokumentation)
- 12 måneders SLA — første år: 195.000 DKK total
Få et prisestimat på 2 minutter
Prøv vores prisberegner og få et skræddersyet tilbud baseret på dine behov — helt gratis og uden forpligtelser.
Ofte stillede spørgsmål om Core Web Vitals
Det praktiske, det tekniske og det kommercielle om performance-optimering.
Klar til at få jeres Core Web Vitals i orden?
Book en 30-minutters gratis snak. Vi kører Lighthouse mod jeres site sammen og giver en ærlig vurdering: hvad der kan hentes, hvad det kræver, og hvad det koster.
30-minutters gratis snak
Ingen salgstale
Live audit på jeres site
Lighthouse + PageSpeed
Realistisk impact-estimat
Hvad kan vi hente?
Ring direkte
Kontakt os