Die Werkzeuge der Webentwicklung, auf die es wirklich ankommt
Werkzeuglisten veralten schnell und helfen jemandem, der eine Website beauftragt, selten. Was bleibt, ist der Satz *Kategorien*, den ein kompetentes Projekt nutzt, und was ihr Fehlen darüber sagt, wie das Projekt laufen wird.
Dieser Leitfaden behandelt die Werkzeugkategorien, auf die es ankommt, was jede verhindert, und die Fragen, die zeigen, ob eine Entwicklerin so arbeitet.
Die nicht verhandelbaren Kategorien#
Das sind keine Vorlieben. Ein Projekt ohne sie sammelt Risiko an, das im schlechtesten Moment auftaucht — meist wenn etwas kaputtgeht und niemand sagen kann, was sich geändert hat.
| Kategorie | Was sie verhindert | Fragen Sie |
|---|---|---|
| Versionskontrolle | Verlorene Arbeit, unerklärte Änderungen, kein Zurück | „In welchem Repository liegt der Code und bekomme ich Zugang?“ |
| Staging-Umgebung | Testen in der Produktion | „Wo nehme ich ab, bevor es live geht?“ |
| Automatisiertes Deployment | Eine Person, die freitags um 18 Uhr Dateien kopiert | „Wie kommt eine Änderung in die Produktion?“ |
| Backups | Totalverlust | „Wie oft, wohin, und wann haben Sie zuletzt eines zurückgespielt?“ |
| Fehler-Monitoring | Stille Ausfälle, die wochenlang niemand bemerkt | „Wie erfahren Sie, dass etwas kaputt ist?“ |
| Verfügbarkeits-Monitoring | Es vom Kunden zu erfahren | „Wer wird alarmiert, wenn die Website ausfällt?“ |
| Abhängigkeits-Updates | Bekannte Schwachstellen bleiben bestehen | „Wie werden Sicherheitsupdates eingespielt?“ |
Das stärkste einzelne Signal ist die Antwort auf „Wie kommt eine Änderung in die Produktion?“. Wenn es dabei ums Ziehen von Dateien in einen FTP-Client geht, fehlt vermutlich alles andere auf dieser Liste auch.
Build- und Frontend-Werkzeuge#
Hier bewegt sich die Mode am schnellsten und hier ist sie für Sie als Auftraggeber am wenigsten wichtig. Es zählt das Ergebnis, nicht das Werkzeug, das es hervorgebracht hat.
- Ein Build-Schritt, der Assets minimiert, bündelt und optimiert — Seitengewicht ist ein Konversionsproblem, kein Reinheitsproblem.
- Eine Bild-Pipeline, die moderne Formate und mehrere Größen automatisch erzeugt. Von Hand exportierte Bilder werden nie aktuell gehalten.
- Ein CSS-Ansatz mit System — Variablen, Tokens, wie auch immer benannt — statt angesammelter Einzelfallregeln.
- Nur das JavaScript, das die Seite braucht. Ein Framework ist für eine Anwendung eine legitime Wahl und für eine Broschürenseite meist Ballast.
- Browser-Unterstützung schriftlich definiert. „Moderne Browser“ ist keine Spezifikation.
Test- und Qualitätswerkzeuge#
Vollständige automatisierte Testsuiten sind auf einer Marketingseite selten gerechtfertigt. Ein wenig Automatisierung auf den Pfaden, die Geld kosten, ist fast immer gerechtfertigt.
- Automatisierte Prüfungen nur auf den kritischen Pfaden: Checkout, Registrierung, das Hauptkontaktformular.
- Ein automatisch geprüftes Performance-Budget — eine Zahl, die einen Build scheitern lässt, keine Hoffnung.
- Automatisierte Barrierefreiheits-Scans in der Pipeline, im Wissen, dass sie etwa ein Drittel der Probleme finden.
- Browserübergreifende Prüfungen auf den Browsern, die Ihre Analytics tatsächlich zeigt, nicht auf einer Liste von allem.
- Ein Staging-Inhaltsbestand, der echte Textlängen abbildet, einschließlich der unbequemen.
Ein Performance-Budget ist die Automatisierung mit dem höchsten Nutzen für eine Inhaltsseite: Ohne eines steigt das Seitengewicht jeden Monat leise, und niemand ist zuständig.
Worauf Sie Zugriff haben sollten#
Unabhängig davon, welche Werkzeuge die Entwicklung bevorzugt, sollten diese Konten vom ersten Tag an auf Ihren Namen laufen. Beim Kickoff ist das weit leichter zu regeln als nach dem Ende einer Zusammenarbeit.
- Domain-Registrar — auf den Namen Ihrer Organisation, mit Ihren Abrechnungsdaten.
- Hosting-Konto, mit der Entwicklung als Nutzer statt als Eigentümerin.
- Code-Repository, mit Ihrer Organisation als Eigentümerin.
- Analytics- und Search-Console-Properties.
- Jeder Drittanbieterdienst, von dem die Website abhängt: Zahlung, E-Mail, CDN, Fehler-Monitoring.
- Eine schriftliche Liste davon, aufbewahrt dort, wo Ihr Team sie findet.
Häufige Fragen
Muss ich diese Werkzeuge verstehen?
Nein, aber Sie sollten fragen, ob es sie gibt und wer Zugriff hat. Die Fragen in der Tabelle oben beantwortet jede kompetente Entwicklerin in je einem Satz, und Zögern bei den Fragen zu Deployment und Backups ist ein echtes Signal statt einer Stilfrage.
Ist ein JavaScript-Framework nötig?
Für eine Webanwendung meist ja. Für eine Marketing- oder Inhaltsseite meist nicht — und es kostet oft Performance ohne Nutzen, weil der Browser ein Framework laden und ausführen muss, bevor er Text anzeigt, der auch im HTML hätte stehen können. Die richtige Frage ist, welches Problem es auf Ihrer Website löst, und „das nutzen wir eben“ ist keine Antwort.
Was ist ein Performance-Budget?
Eine vereinbarte Grenze — zum Beispiel unter 200 KB JavaScript und Largest Contentful Paint unter 2,5 Sekunden auf den Haupt-Templates —, die automatisch geprüft wird und den Build scheitern lässt, wenn sie überschritten wird. Es wirkt, weil es Performance von etwas, das alle für wichtig halten, in etwas verwandelt, das ein Deployment blockiert.
Woran erkenne ich, dass die Website gewartet wird?
Bitten Sie um eine monatliche Notiz: was aktualisiert wurde, was gepatcht wurde, wie die Verfügbarkeit war und welche Fehler auftraten. Erzeugt eine Wartungspauschale keinen Bericht, lässt sich sorgfältige Wartung schwer von gar keiner unterscheiden, und Sie erfahren es meist während eines Vorfalls.
webentwicklung werkzeugeweb development stackversionskontrollestaging umgebungperformance budgetdeployment pipeline
