Core Web Vitals: indflydelse på SEO og sideoplevelse

Hvad Core Web Vitals måler

Core Web Vitals er et lille sæt brugercentrerede performance-målinger, der beskriver tre aspekter af, hvordan en side opleves i praksis: indlæsning, interaktivitet og visuel stabilitet. I praksis bruger du dem til at svare på: hvor hurtigt det primære indhold dukker op, hvor responsiv siden er over for brugerinput, og om layoutskift afbryder oplevelsen.

Largest Contentful Paint (LCP)

LCP måler, hvornår det største synlige element i viewporten er færdigrenderet under sideindlæsning. Det element er ofte et hero-image, en tekstblok over folden eller en stor video-poster-frame. LCP handler om opfattet indlæsningshastighed: hvis det største meningsfulde indhold vises hurtigt, opfatter brugere normalt siden som hurtig.

Interaction to Next Paint (INP)

INP er feltmetrikken, der fanger responsivitet ved at måle latenstiden ved brugerinteraktioner. I modsætning til den ældre FID-metrik, som målte forsinkelsen ved den første interaction, opsummerer INP responsiviteten over mange interaktioner for at afspejle den samlede interaktivitet. INP fremhæver lange main-thread-opgaver og langsomme event handlers, der får en side til at føles sløv.

Cumulative Layout Shift (CLS)

CLS måler uventede layoutbevægelser, der sker i løbet af sidens livscyklus. Den aggregerer individuelle layout-shift-hændelser til en score, der afspejler, hvor meget synligt indhold har flyttet sig, og hvor forstyrrende skiftene var. Stabile layouts, der reserverer plads til billeder, annoncer og embeds, holder CLS lav og reducerer frustrerende reflows.

How Core Web Vitals relate to SEO

Core Web Vitals er en del af Googles page experience signals. De er ét sæt blandt mange signaler, søgemaskiner bruger til at rangere og vise indhold. At forbedre dem kan reducere friktion for brugere og øge engagement, hvilket øger en sides samlede værdi, men gode Core Web Vitals garanterer ikke højere placeringer alene. Omvendt kan meget dårlige Core Web Vitals gøre en side mindre konkurrencedygtig i tilfælde, hvor andre relevanssignaler er lignende.

Hold tre forskelle klare: crawling (bot-opdagelse og hentning), indexing (hvad Google gemmer), og ranking (hvordan resultaterne ordnes). Core Web Vitals påvirker sideoplevelsen og dermed ranking; de bestemmer ikke, om en URL crawles eller indekseres. Bemærk også operationelle fakta, der påvirker måling og udbedring: since July 2024, Google crawls sites for Search with Googlebot Smartphone by default, and in early 2024 Google removed traditional cached pages — begge betyder, at mobilvisning og aktuelt live-indhold er centrale for, hvordan experience signals beregnes og vises.

Field vs. lab measurement — what to use and when

Du har brug for både field (rigtige brugere) og lab (syntetisk) data for at diagnosticere og verificere rettelser. Field-data viser, hvordan rigtige brugere på forskellige enheder og netværk oplever dine sider; lab-data giver et reproducerbart, debugbart snapshot under kontrollerede forhold.

Field tools

Brug Core Web Vitals-rapporten i Google Search Console for site-level trends (kræver ejerskab), PageSpeed Insights til per-URL field-oversigter, og Chrome UX Report (CrUX) til aggregerede real-user-data. Til custom collection, instrumentér sider med web-vitals og send målinger ind i din analytics eller APM-indsamling for segmentering efter enhed, land og forbindelsestype.

Lab tools

Brug Lighthouse (i DevTools eller CLI) og Performance-panelet i Chrome DevTools til trace-baseret debugging. Lab-kørsler lader dig reproducere lange opgaver, inspicere hovedtråden og indfange waterfall-timings for at identificere render-blokerende ressourcer.

Common causes and practical fixes

LCP: causes and fixes

Typiske årsager: slow server response times, render-blocking CSS/JavaScript, store uoptimerede billeder, client-side rendering der forsinker meningsfuld paint, og ressourceprioritering der forsinker det største synlige element.

Practical fixes: improve server TTFB via caching and CDN placement; serve critical CSS inline for above-the-fold content and defer noncritical CSS; prioritize LCP resources with rel=preload and proper resource priorities; compress and resize images, use modern formats and responsive srcset; consider server-side rendering or hybrid rendering for pages where client-rendering delays the primary content.

