Core Web Vitals monitoren: Dauerhaft im Blick

Core Web Vitals sind kein einmaliges Optimierungsprojekt – sie sind eine dauerhafte Aufgabe. Eine Seite die heute gute Werte hat, kann nach einem Theme-Update, neuen Plugins oder einer Content-Änderung wieder schlechte Werte haben. Wer Core Web Vitals dauerhaft monitoren will, braucht professionelles Monitoring – das macht den Unterschied zwischen reaktivem Feuerlöschen und proaktivem Performance-Management.

Warum dauerhaftes Monitoring notwendig ist

Core Web Vitals-Werte können sich durch viele Faktoren verschlechtern:

• Theme-Updates oder Plugin-Updates die zusätzliches JavaScript hinzufügen
• Neue Werbe-Banner oder Marketing-Tools die CLS erhöhen
• Bildgröße-Fehler bei neu hochgeladenen Inhalten
• Serverausfälle die TTFB erhöhen
• Neue Seitentypen die nicht optimiert wurden

Ohne Monitoring entdecken Sie diese Probleme erst wenn Google die Rankings anpasst – mit mehrwöchiger Verzögerung.

Ohne aktives Core Web Vitals Monitoring verschlechtern sich die Werte einer durchschnittlichen WordPress-Website innerhalb von 12 Monaten um 23 % – durch Akkumulation kleiner Regressions durch Plugins, Bilder und Third-Party-Scripts.

Die zwei Datenquellen: Lab vs. Feld

Lab-Daten (synthetische Messung): Automatisierte Tests unter kontrollierten Bedingungen. Tools: Lighthouse, WebPageTest, PageSpeed Insights.

Vorteile: Deterministisch, immer verfügbar, zeigt sofort Auswirkungen von Änderungen. Nachteil: Simulierte Bedingungen weichen von realen Nutzererfahrungen ab.

Felddaten (Real User Monitoring / CrUX): Echte Messwerte von Chrome-Nutzern. Google nutzt diese Felddaten für Rankings.

Vorteile: Repräsentiert echte Nutzererfahrungen, direktes SEO-Signal. Nachteil: Braucht Traffic für aussagekräftige Daten, 28-Tage-Fenster – keine Echtzeit-Signale.

Für SEO gilt: Felddaten entscheiden. Aber Lab-Daten sind der Frühwarnindikator.

Google Search Console: Felddaten immer prüfen

Die Search Console Core Web Vitals-Reports sind der direkteste Blick auf Googles Messung Ihrer Seiten.

Wo zu finden: Search Console → Erfahrung → Core Web Vitals

Was angezeigt wird:

• Seiten in den Kategorien Gut / Verbesserungswürdig / Schlecht
• Primär betroffene Metrik (LCP, INP oder CLS)
• URL-Gruppen (ähnliche Seiten werden zusammengefasst)

Monitoring-Routine:

• Monatlich prüfen ob neue Seiten in „Schlecht” aufgetaucht sind
• Bei Drops in den Felddaten: Deployment-Timeline prüfen (was wurde wann geändert?)
• Jede Seite in „Schlecht” priorisieren und Ursache analysieren

PageSpeed Insights API: Automatisierte Überwachung

PageSpeed Insights bietet eine kostenlose API die Sie für automatisiertes Monitoring nutzen können.

Einfaches Bash-Script für regelmäßige Messung:

#!/bin/bash
API_KEY="IHR_API_KEY"
URL="https://example.de/"

curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed\
?url=${URL}&strategy=mobile&key=${API_KEY}" \
| jq '{
  lcp: .loadingExperience.metrics.LARGEST_CONTENTFUL_PAINT_MS.category,
  inp: .loadingExperience.metrics.INTERACTION_TO_NEXT_PAINT.category,
  cls: .loadingExperience.metrics.CUMULATIVE_LAYOUT_SHIFT_SCORE.category
}'

Für regelmäßige Ausführung: Cronjob oder CI/CD-Pipeline (GitHub Actions täglich triggern).

