Core Web Vitals für Magento 2: Eine praktische Checkliste für INP und LCP

Core Web Vitals sind die drei User-Experience-Metriken von Google für Laden, Interaktivität und visuelle Stabilität. Für einen Shop mit Magento 2 oder Adobe Commerce sind sie zugleich ein nützlicher Gesundheitscheck: Ein schlechter Wert deutet meist auf dieselben Probleme hin, die auch die Conversion beeinträchtigen, etwa langsame ungecachte Seiten, schwere RequireJS-Bundles und Tag Manager, die den Main Thread blockieren.

Dieser Leitfaden behandelt die aktuellen Grenzwerte, die richtige Messung und die Magento-spezifischen Maßnahmen, die die Werte in der Regel verbessern.

Die aktuellen Grenzwerte

Google bewertet jede Metrik beim 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop. Seit dem 12. März 2024 hat Interaction to Next Paint (INP) First Input Delay (FID) als Metrik für die Reaktionsfähigkeit abgelöst.

PageSpeed Insights wertet eine Seite oder einen Origin als bestanden, wenn das 75. Perzentil aller drei Metriken im Bereich „Gut“ liegt. Gibt es nicht genug INP-Daten, kann die Bewertung allein anhand von LCP und CLS bestanden werden.

So messen Sie: zuerst Felddaten, dann Labordaten

CrUX und PageSpeed Insights

Der Chrome User Experience Report (CrUX) sammelt echte Nutzerdaten von berechtigten Chrome-Nutzern. Die CrUX-API liefert einen gleitenden 28-Tage-Durchschnitt, der täglich aktualisiert wird, und PageSpeed Insights zeigt dieselben Felddaten für die vorangegangenen 28 Tage. Für URLs mit wenig Traffic gibt es unter Umständen nur Daten auf Origin-Ebene oder gar keine.

Eine Korrektur, die Sie heute ausrollen, ist erst nach Wochen vollständig in CrUX sichtbar. Die Search Console gruppiert zudem ähnliche URLs, sodass ein einziges langsames Template Tausende URLs herunterziehen kann. Prüfen Sie die Ergebnisse pro Template: Startseite, Kategorie, Produkt, Warenkorb, Checkout und Suche.

Lighthouse und Labor-Tools

Lighthouse in PageSpeed Insights oder in den Chrome DevTools liefert Ihnen einen reproduzierbaren Labortest mit Diagnosen. Nutzen Sie ihn, um Ursachen zu finden, etwa Render-blockierende Ressourcen oder Long Tasks. Behandeln Sie einen Labor-Score nicht als Ihr Core-Web-Vitals-Ergebnis. Labortests können INP nicht messen, da INP echte Nutzerinteraktionen erfordert.

Real User Monitoring (RUM)

CrUX sagt Ihnen, dass ein Template langsam ist. RUM sagt Ihnen, warum, auf welchen Geräten und bei welchen Interaktionen. Googles Open-Source-JavaScript-Bibliothek web-vitals meldet LCP, INP und CLS aus echten Sitzungen, einschließlich Attributionsdaten wie dem LCP-Element und dem Ziel der langsamsten Interaktion. Senden Sie diese Events an Ihr Analytics-Tool oder einen RUM-Dienst und segmentieren Sie nach Seitentyp.

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

function send(metric) {
  navigator.sendBeacon('/rum', JSON.stringify({
    name: metric.name,
    value: metric.value,
    pageType: document.body.className, // Magento adds page-type classes to body
    attribution: metric.attribution
  }));
}

onLCP(send);
onINP(send);
onCLS(send);

Magento-spezifische Maßnahmen

1. Server-Antwortzeit und Full Page Cache

