Der HTML-Code einer Webseite entspricht der Gesamtheit der textuellen Anweisungen, die der Browser interpretiert, um Inhalte auf dem Bildschirm darzustellen. Der Zugriff auf diesen Code ermöglicht es, die Struktur einer Website zu verstehen, einen Anzeige-Fehler zu diagnostizieren oder das Markup eines Konkurrenten zu analysieren. Es gibt zwei Hauptmethoden, die nebeneinander existieren, und sie zeigen nicht dasselbe.
Rohquelle und gerenderter DOM: zwei Ansichten des HTML-Codes
Wenn ein Browser eine Seite lädt, erhält er zunächst eine rohe HTML-Datei, die vom Server gesendet wird. Diese Datei enthält die Tags, wie sie auf der Serverseite geschrieben wurden, bevor sie durch JavaScript verändert wurden.
Die Rohquelle kann über die Tastenkombination Ctrl + U (oder Cmd + U auf Mac) in den meisten Browsern aufgerufen werden. Der angezeigte Inhalt entspricht genau der ursprünglichen HTTP-Antwort. Auf einer klassischen statischen Website spiegelt diese Quelle genau wider, was der Besucher sieht.
Bei modernen Anwendungen vom Typ SPA (Single Page Application) ist die Situation jedoch grundlegend anders. Die Rohquelle kann fast leer erscheinen, da der sichtbare Inhalt dynamisch durch JavaScript nach dem anfänglichen Laden generiert wird. Um den tatsächlichen Zustand der Seite zu sehen, wie sie im Browser erscheint, muss der gerenderte DOM über die Entwicklertools aufgerufen werden. Das Verständnis von dem HTML-Code einer Webseite erfordert daher die Unterscheidung zwischen diesen beiden Schichten.
Der Tab Elemente der DevTools zeigt den DOM, wie er nach der Ausführung aller Skripte existiert. Die durch JavaScript hinzugefügten, geänderten oder entfernten Knoten erscheinen dort in Echtzeit. Diese Ansicht spiegelt wider, was der Browser tatsächlich im Speicher aufgebaut hat, nicht das, was der Server gesendet hat.
Tastenkombinationen zum Anzeigen des Codes in jedem Browser
Die drei am weitesten verbreiteten Desktop-Browser teilen sich ähnliche Tastenkombinationen, mit einigen Variationen.
- Google Chrome: Ctrl + U für die Rohquelle, F12 oder Ctrl + Shift + I, um die DevTools im Tab Elemente zu öffnen, der den gerenderten DOM zeigt.
- Mozilla Firefox: dieselbe Tastenkombination Ctrl + U für die Quelle. Die Entwicklertools werden mit F12 geöffnet. Firefox hat kürzlich spezielle Fälle der Quellanzeige für Dokumente vom Typ blob: und srcdoc korrigiert.
- Safari: Das Entwicklungsmenü muss manuell in den Einstellungen aktiviert werden. Sobald es aktiv ist, zeigt die Tastenkombination Cmd + Option + U die Quelle an, und Cmd + Option + I öffnet den Webinspektor.
Ein Punkt, den man sich merken sollte: die Tastenkombination Ctrl + U zeigt immer die Serverquelle an, niemals den modifizierten DOM. Für das Debugging auf einer dynamischen Website sind die DevTools die einzige zuverlässige Option.
Den HTML-Code auf Mobilgeräten mit dem Präfix view-source anzeigen
Auf einem Android-Smartphone mit Chrome gibt es keine Tastenkombination oder integriertes Menü, um die Quelle anzuzeigen. Die dokumentierte Methode besteht darin, view-source: direkt vor die URL in die Adressleiste einzugeben.
Zum Beispiel, um das HTML von example.com zu überprüfen, reicht es aus, view-source:https://example.com in Chrome mobil einzugeben. Der Browser zeigt dann den rohen Code an, der vom Server gesendet wurde, in einer Ansicht im Nur-Text-Format.
Diese Technik funktioniert auch auf dem Desktop, entfaltet jedoch ihr volles Potenzial auf Mobilgeräten, wo die Entwicklertools nicht nativ zugänglich sind. Auf iOS bietet Safari mobil kein integriertes Äquivalent. Es gibt Drittanbieter-Apps im App Store, die speziell für die Quellinspektion entwickelt wurden, um diese Lücke zu schließen.
Den DOM mit den DevTools inspizieren und vorübergehend ändern
Der Tab Elemente der Entwicklertools beschränkt sich nicht auf das Lesen des Codes. Er ermöglicht es, jedes Element der Seite vorübergehend direkt im Browser zu ändern.
Text oder HTML-Attribute ändern
Ein Doppelklick auf einen Knoten im Tab Elemente macht den Inhalt bearbeitbar. Die Änderung spiegelt sich sofort in der angezeigten Seite wider. Diese Änderung bleibt lokal: Ein Neuladen der Seite stellt den ursprünglichen Inhalt wieder her.
Dieser Mechanismus dient dazu, einen alternativen Titel zu testen, die Darstellung eines längeren Textes zu überprüfen oder das Entfernen eines Blocks zu simulieren, ohne die tatsächliche Quelldatei zu berühren. Front-End-Entwickler nutzen ihn täglich, um CSS- oder HTML-Anpassungen zu prototypisieren, bevor sie diese in den Code übertragen.
JavaScript-Änderungen in Echtzeit beobachten
Der Tab Elemente spiegelt jede Mutation des DOM in Echtzeit wider. Wenn ein Skript nach einem Benutzerklick ein Element hinzufügt, erscheint der entsprechende Knoten sofort im Baum. Geänderte Knoten heben sich durch einen kurzen lila Blitz in Chrome hervor.
Diese Fähigkeit zur Echtzeitbeobachtung unterscheidet den Inspektor grundlegend von der einfachen Quellansicht. Um ein unerwartetes Verhalten auf einer interaktiven Seite zu diagnostizieren, bietet nur der in den DevTools gerenderte DOM ein treues Bild dessen, was passiert.
Drei konkrete Fälle, in denen die Quellansicht nicht ausreicht
Die Quellansicht ist praktisch für schnelle Überprüfungen von Meta-Tags, semantischer Struktur oder der Anwesenheit eines Drittanbieter-Skripts. Sie stößt jedoch in mehreren spezifischen Situationen an ihre Grenzen.
- Websites, die mit JavaScript-Frameworks (React, Vue, Angular) erstellt wurden, generieren den Großteil des HTML auf der Clientseite. Die Rohquelle enthält oft nur ein leeres Wurzel-div-Tag und Links zu JS-Dateien.
- Seiten, die Inhalte über AJAX-Anfragen nach der anfänglichen Anzeige laden. Das dynamisch hinzugefügte HTML erscheint niemals in der Rohquelle.
- Die Shadow-DOM-Elemente, die von bestimmten gekapselten Webkomponenten verwendet werden, sind in der klassischen Quellansicht unsichtbar, aber über den Inspektor mit der aktivierten Option “Show user agent shadow DOM” in den DevTools-Einstellungen zugänglich.
Die Wahl zwischen Ctrl + U und F12 hängt also vom Typ der analysierten Website ab. Für eine statische Website oder ein klassisches CMS reicht die Rohquelle aus. Für alles andere werden die DevTools zum obligatorischen Einstiegspunkt in den tatsächlich vom Browser ausgeführten Code.
