Bilder außerhalb des Viewports auf Mobilgeräten verzögern: Leitfaden für natives lazy loading

Bilder auf Mobilgeräten verzögern: der Standard

Mobile Seiten kämpfen mit begrenzten Verbindungen und knapper CPU. Jedes Bild außerhalb des Viewports, das du vorab lädst, stiehlt Bandbreite von Bildern und Skripten, die für den ersten Paint wirklich zählen.

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

1. Bilder außerhalb des Viewports auf Mobilgeräten verzögern: natives lazy loading

Wenn ein Browser eine Seite lädt, öffnet er eine begrenzte Anzahl paralleler Verbindungen (das hängt von vielen Faktoren ab, im Schnitt sind es 6 pro Domain). Werden diese Verbindungen genutzt, um Bilder außerhalb des Viewports herunterzuladen (z. B. ein Footer-Logo oder ein Carousel-Slide), konkurriert der Download kritischer Ressourcen (typischerweise das LCP-Bild, wichtige Skripte und Schriftarten) um freie Slots und Bandbreite. Das führt zu Network Contention und verschlechtert deine Core Web Vitals direkt.

Indem du Bilder außerhalb des Viewports über das native loading-Attribut verzögerst, setzt du klare Prioritäten. Der Browser lädt nur herunter, was sofort sichtbar ist. So bleibt Bandbreite für Ressourcen frei, die den Largest Contentful Paint (LCP) und First Contentful Paint (FCP) beeinflussen. Natives lazy loading überträgt diese Priorisierung direkt an den Browser. Das ist schneller und macht JavaScript-Bibliotheken für lazy loading überflüssig.

Implementierung

Setze bei allen Bildern unterhalb des initialen Viewports („the fold“) das Attribut loading="lazy" ein.

<!-- Standard Deferred Image -->
<img src="product-detail.jpg"
     loading="lazy"
     alt="Side view of the chassis"
     width="800"
     height="600"
     decoding="async">

Die Attribute width und height sind unverzichtbar. Ohne sie kann der Browser vor dem Laden des Bildes keinen Platz reservieren. Das verursacht Layout-Verschiebungen (CLS). 62 % der mobilen Seiten definieren bei mindestens einem Bild nach wie vor keine expliziten Abmessungen.

Wie lazy loading auf Mobilgeräten funktioniert: die Browser-Heuristik

Natives lazy loading ist JavaScript-Lösungen überlegen, weil der Browser den Ladeschwellenwert (wann der Download eines Bildes startet) anhand des effektiven Verbindungstyps (ECT) anpasst.

• Unter 4G/WLAN: Die Blink-Engine (Chrome/Edge) nutzt einen konservativen Schwellenwert von rund 1.250 px. Sie geht von geringer Latenz aus und lädt das Bild erst, wenn der Nutzer relativ nah heranscrollt.
• Unter 3G/Slow-2G: Der Schwellenwert erweitert sich auf etwa 2.500 px. Der Browser startet den Request deutlich früher, um hohe Round-Trip-Zeiten auszugleichen. So ist das Bild bereit, bevor der Nutzer es in den Viewport scrollt.

Laut dem Web Almanac 2025 lädt eine mobile Seite im Median 15 Bilder mit insgesamt 911 KB. Nur rund 26 % dieser Bilder nutzen loading="lazy". Der Rest lädt eager und konkurriert um dieselben begrenzten Verbindungen. Auf einer typischen mobilen 4G-Verbindung bedeutet das: Das LCP-Bild hängt in der Warteschlange fest – hinter einem Dutzend Bildern, die der Nutzer erst Sekunden später sieht.

Kritische Ausnahme: der LCP-Kandidat

Ein häufiger Performance-Rückschritt: loading="lazy" auf das Largest Contentful Paint-Element anzuwenden (typischerweise das Hero-Bild). Das verzögert den Abruf, bis das Layout komplett berechnet ist.

Analysen von Google zeigen, dass lazy loading beim LCP-Bild den LCP im Median um 624 ms verschlechtert. Das ist kein theoretisches Risiko: Laut dem Web Almanac 2025 machen 17 % der mobilen Seiten immer noch diesen Fehler. Falls Lighthouse das meldet, lies hier nach, wie du die Warnung zu lazy geladenen LCP-Bildern behebst.

Das LCP-Bild muss eager geladen und priorisiert werden:

<!-- Hero Image: Eager and Prioritized -->
<img src="hero.jpg"
     alt="Summer Collection"
     width="1200"
     height="800"
     loading="eager"
     fetchpriority="high">

Kombiniere loading="lazy" nicht mit fetchpriority="high". Sie widersprechen sich: lazy weist den Browser an zu warten, high fordert Eile. Ist lazy gesetzt, ignoriert der Browser den Prioritätshinweis. Mehr dazu, wie Browser Ressourcen priorisieren, erfährst du im Guide zur Ressourcen-Priorisierung.

2. Mobile Besonderheiten: Viewport und Touch

Mobile Viewports sind nicht statisch. Der sichtbare Bereich ändert sich, wenn der Nutzer scrollt, das Gerät dreht oder die Adressleiste ein- und ausklappt. Hier hat natives lazy loading einen echten Vorteil gegenüber JavaScript-Lösungen.

Der dynamische Viewport

In mobilen Browsern ist die Viewport-Höhe (vh) variabel. Sobald der Nutzer scrollt, klappen URL-Leiste und Navigationselemente oft ein, was die Größe des sichtbaren Bereichs verändert.

