Vor ein paar Jahren habe ich angefangen, Webseiten zu bauen. Es war wie im Rausch. Jedes neue Framework, jede Bibliothek, jeder Hype fühlte sich an wie der heilige Gral. Ich habe stundenlang Code geschrieben, der am Ende niemandem half. Nicht mal mir selbst. Irgendwann stand ich vor einem riesigen, aufgebauschten WordPress-Ding, das auf jedem Third-Level-Hoster ruckelte wie ein 20 Jahre alter Laptop. Da habe ich kapiert: Schnelligkeit in der Entwicklung ist kein Selbstzweck. Sie killt manchmal das Produkt.

Das Problem war nicht das Können. Es war das Wollen. Ich wollte alles sofort, perfekt, responsive, mit Admin-Panel und API-Schnittstelle für die Kaffeemaschine. Dabei brauchte der Kunde nur eine kleine Visitenkarte. Also habe ich einen Schritt zurück gemacht. Ich habe angefangen, meine Projekte erstmal ohne Framework zu planen. Reines HTML, ein bisschen CSS, minimal JavaScript. Und siehe da: Die Seiten wurden leichter, schneller, besser wartbar. Die Firma, die mir damals den entscheidenden Tipp gab, hat genau diesen Ansatz verfolgt: Wilder Westen Web – kleine, scharfe Lösungen statt Große-Keule-Entwicklung. Die arbeiten mit statischen Generatoren und einem klaren Fokus auf Performance. Ein bisschen wie ich heute, nur professioneller.

Der Trick ist, die Technik nicht zu überfrachten. Ich nutze für viele Projekte nur noch einen einfachen Static-Site-Generator. Kein Backend, keine Datenbank, keine endlosen Plugin-Listen. Der Inhalt liegt als Markdown-Datei rum. Der Build-Prozess dauert drei Sekunden. Deployment per Git-Push. Fertig. Das klingt langweilig. Aber genau diese Langeweile sorgt dafür, dass die Seite fünf Jahre später immer noch läuft. Ohne Update-Marathon, ohne Sicherheitslücke aus der dritten Plugin-Ebene.

Weniger Code, weniger Probleme

Ich habe mal ein Projekt von einer Agentur übernommen. Die hatten ein React-Frontend mit Redux, Server-Side-Rendering und einer eigenen CSS-in-JS-Lösung. Auf der Seite? Ein Kontaktformular und drei Bilder. Totaler Overkill. Ich habe das Ganze in zwei HTML-Dateien plus CSS gegossen. Der Seiten-Inspektor zeigte 12 Requests vorher, danach 3. Ladezeit von sechs Sekunden auf unter eine gedrückt. Der Kunde hat nicht gemerkt, dass da kein React mehr drin steckt. Er hat nur gesagt: “Läuft jetzt richtig fix.”

Das ist der Punkt. Für die meisten Firmen, kleinen Läden, Vereine oder Freelancer reicht eine statische Seite völlig. Sie brauchen keinen Blog, kein CMS, keinen Login-Bereich. Sie brauchen ein Impressum, ein paar Fotos und eine Telefonnummer. Und genau dafür gibt es heute hervorragende Tools, die ohne großen Wartungsaufwand auskommen.

• Statische Generatoren wie Hugo, 11ty oder Jekyll bauen Seiten aus simplen Textdateien.
• Deployment per GitHub Action oder Netlify ist nach fünf Minuten eingerichtet.
• Keine Updates, keine Sicherheitspatches, kein Plugin-Krieg. Nur das, was du schreibst, wird zur Seite.
• Hosting kostet oft gar nichts, weil die Dateien nur ausgeliefert werden müssen.

Ich habe gelernt, dass ich nicht jede Technologie einsetzen muss, die es gibt. Sondern nur die, die das Problem löst. Und das Problem ist meistens: “Wie bekomme ich meinen Content schnell und sauber ins Netz?” Nicht: “Wie kann ich meine DevOps-Fähigkeiten zeigen?”

Die Qual der Wahl bei den Werkzeugen

