Offscreen-Bilder auf Mobilgeräten verzögern: Leitfaden für natives Lazy Loading

Bildverzögerung auf Mobilgeräten: Der Standard

Mobile Seiten kämpfen um begrenzte Verbindungen und begrenzte CPU-Ressourcen. Jedes Offscreen-Bild, das Sie vorab laden, stiehlt den Bildern und Skripten Bandbreite, die für den ersten Render-Vorgang (Paint) tatsächlich wichtig sind.

Zuletzt überprüft von Arjen Karel im März 2026

1. Offscreen-Bilder auf Mobilgeräten verzögern: natives Lazy Loading

Wenn ein Browser eine Seite lädt, öffnet er eine begrenzte Anzahl paralleler Verbindungen (abhängig von vielen Faktoren, aber 6 pro Domain sind ein üblicher Durchschnitt). Wenn diese Verbindungen zum Herunterladen von Offscreen-Bildern (z. B. einem Footer-Logo oder einem Carousel-Slide) verwendet werden, konkurriert der Download kritischer Ressourcen (typischerweise das LCP-Bild, wichtige Skripte und Schriftarten) um Slots und Bandbreite. Dies führt zu Netzwerkengpässen (Network Contention) und verschlechtert Ihre Core Web Vitals direkt.

Indem Sie Offscreen-Bilder mithilfe des nativen loading-Attributs verzögern, priorisieren Sie das Wesentliche. Der Browser ruft nur das ab, was sofort sichtbar ist, und reserviert Bandbreite für die Assets, die sich auf Largest Contentful Paint (LCP) und First Contentful Paint (FCP) auswirken. Natives Lazy Loading überträgt diese Priorisierung auf den browser-eigenen Mechanismus, was schneller ist und JavaScript-Bibliotheken für Lazy Loading überflüssig macht.

Implementierung

Fügen Sie für alle Bilder unterhalb des initialen Viewports ("the fold") das Attribut loading="lazy" hinzu.

<!-- Standardmäßig verzögertes Bild -->
<img src="product-detail.jpg"
     loading="lazy"
     alt="Seitenansicht des Gehäuses"
     width="800"
     height="600"
     decoding="async">

Die Attribute width und height sind unerlässlich. Ohne sie kann der Browser vor dem Laden des Bildes keinen Platz reservieren, was zu einem Cumulative Layout Shift (CLS) führt. Auf 62 % der mobilen Seiten fehlen nach wie vor explizite Abmessungen bei mindestens einem Bild.

Wie Lazy Loading auf Mobilgeräten funktioniert: Die Browser-Heuristik

Natives Lazy Loading ist JavaScript-Lösungen überlegen, da der Browser den Ladeschwellenwert (wann ein Bild zum Download ausgelöst wird) basierend auf dem Effective Connection Type (ECT) anpasst.

• Bei 4G/WiFi: Die Blink-Engine (Chrome/Edge) verwendet einen konservativen Schwellenwert von etwa 1.250px. Sie geht von einer geringen Latenz aus und ruft das Bild erst ab, wenn der Benutzer relativ nah heran scrollt.
• Bei 3G/Slow-2G: Der Schwellenwert erweitert sich auf etwa 2.500px. Der Browser startet die Anfrage viel früher, um hohe Round-Trip-Zeiten zu kompensieren, sodass das Bild bereit ist, bevor der Benutzer es in den sichtbaren Bereich scrollt.

Laut dem Web Almanac 2025 lädt die mittlere mobile Seite 15 Bilder mit insgesamt 911 KB. Nur etwa 26 % dieser Bilder verwenden loading="lazy". Der Rest wird "eager" (sofort) geladen und konkurriert um dieselben begrenzten Verbindungen. Bei einer typischen mobilen 4G-Verbindung bedeutet dies, dass das LCP-Bild in der Warteschlange hinter einem Dutzend Bildern festhängt, die der Benutzer für mehrere Sekunden nicht sehen wird.

Kritische Ausnahme: Der LCP-Kandidat

