Core Web Vitals Verbesserung in der Praxis — LCP von 3 Sekunden auf 1,2 Sekunden reduziert

Kernzusammenfassung

• LCP (Largest Contentful Paint) ist ein entscheidender Indikator, der direkt das Google-Ranking beeinflusst.
• Durch die schrittweise Anwendung von Bildoptimierung, Schriftarten-Lade-Strategien und Code-Splitting wurde LCP von 3,0 Sekunden auf 1,2 Sekunden verkürzt.
• CLS wurde durch die Angabe expliziter Größen für Bild- und Werbebereiche und die Beseitigung von Layoutänderungen von 0,28 auf 0,04 gesenkt.
• Dies basiert auf einem realen Produktionsprojekt mit Next.js, die gleichen Prinzipien können auch auf React- und Vue-Projekte angewendet werden.

Einleitung — Warum Core Web Vitals?

Im Jahr 2021 hat Google mit dem Page Experience Update die Core Web Vitals über einfache UX-Indikatoren hinaus als Rankingfaktor für SEO etabliert. Seitdem hat Google kontinuierlich das Gewicht dieses Signals erhöht, und bis 2024 wird INP (Interaction to Next Paint) FID vollständig ersetzen, wodurch sich die Bewertungsparameter weiterentwickelt haben.

Das E-Commerce-Projekt, das ich betreibe, hatte vor einem halben Jahr noch eine katastrophale Bewertung von 38 Punkten in PageSpeed Insights für mobile Geräte. LCP betrug 3,0 Sekunden, CLS 0,28 und INP 320 ms — alle drei Indikatoren lagen im Bereich "Verbesserung erforderlich". Ich dokumentiere den gesamten Prozess, wie ich diese Werte verändert habe.

Wie versteht man die drei Core Web Vitals schnell?

LCP — Die "Erstkontakt"-Geschwindigkeit der Seite

LCP ist die Zeit, die benötigt wird, um das größte Inhaltselement (in der Regel ein Hero-Bild oder H1-Text) im Viewport zu rendern. Laut Google ist unter 2,5 Sekunden gut, über 4,0 Sekunden schlecht.

Auf E-Commerce-Websites ist es überwiegend das Hero-Banner-Bild, das das LCP-Ziel darstellt. Wenn dieses Bild nicht rechtzeitig geladen wird, sind alle anderen Optimierungen bedeutungslos.

CLS — Springt das Layout nicht "plötzlich"?

CLS (Cumulative Layout Shift) misst, wie stark sich Elemente während des Ladevorgangs der Seite unerwartet bewegen. Wenn Werbebanner verspätet eingefügt werden oder Bilder ohne Größenangabe spät geladen werden, steigt der Wert. Unter 0,1 ist der gute Standard.

INP — Wie schnell reagiert die Seite auf Benutzereingaben?

INP misst die Verzögerung der Antwort auf alle Interaktionen wie Klicks, Taps und Tastatureingaben. Es hat FID im März 2024 ersetzt, und unter 200 ms ist der gute Standard. Je schwerer das JavaScript-Bundle, desto mehr wird der Hauptthread blockiert, was INP verschlechtert.

Problemdiagnose — Erste Messungsergebnisse

Der Ausgangspunkt ist die genaue Aufzeichnung der Indikatoren vor der Optimierung. Ich habe die folgenden Tools in der Reihenfolge verwendet:

1. 1PageSpeed Insights — Bereitstellung von Felddaten (echte Benutzerdaten) und Labordaten (Lighthouse) gleichzeitig
2. 2Chrome DevTools > Performance-Tab — Überprüfung der Rendering-Zeitleiste und der LCP-Kandidaten
3. 3WebPageTest — Messung basierend auf dem nationalen CDN-Edge-Server, visuelle Überprüfung mit Filmstreifen
4. 4Vercel Analytics / Sentry — Sammlung von Core Web Vitals basierend auf echten Benutzersitzungen

Die Diagnose ergab, dass die Engpässe auf drei Bereiche eingegrenzt werden konnten.

• Hero-Bild — 4,2 MB JPEG, direkt ohne Optimierung mit -Tag eingefügt
• Google Fonts — Synchrones Laden von 3 Schriftartenfamilien mit @import
• Bundle-Größe — Hauptchunk 1,8 MB, viele nicht getroffene Bibliotheken enthalten

Wie wurde LCP von 3,0 Sekunden auf 1,2 Sekunden reduziert?

Methode 1 — Bildoptimierung und Preload

Dies hatte den größten Effekt. Ich habe die Handhabung des Hero-Bildes vollständig geändert.

Vorher

<img src="/banner.jpg" alt="Hauptbanner" />

Nachher — Next.js Image-Komponente + WebP-Konvertierung

import Image from 'next/image';

