Was ist Frontend? Worauf es bei der Frontend Entwicklung ankommt

Das Frontend ist alles, was Sie auf einer Website im Browser sehen und anklicken. Seit 2012 betreue ich Firmenwebsites und Onlineshops. Dabei sehe ich immer wieder dasselbe: Ein schönes Design scheitert, wenn der Frontend Code schlampig ist. Besucher spüren das als langsame Seiten, springende Buttons und schwer lesbare Texte.

Dieser Artikel ist allerdings kein Karriereplan, und er behandelt auch nicht die Serverseite. Stattdessen erkläre ich, was das Frontend ausmacht, aus welchen Schichten es besteht und worauf Sie bei der Abnahme eines Projekts achten sollten.

Was ist ein Frontend und wofür braucht man es?

Das Frontend ist die Schicht einer Website oder Web App, die im Browser des Besuchers läuft. Es nutzt HTML für die Struktur, CSS für das Aussehen und JavaScript für die Interaktion. Kurz gesagt: Alles, was Besucher sehen, anklicken, lesen oder in Formulare eintippen, ist Aufgabe des Frontends.

Man spricht auch von der Clientseite. Der Kern ist einfach: Der Code läuft auf dem Gerät des Besuchers, nicht auf Ihrem Server. Das ist wichtig, denn Smartphone, Verbindung und Browser Ihrer Besucher kontrollieren Sie nicht.

Zudem ist das Frontend die Brücke zwischen Design und Software. Es verwandelt einen statischen Entwurf aus Figma in eine echte Seite, die auf jeder Bildschirmgröße funktioniert. Wie die Designphase selbst abläuft, zeige ich in meinem Beitrag Webdesign mit Figma Schritt für Schritt.

Wo endet das Frontend und wo beginnt das Backend?

Ich nutze eine einfache Regel. Läuft der Code im Browser des Besuchers, gehört er zum Frontend. Läuft er auf dem Server, gehört er zum Backend. Zum Beispiel sind Felder, Fehlermeldungen und Absendebutton eines Kontaktformulars Frontend. Die Nachricht speichern und per E-Mail versenden, das erledigt dagegen das Backend.

Heute verschwimmt diese Grenze allerdings. Moderne Frameworks erzeugen Seiten auf dem Server und liefern im selben Projekt interaktiven Code an den Browser. Trotzdem bleibt die Verantwortung gleich: Das Frontend bestimmt, was Nutzer sehen und wie sich die Seite anfühlt.

Wenn eine Seite langsam wirkt, stellen Sie deshalb zwei getrennte Fragen. Antwortet der Server langsam? Oder laden Bilder und Skripte im Browser zu spät? Antwortet der Server schnell und die Seite erscheint trotzdem spät, liegt das Problem meist im Frontend. So vermeiden Sie, den Falschen zu beschuldigen und Budget zu verschwenden.

Warum ist HTML das Fundament im Frontend?

HTML legt die Bedeutung fest. Wenn Sie Überschriften, Absätze, Listen, Buttons und Formulare korrekt auszeichnen, verstehen Browser, Screenreader und Suchmaschinen Ihren Inhalt. Anders gesagt: HTML ist nicht nur ein Gerüst, sondern die Sprache der Seite.

Der häufigste Fehler, den ich sehe, ist ein wildes Gerüst aus lauter Div Elementen. Buttons sind dann nur anklickbare Kästen. Optisch wirkt alles gleich. Allerdings erreichen Tastaturnutzer diese Kästen nicht, und Screenreader erkennen sie nicht als Buttons.

Meine kurze Checkliste für semantisches HTML:

• Nutzen Sie pro Seite genau eine H1 und eine logische Reihenfolge der Überschriften.
• Jedes klickbare Element sollte ein echter Button oder Link sein.
• Verbinden Sie jedes Formularfeld mit einem Label.
• Setzen Sie header, nav, main und footer als Bereiche ein.
• Schreiben Sie Alternativtexte, die den Bildinhalt beschreiben.

Auch strukturierte Daten gehören in diese Schicht. Mehr dazu lesen Sie in meinem Beitrag Was ist Schema Markup.