INP: causes and fixes

Typiske årsager: lange JavaScript opgaver, der blokerer main thread, tung synkron arbejde under brugerinteraktioner, store bundlere der kører initialiseringskode, og ikke-optimerede event handlers.

Practical fixes: split code into smaller chunks and defer nonessential scripts, move work off the main thread using web workers, remove or postpone large initialization tasks until after first input, make event handlers fast (do minimal work, schedule heavy work via requestIdleCallback or setTimeout), and avoid layout-thrashing patterns (read–write–read).

CLS: causes and fixes

Typiske årsager: images or iframes without width/height, annoncer eller embeds injiceret uden reserveret plads, web fonts causing layout swap, og DOM insertions above existing content.

Practical fixes: always include width and height attributes (or CSS aspect-ratio) for images and iframes; reserve space for ads and dynamic content with CSS containers; use font-display swap or optional to avoid invisible text phases; avoid inserting content above existing content unless space is reserved; prefer transform-based animations rather than animating layout-affecting properties.

Prioritizing work and implementing fixes

Start med at triagere sider, hvor dårlige Core Web Vitals og høj trafik overlapper. Brug site-level Search Console-data til at finde URL-grupper med dårlige field-metrics, og debug repræsentative URLs i lab-værktøjer. For hver målside, lav en kort remediation-plan, der lister quick wins (image compression, rel=preload LCP, defer noncritical JS), medium work (code-splitting, server-side rendering), og større investeringer (arkitekturændringer eller UX-redesign).

When you deploy fixes, collect real-user metrics (RUM) for a defined validation window and compare percentiles and device segments. Because page experience is only one of many ranking signals, treat Core Web Vitals improvements as part of an iterative program: measure, fix the highest-impact items first, monitor user behavior and rankings, iterate.

Verification and troubleshooting checklist

Følg denne tjekliste, når du skal verificere Core Web Vitals-problemer og bekræfte rettelser:

1. Site-level trends: check the Core Web Vitals report in Google Search Console for URL groups that show 'poor' or 'needs improvement' status (requires ownership).

2. Per-URL field snapshot: run PageSpeed Insights to view field and lab data for a specific URL; review the CrUX field data and the diagnostic suggestions.

3. Reproduce in lab: run Lighthouse in an incognito DevTools session and examine the Performance trace. Use the Performance panel to see long tasks and main-thread activity.

4. Collect targeted RUM: instrument pages with the web-vitals library and send measurements to your analytics. Example module snippet for quick capture:

<script type="module">import {getCLS, getLCP, getINP} from 'https://unpkg.com/web-vitals?module';getCLS(r => console.log('CLS', r));getLCP(r => console.log('LCP', r));getINP(r => console.log('INP', r));</script>

5. Check device parity: because Google uses the mobile view as the primary basis for indexing and page experience, verify your mobile HTML serves equal or equivalent content and that responsive images, CSS and critical resources are optimized for smartphone viewport sizes.

6. Isolate third-party impact: load the page with and without third-party scripts (ads, analytics, widgets) in a lab run to measure their impact on LCP, INP and CLS. Replace or lazy-load the providers that cause excessive long tasks or unexpected layout shifts.

Common mistakes and diagnostic traps

• Treating lab scores as field reality. Lab runs are essential for debugging, but they simulate a single device/network profile and may not represent your user base. Always validate with field RUM.

• Fixing desktop only. Because Google evaluates page experience primarily on the mobile rendering, fixes must target the mobile experience first unless your analytics show a different device mix for important user journeys.

• Over-optimizing a single metric. Improvements should respect user needs: aggressively deferring fonts to lower CLS may harm readability; removing important scripts to lower INP may break functionality. Use experiments and measure user metrics beyond Core Web Vitals, like engagement and conversion.

• Ignoring randomized variability. Field data contains noise: geographic, carrier, and device variation can change percentiles. Segment RUM by meaningful cohorts to identify real regressions.

When to accept trade-offs

Nogle sider tilbyder komplekse interaktive oplevelser, som nødvendigvis koster CPU- eller netværksbudget. Hvis en funktion er kerne i dit produkt og giver målelig brugerværdi, dokumentér trade-off'et, optimer alt andet du kan, og overvåg brugeradfærd. Prioritér rettelser, der reducerer omkostningen ved den funktion (f.eks. incremental hydration, partial hydration, eller isolering af tung kode i en deferred bundle) frem for at fjerne funktionalitet helt.

FAQ