Sie haben einen Preload für das Hero-Bild gesetzt, wie es jeder Leitfaden empfiehlt. Auf dem Desktop hat sich der Largest Contentful Paint verbessert. Auf Mobilgeräten nicht, und PageSpeed warnt jetzt, dass ein per Preload geladenes Bild nicht verwendet wurde, oder das Netzwerk-Panel zeigt den Hero zweimal heruntergeladen.
Der Preload an sich ist nicht falsch. Er zielt auf ein Gerät, und das andere Gerät zahlt dafür.
Warum sich das LCP-Bild mit dem Bildschirm ändert
- Unterschiedliche Layouts: Auf dem Desktop ist das Hero-Bild das größte Element; auf einem Smartphone nimmt der Titel oder ein Bild weiter unten in der Spalte seinen Platz ein.
- Duplizierte Abschnitte: Page Builder zeigen oft einen Abschnitt auf dem Desktop und einen anderen auf Mobilgeräten, jeder mit eigenem Bild, der jeweils andere versteckt.
- Art Direction: eine zugeschnittene Hochformat-Version des Heros für Smartphones.
- Gleiches Bild, andere Größe: eine Datei in mehreren Breiten, wobei das Smartphone eine kleine herunterladen sollte.
- Ein Hintergrundbild: Wenn der Hero ein CSS-Hintergrund ist, entdeckt der Browser ihn noch später, ein Fall, den unser Leitfaden zu Hero-Bereichen mit Hintergrundbild behandelt.
Das LCP-Element auf jedem Gerät finden
Führen Sie PageSpeed für Mobil und Desktop aus und öffnen Sie in jedem Tab die Diagnose „Largest Contentful Paint-Element“. Oder zeichnen Sie im Performance-Panel der DevTools mit mobiler Emulation auf: Die LCP-Markierung benennt das Element. Machen Sie das für beide Größen; nehmen Sie nichts an.
new PerformanceObserver(l => {
const e = l.getEntries().at(-1);
console.log('LCP', Math.round(e.startTime), e.element, e.url);
}).observe({ type: 'largest-contentful-paint', buffered: true });Die vier Fehler, die den Preload verschwenden
1. Ein Preload für alle. Der Desktop-Hero wird für alle Besucher per Preload geladen. Smartphones laden ein großes Bild herunter, das sie nie anzeigen, mit hoher Priorität, in Konkurrenz zu ihrem echten LCP. Signatur: die Warnung „per Preload geladen, aber nicht verwendet“ auf Mobilgeräten.
2. Ein Preload ohne das srcset des Bildes. Der Preload zeigt auf eine Datei, während das <img> eine andere Breite aus seinem srcset wählt. Der Browser lädt beide herunter. Signatur: dasselbe Bild zweimal im Netzwerk-Panel, in zwei Größen.
3. Ein Preload vor dem Viewport-Tag. Bis der Browser <meta name="viewport"> liest, legt ein Smartphone die Seite so an, als wäre sie etwa 980 Pixel breit. Ein responsiver Preload, der vor diesem Tag gelesen wird, wird für diese Breite aufgelöst, also holt das Smartphone erst einen zu großen Kandidaten und dann den richtigen. Signatur: ein doppelter Download, nur auf Mobilgeräten.
4. Das LCP-Bild wird per Lazy Loading geladen. Ein loading="lazy" am Hero, oft von einem Theme oder Plugin jedem Bild hinzugefügt, sagt dem Browser, mit dem Laden bis zum Layout zu warten. Signatur: Die Bildanfrage startet spät, nach den Stylesheets.
Die Lösung, Fall für Fall
Unterschiedliches Bild pro Gerät. Je ein Preload, aufgeteilt durch eine Media Query, die dem Breakpoint Ihres Themes entspricht:
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="preload" as="image" href="/uploads/hero-mobile.webp"
media="(max-width: 768px)" fetchpriority="high">
<link rel="preload" as="image" href="/uploads/hero-desktop.webp"
media="(min-width: 769px)" fetchpriority="high">Gleiches Bild, mehrere Breiten. Ein Preload, der das srcset des Bildes als imagesrcset und seine sizes als imagesizes wiederholt, Zeichen für Zeichen, damit der Browser zweimal denselben Kandidaten wählt und ihn einmal herunterlädt. Sind die sizes des Bildes schon von vornherein falsch, korrigieren Sie sie zuerst: unser Leitfaden zu srcset und sizes erklärt, wie.
<link rel="preload" as="image" fetchpriority="high"
imagesrcset="/uploads/hero-480.webp 480w, /uploads/hero-960.webp 960w, /uploads/hero-1920.webp 1920w"
imagesizes="100vw">Am Bild selbst. Entfernen Sie loading="lazy", fügen Sie fetchpriority="high" hinzu und behalten Sie seine Attribute width und height.
Duplizierte Builder-Abschnitte. Die versteckte Variante sollte gar nicht heruntergeladen werden. Ein verstecktes Bild mit loading="lazy" wird nie geladen; ohne das Attribut schon, bei jedem Besuch.
Das Ergebnis prüfen
- Netzwerk-Panel, mobile Emulation, Cache deaktiviert: Der Hero erscheint einmal, früh, in der erwarteten Breite.
- Dasselbe auf dem Desktop.
- Keine Warnung „per Preload geladen, aber nicht verwendet“ in keinem der beiden PageSpeed-Tabs.
- Mehrere Läufe pro Gerät, per Median verglichen, wie in unserem Leitfaden zu Labor- und Felddaten erklärt.
Mit Mantys Core
Mantys Core kann Ihre gesamte Performance-Schicht übernehmen, Cache inklusive, oder neben Ihrem bestehenden Setup laufen. Beim LCP-Bild misst es, statt zu raten:
Das LCP-Bild wird aus echten Renderings jeder Seite erfasst, auf Mobil und Desktop, in den Größen, die der Speedtest verwendet.
Unterscheiden sich die beiden, erzeugt es einen Preload pro Gerät; sind sie gleich, einen einzigen Preload, der das endgültige srcset und die sizes des Bildes übernimmt.
Preloads tragen hohe Fetch-Priorität und werden direkt nach dem Viewport-Tag platziert, vor den Stylesheets.
Bilder im sichtbaren Bereich beim Laden werden nie per Lazy Loading geladen.
Der Preload folgt der Seite, Seite für Seite und Gerät für Gerät, ohne dass Sie eine Liste von Heros pflegen müssen.
Zusammenfassung
- Das LCP-Element unterscheidet sich oft zwischen Smartphone und Desktop: Prüfen Sie beide.
- Ein einziger Preload lässt ein Gerät ein Bild herunterladen, das es nicht anzeigt.
- Verwenden Sie einen Preload pro Gerät oder einen Preload mit demselben srcset und denselben sizes wie das Bild.
- Platzieren Sie ihn direkt nach dem Viewport-Tag und laden Sie das LCP-Bild nie per Lazy Loading.
- Prüfen Sie im Netzwerk-Panel, dass der Hero auf jedem Gerät nur einmal heruntergeladen wird.
Kommentare
Hängen Sie an einem ähnlichen Problem? Beschreiben Sie Ihr Setup und was Sie beobachten. Wir lesen jeden Kommentar und antworten.
Noch keine Kommentare. Teilen Sie als Erste oder Erster Ihren Fall.