Die Time to First Byte ist der erste Teil des LCP. Googles LCP-Leitfaden zerlegt den LCP in vier Teilbereiche (TTFB, Resource Load Delay, Resource Load Duration und Element Render Delay) und empfiehlt, dass die TTFB etwa 40 % der Gesamtzeit ausmachen sollte. Eine ungecachte Magento-Seite kann den Großteil des LCP-Budgets verbrauchen, bevor der Browser überhaupt HTML erhält.

Adobes Best Practices zur Konfiguration empfehlen Varnish als Page Cache in der Produktion. Aktivieren Sie ihn und teilen Sie Magento mit, wohin Purges gesendet werden sollen:

bin/magento config:set --scope=default --scope-code=0 system/full_page_cache/caching_application 2
bin/magento setup:config:set --http-cache-hosts=127.0.0.1:6081

Exportieren Sie anschließend die VCL unter Stores > Settings > Configuration > Advanced > System > Full Page Cache. Prüfen Sie danach Ihre Trefferquote. Häufige Gründe für Cache-Misses in Magento sind Blöcke, die als cacheable="false" im Layout-XML markiert sind (wodurch die gesamte Seite nicht mehr gecacht werden kann), Tracking-Parameter, die den Cache fragmentieren, sowie kundenspezifische Inhalte, die serverseitig statt über Private Content Sections gerendert werden.

# Find layout XML that disables FPC for a whole page
grep -rn 'cacheable="false"' app/code app/design vendor/*/*/view/frontend/layout

Adobe empfiehlt außerdem, Indexer aus Performance-Gründen auf „Update on Schedule“ zu stellen, damit das Speichern im Katalog während laufenden Traffics keine aufwendige Neuindizierung auslöst:

bin/magento indexer:set-mode schedule
bin/magento indexer:status

Beachten Sie, dass laut Adobe der Index „Customer Grid“ auf „Update on Save“ bleiben muss.

2. Cache Warming

Jedes Deployment oder jedes vollständige Leeren des Caches schickt die nächsten Besucher zu PHP. Wärmen Sie die wertvollsten URLs direkt nach dem Deployment auf: Startseite, Top-Kategorien, Top-Produkte und wichtige CMS-Seiten. Auf Adobe Commerce on Cloud Infrastructure übernehmen das die Post-Deploy-Variablen WARM_UP_PAGES und WARM_UP_CONCURRENCY . Auf selbst gehosteten Stacks genügt ein einfacher Crawler über eine Sitemap (dieses Beispiel nutzt GNU grep):

curl -s https://www.example.com/sitemap.xml \
  | grep -oP '(?<=<loc>)[^<]+' \
  | head -500 \
  | xargs -P 4 -I{} curl -s -o /dev/null -w "%{http_code} %{time_starttransfer} {}\n" {}

Vermeiden Sie außerdem routinemäßige vollständige Cache-Flushes. Leeren Sie gezielt einzelne Cache-Typen und setzen Sie, wo möglich, auf Tag-basierte Invalidierung.

3. Das LCP-Bild

Auf Produkt- und Kategorieseiten ist das LCP-Element meist das Hauptproduktbild oder ein Hero-Banner. Googles Empfehlung ist eindeutig: Laden Sie das LCP-Bild niemals per Lazy Loading und erwägen Sie fetchpriority="high" dafür, wobei Sie hohe Priorität auf höchstens ein oder zwei Bilder beschränken.

• Entfernen Sie loading="lazy" beim ersten Galeriebild und bei Bannern above the fold.
• Unter Luma wird die Produktgalerie per JavaScript initialisiert, nachdem das Platzhalterbild geladen ist. Prüfen Sie in den DevTools, welches Element als LCP gemeldet wird, und stellen Sie sicher, dass dieses Bild früh im HTML angefordert (oder vorgeladen) und nicht erst von einem Skript entdeckt wird.
• Liefern Sie Bilder in der richtigen Größe aus. Der Image Cache von Magento skaliert Produktbilder pro Ansicht; achten Sie darauf, dass die Größen in Ihrer view.xml der tatsächlichen Anzeigegröße entsprechen.
• Nutzen Sie moderne Formate. Auf Adobe Commerce on Cloud Infrastructure kann Fastly Image Optimization Bilder automatisch in WebP umwandeln. Bei anderem Hosting nutzen Sie einen CDN-Bilddienst oder eine geprüfte Extension.
• Laden Sie Bilder unterhalb des sichtbaren Bereichs dagegen per Lazy Loading, etwa Produktraster ab der zweiten Reihe.