Eine häufige Performance-Regression: Die Anwendung von loading="lazy" auf das Largest Contentful Paint-Element (typischerweise das Hero-Bild). Dies verzögert den Abruf, bis das Layout abgeschlossen ist.

Untersuchungen von Google zeigen, dass das Lazy-Loading des LCP-Bildes dem medianen LCP 624ms hinzufügt. Das ist kein theoretisches Risiko. 17 % der mobilen Seiten machen laut dem Web Almanac 2025 immer noch diesen Fehler. Wenn Lighthouse dies meldet, lesen Sie, wie Sie die Warnung zum verzögert geladenen LCP beheben.

Das LCP-Bild muss "eager" (sofort) geladen und priorisiert werden:

<!-- Hero-Bild: Eager und Priorisiert -->
<img src="hero.jpg"
     alt="Sommerkollektion"
     width="1200"
     height="800"
     loading="eager"
     fetchpriority="high">

Kombinieren Sie loading="lazy" nicht mit fetchpriority="high". Sie widersprechen sich: "lazy" sagt dem Browser, er soll warten, "high" sagt ihm, er soll sich beeilen. Der Browser ignoriert den Prioritätshinweis, wenn "lazy" gesetzt ist. Weitere Informationen dazu, wie Browser Ressourcen priorisieren, finden Sie im Leitfaden zur Ressourcenpriorisierung.

2. Mobile Komplexitäten: Viewport und Touch

Mobile Viewports sind nicht statisch. Der sichtbare Bereich ändert sich, wenn der Benutzer scrollt, das Gerät dreht oder das Einfahren der URL-Leiste auslöst. Hier hat natives Lazy Loading einen echten Vorteil gegenüber JavaScript-Lösungen.

Der dynamische Viewport

Bei mobilen Browsern ist die Viewport-Höhe (vh) fließend. Wenn der Benutzer ein Touch-Scrollen einleitet, fahren die URL-Leiste und die Navigationssteuerelemente oft ein, wodurch sich die Größe des sichtbaren Bereichs ändert.

JavaScript-Bibliotheken für Lazy Loading berechnen die Viewport-Höhe (window.innerHeight) typischerweise einmal beim Laden der Seite. Wenn mobile Browser den sichtbaren Bereich dynamisch in der Größe ändern, indem sie die URL-Leiste während eines Scrollvorgangs ausblenden, verwenden JavaScript-Methoden weiterhin den alten, kleineren Höhenwert. Bilder bleiben ungeladen, selbst wenn sie in den erweiterten Viewport gelangen, was zu leeren Platzhaltern für die Besucher führt.

Die interne Layout-Engine des Browsers verfolgt den visuellen Viewport automatisch, sodass native Lazy-Loading-Auslöser unabhängig von Änderungen der Viewport-Größe ausgelöst werden. Dies ist ein Grund, natives Lazy Loading gegenüber jeder JavaScript-Alternative zu bevorzugen.

3. Mobile Bilddekodierung und CPU-Drosselung

Mobilgeräte verfügen über eine begrenzte CPU und die Bilddekodierung auf Mobilgeräten kann relativ langsam und teuer sein. Die Konvertierung eines JPEG in eine Bitmap erfordert viele CPU-Zyklen. Auf einem mobilen Prozessor kann die Dekodierung einer Sequenz größerer Bilder den Main Thread für jeweils 50ms bis 100ms blockieren, was zu Eingabelatenzen führt.

Die Lösung: content-visibility

Die CSS-Eigenschaft content-visibility: auto wirkt als Lazy Rendering. Sie weist den Browser an, die Layout- und Painting-Phasen für Offscreen-Elemente vollständig zu umgehen. Das Element existiert im DOM, aber es existiert nicht im Render Tree, bis es sich dem Viewport nähert.

Da diese Optimierung durch das Überspringen des Renderings des Subtrees eines Elements funktioniert, können Sie sie nicht direkt auf ein <img>-Tag anwenden (welches keinen Subtree hat). Wenden Sie content-visibility auf den Produkt-Container oder die Image-Card an, die die Bilder und deren Inhalt hosten:

