Eine Website übernehmen – und nur das Endprodukt vorfinden
Wer eine bestehende Website von einer anderen Agentur übernimmt, bekommt nicht immer alles, was dazugehört. Ein Klassiker: Im Projekt liegt das fertig gebaute Stylesheet, eine einzige, maschinell verdichtete Datei. Die Quellen, aus denen sie einmal entstanden ist, lagen auf einem Rechner der früheren Agentur – und sind nie mit übergeben worden.
Solange an der Gestaltung nichts geändert wird, fällt das nicht auf. Die Seite läuft ja. Spätestens beim Relaunch wird es zum Problem – genau dort standen wir bei einer Schweizer Organisation, deren Website wir neu aufbauen.
Die Herausforderung
Die Ausgangslage im Projekt:
- Ein Stylesheet mit 1,4 MB, maschinell verdichtet, auf Basis von Bootstrap 5.
- Kein Quellbaum. Keine SCSS-Dateien, keine Build-Anleitung, keine Liste der verwendeten Werkzeuge. Der ursprüngliche Build lief auf einem fremden Rechner.
- Eine Live-Seite, die sich nicht verändern darf. Die bestehende Website läuft weiter, bis der Relaunch umgeschaltet wird.
Ohne Quellen ist jede Designänderung Flickwerk: Man sucht in einer unlesbaren Datei nach der passenden Stelle, überschreibt sie von Hand und hofft, dass nichts anderes davon abhängt. Eine Farbe zu ändern, die an vielen Stellen in abgeleiteter Form vorkommt, ist so praktisch nicht sauber zu machen. Für einen Relaunch ist das keine Grundlage.
Die Alternative – alles neu schreiben – hätte bedeutet, das bestehende Erscheinungsbild nach Augenmaß nachzubauen. Auch das wollten wir nicht.
Unsere Lösung
1. Der Fund: Die Quellen waren nie weg
Neben dem Stylesheet lag eine zweite, auf den ersten Blick uninteressante Datei: die Source-Map. Sie ist eigentlich ein Hilfsmittel für Entwickler – der Browser kann damit anzeigen, aus welcher Quelldatei eine bestimmte Regel im verdichteten Stylesheet stammt.
- 2,1 MB große Source-Map
- 99 Quelldateien samt Inhalt
- 24 projekteigene SCSS-Dateien
Was viele nicht wissen: Eine Source-Map kann nicht nur auf die Quelldateien verweisen, sondern deren vollständigen Inhalt enthalten. Genau das war hier der Fall. Die 2,1 MB große Datei führte 99 Quelldateien samt Inhalt – darunter den kompletten projekteigenen SCSS-Baum mit 24 Dateien: Variablen, Schriften, Kopf- und Fußbereich, Schaltflächen, Navigation, die einzelnen Seitenabschnitte.
Die Quellen lagen die ganze Zeit im Projekt. Nur eben verpackt in einer Datei, die niemand öffnet.
2. Auspacken und den Build nachbauen
Die Dateien aus der Map herauszuschreiben, ist der einfache Teil. Der schwierigere: herausfinden, womit sie ursprünglich gebaut wurden. Ein Stylesheet entsteht selten in einem Schritt. In diesem Fall waren es drei:
- Sass übersetzt die SCSS-Quellen in CSS,
- Autoprefixer ergänzt die Schreibweisen für ältere Browser,
- clean-css verdichtet das Ergebnis.
Lässt man die letzten beiden weg, sieht das Ergebnis auf den ersten Blick richtig aus – es fehlen aber die Browser-Präfixe, die zum Beispiel ältere Safari-Versionen für bestimmte Effekte brauchen. Wir haben deshalb nicht nur die Werkzeuge, sondern auch ihre Versionen so lange eingegrenzt, bis das Ergebnis zum ausgelieferten Stylesheet passte, und diese Versionen im Projekt festgeschrieben.
3. Der Beweis vor dem ersten Eingriff
Bevor wir auch nur eine Zeile an der Gestaltung ändern, wollten wir eine Frage beantwortet haben: Erzeugt unser nachgebauter Build wirklich dasselbe, was heute auf der Live-Seite ausgeliefert wird?
„Sieht gleich aus” ist dafür kein Maßstab. Wir haben neu gebaut und das Ergebnis Byte für Byte gegen die ausgelieferte Datei verglichen. Der Unterschied nach 1,4 MB:
- ein überflüssiges Semikolon, das im Original stand und im neuen Build fehlt,
- ein Kommentar am Dateiende, der auf die alte Source-Map verwies.
Zusätzlich abgesichert haben wir das auf zwei weiteren Wegen: Beide Dateien ergeben, maschinell zerlegt, dieselben 8.967 Formatanweisungen in derselben Reihenfolge. Und Bildschirmfotos der Startseite mit altem und neuem Stylesheet sind auf Desktop- und Handybreite pixelgleich.
Erst danach ging der neue Build live. Nach der Veröffentlichung haben wir geprüft, dass der Server exakt die Datei ausliefert, die aus den Quellen entsteht. Für Besucherinnen und Besucher hat sich nichts geändert – und genau das war das Ziel dieses Schritts.
Ein zweites Sicherheitsnetz gehört seitdem zum Projekt: Ein Prüfbefehl baut das Stylesheet neu und meldet, ob die abgelegte Datei noch zu den Quellen passt. Handänderungen am Endprodukt fallen damit auf, statt still liegen zu bleiben.
4. Was die Gegenprobe ans Licht brachte
Der Byte-Vergleich war nicht nur ein Beweis. Er hat drei Annahmen korrigiert, mit denen wir gestartet waren – und die ohne ihn unbemerkt in den Relaunch gewandert wären.
Die Source-Map gehörte gar nicht zu dieser Website. Sie war identisch mit der Map einer Schwesterseite. Das Stylesheet unserer Website war das fertig gebaute Stylesheet der Schwesterseite, in dem jemand nachträglich die Farbwerte ersetzt hatte – per Suchen und Ersetzen im Endprodukt.
Die Hausfarbe war deshalb nur halb angekommen. Ersetzt wurden die Stellen, an denen die Hauptfarbe wörtlich stand. Ein Framework wie Bootstrap leitet aus der Hauptfarbe aber viele weitere Töne ab: die Farbe von Links, die Abdunklung beim Überfahren einer Schaltfläche, den Rahmen um ein angeklicktes Formularfeld. Diese abgeleiteten Werte stehen in anderer Schreibweise im Stylesheet – und trugen auf der Live-Seite noch immer den Farbton der Schwesterseite. An kaum sichtbaren Stellen, aber eben unbemerkt.
Die Map war älter als das ausgelieferte Stylesheet. Die fertige Datei enthielt Regeln, die in den Quellen der Map fehlten – etwa für das Logo und die Navigation auf dem Handy. Auch hier war offenbar nachträglich am Endprodukt gearbeitet worden. Drei Quelldateien haben wir auf den ausgelieferten Stand gebracht.
Dazu kam eine Eigenheit, die man kennen muss: Eine Source-Map führt nur Dateien auf, die selbst CSS erzeugen. Dateien, die nur Einstellungen enthalten – die Einstiegsdatei mit der Reihenfolge aller Teile, die Umbruchpunkte für verschiedene Bildschirmbreiten, die Definitionen von 59 Symbolen –, fehlten. Sie ließen sich aus dem fertigen Stylesheet zurückrechnen. Ob die Rekonstruktion stimmt, zeigte wieder der Vergleich: Ohne den Farbtausch erzeugt unser Build das Stylesheet der Schwesterseite Byte für Byte.
5. Die saubere Lösung: Farbe in die Quellen, Ersetzungsschritt weg
Damit das neu gebaute Stylesheet der Live-Seite entspricht, mussten wir den nachträglichen Farbtausch zunächst nachbilden – als ausdrücklichen, dokumentierten letzten Schritt im Build. Unschön, aber ehrlich: Das Stylesheet war so entstanden, also bildet der Build es so ab.
Die eigentliche Korrektur haben wir bewusst nicht an der laufenden Seite vorgenommen. Die Hauptfarbe richtig in den Quellen zu setzen, verändert überall dort die Darstellung, wo ein abgeleiteter Ton sichtbar ist. Das ist eine Gestaltungsentscheidung und keine Aufräumarbeit – und sie gehört in den Relaunch, der ohnehin von Grund auf entsteht.
Dort ist sie jetzt umgesetzt: Die Hausfarbe steht einmal in den Quellen, alle abgeleiteten Töne ergeben sich daraus von selbst, den Ersetzungsschritt gibt es nicht mehr. Nebenbei ist das Stylesheet des Relaunchs auf 274 KB geschrumpft, weil es nur noch enthält, was die neue Seite wirklich braucht.
6. Aufräumen, wo es nichts kostet
Zwei Dinge haben wir an der bestehenden Seite trotzdem bereinigt, weil sie die Darstellung nachweislich nicht berühren:
- Die Formatierungen einer Slider-Bibliothek steckten doppelt im Stylesheet. Eine Kopie entfernt: rund 18 KB weniger.
- Die Source-Map selbst haben wir vom Server genommen. Ihr Inhalt liegt jetzt als Quellen im Projekt, wo er hingehört.
Auch hier galt dieselbe Gegenprobe: Das neue Stylesheet entspricht dem alten, abzüglich genau eines zusammenhängenden Blocks – der doppelten Kopie. Kein anderes Byte weicht ab.
Das Ergebnis
- Quellen und Build liegen im Projekt. Das Stylesheet entsteht mit einem Befehl aus lesbaren Dateien, mit festgeschriebenen Werkzeugversionen und unabhängig von einem bestimmten Rechner.
- Die Live-Seite ist unverändert. Nachgewiesen durch den Byte-Vergleich, nicht durch Hinsehen.
- Eine unbemerkte Farb-Altlast ist gefunden und im Relaunch an der Wurzel behoben.
- Der Relaunch baut auf den echten Quellen auf statt auf einem Nachbau nach Augenmaß.
- 2,1 MB interner Projektdaten sind nicht mehr öffentlich abrufbar.
Checkliste: Was bei einer Übergabe dazugehört
Der Fall ist gut ausgegangen, weil zufällig eine Source-Map mit vollständigem Inhalt im Projekt lag. Darauf sollte sich niemand verlassen – für die JavaScript-Datei derselben Website gab es zum Beispiel keine. Wer eine Website beauftragt, übernimmt oder übergibt, sollte auf vier Dinge bestehen:
- Die Quellen, nicht nur das Ergebnis. Zu jeder gebauten Datei (Stylesheet, JavaScript) gehören die Dateien, aus denen sie entsteht – im selben Projektarchiv wie der Rest der Website.
- Eine Build-Anleitung, die funktioniert. Ein Befehl, der auf einem frischen Rechner das ausgelieferte Ergebnis erzeugt. Lässt sich das nicht vorführen, ist der Build faktisch nicht übergeben.
- Die Abhängigkeiten mit festen Versionen. Dieselben Quellen ergeben mit anderen Werkzeugversionen ein anderes Ergebnis. Ohne Versionsliste wird jede spätere Änderung zum Ratespiel.
- Keine Handänderungen am Endprodukt. Was nach dem Build von Hand ersetzt wird, ist beim nächsten Build wieder weg – oder bleibt, wie hier, halb erledigt stehen.
Und ein Punkt für die Sicherheit: Source-Maps gehören in der Regel nicht auf eine Live-Seite. Was uns hier geholfen hat, steht jedem anderen genauso offen. Eine öffentlich abrufbare Map kann den kompletten Quelltext verraten, einschließlich interner Kommentare, der Ordnerstruktur auf dem Rechner des Entwicklers und Hinweisen auf andere Projekte. Ein kurzer Blick, ob neben den eigenen Stylesheets und Skripten Dateien mit der Endung .map ausgeliefert werden, lohnt sich.