4. JavaScript: Bundling und Minifizierung vs. Hyvä

INP-Probleme in Magento entstehen meist dadurch, dass der Main Thread ausgelastet ist. Luma lädt viele RequireJS- und Knockout-Module, und Extensions fügen weitere hinzu.

Adobes eigene Dokumentation äußert sich zurückhaltend zu den integrierten Optionen. Sie beschreibt, dass das native Bundling alle Bundles lädt, selbst wenn eine Seite nur wenige benötigt, empfiehlt Drittanbieter-Tools wie r.js für Bundling und Minifizierung, weist darauf hin, dass HTTP/2 eine gute Alternative zum Bundling sein kann, und rät von den veralteten Einstellungen zum Zusammenführen von JS und CSS ab. Die Minifizierung können Sie bedenkenlos aktivieren:

bin/magento config:set --lock-config dev/js/minify_files 1
bin/magento config:set --lock-config dev/css/minify_files 1

Für Luma-basierte Themes sind mit r.js erstellte Bundles pro Seitentyp (common, catalog, checkout) der dokumentierte fortgeschrittene Weg.

Der andere Weg ist, das Frontend zu ersetzen. Hyvä Theme baut die Storefront mit Alpine.js und Tailwind CSS und deutlich weniger JavaScript neu auf. Seit dem 10. November 2025 ist Hyvä Theme kostenlos und Open Source (OSL3 + AFL3); Hyvä Checkout und die übrigen kommerziellen Produkte bleiben kostenpflichtig. Hyvä ist ein Projekt, keine Einstellung: Jede Frontend-Extension braucht eine Hyvä-kompatible Version oder eine Neuentwicklung, prüfen Sie also zuerst Ihre Extension-Liste.

5. Drittanbieter-Skripte

Tag Manager, Chat-Widgets, Bewertungs-Widgets, A/B-Testing-Tools und Personalisierungsskripte sind häufige Ursachen für schlechte INP- und CLS-Werte. Gehen Sie jedes einzeln durch:

• Entfernen Sie Tags, die niemand nutzt. Prüfen Sie den Tag-Manager-Container mindestens einmal pro Quartal.
• Laden Sie nicht notwendige Widgets erst nach einer Nutzerinteraktion oder im Leerlauf statt beim Seitenaufruf.
• Reservieren Sie Platz für alles, was spät gerendert wird (Bewertungssterne, Banner, Consent-Leisten), um Layoutverschiebungen zu vermeiden.
• Zerlegen Sie Long Tasks in Ihrem eigenen Code. Google definiert eine Long Task als alles über 50 ms und empfiehlt, den Main Thread freizugeben mit scheduler.yield(), ersatzweise mit setTimeout , wo dies nicht unterstützt wird.

6. Layoutstabilität

Google nennt Bilder ohne Abmessungen, Anzeigen und Embeds, Webfonts sowie dynamisch eingefügte Inhalte als Hauptursachen für Layoutverschiebungen. Achten Sie in Magento auf Platzhalter für Produktbilder, das Rendern von Swatches, Aktualisierungen von Minicart und Customer Sections sowie von Extensions eingefügte Promo-Leisten. Legen Sie explizit Breite und Höhe (oder aspect-ratio) für Bilder fest und halten Sie Container auf fester Höhe, während Inhalte laden.

Priorisierte Checkliste