Wie steuert CSS das Aussehen einer Seite?

CSS bestimmt Farben, Schriften, Abstände, Layout und Bewegung. Modernes CSS braucht die Tricks früherer Jahre nicht mehr. Mit Flexbox und Grid bauen Sie komplexe Layouts in wenigen Zeilen.

Andererseits wächst CSS schnell unkontrolliert. Jeder Entwickler ergänzt eine Klasse, und nach wenigen Monaten traut sich niemand mehr, etwas zu löschen. Deshalb empfehle ich, Farben, Schriftgrößen und Abstände von Anfang an als Variablen festzulegen. Das Tool HTML Farbcodes hilft Ihnen, Markenfarben konsistent zu halten.

Ungenutztes CSS ist ein verwandtes Problem. Projekte, die mit einem großen Theme starten, liefern oft Stylesheets aus, die kaum eine Seite braucht. Der Browser lädt und verarbeitet die Datei trotzdem komplett. Lassen Sie daher überflüssige Stile vor dem Launch entfernen.

Auch responsives Design ist Aufgabe von CSS. Media Queries und flexible Einheiten zeigen dieselbe Seite am Smartphone einspaltig und am Desktop dreispaltig. Den Ansatz erkläre ich in Was ist Mobile First Design.

Was bringt JavaScript ins Frontend?

JavaScript fügt Verhalten hinzu. Aufklappmenüs, Tabs, Formularprüfung, Warenkorb und Live Suche hängen davon ab. Kurz gesagt: Es macht aus einem Dokument eine Anwendung.

Allerdings ist JavaScript die teuerste Ressource auf einer Seite. Ein Bild lädt der Browser herunter und zeigt es an. JavaScript muss er herunterladen, parsen, kompilieren und ausführen. Auf Smartphones der Mittelklasse entstehen daraus lange Aufgaben, die den Bildschirm einfrieren.

Meine Regel ist deshalb klar. Was HTML und CSS lösen können, gehört nicht in JavaScript. Ein einfaches Akkordeon funktioniert zum Beispiel mit dem nativen details Element. Somit bleibt der Inhalt sichtbar, selbst wenn ein Skript ausfällt.

Zudem zählt die Ladereihenfolge. Wenn Sie Skripte zurückstellen, die die erste Ansicht nicht braucht, zeichnet der Browser zuerst den Inhalt. Danach ergänzt er die Interaktion. Besucher sehen also eine lesbare Seite statt eines weißen Bildschirms.

Wie wählen Sie ein Framework für das Frontend?

React, Vue, Angular und Svelte zerlegen große Oberflächen in Komponenten. Jede Komponente bringt ihr eigenes Markup, ihren Stil und ihr Verhalten mit. Dadurch ändern Sie einen Button an einer Stelle, und die Änderung erscheint auf hundert Seiten.

Trotzdem braucht nicht jedes Projekt ein Framework. Eine schwere Single Page App für eine Firmenwebsite mit fünf Seiten liefert JavaScript aus, das niemand braucht. Beantworten Sie daher vor der Wahl diese Fragen:

1. Besteht die Seite vor allem aus Lesestoff oder aus ständiger Interaktion?
2. Kann Ihr Team diese Technik über Jahre pflegen?
3. Kann das Framework HTML auf dem Server erzeugen?
4. Sind Community und Dokumentation ausgereift?
5. Wer übernimmt die jährlichen Updates?

Sehr große Plattformen mit mehreren Teams teilen das Frontend manchmal in unabhängige Teile. Diese Architektur beschreibe ich in meinem Beitrag über Micro Frontends, deshalb wiederhole ich sie hier nicht.

Framework oder schlanker Code: was passt zu welchem Projekt?

Die folgende Tabelle ist mein grober Rahmen aus der Praxis. Sie ist also ein Ausgangspunkt, keine feste Regel.

Entscheidend ist also nicht die Frage, was gerade beliebt ist. Die richtige Frage lautet: Was tut der Besucher auf dieser Seite? Treffen Sie die Technikwahl daher erst nach dem Design und dem Inhaltsplan.

Was macht ein Frontend Entwickler konkret im Projekt?