@media (max-width: 768px) {
    .image-card, .product-card {
        /* Überspringe das Rendering des Containers und seiner untergeordneten Elemente */
        content-visibility: auto;

        /* Unerlässlich: Verhindert, dass der Container auf 0px Höhe kollabiert */
        contain-intrinsic-size: auto 300px;
    }
}

Dies stellt sicher, dass der Browser die Layout-/Paint-Kosten erst trägt, wenn der Benutzer tatsächlich dorthin scrollt, selbst wenn ein Bild heruntergeladen wurde.

content-visibility erreichte im September 2024 den Baseline-Status, als Safari 18 den Support auslieferte. Es funktioniert nun in 93 % der Browser weltweit. Die Benchmarks von Google zeigen eine 7-fache Steigerung der Rendering-Performance beim initialen Laden von Seiten mit vielen Offscreen-Bereichen.

Wenn Sie die Rendering-Verbesserung auf echten Geräten überprüfen möchten, zeigt Ihnen Real User Monitoring die tatsächlichen Auswirkungen auf INP und LCP in Ihrem gesamten mobilen Traffic. Auf Websites, die von CoreDash überwacht werden, weisen Seiten, die content-visibility: auto in Produkt-Grids verwenden, auf Mobilgeräten einen um etwa 15 % besseren INP auf als Seiten ohne diese Eigenschaft.

4. Veraltete Methoden: Warum man sie vermeiden sollte

Bevor loading="lazy" Browser-Support erhielt, war JavaScript die einzige Option. Angesichts der Tatsache, dass natives Lazy Loading weltweit zu 95 % unterstützt wird, sind diese JavaScript-Methoden technische Schulden. Entfernen Sie sie.

Die Ära der Scroll-Handler (2010 bis 2016)

Frühe Implementierungen haben Event-Listener an das Scroll-Event angehängt.

// Veraltet: nicht verwenden
window.addEventListener('scroll', () => {
    images.forEach(img => {
        if (img.getBoundingClientRect().top < window.innerHeight) {
            img.src = img.dataset.src;
        }
    });
});

Blockierung des Main Threads: Das Scroll-Event wird Dutzende Male pro Sekunde ausgelöst. Die Ausführung von Logik und die Berechnung des Layouts (getBoundingClientRect) während des aktiven Scrollens verursacht Frame Drops (Jank).

Layout Thrashing: Das Abfragen geometrischer Eigenschaften zwingt den Browser, das Layout synchron neu zu berechnen, eine rechenintensive Operation auf mobilen CPUs.

Die Ära des IntersectionObserver (2016 bis 2019)

Die IntersectionObserver-API verbesserte die Performance durch die asynchrone Beobachtung von Änderungen in der Element-Sichtbarkeit.

// Veraltet: natives loading="lazy" bevorzugen, wo möglich
const observer = new IntersectionObserver((entries) => {
    entries.forEach(entry => {
        if (entry.isIntersecting) {
            const img = entry.target;
            img.src = img.dataset.src;
            observer.unobserve(img);
        }
    });
});

Skript-Abhängigkeit: Es erfordert die Ausführung von JavaScript. Wenn der Main Thread mit dem Hydratisieren eines Frameworks (React/Vue) beschäftigt ist, bleiben die Bilder ungeladen, selbst wenn sie sich im Viewport befinden.

Mangelndes Netzwerkbewusstsein (Network Awareness): Im Gegensatz zum nativen Laden verwendet der IntersectionObserver feste Ränder (z. B. rootMargin: '200px'). Er erweitert seinen Puffer in langsamen Netzwerken nicht automatisch, was bei Benutzern mit schlechten Verbindungen zu weißen Blitzern (Blank Flashes) führt.

Für einen vollständigen Überblick über Bildoptimierungstechniken über Lazy Loading hinaus oder um mehr über das Verzögern von CSS-Hintergrundbildern zu erfahren (was loading="lazy" nicht abdeckt), lesen Sie diese speziellen Leitfäden.