Meine 20 Jahre im Web: Was sich verändert hat, und was geblieben ist

Es begann weniger glamourös, als „Tech-Karriere“ klingt

Ich arbeite seit rund 20 Jahren im Web. Angefangen habe ich als Webmaster für einen Onlineshop, ohne großen Karriereplan und lange bevor jeder berufliche Schritt als persönliche Marke präsentiert wurde.

Die Aufgaben waren sehr konkret: Produkte einpflegen, Kategorien organisieren, Inhalte aktualisieren, Fehler finden und Probleme beheben, die grundsätzlich im unpassendsten Moment auftraten. Manchmal ging es um Gestaltung, manchmal um Code und oft einfach darum, dass der Shop wieder funktionieren musste.

Ab etwa 2010 wurde die Entwicklung von Websites endgültig zu meinem beruflichen Schwerpunkt. Aus einzelnen Aufgaben wurde ein Handwerk und daraus eine Laufbahn über verschiedene Unternehmen, Märkte, Branchen und technische Systeme hinweg.

Diese frühen Jahre haben meine Sicht auf Websites stärker geprägt als jedes spätere Framework. Ich habe gelernt, eine Website nicht nur als visuelle Oberfläche zu betrachten, sondern als laufendes Geschäftssystem, das Inhalte, Technik, Nutzer und interne Prozesse miteinander verbindet.

Heute arbeite ich an der Schnittstelle von Frontend-Entwicklung, Webdesign, UX, Performance, Barrierefreiheit, SEO und Conversion-Optimierung. Die Werkzeuge sind moderner geworden, aber die grundlegende Aufgabe ist dieselbe geblieben: eine Website muss für die Menschen funktionieren, die sie besuchen, und für das Unternehmen, das sie betreibt.

Ich habe mehrere „Revolutionen“ im Web erlebt

In zwei Jahrzehnten hat sich der technische Alltag mehrfach vollständig verändert:

• statisches HTML und Tabellenlayouts
• CSS-basierte Layouts und semantischeres Markup
• Browserweichen und endlose Kompatibilitätsprobleme
• die jQuery-Ära
• responsive Design und Mobile-first
• WordPress in sehr unterschiedlichen Unternehmensumgebungen
• komponentenbasierte Frameworks wie Vue, React, Nuxt und Next.js
• der Wechsel von FTP-Uploads zu Git, automatisierten Tests und CI/CD
• moderne Analytics, A/B-Tests und datenbasierte Produktarbeit
• KI als Unterstützung bei Planung, Entwicklung, Refactoring und Qualitätssicherung

Fast jede neue Welle kam mit demselben Versprechen: Jetzt wird Webentwicklung endlich einfach.

Das ist nie wirklich passiert.

Neue Werkzeuge machen bestimmte Aufgaben schneller und lösen reale Probleme. Gleichzeitig schaffen sie neue Abhängigkeiten, neue Komplexität und neue Möglichkeiten, schlechte Entscheidungen effizienter umzusetzen.

Ein modernes Framework verhindert keine unklare Navigation. Ein Page Builder formuliert kein überzeugendes Angebot. Ein KI-Assistent weiß nicht automatisch, welche Kunden ein Unternehmen erreichen möchte oder welche Kompromisse im jeweiligen Projekt sinnvoll sind.

Werkzeuge verstärken Entscheidungen. Sie ersetzen kein Urteilsvermögen.

Die wichtigsten Fragen haben sich kaum verändert

Der technische Stack hat sich mehrfach gewandelt. Die nützlichen Fragen sind fast dieselben geblieben:

• Welches Problem lösen wir?
• Für wen bauen wir?
• Was muss ein Besucher verstehen?
• Warum sollte er uns vertrauen?
• Welchen nächsten Schritt soll er gehen?
• Wie erkennen wir, ob die Website ihre Aufgabe erfüllt?

Fehlen klare Antworten, wird selbst eine technisch moderne Website schnell zu einem teuren Platzhalter.

Ich habe Websites mit hervorragenden Lighthouse-Werten gesehen, deren Angebot kaum zu verstehen war. Ich habe visuell beeindruckende Seiten gesehen, auf denen Nutzer nicht wussten, wie sie Kontakt aufnehmen können. Und ich habe schlichte Websites gesehen, die gut funktionierten, weil Zielgruppe, Botschaft und nächster Schritt glasklar waren.

Performance ist wichtig. Gestaltung ist wichtig. SEO ist wichtig. Aber keines davon rettet eine Website, die nicht verständlich macht, was das Unternehmen anbietet und warum es relevant ist.