Ein Frontend Entwickler nimmt eine Designdatei und macht daraus eine funktionierende Seite. Die Arbeit geht allerdings weit über das Nachbauen von Bildschirmen hinaus. Er baut Komponenten, testet jede Bildschirmgröße, schreibt das Verhalten von Formularen und bindet Daten aus dem Backend an.

Meine eigene Reihenfolge ist fest. Zunächst ziehe ich gemeinsame Bausteine heraus: Buttons, Karten, Überschriften, Formularfelder. Dann setze ich die Seiten aus diesen Bausteinen zusammen. Schließlich teste ich Tempo, Barrierefreiheit und Browser.

Diese Reihenfolge ist auch für Sie ein gutes Signal. Sagt ein Entwickler, er baue erst alle Seiten und räume später auf, erwarten Sie am Ende uneinheitliche Komponenten. Zudem macht der Start mit Bausteinen spätere Änderungen deutlich günstiger.

Warum darf Barrierefreiheit im Frontend nicht warten?

Barrierefreiheit bedeutet, dass Menschen mit Seh, Hör, motorischen oder kognitiven Einschränkungen Ihre Website nutzen können. Außerdem profitieren ältere Nutzer, Menschen in grellem Sonnenlicht und alle, die einhändig surfen.

Die Lage ist schlechter, als viele denken. Laut WebAIM Million Report 2026 zeigten 95,9 % der untersuchten eine Million Startseiten automatisch erkennbare WCAG Fehler. Zu geringen Kontrast fand der Bericht auf 83,9 % der Startseiten, fehlende Alternativtexte auf 53,1 %.

Die gute Nachricht: Die meisten dieser Fehler liegen im Frontend und kosten wenig. Ein Kontrastproblem ist eine Farbänderung, ein fehlender Alternativtext ein einziges Attribut. Deshalb sollten Sie Barrierefreiheit als Teil des Codes sehen, nicht als Zusatzaufgabe für später.

Für viele Unternehmen ist das zudem Pflicht. Das Barrierefreiheitsstärkungsgesetz setzt den European Accessibility Act in Deutschland um und gilt seit dem 28. Juni 2025 für bestimmte digitale Produkte und Dienstleistungen, darunter viele Angebote im E-Commerce. Klären Sie Ihre Pflichten daher mit Ihrer Rechtsberatung.

Welche Prüfungen zur Barrierefreiheit sollte jedes Frontend bestehen?

Der Maßstab sind die WCAG 2.2 des W3C. Auf Stufe AA braucht normaler Text ein Kontrastverhältnis von mindestens 4,5:1, großer Text 3:1. Außerdem mache ich in jedem Projekt einen kurzen manuellen Test:

• Legen Sie die Maus weg und bewegen Sie sich nur mit der Tabulatortaste durch die Seite.
• Prüfen Sie, ob der Fokusrahmen bei jedem Element sichtbar ist.
• Senden Sie das Formular mit falschen Daten ab und lesen Sie die Fehlermeldung.
• Zoomen Sie auf 200 % und achten Sie auf überlaufenden Text.
• Schalten Sie den Screenreader Ihres Smartphones ein und hören Sie sich das Menü an.

Diese fünf Schritte finden viele Probleme, die automatische Tools übersehen. Nebenbei entdecken Sie auch Schwächen in der Nutzerführung. Die teuersten davon habe ich in UX Fehler, die Umsatz kosten gesammelt.

Wie messen Sie die Leistung im Frontend?

Google misst die Nutzererfahrung mit drei Core Web Vitals. Laut web.dev gelten als gut: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1. Google empfiehlt, diese Werte beim 75. Perzentil der Seitenaufrufe zu erreichen.

LCP zeigt, wann das größte Inhaltselement erscheint. INP misst, wie schnell die Seite auf Klicks und Tippen reagiert; es hat im März 2024 FID abgelöst. CLS misst schließlich, wie stark das Layout beim Laden verrutscht.

Alle drei hängen größtenteils von Entscheidungen im Frontend ab. Wie ich messe, erkläre ich in Google Lighthouse Test.