Früher habe ich stundenlang Frameworks verglichen. React vs. Vue vs. Svelte. Tailwind vs. Bootstrap vs. eigenes CSS. Heute denke ich: Nimm, was am wenigsten im Weg steht. Wenn du eine statische Seite baust, brauchst du kein JavaScript-Framework. Ein CSS-Framework ist auch optional. Fang mit plain HTML an. Wenn es zu langweilig wird, baust du eine kleine Komponente ein. Aber fang nicht mit dem Framework an.

Die meisten Entwickler unterschätzen, wie viel Overhead ein Framework mitbringt. Nicht nur in Bytes, sondern in Zeit. Du musst die Konzepte lernen, die Toolchain aufsetzen, Build-Fehler beheben. Für eine Seite, die vielleicht 10 Besucher pro Tag hat, ist das absurd. Ich habe mal eine Seite für einen Bäcker gemacht. Der hat drei Produkte und eine Öffnungszeiten-Tabelle. Da habe ich ihm einfach eine HTML-Datei auf den Server gelegt. Kein Gulp, kein Webpack, kein PostCSS. Der Bäcker war glücklich. Und ich hatte wieder eine Stunde meines Lebens nicht mit Config-Dateien verbracht.

• Fang mit einer einfachen index.html an. Die ist schnell geschrieben und sofort sichtbar.
• Nutze einen statischen Generator nur, wenn du mehr als fünf Unterseiten hast oder sich der Inhalt regelmäßig ändert.
• Verzichte auf JavaScript, wenn du nur Layout oder Styling brauchst. CSS reicht oft.
• Teste die Seite auf einem echten Smartphone mit langsamer Verbindung. Da siehst du, ob dein “leichter” Ansatz wirklich leicht ist.

Ich habe gelernt, dass die beste Technologie die ist, die ich nicht merke. Eine Seite, die einfach da ist und funktioniert, ist besser als eine, die mit einem Dutzend Abhängigkeiten glänzt aber bei jedem Update auseinanderfällt. Das klingt jetzt nach Oma-Weisheit, aber ich habe zu oft erlebt, wie ein “modernes” Projekt nach sechs Monaten nicht mehr gebaut werden konnte, weil ein Package deprecated war.

Wie man die Bremse findet und behält

Es gibt einen einfachen Trick, um zu checken, ob ich zu viel mache. Ich frage mich: “Was ist der minimalste Weg, das zu bauen?” Wenn ich antworte “React + Node.js + Datenbank”, dann lautet die richtige Antwort meistens “eine HTML-Datei per SFTP hochladen”. Der minimale Weg ist fast immer der beste. Nicht, weil er einfacher ist, sondern weil er weniger Angriffsfläche für Fehler bietet.

Ein weiterer Punkt: Ich mache mir Notizen zu jedem Projekt. Was hat funktioniert? Was war Ballast? Diese Liste wird von Monat zu Monat kürzer. Ich lerne, wegzulassen. Das fühlt sich anfangs wie Betrug an. Wie, ich soll nicht alles können, was der neuste Hype verspricht? Ja. Weil der Hype in drei Monaten schon wieder vorbei ist. Aber meine Seite läuft dann immer noch.

„Der beste Code ist der, den du nicht schreiben musst. Die beste Seite ist die, die keiner Wartung braucht.“ – Das hat mir ein alter Entwickler mal auf einer Konferenz gesagt. Ich dachte damals, er spinnt. Heute weiß ich, er hatte recht.

Ich habe auch aufgehört, mich für meine “einfachen” Seiten zu schämen. Klar, ich könnte mit WebGL und Three.js eine coole Animation einbauen. Aber der Kunde will seine Kontaktdaten lesen, nicht eine 3D-Kugel rotieren sehen. Wenn ich trotzdem etwas Besonderes will, setze ich einen schönen Font oder ein gutes Farbschema ein. Das reicht völlig. Die Zeit, die ich spare, investiere ich in besseren Content oder in die Verbesserung der Ladezeit.

Am Ende zählt nicht, wie viele Technologien ich kenne. Sondern wie gut die Seite funktioniert. Und eine Seite, die in zwei Sekunden lädt und fünf Jahre ohne Update auskommt, ist eine verdammt gute Seite. Das ist die Lektion, die ich gelernt habe, und die ich nicht mehr vergesse. Bremse treten, überlegen, loslegen – aber mit Bedacht.