Technologie sollte dem Projekt dienen

In der Webbranche wird die Auswahl einer Technologie häufig wie eine Identitätsfrage behandelt. WordPress, Webflow, Framer, Nuxt, Next.js oder ein individuell entwickeltes System werden zu Lagern, denen man sich anschließen soll.

Nach vielen Jahren sehe ich das pragmatischer.

Die richtige Technologie hängt davon ab:

• wer die Website nach dem Launch pflegt
• wie häufig sich Inhalte ändern
• welche Integrationen benötigt werden
• wie wichtig individuelle Funktionen sind
• welche internen Fähigkeiten vorhanden sind
• wie hoch Budget und Risikobereitschaft sind
• wie lange die Lösung sinnvoll betrieben werden soll

Ein technisch spannender Stack ist nicht automatisch die richtige Wahl. Wenn ein kleines Team für jede Textänderung einen Entwickler benötigt, ist die Lösung möglicherweise am eigentlichen Bedarf vorbeigegangen.

Umgekehrt reicht ein einfacher Baukasten nicht immer aus, wenn Performance, Mehrsprachigkeit, komplexe Daten oder besondere Nutzerabläufe entscheidend sind.

Die beste Technologie ist nicht die modernste auf einer Konferenzfolie. Es ist diejenige, die das konkrete Problem zuverlässig löst und später nicht unnötig im Weg steht.

Performance, Barrierefreiheit und Wartbarkeit gehören zusammen

Früher wurden Performance, Barrierefreiheit und Wartbarkeit häufig als getrennte technische Themen behandelt. Für mich sind sie Bestandteile derselben Qualitätsfrage.

Eine Website, die schnell lädt, aber mit der Tastatur nicht bedienbar ist, ist unvollständig. Eine visuell überzeugende Seite, die auf einem durchschnittlichen Smartphone ruckelt, ist nicht wirklich gut gestaltet. Und eine Website, für deren kleinste Änderung Spezialwissen nötig ist, verursacht langfristig andere Kosten.

Bei der Performance-Optimierung einer Marketing-Website konnte ich beispielsweise eine Verbesserung von GTmetrix B auf A erreichen, mit ungefähr:

• 91 Performance
• 96 Structure
• rund 1,2 Sekunden LCP
• etwa 6 Millisekunden Total Blocking Time
• CLS 0

Dahinter standen keine geheimen Tricks, sondern konsequente Arbeit an Bildern, Schriftarten, JavaScript, Drittanbieter-Skripten und dem tatsächlichen Ladeverhalten der wichtigsten Templates.

Diese Werte sind hilfreich, weil sie einen Teil der Nutzererfahrung messbar machen. Sie sind aber nicht das Geschäftsergebnis selbst. Eine Seite kann in 1,2 Sekunden laden und trotzdem nichts bewirken, wenn sie danach eine austauschbare Botschaft zeigt.

Deshalb gehören technische Qualität, verständliche Inhalte, Barrierefreiheit und klare Conversion-Pfade in dasselbe Gespräch.

Von neuen Frameworks zu besseren Ergebnissen

In früheren Jahren habe ich neue Frameworks und Tools sehr eng verfolgt. Das war sinnvoll: Wer im Web arbeitet, muss lernen und mit Veränderungen umgehen können.

Heute interessiert mich weniger, ob etwas neu ist, und stärker, ob es einen messbaren Vorteil bringt.

Ich frage eher:

• Versteht ein Besucher das Angebot schneller?
• Findet er relevante Informationen leichter?
• Kann er den nächsten Schritt ohne unnötige Reibung gehen?
• Funktioniert die Seite auf einem normalen Smartphone und einer durchschnittlichen Verbindung?
• Kann das Kundenteam die Website nach dem Launch selbst sinnvoll pflegen?
• Bleibt die technische Grundlage stabil, wenn neue Inhalte und Funktionen hinzukommen?

Das klingt weniger spektakulär als die nächste große Technologiewelle. Für Unternehmen ist es meistens wertvoller.

Experimentieren ersetzte einen Teil der Meinungsdebatten

Seit ungefähr 2019 gehören strukturierte A/B-Tests und Experimente zu meiner Arbeit an UX und Conversion.

Das hat meine Sicht auf Gestaltung weiter verändert. Viele Diskussionen über Überschriften, Handlungsaufforderungen oder Seitenstrukturen werden geführt, als gäbe es eine objektiv richtige Antwort, die eine erfahrene Person nur erkennen müsse.