Wichtig ist dabei der Unterschied zwischen Labordaten und Felddaten. Lighthouse testet einmal in einer kontrollierten Umgebung. Die Search Console zeigt dagegen Daten aus den Browsern echter Besucher. Beide können abweichen, also entscheiden Sie auf Basis der Felddaten.

Was bremst das Frontend am häufigsten aus?

Fast jede langsame Seite, die ich prüfe, hat dieselben Ursachen. Diese Liste ist eine Beobachtung aus der Praxis, keine Rangfolge:

• Große, unkomprimierte Bilder ohne Angabe von Breite und Höhe.
• JavaScript Pakete, die jede Seite lädt, aber kaum eine nutzt.
• Mehrere Skripte für Analyse, Chat und Werbung gleichzeitig.
• Späte Webfonts, durch die Text springt.
• Plugins für Slider und Animationen.

Bilder vor dem Upload zu verkleinern, ist der günstigste Gewinn; dafür eignet sich das Tool Bild verkleinern. Außerdem senken Breite und Höhe an Bildern den CLS direkt. Die Rankingseite beleuchte ich in Wie beeinflusst die Ladezeit SEO.

Wie gehen Sie mit Schriften und Typografie um?

Typografie prägt Lesbarkeit und Markengefühl zugleich. Eine sehr dünne Schrift wirkt am Desktop elegant, am Smartphone ist sie jedoch schwer lesbar. Auch Zeilenlänge und Zeilenabstand beeinflussen den Lesekomfort.

Technisch brauchen Webfonts Sorgfalt. Jeder Schnitt ist eine eigene Datei. Laden Sie vier Schnitte, warten Besucher womöglich auf alle, bevor sie Text sehen. Deshalb nutze ich meist zwei Schnitte und liefere die Schriften von der eigenen Domain aus.

Zeigen Sie zudem eine Ersatzschrift, bis der Webfont da ist. Dann ist der Text sofort lesbar. Eine Ersatzschrift mit ähnlichen Maßen verringert das Springen nach dem Laden. Wie gut Ihre Texte lesbar sind, prüfen Sie mit dem Tool Lesbarkeit prüfen.

Ist Browserkompatibilität heute noch ein Problem?

Weniger als früher, aber es ist nicht verschwunden. Zu Zeiten des Internet Explorer schrieben wir für jede Seite eigene Workarounds. Heute folgen Chrome, Safari, Firefox und Edge den Standards weitgehend. Dennoch unterstützt Safari auf iOS neue Funktionen in CSS und JavaScript manchmal später.

Mein Ansatz heißt Progressive Enhancement. Zunächst bauen Sie ein Grundangebot, das überall funktioniert. Danach ergänzen Sie Verbesserungen für Browser, die neuere Funktionen beherrschen. So kann auch ein Besucher mit altem Smartphone das Formular absenden.

Prüfen Sie vor dem Einsatz einer Funktion die Kompatibilitätstabelle in den MDN Web Docs. Öffnen Sie die Seite vor dem Launch außerdem auf mindestens einem echten iPhone und einem echten Android Gerät. Emulatoren übersehen einiges.

Auch Browsererweiterungen zählen. Werbeblocker verstecken manchmal Elemente mit Klassennamen wie "banner" oder "ad". Nennen Sie Ihre Aktionsbox also besser nicht "adbox", sonst sieht ein Teil der Besucher sie nie.

Warum braucht das Frontend auf Mobilgeräten eigene Aufmerksamkeit?

Google indexiert Websites heute anhand ihrer mobilen Version. Das heißt: Die Seite auf dem Smartphone ist für Google die maßgebliche Fassung. Inhalte, die Sie mobil ausblenden, sind somit auch in der Suche schwächer.

Fehler im Frontend fallen mobil stärker auf. Zu kleine Buttons, Tabellen, die über den Rand laufen, und Popups ohne erreichbaren Schließen Button sehe ich am häufigsten. Zudem führen mobile Prozessoren JavaScript langsamer aus als Desktops.

Meine mobilen Prüfungen liste ich in Mobilfreundlichkeit testen auf. Kurz gesagt: Planen Sie zuerst für das Smartphone und erweitern Sie dann auf breitere Bildschirme.

Wie beeinflusst das Frontend Ihr SEO?

