Warum HTML-Änderungen im Browser nicht angezeigt werden

Einmal hat mich das zehn Minuten gekostet. Ich speicherte eine Datei in meinem Downloads-Ordner und aktualisierte einen Tab, der dieselbe Seite zeigte — geöffnet allerdings vom Desktop. Gleicher Name, gleicher Inhalt, zwei verschiedene Dateien, und ich bearbeitete brav die Kopie, auf die keiner schaute. So läuft es meistens. Wenn eine HTML-Änderung sich partout nicht zeigt, liegt es fast nie am Code — es ist ein veralteter Cache, eine Datei, die du nicht wirklich gespeichert hast, eine .html.txt-Endung, eine in den DevTools gestrandete Änderung, oder der Browser liest eine andere Kopie als die, die du geändert hast. Hier die Checkliste, die ich durchgehe, den schnellsten Fang zuerst.

die Checkliste in sechzig Sekunden

Bevor du irgendetwas anfasst, lies diese Liste von oben nach unten. Meistens steht die Antwort schon drin.

• Du hast nicht gespeichert. Die Änderung steckt noch im Editor, nie auf die Festplatte geschrieben.
• Du schaust auf eine andere Kopie. Der Tab zeigt auf einen anderen Ordner oder auf eine gehostete Version — nicht die Datei, die du bearbeitet hast.
• Der Browser hat sie im Cache. Er liefert die alte Seite oder das alte CSS aus dem Speicher, statt die Datei neu zu lesen.
• Die Datei hat die falsche Endung. index.html.txt sieht richtig aus und verhält sich wie reiner Text.
• Du hast es nur in den DevTools geändert. Diese Änderungen leben im Tab und verschwinden beim Neuladen.
• Eine andere CSS-Regel überschreibt deine. Deine Änderung ist da — sie verliert nur die Kaskade.

Jetzt die Lösungen, in der Reihenfolge, in der ich sie wirklich prüfen würde.

du hast gar nicht gespeichert

Fang mit der dümmsten Möglichkeit an, weil sie die häufigste ist. Schau auf den Tab deines Editors — trägt er einen Punkt oder ein Sternchen, ist das die „ungespeichert"-Markierung, und du hast den Browser aktualisiert, bevor die Änderung je auf der Festplatte ankam. Strg+S. Erledigt.

Eine leisere Variante desselben Problems ist das Speichern am falschen Ort. Dein Editor hat „eine Kopie gespeichert", wo du sie nicht erwartest, oder die Datei ist zweimal offen, und der Browser liest das Original, das du nie geändert hast. Was direkt zum nächsten Punkt führt.

du bearbeitest eine Datei und schaust auf eine andere

Das ist der Zwilling des letzten Punkts, und er versteckt sich noch besser. Die Datei ist an zwei Stellen offen — zwei verschiedene Ordner, sagen wir, oder eine lokale Kopie und eine gehostete Version — und du bearbeitest fleißig die eine, während der Browser dir die andere zeigt.

Schau in die Adressleiste. Eine lokale Datei zeigt einen file:///-Pfad mit dem vollen Speicherort, und der muss zur gerade bearbeiteten Datei passen, Zeichen für Zeichen. Arbeitest du an einer Seite, die tatsächlich ausgeliefert wird — läuft auf localhost oder ist schon irgendwo deployt — kommt eine ganze Ebene dazu. Die lokale Datei neu zu laden zeigt keine Serveränderungen, und die Live-URL neu zu laden zeigt keine lokalen. Finde heraus, welche Kopie du änderst, und richte den Browser genau auf diese Kopie.

der Browser zeigt dir die Seite von gestern

Browser behalten eine lokale Kopie von Seiten, Bildern und vor allem CSS, damit sie nicht bei jedem Besuch alles neu laden. An den meisten Tagen ist das ein Gefallen. Während du bearbeitest, ist es das, was dich glatt anlügt — ein einfaches Neuladen kann dir die Cache-Version reichen, statt die Datei neu zu lesen.

Die Lösung ist ein erzwungenes Neuladen, das dem Browser sagt, seine Kopie wegzuwerfen und alles neu zu holen. Strg+Umschalt+R unter Windows und Linux, Cmd+Umschalt+R auf dem Mac. Strg+F5 geht auch unter Windows. Das CSS ist hier der hinterhältige Teil — dein HTML-Text aktualisiert sich, das Styling aber nicht, weil das verlinkte Stylesheet für sich allein im Cache gelandet ist. Ein erzwungenes Neuladen räumt beides ab. Und wenn er immer noch nicht loslässt, öffne die DevTools, und bei geöffneten DevTools mach einen Rechtsklick auf die Neu-laden-Schaltfläche und wähle „Cache leeren und vollständig neu laden". Danach bleibt nichts mehr für die Seite gespeichert.

