JavaScript im Head vs. Footer: Wie es die Core Web Vitals beeinflusst

Warum defer im Head die moderne Best Practice ist und wann eine Platzierung im Footer noch Sinn macht

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-03

Die kurze Antwort: defer im Head

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

Der klassische Ratschlag war, JavaScript in den Footer zu packen. Dieser Ratschlag ist veraltet. Da async und defer in jedem Browser unterstützt werden, ist der beste Platz für die meisten Skripte im <head> mit einem defer-Attribut.

Der Grund dafür liegt beim Preload Scanner: Ihr Browser entdeckt Skripte im Head sofort und beginnt mit dem Herunterladen parallel zum HTML-Parsing. Skripte im Footer werden erst später entdeckt, was einen späteren Start des Downloads bedeutet. Das Ergebnis ist dasselbe nicht blockierende Verhalten, aber mit einer schnelleren Entdeckung von Ressourcen.

Laut dem Web Almanac 2025 bestehen 85 % der Seiten immer noch nicht den Audit für render-blockierende Ressourcen. Das ist eine enorme Zahl. Währenddessen stieg die mobile Total Blocking Time im Jahresvergleich um 58 % auf einen Median von 1.916 ms. JavaScript wird schwerer, nicht leichter. Die richtige Platzierung Ihrer Skripte ist eine der einfachsten Maßnahmen, die Sie ergreifen können, um Ihren First Contentful Paint und Largest Contentful Paint zu verbessern.

Wie der Preload Scanner funktioniert

Der Preload Scanner ist ein zweiter HTML-Parser, der dem Hauptparser vorausläuft. Er scannt schnell das reine HTML und beginnt mit dem Abrufen kritischer Ressourcen (Bilder, CSS, JavaScript), bevor der Hauptparser sie erreicht. Der Preload Scanner ruft Ressourcen in etwa in der Reihenfolge ab, in der er sie entdeckt.

Hier ist die Platzierung von Skripten wichtig. Ein Skript im <head> wird fast sofort entdeckt. Ein Skript am Ende des <body> wird erst später entdeckt, insbesondere bei großen HTML-Dokumenten. Diese Verzögerung kann Sie über eine mobile Verbindung Hunderte von Millisekunden kosten.

Dynamisch injizierte Skripte (über JavaScript erstellt) sind für den Preload Scanner völlig unsichtbar. Der Scanner entdeckt nur Ressourcen, die im vom Server zurückgegebenen HTML-Markup existieren. Aus diesem Grund ist das Zurückstellen von JavaScript (Deferring) über HTML-Attribute fast immer besser als das Injizieren von Skripten mit Code.

JavaScript im Head

Die Platzierung von JavaScript im <head> der Seite ermöglicht die frühestmögliche Entdeckung durch den Preload Scanner.

Vorteile

  1. Frühe Entdeckung: Der Preload Scanner findet Head-Skripte noch vor dem Inhalt des Bodys. Der Download beginnt so früh wie möglich.
  2. Frühere Ausführung: Skripte im Head (mit defer) werden vor Skripten ausgeführt, die später im Dokument entdeckt werden. Einen detaillierten Vergleich finden Sie unter defer vs. async JavaScript und die Core Web Vitals.
  3. Code-Trennung: Durch die Aufbewahrung von Skriptreferenzen im <head> werden sie vom Content-Markup getrennt, wodurch das HTML leichter zu warten ist.

Nachteile

  1. Render-Blockierung (ohne defer oder async): Ein einfaches <script> im Head blockiert das HTML-Parsing, bis das Skript heruntergeladen und ausgeführt ist. Dies ruiniert Ihren First Contentful Paint. Verwenden Sie bei externen Skripten im Head immer defer oder async, um dies zu vermeiden.
  2. Wettbewerb um Bandbreite: Head-Skripte mit hoher Priorität konkurrieren mit Ihrem CSS, Ihren Schriftarten und dem LCP-Bild um Bandbreite. Bei langsameren Verbindungen kann dies Ihren Largest Contentful Paint über die Grenze von 2,5 Sekunden hinausschieben.