Suchmaschinen verstehen Ihre Seite über das HTML, das Ihr Frontend erzeugt. Überschriftenhierarchie, Linkstruktur, Meta Tags und der Zeitpunkt, an dem Inhalt erscheint, sind daher Entscheidungen im Frontend.

Am riskantesten sind Seiten, die komplett im Browser per JavaScript entstehen. Google kann JavaScript verarbeiten, allerdings kostet das einen Zusatzschritt und Zeit. Zudem lesen manche KI Crawler nur rohes HTML und führen keine Skripte aus. Deshalb halte ich wichtige Inhalte im HTML, das der Server ausliefert.

Links sollten außerdem echte a Elemente mit href sein. Unechte Links, die nur an ein Klickereignis gebunden sind, verfolgen Suchmaschinen nicht. Für Meta Tags spart der Meta Tag Generator Zeit.

Endloses Scrollen ist eine weitere Falle. Lädt eine Produktliste nur beim Scrollen nach, sehen Crawler womöglich nur die ersten Artikel. Bieten Sie daher zusätzlich Seitenlinks an, damit Menschen und Bots jedes Produkt erreichen.

Warum brauchen Formulare im Frontend besondere Sorgfalt?

Ein Formular ist der Moment, in dem Besucher Ihnen etwas geben: Namen, Telefonnummer, Bestellung oder Frage. Deshalb ist es oft der wertvollste Teil der Oberfläche. Gleichzeitig verstecken sich hier die meisten Fehler.

Diese Details prüfe ich bei jedem Formular:

• Das Telefonfeld öffnet am Smartphone eine Zifferntastatur.
• Fehlermeldungen erscheinen direkt am Feld und in klarer Sprache.
• Der Absendebutton verhindert doppelte Klicks während des Sendens.
• Nach dem Absenden folgt eine klare Bestätigung.
• Das automatische Ausfüllen des Browsers funktioniert.

Jedes Detail wirkt klein. Dennoch beeinflusst jedes davon, wie viele Besucher abbrechen. Auch die Übergabe des Absendens als Ereignis an Ihre Webanalyse ist Aufgabe des Frontends. Sonst sehen Sie nicht, welche Kampagne die Anfrage gebracht hat.

Welche Sicherheitsrisiken gibt es im Frontend?

Sicherheit klingt nach Backend. Allerdings birgt auch der Browser echte Risiken. Am bekanntesten ist Cross Site Scripting, kurz XSS: Nutzereingaben landen ungeprüft auf der Seite. Ein Angreifer kann dann eigenes Skript einschleusen.

Außerdem läuft jedes externe Skript mit denselben Rechten wie Ihr eigener Code. Wird der Server eines Chatanbieters kompromittiert, kann dessen Skript Formulardaten auf Ihrer Seite auslesen. Bewerten Sie daher jedes fremde Skript nach echtem Bedarf.

Merken Sie sich noch eine Regel. Prüfungen im Browser dienen der Nutzerführung, nicht der Sicherheit. Liegen Preis, Lager oder Rechteprüfung nur im Frontend, umgeht sie jeder mit den Entwicklertools. Betten Sie außerdem nie geheime API Schlüssel in Frontend Code ein, denn den Quelltext kann jeder lesen.

Wie richten Sie Tests für das Frontend sinnvoll ein?

Tests belegen, dass alte Funktionen nach einer Änderung noch laufen. Bei kleinen Seiten reichen manuelle Prüfungen oft aus. Wachsen Seiten und Komponenten, sparen automatische Tests allerdings Zeit.

Denken Sie an drei Ebenen. Unit Tests prüfen zunächst eine einzelne Funktion oder Komponente. End to End Tests öffnen dann einen echten Browser, füllen Formulare aus und legen Artikel in den Warenkorb. Visuelle Vergleichstests zeigen schließlich pixelgenau, was sich gegenüber der Vorversion verändert hat.

Mein Rat: Schreiben Sie mindestens für kritische Abläufe End to End Tests. Konkret heißt das Kontaktformular, Warenkorb und Checkout. Fallen diese aus, verlieren Sie direkt Geld; schützen Sie sie also zuerst.

