Core Web Vitals: vad du ska övervaka och hur du fixar regressioner
Prestandaregressioner skickas nästan aldrig med avsikt. De kommer med en till synes oskyldig ändring: en ny bildkarusell, en tredjepartstagg, ett typsnittsbyte. När någon märker fallet i konvertering är regressionen två veckor gammal. Kontinuerlig CWV-övervakning vänder på loopen — du ser regressionen samma dag.
Google rangordnar webbplatser efter prestanda hos riktiga användare. LCP, FCP, CLS, TTFB — det är inte abstrakta siffror, de är konverteringsmördare när de glider. Så övervakar du dem kontinuerligt och fångar regressioner innan de når användarna.
Vad Core Web Vitals faktiskt mäter
De sex mätvärden du bryr dig om, enkelt förklarade:
• LCP (Largest Contentful Paint) — hur lång tid tills det största synliga elementet är renderat. Bra < 2,5s. • FCP (First Contentful Paint) — hur lång tid tills någon pixel renderas. Bra < 1,8s. • CLS (Cumulative Layout Shift) — hur mycket sidan hoppar runt. Bra < 0,1. • TTFB (Time to First Byte) — ren server/CDN-latens. Bra < 0,8s. • TBT (Total Blocking Time) — hur länge huvudtråden blockerades. Bra < 200ms. • Speed Index — syntetiserad 'hur snabbt kändes det'-poäng. Bra < 3,4s.
Varför syntetiska labbpoäng ljuger
Lighthouse-CI kör din sida på en simulerad mellanklass-enhet med simulerad 3G. Det är bra för relativa jämförelser men missar många verkliga fel. Tredjepartsskript som lazy-loadar baserat på cookie-samtycke, A/B-grenar som bara syns för hälften av användarna — Lighthouse ser dem aldrig.
En fullbrowsers Playwright-check — en riktig Chromium-instans som navigerar din sida med dina cookies och headers — fångar felen Lighthouse missar. SpeedTest kör båda så du får både CI-baslinjen och verklig browser-sanning.
Läsa graferna: gradvisa vs. stegvisa regressioner
Två regressionsformer berättar olika historier.
En gradvis klättring i LCP över två veckor betyder oftast att en enda resurs växer — ett produkt-image-feed som saknar pagination, ett analyspaket som får fler funktioner.
En stegvis förändring vid en enda deploy — TTFB hoppar från 400ms till 1200ms över natten — är en direkt kodorsak. Korrelera tidsstämpeln med dina DeployLog-poster, hitta committen, återställ eller fixa.
Per-metric larmtrösklar som faktiskt fungerar
En tröskel per metric, larma vid överträdelse av 'poor'-gränsen snarare än vid en iögonfallande 'regressed by 10%':
• LCP > 4,0s — larm • FCP > 3,0s — larm • CLS > 0,25 — larm • TTFB > 1,8s — larm • TBT > 600ms — larm
Parar dessa med en 'varna'-tröskel vid Googles 'needs improvement'-gräns.
Vad man gör när CWV regresserar efter en deploy
Playboken när ett rött mätvärde larmar direkt efter en release:
1. Öppna Playwright-spåret för den misslyckade körningen. 2. Hitta den nya eller ändrade resursen. Leta efter nya script-taggar, större bildnyttolaster. 3. Om det är en tredjepart, kontrollera deras statussida och överväg `async` eller `defer`. 4. Om det är din kod, korrelera med DeployLog och återställ eller hotfixa. 5. Lägg till felmönstret i din pre-deploy-checklista.
Funktionsguide
Uptime Monitoring
AlertsDock gives teams uptime monitoring for websites, APIs, TCP checks, DNS checks, SSL expiry, and fast alert routing without enterprise overhead.
Läs guideAlternativsida
Better Stack Alternative
Compare AlertsDock with Better Stack for teams that want a more focused monitoring product covering uptime, cron jobs, status pages, and webhooks.
Se jämförelseMore articles
AI-genererade changelogs: gör git-commits till release notes automatiskt
Att skriva release notes är sysslan ingen vill ha. DeployLog läser dina commits vid varje push och genererar rena, läsbara changelogs grupperade efter typ — ingen Anthropic krävs, fungerar med Groq, Gemini, Cloudflare, OpenRouter eller self-hosted Ollama.
Sluta maila .env-filer: en praktisk guide till krypterade valv
Ditt teams DATABASE_URL ligger i någons Slack-DM. Din STRIPE_SECRET_KEY bor på en Notion-sida. Så läcker hemligheter. Här är den hygien du borde haft från dag ett — och hur krypterade valv gör det smärtfritt.
Incidentplaybooks som kör sig själva: från runbook till runtime
Att skriva en runbook som ingen läser kl 3 på natten är bortkastat. Att skriva en som auto-startar i samma ögonblick som en monitor går ner och loggar varje steg är en kraftmultiplikator. Så gör du on-call mindre som en ensam krisrespons och mer som att följa en checklista.