deine Datei ist heimlich zur .txt geworden

Erst die Lösung, dann das Warum. Stell den „Dateityp" auf „Alle Dateien", bevor du speicherst, oder setz den Namen in Anführungszeichen — "index.html" — und schalte die Anzeige der Dateiendungen ein, damit du die echte Endung siehst. Was dich erwischt, ist die Voreinstellung vom Editor. Du bearbeitest index.html, klickst auf Speichern unter, und der Dialog nimmt ein reines Textdokument an, hängt also .txt an, und du gehst mit index.html.txt weg — was der Browser als Text liest, während die echte .html gleich daneben sich nie rührt. Das erwischt mehr Leute als alles andere auf dieser Liste, und ich gehe tiefer darauf ein in wie man eine HTML-Datei bearbeitet.

du hast es nur in den DevTools geändert

Wenn du die ganze Zeit mit Rechtsklick auf die Seite gehst, Untersuchen wählst und deine Änderungen ins Elemente- oder Stile-Panel tippst — dann sind diese Änderungen nicht echt, nicht im Sinne, der zählt. DevTools-Änderungen leben im Speicher des Tabs. Sie sind super, um etwas auf der Live-Seite auszuprobieren, aber sie berühren nie die Datei auf der Festplatte, und in der Sekunde, in der du neu lädst, sind sie weg.

Also klar verschwindet die Änderung. Neuladen ist genau das, was sie wegwirft. Damit sie bleibt, kopier das, was funktioniert hat, aus den DevTools heraus und füg es in deine echte Datei ein, dann speichere. Die DevTools sind ein Skizzenblock, auf dem du kritzelst, um zu sehen, wie es aussieht. Die Datei ist das Dokument. Nur eins von beiden behält, was du schreibst.

eine andere Regel gewinnt das Kräftemessen

Manchmal ist die Änderung wirklich in der Datei, gespeichert und nicht im Cache — und trotzdem rührt sich nichts. Neun von zehn Malen ist das CSS, das CSS überschreibt. Du setzt eine Farbe auf einen Absatz, aber ein spezifischerer Selektor weiter unten im Stylesheet, oder ein Inline-Stil direkt am Element, oder irgendwessen verirrtes !important schlägt dich. Die Spezifität kommt zuerst — ein gezielterer Selektor gewinnt, egal wo er in der Datei steht, und nur wenn zwei Regeln gleich spezifisch sind, macht die spätere das Rennen. Das ist die Kaskade bei ihrer Arbeit — nur nicht bei der, die du im Sinn hattest.

Die DevTools machen es offensichtlich. Untersuche das Element, öffne das Stile-Panel, und die Regel, die verloren hat, steht genau dort, durchgestrichen. Was deine Regel durchstreicht, ist das, was du ändern musst — oder spezifischer schlagen musst. Das schlägt Raten jedes Mal.

wie ein Live-Editor das meiste davon umgeht

Schau nochmal auf die Liste und merk, was das meiste davon teilt. Das Speichern, der Wechsel zum Browser, das Neuladen — diese kleine Lücke zwischen Bearbeiten und Sehen ist da, wo sich ein Cache einschleicht, wo die falsche Datei reinrutscht, wo sich eine .txt versteckt. Schließ die Lücke, und das meiste davon kann schlicht nicht mehr passieren.

Das ist die Idee hinter dem Tool, das ich gebaut habe, HTML Tweak. Du öffnest deine .html-Datei und bearbeitest sie mit der gerenderten Seite und dem Code nebeneinander und synchron — änder das eine, das andere zieht mit, ohne den Speichern-und-Neuladen-Tanz dazwischen. Keine Cache-Kopie, gegen die du kämpfst, weil du die Datei selbst anschaust, und nichts, was du tippst, strandet in einem Panel, das es beim Neuladen vergisst. In Chrome oder Edge speichert es direkt zurück in die Datei; andere Browser laden die bearbeitete Kopie herunter. Es fährt kein React- oder Next-Projekt aus mehreren Dateien — es ist dafür gemacht, eine einzelne Seite fertigzustellen — aber dafür hört die ganze „warum zeigt sich das nicht"-Frage weitgehend auf zu kommen.

Also wenn sich die Seite das nächste Mal nicht rührt, geh die Checkliste von oben durch — es ist fast immer der Cache und fast nie dein Auge. Und wenn du das Speichern-und-Neuladen-Roulette lieber ganz sein lässt, HTML Tweak zeigt dir einfach die Datei, wie sie sich beim Tippen verändert.