Wann man die Platzierung im Head verwendet

Verwenden Sie den <head> für Skripte, die für das Seitenerlebnis entscheidend sind: Ihr Menü, der Cookie-Hinweis, der Slider oder jedes Skript, das beeinflusst, was der Besucher "above the fold" sieht. Fügen Sie defer (oder async, wenn die Ausführungsreihenfolge keine Rolle spielt) hinzu, um Render-Blockierung zu verhindern. Bibliotheken zur Feature-Erkennung gehören ebenfalls in den Head, da sie ausgeführt werden müssen, bevor der Body geparst wird.

JavaScript im Footer

JavaScript direkt vor dem schließenden </body>-Tag zu platzieren, war jahrelang der Standardratschlag in Sachen Performance. Die Idee: Das HTML zuerst rendern lassen, Skripte danach herunterladen.

Vorteile

  1. Standardmäßig nicht blockierend: Footer-Skripte blockieren das anfängliche Rendering nicht, da das HTML darüber bereits geparst wurde.
  2. Geringerer Wettbewerb um Bandbreite: Wenn der Browser Footer-Skripte erreicht, haben Ihr CSS, Ihre Schriftarten und Ihr LCP-Bild bereits mit dem Herunterladen begonnen.

Nachteile

  1. Späte Entdeckung: Der Preload Scanner findet Footer-Skripte später als Head-Skripte. Bei einer großen Seite bedeutet dies einen späteren Download-Start und eine spätere Ausführung.
  2. Veraltetes Muster: <script defer> im <head> erzielt dasselbe nicht blockierende Verhalten bei früherer Entdeckung. Die Platzierung im Footer war der Workaround, bevor defer eine universelle Browserunterstützung hatte. Diese Ära ist vorbei.

Wann eine Platzierung im Footer noch Sinn macht

Eine Platzierung im Footer kann bei Skripten sinnvoll sein, bei denen Sie wirklich nicht möchten, dass sie beim ersten Laden der Seite um Bandbreite konkurrieren: Analysetools, A/B-Testtools oder soziale Widgets. Aber selbst bei diesen ist defer im Head meist die bessere Wahl, da der Preload Scanner sie früher entdeckt.

Moderne Skript-Attribute

Über async und defer hinaus gibt es noch zwei weitere Attribute, die Sie kennen sollten:

type="module": Modulskripte werden standardmäßig zurückgestellt (deferred). Sie müssen einem Modulskript kein defer hinzufügen, da es sich bereits so verhält. Das Hinzufügen von async zu einem Modulskript überschreibt das standardmäßige defer-Verhalten und sorgt dafür, dass es ausgeführt wird, sobald der Download abgeschlossen ist.

fetchpriority: Standardmäßig erhalten async- und defer-Skripte die Netzwerkpriorität Low (niedrig). Wenn Sie einem async-Skript fetchpriority="high" hinzufügen, erhalten Sie einen nicht blockierenden Download mit hoher Priorität. Dies ist die ideale Kombination für Skripte, die für das Benutzererlebnis (User Experience) entscheidend sind, das Rendering aber nicht blockieren sollen. Das vollständige Bild finden Sie in der Anleitung zur Ressourcenpriorisierung und in den JavaScript-Prioritätsstufen.

Eine praktische Strategie zur Platzierung von Skripten

Nicht alle Skripte verdienen die gleiche Behandlung. Ich verwende einen vierstufigen Ansatz:

  1. Render-kritische Skripte: Skripte, die das sichtbare Layout der Seite beeinflussen (Menü, Slider, Benutzeroberfläche "above the fold"). Platzieren Sie sie ohne defer im <head>, wenn sie vor dem ersten Paint ausgeführt werden müssen. Halten Sie diese so klein wie möglich, da sie das Rendering blockieren und Ihren Core Web Vitals schaden.
  2. Wichtige Skripte: Skripte, die für Konversion oder Interaktion entscheidend sind (Formulare, Navigation, Cookie-Zustimmung). Platzieren Sie sie mit defer oder async im <head>.
  3. Normale Skripte: Skripte, die das erste Rendering der Seite nicht beeinflussen (Karusselle, Modals, Tabs). Platzieren Sie sie mit defer im <head>.
  4. Nice-to-have Skripte: Skripte, auf die Sie im absoluten Notfall verzichten könnten (Analytics, Chat-Widgets, Social Sharing). Laden Sie diese, nachdem die Seite vollständig gerendert wurde, indem Sie das load-Event oder requestIdleCallback verwenden. Techniken dazu finden Sie unter 16 Methoden zum Zurückstellen von JavaScript. Wenn Sie viel ungenutztes JavaScript in dieser Kategorie haben, erfahren Sie unter wie man ungenutztes JavaScript reduziert mehr dazu.