Erfahrung hilft, bessere Hypothesen zu entwickeln. Sie garantiert aber nicht, dass eine Änderung bei echten Besuchern funktioniert.

Einige Experimente liefern klare Verbesserungen. Viele enden ohne eindeutigen Gewinner. Auch das ist nützlich: Ein flaches Ergebnis kann verhindern, dass eine Änderung allein aufgrund interner Begeisterung veröffentlicht wird.

Die wichtigste Erkenntnis ist nicht, dass alles getestet werden muss. Es ist, dass Meinung und Wirkung nicht dasselbe sind.

KI ist ein Multiplikator, keine Abkürzung

KI ist die jüngste große Veränderung in meinem Arbeitsalltag. Ich nutze sie für erste Entwürfe, Recherche, Codegerüste, Refactoring, Tests, Übersetzungen und Reviews.

Richtig eingesetzt spart sie viel Zeit. Sie kann Zusammenhänge in großen Codebasen schneller sichtbar machen, Varianten vorschlagen und repetitive Arbeit reduzieren.

Sie kann aber ebenso schnell durchschnittliche Texte, unnötig komplizierten Code und überzeugend formulierte Fehler produzieren.

Deshalb bleibt die menschliche Prüfung entscheidend:

• Passt die Lösung zum eigentlichen Geschäftsproblem?
• Ist der Code sicher, verständlich und wartbar?
• Stimmen die Fakten?
• Ist die Sprache konkret und markengerecht?
• Funktioniert die Benutzeroberfläche auch außerhalb des idealen Beispiels?
• Würde ich das Ergebnis unter meinem eigenen Namen veröffentlichen?

Ich sehe KI als Multiplikator, nicht als Ersatz für Fachwissen. Sie macht gute Arbeit schneller, wenn jemand die Qualität beurteilen kann. Ohne diese Beurteilung macht sie auch schlechte Arbeit schneller.

Unterschiedliche Märkte, ähnliche Probleme

Im Laufe der Jahre habe ich mit Unternehmen und Teams aus Serbien, Norwegen, Schweden, Slowenien, Kroatien und Deutschland gearbeitet.

Die Märkte, Sprachen und Erwartungen unterscheiden sich. Die grundlegenden Probleme ähneln sich erstaunlich oft:

• Das Angebot ist intern klarer als für Außenstehende.
• Die Website ist optisch modern, aber langsam oder schwer bedienbar.
• Inhalte sind über Jahre gewachsen, ohne klare Struktur.
• Niemand weiß genau, wer nach dem Launch für die Website verantwortlich ist.
• Das Unternehmen plant einen vollständigen Relaunch, obwohl gezielte Verbesserungen möglicherweise sinnvoller wären.

Je mehr Projekte ich sehe, desto weniger glaube ich an universelle Lösungen. Gute Arbeit beginnt mit dem Kontext.

Nicht jedes Problem braucht eine neue Website

Menschen kommen häufig mit einer bestehenden Website, einer Idee oder einem Angebot für einen Relaunch und stellen im Kern dieselbe Frage:

Lösen wir überhaupt das richtige Problem?

Manchmal lautet die Antwort: Ja, eine neue Website ist sinnvoll.

Manchmal braucht es zunächst eine klarere Struktur, bessere Leistungsseiten, eine verständlichere Positionierung oder Reparaturen an mobiler Nutzung, Performance und Formularen.

Und manchmal ist der beste nächste Schritt kein Relaunch, sondern ein ehrlicher Audit, der zeigt, was bereits funktioniert und wo tatsächlich Geld und Aufmerksamkeit verloren gehen.

Nach rund 20 Jahren im Web ist das vielleicht meine wichtigste Veränderung: Ich möchte nicht möglichst schnell eine bestimmte Lösung verkaufen. Ich möchte zuerst verstehen, welche Verbesserung für das Unternehmen wirklich sinnvoll ist.

Klarheit zuerst. Werkzeuge danach.

Wenn Sie über Ihr Projekt sprechen möchten, können Sie sich gerne bei mir melden. Ich verspreche keine Magie, sondern direktes Feedback auf Grundlage dessen, was ich in zwei Jahrzehnten im Web funktionieren und scheitern gesehen habe.

Möchten Sie Ihr Projekt gemeinsam durchdenken?

Buchen Sie ein kurzes Gespräch darüber, wo Sie aktuell feststecken und was „besser“ für Ihr Unternehmen konkret bedeuten soll, nicht nur für das Erscheinungsbild Ihrer Startseite.