JavaScript-Bibliotheken für lazy loading berechnen die Viewport-Höhe (window.innerHeight) typischerweise nur einmal beim Laden der Seite. Wenn mobile Browser den sichtbaren Bereich beim Scrollen durch das Ausblenden der Adressleiste dynamisch vergrößern, nutzen JavaScript-Methoden weiterhin den alten, kleineren Wert. Bilder bleiben ungeladen, selbst wenn sie bereits in den vergrößerten Viewport rücken – für Besucher entstehen leere Platzhalter.

Die browserinterne Layout-Engine verfolgt den visuellen Viewport automatisch, sodass Trigger für natives lazy loading unabhängig von Änderungen der Viewport-Größe feuern. Das ist ein wichtiger Grund, natives lazy loading jeder JavaScript-Alternative vorzuziehen.

3. Bilddekodierung und CPU-Throttling auf Mobilgeräten

Mobilgeräte haben begrenzte CPU-Kapazitäten. Das Dekodieren von Bildern kann dort relativ langsam und teuer sein. Ein JPEG in eine Bitmap umzuwandeln, kostet viele CPU-Zyklen. Auf einem mobilen Prozessor kann das Dekodieren mehrerer großer Bilder den main thread für jeweils 50 ms bis 100 ms blockieren und Input-Latenz verursachen.

Die Lösung: content-visibility

Die CSS-Eigenschaft content-visibility: auto wirkt wie lazy rendering. Sie weist den Browser an, die Layout- und Paint-Phasen für Elemente außerhalb des Viewports komplett zu überspringen. Das Element existiert im DOM, taucht aber erst im Render Tree auf, wenn es sich dem Viewport nähert.

Da diese Optimierung das Rendern des Subtrees eines Elements überspringt, kannst du sie nicht direkt auf ein <img>-Tag anwenden (dieses hat keinen Subtree). Wende content-visibility auf den Produkt-Container oder die Image Card an, die das Bild und seine Inhalte umschließt:

@media (max-width: 768px) {
    .image-card, .product-card {
        /* Skip rendering of the container and its children */
        content-visibility: auto;

        /* Essential: Prevents container from collapsing to 0px height */
        contain-intrinsic-size: auto 300px;
    }
}

Das stellt sicher, dass der Browser selbst bei bereits heruntergeladenen Bildern die Layout- und Paint-Kosten erst zahlt, wenn der Nutzer tatsächlich dorthin scrollt.

content-visibility erreichte im September 2024 den Baseline-Status, als Safari 18 die Unterstützung lieferte. Die Eigenschaft wird mittlerweile von 93 % aller Browser weltweit unterstützt. Googles Benchmarks zeigen beim initialen Laden einen 7-fachen Schub bei der Rendering-Performance für Seiten mit vielen Abschnitten außerhalb des Viewports.

Wenn du die Rendering-Verbesserung auf echten Geräten überprüfen willst, zeigt dir Real User Monitoring die tatsächlichen Auswirkungen auf INP und LCP über deinen gesamten mobilen Traffic. Bei Websites, die von CoreDash überwacht werden, weisen Seiten mit content-visibility: auto auf Produkt-Grids einen rund 15 % besseren mobilen INP auf als Seiten ohne diese Eigenschaft.

4. Veraltete Methoden: Warum du sie meiden solltest

Bevor Browser loading="lazy" unterstützten, war JavaScript die einzige Option. Bei einer weltweiten Browser-Unterstützung von 95 % für natives lazy loading sind diese JavaScript-Methoden heute technische Schulden. Entferne sie.

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

Frühe Implementierungen banden Event-Listener an das Scroll-Event.

// Obsolete: do not use
window.addEventListener('scroll', () => {
    images.forEach(img => {
        if (img.getBoundingClientRect().top < window.innerHeight) {
            img.src = img.dataset.src;
        }
    });
});

Main-Thread-Blockierung: Das Scroll-Event feuert dutzende Male pro Sekunde. Wer beim aktiven Scrollen Logik ausführt und das Layout berechnet (getBoundingClientRect), verursacht Frame Drops (Jank).

Layout Thrashing: Das Abfragen geometrischer Eigenschaften zwingt den Browser zu synchronen Layout-Neuberechnungen – ein rechenintensiver Vorgang auf mobilen CPUs.

Die IntersectionObserver-Ära (2016 bis 2019)

Die IntersectionObserver-API verbesserte die Performance, indem sie Änderungen der Elementsichtbarkeit asynchron beobachtet.

// Legacy: prefer native loading="lazy" where possible
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: Dieser Ansatz erfordert JavaScript-Ausführung. Ist der main thread damit beschäftigt, ein Framework (React/Vue) zu hydrieren, bleiben die Bilder ungeladen – selbst wenn sie sich bereits im Viewport befinden.

Fehlende Netzwerkerkennung: Anders als natives lazy loading arbeitet der IntersectionObserver mit festen Abständen (z. B. rootMargin: '200px'). Bei langsamen Netzwerken erweitert er diesen Puffer nicht automatisch, was bei Nutzern mit schlechter Verbindung zu kurz aufblitzenden Leerstellen führt.

Einen vollständigen Überblick über Techniken zur Bildoptimierung jenseits von lazy loading sowie Anleitungen zum Verzögern von CSS-Hintergrundbildern (die loading="lazy" nicht abdeckt) findest du in unseren weiterführenden Guides.