Mit den Ereignissen DOMContentLoaded und load können Sie den Zeitpunkt der Ausführung steuern, unabhängig davon, wo das Skript im HTML platziert ist. Dies ist nützlich, um sicherzustellen, dass Ihr Code zum richtigen Zeitpunkt ausgeführt wird.

Codebeispiele

Beispiel 1: JavaScript im Head (Render-blockierend)

<!DOCTYPE html>
<html>
<head>
    <title>Beispiel für JavaScript im Head</title>
    <script>
        function showMessage() {
            alert("Hallo vom JavaScript im Head!");
        }
    </script>
    <!-- Dieses Skript blockiert das Rendering -->
    <script src="script.js"></script>
</head>
<body>
    <button onclick="showMessage()">Klick mich</button>
</body>
</html>

In diesem Beispiel blockiert script.js im <head> das Rendering. Der Browser zeigt die Schaltfläche nicht an, bis das Skript heruntergeladen und ausgeführt wurde. Fügen Sie defer zum Skript-Tag hinzu, um dies zu beheben.

Beispiel 2: JavaScript im Footer

<!DOCTYPE html>
<html>
<head>
    <title>Beispiel für JavaScript im Footer</title>
</head>
<body>
    <button onclick="showMessage()">Klick mich</button>
    <!-- Skript am Ende des Bodys -->
    <script src="script.js"></script>
    <script>
        function showMessage() {
            alert("Hallo vom JavaScript im Footer!");
        }
    </script>
</body>
</html>

Hier wird script.js nach dem HTML-Inhalt geladen, blockiert also nicht das Rendering. Aber der Preload Scanner entdeckt es später, als er es im Head tun würde. Die Verwendung von <script defer src="script.js"></script> im <head> bietet Ihnen dasselbe nicht blockierende Verhalten bei früherer Download-Entdeckung.

Beispiel 3: Verwendung von Event Listenern

<!DOCTYPE html>
<html>
<head>
    <title>Beispiel für einen Event Listener</title>
    <script>
        window.addEventListener('load', function() {
            console.log("Seite ist vollständig geladen.");
        });
    </script>
</head>
<body>
    <!-- Seiteninhalt -->
</body>
</html>

Der load-Event-Listener stellt sicher, dass der Code im Callback erst ausgeführt wird, nachdem die Seite vollständig geladen wurde, unabhängig davon, wo das Skript platziert ist. Dies ist nützlich für nicht-kritische Initialisierungen, die warten sollten, bis alles andere bereit ist.

Überprüfen Sie Ihre Änderungen

Nachdem Sie Skripte aus dem Footer mit defer in den <head> verschoben haben, überprüfen Sie die Auswirkungen mit dem Real User Monitoring. Ihr FCP und LCP sollten sich beide verbessern. Bei von CoreDash überwachten Sites haben Ursprünge, die defer für den Großteil ihrer Skripte verwenden, einen um 18 % schnelleren Median-FCP als Ursprünge, die sich immer noch auf die Platzierung im Footer verlassen.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

Search Console flagged your site?

When Google flags your Core Web Vitals you need a clear diagnosis fast. I deliver a prioritized fix list within 48 hours.

Request Urgent Audit
JavaScript im Head vs. Footer: Wie es die Core Web Vitals beeinflusstCore Web Vitals JavaScript im Head vs. Footer: Wie es die Core Web Vitals beeinflusst