1. CrUX- und Search-Console-Daten pro Template abrufen. Ermitteln, welche Metrik wo durchfällt.
2. RUM einrichten mit der Bibliothek web-vitals , um das LCP-Element und die langsamsten Interaktionen zu erfassen.
3. Sicherstellen, dass Varnish (oder Fastly) auf Startseite, Kategorie- und Produktseiten Cache-Treffer liefert. Verirrte cacheable="false" -Blöcke entfernen.
4. Indexer auf „Update on Schedule“ stellen und routinemäßige vollständige Cache-Flushes beenden.
5. Top-URLs nach jedem Deployment aufwärmen.
6. Das LCP-Bild optimieren: kein Lazy Loading, fetchpriority="high", richtige Größe, wo möglich WebP.
7. JS- und CSS-Minifizierung aktivieren; JS-Merging deaktivieren; Bundling pro Seitentyp oder HTTP/2 ohne Bundling testen.
8. Drittanbieter-Skripte prüfen und verzögert laden.
9. Platz für spät ladende Elemente reservieren, um den CLS unter 0,1 zu bringen.
10. Bleibt der INP unter Luma nach diesen Schritten schlecht, eine Hyvä-Migration planen.
11. Nach 28 Tagen Felddaten erneut messen.

Häufig gestellte Fragen

Ist FID noch ein Core Web Vital?

Nein. INP hat FID am 12. März 2024 als Core Web Vital abgelöst. Wenn ein alter Bericht oder ein Tool noch FID anzeigt, verwenden Sie stattdessen INP.

Warum zeigt PageSpeed Insights einen guten Score, während die Search Console meldet, dass meine Seiten durchfallen?

Der Performance-Score stammt aus einem einzelnen Lighthouse-Labortest. Die Search Console nutzt CrUX-Felddaten echter Chrome-Nutzer über 28 Tage. Bei den Core Web Vitals zählen die Felddaten, und sie umfassen auch langsame Geräte und Netzwerke, die ein Labortest womöglich nicht abbildet.

Brauche ich Hyvä, um die Core Web Vitals mit Magento zu bestehen?

Nicht unbedingt. Viele Luma-Shops verbessern sich durch Arbeit an Caching, Bildern und Skripten erheblich. Eine Prüfung von Hyvä lohnt sich, wenn der INP aufgrund der JavaScript-Menge, die das Luma-Frontend und seine Extensions laden, schlecht bleibt.

Wie lange dauert es, bis Verbesserungen sichtbar werden?

CrUX nutzt ein gleitendes 28-Tage-Fenster, rechnen Sie also nach dem Deployment mit einer schrittweisen Verbesserung über etwa vier Wochen. RUM-Daten zeigen die Wirkung sofort.

Quellen

• https://web.dev/articles/vitals
• https://web.dev/articles/lcp
• https://web.dev/articles/inp
• https://web.dev/articles/cls
• https://web.dev/blog/inp-cwv-march-12
• https://web.dev/articles/optimize-lcp
• https://web.dev/articles/optimize-long-tasks
• https://developers.google.com/speed/docs/insights/v5/about
• https://developer.chrome.com/docs/crux/api
• https://github.com/GoogleChrome/web-vitals
• https://experienceleague.adobe.com/en/docs/commerce-operations/performance-best-practices/configuration
• https://experienceleague.adobe.com/en/docs/commerce-operations/performance-best-practices/concepts/advanced-js-bundling
• https://experienceleague.adobe.com/en/docs/commerce-operations/implementation-playbook/best-practices/development/optimize-css-js-files
• https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/varnish/configure-varnish-commerce
• https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/varnish/use-varnish-cache
• https://experienceleague.adobe.com/en/docs/commerce-on-cloud/user-guide/configure/env/stage/variables-post-deploy
• https://experienceleague.adobe.com/en/docs/commerce-on-cloud/user-guide/cdn/fastly-image-optimization
• https://www.hyva.io/blog/news/hyva-is-free-open-source.html