Mit Alert: Wenn ein Wert auf „SLOW” (schlecht) fällt, E-Mail oder Slack-Notification senden.

Lighthouse CI für Deployment-Monitoring

Lighthouse CI (beschrieben in einem separaten Artikel) ist das beste Tool um sicherzustellen dass neue Deployments keine Core Web Vitals-Regressions einführen.

Konfiguration für CWV-Assertions:

// lighthouserc.js
module.exports = {
  ci: {
    assert: {
      assertions: {
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
        'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }],
        'total-blocking-time': ['warn', { maxNumericValue: 300 }],
      },
    },
  },
};

Real User Monitoring (RUM) einrichten

Für Traffic-starke Seiten lohnt sich echtes Real User Monitoring das Felddaten in Echtzeit erfasst:

Web Vitals JavaScript Library (Google):

<script type="module">
  import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals/dist/web-vitals.js';

  function sendToAnalytics(metric) {
    const body = JSON.stringify({name: metric.name, value: metric.value, rating: metric.rating});
    navigator.sendBeacon('/analytics', body);
  }

  onLCP(sendToAnalytics);
  onINP(sendToAnalytics);
  onCLS(sendToAnalytics);
</script>

Diese Library misst echte Core Web Vitals auf Nutzergeräten. Die Daten können in Google Analytics 4 (über Custom Events), Datadog, New Relic oder ein eigenes Monitoring-System gesendet werden.

Google Analytics 4 Integration:

import {onLCP, onINP, onCLS} from 'web-vitals';

function sendToGA(metric) {
  gtag('event', metric.name, {
    value: Math.round(metric.name === 'CLS' ? metric.value * 1000 : metric.value),
    metric_id: metric.id,
    metric_value: metric.value,
    metric_rating: metric.rating,
  });
}

onLCP(sendToGA);
onINP(sendToGA);
onCLS(sendToGA);

CrUX Dashboard: Historische Felddaten visualisieren

Das Chrome User Experience Report (CrUX) Dashboard in Google Looker Studio zeigt historische Core Web Vitals-Felddaten für jede Domain:

Looker Studio → Vorlagen → „CrUX Dashboard” suchen → Eigene Domain eintragen

Das Dashboard zeigt 12 Monate historische Felddaten, aufgeteilt nach Gerättyp und Metrik. Ideal um langfristige Trends zu identifizieren.

Alerting: Probleme sofort erkennen

Monitoring ohne Alerting ist unvollständig. Richten Sie automatische Benachrichtigungen ein:

Uptime-Monitoring mit Core Web Vitals: Tools wie UptimeRobot, StatusCake oder Better Uptime können nicht nur Downtime, sondern auch Performance-Metriken überwachen und bei Überschreitung von Schwellenwerten alertieren.

Sentry Performance Monitoring: Sentry (primär für Fehlermonitoring) bietet auch Performance Monitoring mit Core Web Vitals Tracking und Alerting.

Custom Alerts in Google Analytics 4: GA4 Custom Alerts können konfiguriert werden um bei starken Traffic-Einbrüchen (die oft mit Performance-Problemen korrelieren) zu benachrichtigen.

Websites mit aktivem Core Web Vitals Alerting erkennen Performance-Regressions im Median 8 Tage früher als Websites ohne Alerting – bevor Google die schlechteren Felddaten in Rankings umsetzt.

Monitoring-Checkliste

Wöchentlich (5 Minuten):

• PageSpeed Insights für Startseite + 2 wichtige Landing Pages manuell testen

Monatlich (30 Minuten):

• Search Console Core Web Vitals Report prüfen
• CrUX Dashboard auf Trends überprüfen
• Neue Seiten in „Schlecht” analysieren

Bei jedem Deployment:

• Lighthouse CI automatisch durch Pipeline laufen lassen
• Bei Regressions: Deploy stoppen oder sofort reparieren

Quartalsweise:

• Vollständiger WebPageTest für Top-5-Seiten
• Vergleich mit 3-Monats-Trend in CrUX