<Image
  src="/banner.webp"
  alt="Hauptbanner"
  width={1920}
  height={800}
  priority          // LCP-Zielbild muss unbedingt priorisiert werden
  quality={80}
  sizes="(max-width: 768px) 100vw, 1920px"
/>

Durch das Hinzufügen des priority-Props fügt Next.js automatisch das -Tag für dieses Bild hinzu. Nach der WebP-Konvertierung reduzierte sich die Dateigröße von 4,2 MB auf etwa 340 KB, was einer Reduzierung von 92 % entspricht.

In einem reinen HTML/React-Projekt müsste das Preload-Tag direkt im hinzugefügt werden.

<link
  rel="preload"
  as="image"
  href="/banner.webp"
  type="image/webp"
/>

Mit dieser einzigen Maßnahme fiel der LCP von 3,0 Sekunden auf 1,8 Sekunden.

Methode 2 — Änderung der Schriftarten-Lade-Strategie

Wenn Google Fonts über @import geladen werden, stoppt der Browser beim Parsen des CSS und sendet die Schriftanfrage. Diese Wartezeit erhöht den LCP erheblich.

Vorher

<style>
  @import url('https://fonts.googleapis.com/css2?family=Noto+Sans+KR:wght@400;700&display=swap');
</style>

Nachher — + display=swap + Selbsthosting

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link
  rel="stylesheet"
  href="https://fonts.googleapis.com/css2?family=Noto+Sans+KR:wght@400;700&display=swap"
/>

Darüber hinaus kann die Verwendung von next/font (Next.js 13+) die Schriftarten zur Build-Zeit selbst hosten, wodurch externe Anfragen vollständig entfallen.

// app/layout.js
import { Noto_Sans_KR } from 'next/font/google';

const notoSansKR = Noto_Sans_KR({
  weight: ['400', '700'],
  subsets: ['latin'],
  display: 'swap',
});

Nach der Schriftartenverbesserung fiel der LCP von 1,8 Sekunden auf 1,5 Sekunden.

Methode 3 — Code-Splitting und Bundle-Optimierung

Wenn das Haupt-JS-Bundle groß ist, wird der Hauptthread des Browsers mit dem Parsen und Ausführen blockiert. Während dieser Zeit wird das LCP-Element nicht auf dem Bildschirm angezeigt.

Dynamisches Importieren zur Trennung des Anfangsbundles

import dynamic from 'next/dynamic';

// Schwerer Diagrammkomponenten, die unterhalb des Scrollbereichs liegt
const SalesChart = dynamic(() => import('@/components/SalesChart'), {
  ssr: false,
  loading: () => <div className="chart-skeleton" />, 
});

Bundle-Analyse zur Entfernung unnötiger Bibliotheken

npx @next/bundle-analyzer

Die Analyse ergab, dass moment.js (66 KB gzip) und die gesamte lodash-Bibliothek (70 KB gzip) enthalten waren. moment wurde durch individuelle Importe der benötigten Funktionen von date-fns ersetzt, und lodash wurde auf die Tree-Shaking-Importe von lodash-es umgestellt.

// Vorher
import _ from 'lodash';
const result = _.groupBy(data, 'category');

// Nachher
import { groupBy } from 'lodash-es';
const result = groupBy(data, 'category');

Das Hauptbundle reduzierte sich von 1,8 MB auf 420 KB, und der LCP fiel von 1,5 Sekunden auf 1,2 Sekunden.

CLS von 0,28 auf 0,04 senken

Die Hauptursachen für Layoutverschiebungen waren zwei Bereiche.

1. Nicht spezifizierte Bildgrößen

Für alle -Tags wurden width und height angegeben oder das aspect-ratio-CSS fixiert.

.product-image-wrapper {
  aspect-ratio: 4 / 3;
  overflow: hidden;
}

2. Verspätet eingefügte Werbebanner

Vor dem Laden des Werbeslots wurde ein Platzhalter mit derselben Höhe reserviert.

<div style={{ minHeight: '90px' }}>
  <AdBanner slot="header" />
</div>

Mit diesen beiden Maßnahmen sank der CLS von 0,28 auf 0,04.

Verbesserung von INP — Belastung des Hauptthreads reduzieren

INP verbesserte sich nach der Gewichtsreduzierung des Bundles von 320 ms auf 140 ms. Zusätzlich wurde der Teil, der schwere Berechnungen synchron im Klick-Event-Handler ausführte, mit requestIdleCallback verschoben.

button.addEventListener('click', () => {
  // Sofort erforderliches UI-Update
  setLoading(true);

  // Schwere Verarbeitung auf Leerlaufzeit verschieben
  requestIdleCallback(() => {
    processHeavyData(payload);
  });
});

Vergleich vor und nach der Optimierung