Der Browser ist ein sehr gehorsamer Mitarbeiter. Er arbeitet die Einkaufsliste ab, die Du ihm gibst, und zwar streng von oben nach unten. Steht das Analyse-Skript vor dem Text, lädt er erst das Skript. Der Besucher schaut so lange auf eine weiße Seite. Nicht weil die Leitung langsam wäre, sondern weil niemand dem Browser gesagt hat, was wirklich zuerst gebraucht wird.
Die zwei Erfolgskriterien von Guideline 3.7
Asynchroner Code: Lade nicht essenzielle externe Ressourcen asynchron oder verzögert, um Darstellungsprobleme zu vermeiden, etwa kurz aufblitzende unformatierte Inhalte (FOUC), unsichtbaren Text (FOIT) oder ersatzweise dargestellte Schrift (FOFT).
Optimiertes Laden: Nutze Resource Hints und Priority Hints, um das Ladeverhalten zu verbessern, wenn mehrere Ressourcen um Bandbreite oder Rendering-Reihenfolge konkurrieren.
Meine Einordnung
Beide Kriterien oben drehen sich um dieselbe Frage: Was muss jetzt da sein, und was kann warten? Das erste Kriterium beantwortet sie mit einem Aufschub, das zweite mit einer Rangfolge. Zusammen bestimmen sie, wie schnell ein Besucher etwas Nutzbares sieht.
Und genau das misst Google. Der Largest Contentful Paint, eine der drei Core Web Vitals, erfasst den Moment, in dem das größte sichtbare Element fertig geladen ist. Jede blockierende Datei im Kopfbereich schiebt diesen Moment nach hinten, egal ob sie für die erste Bildschirmseite gebraucht wird oder nicht. Wer nicht kritische Ressourcen verzögert, verbessert also nicht nur die gefühlte Geschwindigkeit, sondern eine Kennzahl, die direkt in die Suchbewertung einfließt. Nachhaltigkeit und Sichtbarkeit zeigen hier ausnahmsweise in dieselbe Richtung.
Auf datensm.art wende ich das konsequent an: Matomo lädt verzögert, Bilder unterhalb des sichtbaren Bereichs erst beim Heranscrollen, und der Podcast-Player kommt ausschließlich auf den Seiten zum Einsatz, die ihn wirklich brauchen. Das Ergebnis ist nicht spektakulär, sondern unauffällig, und genau das ist der Punkt: Der Besucher merkt nichts von den Dingen, die er nicht braucht.
Eine Warnung aus der Praxis gehört dazu, weil ich diesen Fehler regelmäßig sehe: Verzögere niemals das Bild, das ganz oben steht. Genau dieses Element ist in aller Regel Dein Largest Contentful Paint. Setzt Du es auf verzögertes Laden, erfährt der Browser erst spät davon und Deine Kennzahl wird schlechter statt besser. Alles unterhalb der ersten Bildschirmseite verzögern, das eine oben mit hoher Priorität laden.
Wo ich weiter gehe
Hier gehe ich über den Wortlaut der Guideline hinaus. Sie regelt den Zeitpunkt, nicht die Menge. Eine verzögert geladene Datei ist trotzdem eine geladene Datei. Die Bytes reisen, der Server rechnet, das Endgerät verarbeitet, nur eben ein paar hundert Millisekunden später. Für die Wahrnehmung ist das ein großer Unterschied, für die CO₂-Bilanz fast keiner.
Deshalb stelle ich vor die Frage nach dem Wann immer die Frage nach dem Ob. Verzögertes Laden ist ein Terminplan, kein Sparprogramm. Und es birgt eine Falle, die mir in Projekten oft begegnet: Wer sauber verzögert, hält plötzlich alles für vertretbar. Das dritte Tracking-Skript, das eingebettete Video, das Karten-Widget, alles lädt ja nachrangig und stört die Messwerte nicht mehr. Die Ladezeit sieht gut aus, die übertragene Datenmenge steigt trotzdem weiter.
Dein erster Schritt heute
Fang bei dem an, was der Browser Dir ohnehin schon verrät. Du brauchst kein Werkzeug zu kaufen und keine Bibliothek einzubinden.
Verzögertes Laden ist die eleganteste Art, Ballast zu tragen. Ihn abzulegen bleibt trotzdem die bessere.
Quelle: W3C-Fassung von Guideline 3.7