JavaScript korrekt einbetten: CDATA, defer, async und moderne Best Practices

Was hat es mit CDATA und JavaScript auf sich?

Wer ältere Webprojekte betreut oder historische Code-Snippets liest, stolpert früher oder später über diese Konstruktion:

<script type=“text/javascript“>
/* <![CDATA[ */
// Skript hier platzieren
/* ]]> */
</script>

Was steckt dahinter – und braucht man das heute noch?
Was ist CDATA?

CDATA steht für Character Data und stammt aus der XML-Spezifikation. In XHTML – dem strikten, XML-basierten Vorläufer von HTML5 – musste eingebettetes JavaScript in einen CDATA-Abschnitt verpackt werden. Der Grund: XML-Parser interpretieren bestimmte Zeichen wie < oder & als Markup. Ein JavaScript wie if (a < b) würde den Parser zum Absturz bringen, weil < als Beginn eines Tags gewertet wird.

Die CDATA-Sektion signalisiert dem Parser: Dieser Inhalt ist Rohdaten – bitte nicht interpretieren.

Der Workaround mit JavaScript-Kommentaren (/* <![CDATA[ */) war nötig, damit Browser, die CDATA nicht verstanden, den Block trotzdem korrekt ausführten. Ein klassischer Kompromiss zwischen zwei inkompatiblen Standards.

Ist CDATA heute noch relevant?

Kurze Antwort: Nein – für die allermeisten Projekte nicht mehr.

Mit HTML5 hat sich die Situation grundlegend verändert. HTML5 ist kein XML und erwartet keine CDATA-Sektionen. Browser parsen <script>-Blöcke ohnehin als reinen Text, nicht als Markup. Das bedeutet: <, > und & innerhalb eines <script>-Tags sind in modernem HTML völlig unbedenklich.

Das type="text/javascript"-Attribut ist seit HTML5 ebenfalls optional – JavaScript ist der Standard, kein explizites Attribut nötig.

Ausnahme: Wer tatsächlich XHTML 1.0 Strict oder XML-basierte Ausgaben bedient (z.B. bestimmte XML-Feeds oder SVG-Dokumente mit eingebettetem Script), sollte CDATA weiterhin verwenden.

Wie bettet man JavaScript ein – moderne Best Practices

Variante 1: Externes Script (empfohlen)

<script src="/assets/js/main.js" defer></script>

Das ist der Goldstandard. Warum:

• Trennung von Struktur (HTML) und Verhalten (JS)
• Browser kann das Script cachen
• defer sorgt dafür, dass das Script erst nach dem HTML-Parsing ausgeführt wird
• Kein Blocking des Renderings

Korrekt eingebundenes JavaScript ist übrigens auch eine Grundvoraussetzung für barrierefreies Webdesign nach WCAG – Screen Reader und assistive Technologien reagieren empfindlich auf blockierendes oder fehlerhaft geladenes Script.

Variante 2: Inline Script ohne CDATA (HTML5)

<script>
  document.addEventListener('DOMContentLoaded', () => {
    console.log('DOM bereit');
  });
</script>

Einfach, sauber, valide. Kein CDATA nötig.

JavaScript einbetten: defer, async und inline

Beide Attribute verhindern, dass ein externes Script das Rendering blockiert. Der Unterschied liegt im Ausführungszeitpunkt:

Attribut	Laden	Ausführung	Reihenfolge
(keines)	blockiert	sofort	garantiert
async	parallel	sobald geladen	nicht garantiert
defer	parallel	nach HTML-Parsing	garantiert

Faustregel:

• defer für Scripts, die auf das DOM zugreifen oder in einer bestimmten Reihenfolge laufen müssen
• async für unabhängige Scripts wie Analytics oder Tracking-Pixel

<!-- Analytics: unabhängig, Reihenfolge egal -->
<script src="analytics.js" async></script>

<!-- App-Logik: braucht das DOM, Reihenfolge wichtig -->
<script src="app.js" defer></script>

Was gilt für WordPress?

In WordPress registriert und lädt man Scripts über wp_enqueue_script() – nie direkt im Template hardcoden. WordPress übernimmt dabei automatisch die korrekte Platzierung und ermöglicht die Übergabe von PHP-Variablen via wp_localize_script().

function mein_theme_scripts() {
    wp_enqueue_script(
        'mein-script',
        get_template_directory_uri() . '/js/main.js',
        array('jquery'),
        '1.0.0',
        true // im Footer laden = defer-ähnliches Verhalten
    );
}
add_action('wp_enqueue_scripts', 'mein_theme_scripts');

Der letzte Parameter true lädt das Script im Footer – ähnlich wie defer, ohne das Attribut explizit setzen zu müssen.

W3C-Validierung: Was prüfen?

Wenn du deine Seite durch den W3C Markup Validator jagst und JavaScript-bezogene Fehler auftauchen, sind das heute meistens:

• Ungültiges type-Attribut: type="text/javascript" ist in HTML5 nicht falsch, aber unnötig. Validator-Warnungen können auftreten.
• Inline-Scripts mit nicht-escapten Sonderzeichen: Passiert selten, aber </script> innerhalb eines Strings im Script kann den Parser verwirren.
• CDATA-Fragmente in HTML5-Dokumenten: Werden vom Validator als unbekannte Konstrukte gemeldet – hier war früher Pflicht, was heute Warnung auslöst.

Du weißt nicht, wo deine Website aktuell steht? Mit unserem kostenlosen Website Check bekommst du eine schnelle Einschätzung zu Performance, DSGVO und technischen Fehlern.

Fazit

CDATA war eine sinnvolle Lösung für ein reales Problem zur XHTML-Ära. Heute ist es ein Relikt – gut zu kennen, wenn man alten Code versteht oder pflegt, aber nicht mehr aktiv einzusetzen.

Moderne JavaScript-Einbindung heißt: externe Scripts, defer als Standard, async für Tracking, und in WordPress immer über wp_enqueue_script().