Wie erkennen Sie gute Frontend Qualität ohne Code zu lesen?

Qualität erkennen Sie auch von außen. Öffnen Sie die Seite zum Beispiel mit deaktiviertem JavaScript. Erscheint gar kein Inhalt, entsteht die Seite komplett im Browser. Zeigt die Konsole der Entwicklertools ständig rote Fehler, fehlt es an Pflegedisziplin.

Achten Sie zudem auf diese Zeichen: Sieht dieselbe Komponente auf verschiedenen Seiten unterschiedlich aus? Sind Hover und Fokuszustände einheitlich? Sind Fehlermeldungen verständlich? Uneinheitlichkeit bedeutet meist, dass ein gemeinsames Komponentensystem fehlt.

Fragen Sie schließlich nach Versionskontrolle und Dokumentation. Code in einem Repository, eine Änderungshistorie und schriftliche Installationshinweise retten Sie, wenn später jemand anderes übernimmt. Vor allem ist ein Entwickler, der Änderungen offen erklärt, selbst ein Qualitätsmerkmal.

Was prüfen Sie vor der Abnahme eines Frontends?

Das ist meine kurze Abnahmeliste vor dem Projektabschluss. Jeden Schritt können Sie selbst durchführen:

1. Lassen Sie Lighthouse für Mobil und Desktop laufen und speichern Sie die Ergebnisse.
2. Gehen Sie die gesamte Seite mit der Tastatur durch.
3. Senden Sie jedes Formular mit gültigen und ungültigen Daten ab.
4. Öffnen Sie die Seite auf mindestens zwei echten Smartphones und in zwei Browsern.
5. Prüfen Sie, dass die Konsole keine Fehler zeigt.
6. Kontrollieren Sie Bildgrößen und Alternativtexte.
7. Stellen Sie sicher, dass Sie Quellcode und Installationshinweise erhalten.

Das ist kein vollständiges Audit. Trotzdem fängt die Liste die teuersten Fehler vor dem Launch ab. Außerdem hinterlassen Sie dem nächsten Entwickler einen sauberen Ausgangspunkt. Wenn Sie das komplett abgeben möchten, finden Sie Details bei meinem Angebot Webdesign.

Was bestimmt die Kosten für ein Frontend?

Die Zahl einzigartiger Vorlagen und die Tiefe der Interaktion bestimmen die Kosten stärker als die Seitenzahl. Eine Website mit zehn Seiten und drei Vorlagen geht oft schneller als gedacht. Dagegen kann ein einzelner Produktkonfigurator mehr Aufwand bedeuten als der Rest der Seite.

Weitere Kostentreiber sind eigene Animationen, Mehrsprachigkeit, Anbindungen an Drittsysteme und ein hohes Ziel bei der Barrierefreiheit. Zudem verlängern Entwürfe ohne mobile Ansicht und ohne Fehlerzustände die Schätzung und die Korrekturschleifen.

Zusammengefasst: Achten Sie beim Angebotsvergleich nicht nur auf die Summe, sondern darauf, wie klar der Umfang beschrieben ist. Das Angebot sollte die zu testenden Browser, das Leistungsziel und die Übergabe des Quellcodes nennen.

Warum ist Frontend Pflege nie eine einmalige Aufgabe?

Frontend Code altert, weil sich Bibliotheken und Browser ändern. Verliert eine Framework Version den Support, kommen keine Sicherheitsupdates mehr. Ändert ein Browser eine Funktion, kann ein Menü, das gestern lief, heute versagen.

Deshalb empfehle ich, Abhängigkeiten mindestens einmal im Jahr zu aktualisieren und die Prüfungen zu Leistung und Barrierefreiheit zu wiederholen. Hinterfragen Sie außerdem jedes neue Marketingskript, denn Langsamkeit sammelt sich meist schleichend an.

Somit gilt: Das Frontend ist das Gesicht Ihrer Website, das mit Besuchern spricht. Wenn semantisches HTML, ordentliches CSS, maßvolles JavaScript, Barrierefreiheit und Tempo zusammenspielen, spricht Ihre Seite klar zu Menschen und Suchmaschinen.