Core Web Vitals regressioner — Når LCP, INP og CLS pludselig forværres
Core Web Vitals regressioner er pludselige fald i LCP, INP eller CLS — typisk forårsaget af deployments, nye tredjeparts-scripts eller billedoptimerings-fejl. Uden monitoring opdages de først når rankings falder.
Core Web Vitals regressioner er pludselige fald i LCP, INP eller CLS der forværrer brugeroplevelse og over tid rankings. De opstår typisk ikke gradvist men som konsekvens af specifikke ændringer: deployments med nye scripts, billedoptimerings-fejl, font-changes eller layout-ændringer. Uden monitoring opdages de først når rankings allerede er faldet — så er skaden sket.
Detektion via tre monitoring-lag
Ingen enkelt kilde fanger alle regressioner. Google Search Console viser feltdata aggregeret over 28 dage — god til trends men langsom. Real User Monitoring (RUM) via SpeedCurve, DebugBear eller web-vitals.js logger metrics per side-load og fanger regressioner inden for timer. Synthetic monitoring med Lighthouse CI scheduleret ved deployments fanger regressioner før de rammer brugere. Kombinationen er nødvendig fordi hver kilde har blinde pletter.
Hyppigste årsager
Nye tredjeparts-scripts er den hyppigste synder — analytics, chat-widgets, reklamer og A/B-test tools tilføjer alle main-thread arbejde der forværrer INP. Billedoptimerings-fejl sker typisk ved deployments der fjerner WebP-konvertering eller lazy loading. Font-changes uden font-display: swap forårsager CLS. Layout-ændringer i hero-sektionen flytter LCP-elementet og kan forværre LCP dramatisk uden at udvikler opdager det.
Deployment som primær trigger
De fleste regressioner kan spores tilbage til specifikke deployments. En performance-regression-review som del af pull request-processen fanger de fleste problemer før de når produktion. Lighthouse CI viser delta per commit — hvis LCP forværres med mere end 10%, skal årsagen identificeres før merge.
Rankings-effekt over tid
Google bruger feltdata over 28 dage, hvilket betyder at kortvarige regressioner (under 7 dage) typisk ikke påvirker rankings målbart. Regressioner der varer 2+ uger begynder at påvirke positioner, særligt i konkurrenceudsatte nicher hvor konkurrenter har sammenlignelig content-kvalitet. For informational content med lav konkurrence er effekten mindre.
Forebyggelse gennem performance budgets
Performance budgets i CI/CD blokerer deployments der overskrider definerede tærskelværdier. En typisk budget: LCP må ikke stige med mere end 10% vs. baseline, INP ikke over 200ms, CLS ikke over 0.1. Organisatorisk: nye tredjeparts-integrationer kræver altid performance-impact-analyse inden produktion.
Andre artikler i samme emne
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- RUM vs. syntetisk monitoring — To syn på web performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- Video performance — Lazy loading, formater og indlæsningsstrategi
Ofte stillede spørgsmål
- Hvordan opdager man Core Web Vitals regressioner?
- Tre monitoring-lag: (1) Google Search Console Core Web Vitals-rapporten — viser feltdata (CrUX) aggregeret over 28 dage, god til trends men langsom til at fange regressioner. (2) Real User Monitoring (RUM) — tools som SpeedCurve, DebugBear eller web-vitals.js der logger metrics per side-load, opdager regressioner inden for timer. (3) Synthetic monitoring — Lighthouse CI eller PageSpeed Insights API scheduleret ved hver deployment. Kombinationen er nødvendig: GSC viser impact, RUM viser real-time drift, synthetic viser deployment-regressioner.
- Hvad er de hyppigste årsager til CWV-regressioner?
- De fire hyppigste: (1) Nye tredjeparts-scripts (analytics, chat-widgets, ads, A/B-test tools) der blokerer main thread og forværrer INP. (2) Billedoptimerings-fejl — en deployment der fjerner WebP-konvertering eller lazy loading forværrer LCP dramatisk. (3) Font-changes — ny font uden font-display: swap forårsager CLS. (4) Layout-ændringer i hero-sektionen der flytter LCP-elementet — typisk en ny banner eller cookie-consent der skubber indhold ned. Deployment-review bør altid inkludere performance-regression-check.
- Hvor hurtigt påvirker CWV-regressioner rankings?
- Google bruger feltdata over 28 dage. En regression der varer under 7 dage påvirker typisk ikke rankings målbart. En regression der varer 2+ uger kan begynde at påvirke positioner for konkurrenceudsatte søgeord. For informational content med lav konkurrence er effekten mindre — Google er villig til at acceptere suboptimal performance hvis indholdet er den bedste match. Primær risiko er i commercial intent-nicher hvor konkurrenter har lige så godt indhold.
- Hvordan forebygger man CWV-regressioner?
- Tre tekniske forsvarslag: (1) Performance budgets i CI/CD — en deployment der forværrer LCP med 10%+ blokeres indtil årsag er identificeret. (2) Lighthouse CI integreret i pull requests — viser delta per commit. (3) RUM-alerting der notificerer ved 15%+ regression over 6 timer. Organisatorisk: deployment-review bør altid inkludere en performance-impact-analyse, særligt ved nye tredjeparts-integrationer og hero-sektion-ændringer.
Placering i ordbogen
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Resource hints — Preload, prefetch og preconnect til SEO
- Responsive images — srcset, sizes og art direction
- RUM vs. syntetisk monitoring — To syn på web performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- Video performance — Lazy loading, formater og indlæsningsstrategi