Entwicklung leistungsstarker Websites: Ein praxisnaher Leitfaden

Entwicklung leistungsstarker Websites: Ein praxisnaher Leitfaden

Eine leistungsstarke Website lädt schnell, reagiert sofort auf Tippen oder Klicken, bleibt visuell stabil und tut dies auch nach dem zehnten Release – nicht nur am Tag des Launches. Eine solche Website zu entwickeln, hat weniger mit einer Sammlung von Tricks zu tun als mit vier Entscheidungen: Was messen Sie, wie gestalten Sie die Architektur, was darf auf die Seite und wer ist nach dem Go-live für die Geschwindigkeit verantwortlich? Dieser Leitfaden führt durch alle vier Bereiche – mit den Kennzahlen, die Google tatsächlich verwendet, und den Zielkonflikten, die wir in realen Projekten beobachten.

Die wichtigsten Erkenntnisse

• Performance wird anhand realer Nutzer gemessen. Google bewertet die Core Web Vitals am 75. Perzentil der Felddaten. Ein guter Lighthouse-Wert im Labor ist daher eine Plausibilitätsprüfung, aber kein Ergebnis.
• Die Zielwerte sind konkret: LCP von höchstens 2,5 Sekunden, INP von höchstens 200 Millisekunden und CLS von höchstens 0,1.
• Die Geschwindigkeit wird größtenteils früh festgelegt – durch Architektur, Rendering-Strategie und Skripte von Drittanbietern – und lässt sich später nur teuer nachrüsten.
• Die Geschwindigkeit bleibt nur erhalten, wenn sie gesteuert wird: durch Performance-Budgets in der CI, Dashboards für reale Nutzer, die das Unternehmen lesen kann, und regelmäßige teamübergreifende Reviews.
• Performance und Barrierefreiheit gehören zum selben Qualitätsmaßstab. Beide sind Kennzahlen für die Nutzererfahrung, und bei beiden treten unbemerkt Verschlechterungen auf.

Inhaltsverzeichnis

• Was „leistungsstark“ für eine Unternehmenswebsite bedeutet
• Die drei Kennzahlen, nach denen Google bewertet
• Zuerst reale Nutzer messen, Laborwerte an zweiter Stelle
• Architekturentscheidungen, die Ihre Obergrenze festlegen
• Die Checkliste für die Entwicklungsphase
• Performance und Barrierefreiheit sind ein gemeinsamer Qualitätsmaßstab
• Warum Geschwindigkeit sich auszahlt: der geschäftliche Nutzen
• Schnell bleiben: eine Performance-Kultur
• Den Umfang einer leistungsstarken Entwicklung festlegen
• Zusammenarbeit mit Ridiculous Engineering
• FAQ
• Quellen

Was „leistungsstark“ für eine Unternehmenswebsite bedeutet

Ingenieurinnen und Ingenieure definieren Performance meist als Ladezeit. Geschäftsverantwortliche definieren sie als Ergebnisse: Conversions, Leads, abgeschlossene Formulare, weniger Supportanfragen. Beide Sichtweisen sind richtig – die Aufgabe besteht darin, sie miteinander zu verknüpfen.

MDN beschreibt Web-Performance als die Zeit, die eine Website benötigt, um zu laden, interaktiv und reaktionsfähig zu werden, sowie als die Frage, wie flüssig sich Inhalte während der Interaktion mit Nutzern verhalten. Der letzte Punkt ist wichtig. Eine Seite, die schnell dargestellt wird, aber eine halbe Sekunde einfriert, wenn jemand ein Menü öffnet, ist nicht leistungsstark. Sie wirkt nur schnell, ist aber langsam.

In der Praxis weist eine leistungsstarke Website fünf Eigenschaften auf:

1. Sie lädt ihre wesentlichen Inhalte auf Mobiltelefonen der mittleren Preisklasse und in gewöhnlichen Netzwerken schnell – nicht nur auf dem Laptop einer Entwicklerin oder eines Entwicklers.
2. Sie reagiert auf Eingaben ohne sichtbar wahrnehmbare Verzögerung.
3. Während des Ladens springt nichts unerwartet hin und her.
4. Sie bleibt sicher, barrierefrei und wartbar, wenn sich Inhalte und Code ändern.
5. Sie lässt sich ohne vollständige Neuentwicklung skalieren, wenn Traffic, Inhalte oder Integrationen wachsen.

Die Punkte eins bis drei lassen sich heute mit kostenlosen Tools messen. Bei den Punkten vier und fünf scheitern Projekte häufig unbemerkt; darauf kommen wir weiter unten zurück.

Die drei Kennzahlen, nach denen Google bewertet

Googles Core Web Vitals kommen einer gemeinsamen Bewertungsgrundlage der Branche am nächsten. Laut der Definition der Web Vitals auf web.devbesteht eine Seite nur dann, wenn alle drei Kennzahlen den Schwellenwert „gut“ erreichen, gemessen am 75. Perzentil echter Nutzerdaten aus dem Chrome UX Report.

Dieselben Schwellenwerte gelten für Mobilgeräte und Desktop. Alles zwischen „gut“ und „schlecht“ wird als „verbesserungsbedürftig“ eingestuft.

Zwei Details verändern die Planung der Arbeit.

Das 75. Perzentil lässt wenig Spielraum. Bestanden bedeutet, dass drei von vier echten Besuchen das Ziel erreichen. Eine Website, die in Ihrem Büro über Glasfaser schnell ist, aber bei einem Viertel der Kunden mit älteren Android-Telefonen langsam lädt, fällt durch. Ihr Median ist nicht entscheidend.

INP hat die ältere FID-Kennzahl ersetzt. Wie eine ausführliche Analyse der modernen Web-Performance es formuliert, hat diese Umstellung die drei Web Vitals zu LCP, CLS und INP neu ausgerichtet. INP betrachtet die Reaktionsfähigkeit während des gesamten Besuchs. Daher werden umfangreiche JavaScript-Ausführungen nach dem Laden, etwa durch Tag-Manager, Chat-Widgets und übergroße clientseitige Frameworks, nun gegen Sie gewertet.

Messen Sie zuerst echte Nutzer, Laborwerte erst danach

Lighthouse ist nützlich. Es ist aber auch eine Simulation: ein festgelegtes, simuliertes Gerät (typischerweise ein Moto G Power mit 4G), keine angemeldeten Zustände, keine Vielfalt. Fachleute, die über Frontend-Observability schreiben, vertreten denselben Standpunkt, den wir auch gegenüber Kunden hervorheben: Google bewertet das 75. Perzentil des tatsächlichen Traffics aus dem Feld. Daher sollten Daten aus dem Real User Monitoring (RUM) einen höheren Stellenwert haben als ein Laborwert.

Eine praktikable Messkonfiguration besteht aus drei Ebenen:

• Prüfungen im Labor in der CI. Lighthouse oder ein gleichwertiges Tool bei jedem Pull Request, um offensichtliche Regressionen zu erkennen, bevor sie zusammengeführt werden.
• Felddaten aus CrUX. Kostenlos, öffentlich und aus denselben Daten, die Google verwendet. Gut für einen Realitätscheck und den Vergleich mit Wettbewerbern.
• Ihr eigenes RUM. Die web-vitals-Bibliothek oder ein Observability-Tool, das Beacons aus echten Sitzungen an ein Dashboard sendet.

Ein Detail aus derselben Quelle ist es wert, übernommen zu werden. Berichten Sie RUM-Daten nach Routenmuster statt nach dem wörtlichen Pfad, damit /products/blue-widget und /products/red-widget zu einer einzigen /products/:slug Route zusammenfassen. Fügen Sie in jedes Beacon den Release-SHA ein. Ohne beides können Sie nicht feststellen, ob der Deploy vom vergangenen Dienstag die Regression der p75-Reaktionsfähigkeit verursacht hat, und Sie werden darüber diskutieren, statt das Problem zu beheben.

Architekturentscheidungen, die Ihre Obergrenze festlegen

Sie können Bilder endlos optimieren, aber bestimmte Entscheidungen begrenzen, was eine Website leisten kann. Diese Punkte sollten geklärt sein, bevor auch nur eine Zeile Produktionscode geschrieben wird.

Rendering-Strategie

Seiten, die größtenteils aus Inhalten bestehen (Marketingseiten, Dokumentationen, Produktdetailseiten), werden am besten als statisches oder vorgerendertes HTML über ein CDN ausgeliefert. Personalisierte oder datenintensive Seiten können serverseitiges Rendering oder Streaming verwenden. Vollständiges clientseitiges Rendering ist der häufigste Grund dafür, dass ein ansonsten sauberer Build bei LCP und INP Schwierigkeiten bekommt, da der Browser ein großes Bundle herunterladen, parsen und ausführen muss, bevor der Nutzer etwas Nützliches sieht.

Die Frameworks, die professionelle Teams bereits überwiegend einsetzen, machen die besseren Muster zugänglich. Die Berichterstattung zur Stack Overflow Developer Survey 2025 berichtet, dass Node.js, React und Next.js bei professionellen Entwicklern weiterhin die Framework-Nutzung dominieren. Diese weite Verbreitung erleichtert Einstellung und Wartung, aber das Framework garantiert keine Geschwindigkeit. Eine Next.js-Website kann langsam sein, wenn sie alles an den Client ausliefert.

Trennung von Inhalt und Darstellung

Wenn Marketingteams täglich veröffentlichen müssen, wird das CMS ebenfalls zu einer Performance-Frage. Ein Headless-Setup, bei dem Inhalte in einem CMS liegen und ein speziell entwickeltes Frontend sie rendert, ermöglicht schlanke Seiten und bietet Redakteuren dennoch eine gute Authoring-Erfahrung. Die Abwägungen erläutern wir in warum eine Headless-Architektur traditionelle Plattformen überdauert. Für jede Website ist es nicht geeignet. Eine fünfseitige Broschüren-Website benötigt es selten, und die zusätzlichen beweglichen Teile verursachen reale Kosten.

Integrationen und Daten

Langsame Websites sind oft langsam wegen dessen, was sie aufrufen. Eine Seite, die auf drei nicht gecachte API-Anfragen an ein CRM, einen Preisdienst und einen Personalisierungsanbieter wartet, bleibt langsam, ganz gleich, wie gut das CSS geschrieben ist. Legen Sie früh fest, was zur Build-Zeit abgerufen wird, was am Edge gecacht wird und was geladen wird, nachdem die Seite nutzbar ist. Unser Beitrag zu Anpassung und Datenintegration geht näher darauf ein.

Wenn Sie außerdem entscheiden, wie viel der Plattform Sie selbst besitzen und betreiben möchten, gilt dieselbe Logik in größerem Maßstab. Eine Checkliste für Eigenentwicklung oder Zukauf hilft dabei, zu beurteilen, wann sich ein eigenes Frontend lohnt. Für eine umfassendere Perspektive darauf, wie Systeme so strukturiert werden, dass sie mit dem Wachstum Schritt halten, ist dieser Überblick über skalierbare Systeme eine sinnvolle ergänzende Lektüre.

Die Checkliste für die Build-Zeit

Sobald die Architektur solide ist, kommt es auf die tägliche Arbeit an. Dies sind die Punkte, die Feldmetriken am zuverlässigsten verbessern.

Bilder und Medien. Bilder sind in der Regel das größte Element auf der Seite und damit meist auch das LCP-Element. Verwenden Sie moderne Formate, passen Sie die Größe an das Layout an, laden Sie Inhalte unterhalb des sichtbaren Bereichs verzögert und laden Sie das Hero-Bild niemals verzögert. Wir haben einen praxisnahen Leitfaden zur Optimierung von Webbildern verfasst, der Format- und Größenentscheidungen ausführlich behandelt.

JavaScript. Liefern Sie weniger davon aus. Teilen Sie Bundles nach Route auf, verzögern Sie alles, was für die erste Interaktion nicht benötigt wird, und unterteilen Sie lange Aufgaben, damit der Hauptthread auf Eingaben reagieren kann. Das ist der wichtigste Hebel für INP.

Schriftarten. Beschränken Sie sie auf die benötigten Zeichen, laden Sie die kritischen vor und legen Sie sinnvolle Fallbacks fest, damit der Text nicht umfließt, sobald die Webschrift geladen wird. Ein solcher Umbruch ist eine häufige Ursache für CLS.

Layoutstabilität. Reservieren Sie mit expliziten Abmessungen oder Seitenverhältnissen Platz für Bilder, Einbettungen, Anzeigen und Cookie-Banner. Inhalte, die spät erscheinen, sollten bereits lesbare Inhalte nicht verschieben.

Caching und Auslieferung. Verwenden Sie ein CDN, legen Sie für gehashte statische Assets lange Cache-Laufzeiten fest und cachen Sie HTML, sofern die Personalisierung dies zulässt.

Skripte von Drittanbietern. Jedes Tag hat einen Verantwortlichen und einen Grund – andernfalls wird es entfernt. Prüfen Sie sie vierteljährlich. Analyse-, Chat-, A/B-Test- und Heatmap-Tools häufen sich schneller an, als sich irgendjemand daran erinnert, ihrer Einführung zugestimmt zu haben.

Wenn Sie sehen möchten, wie das von Anfang bis Ende aussieht, haben wir dokumentiert eine moderne Transformation der Website-Performance von verworren zu sauber.

Performance und Barrierefreiheit sind ein gemeinsamer Qualitätsmaßstab

Teams finanzieren Geschwindigkeit und Barrierefreiheit häufig aus unterschiedlichen Budgets und prüfen sie zu verschiedenen Zeitpunkten. Diese Trennung ist ein Fehler. Die Analyse von Siteimprove zu Core Web Vitals und WCAG 2.2 beschreibt sie als zwei Hälften desselben Systems: Die eine misst das Nutzungserlebnis in Bezug auf Performance, die andere das Zugangserlebnis – und beide sollten gemeinsam gesteuert werden.

Dabei gibt es auch einen praktischen Vorbehalt. Dieselbe Analyse weist darauf hin, dass automatisierte Tools wie axe-core nur etwa 30 bis 40 Prozent der Barrierefreiheitsverstöße erkennen. Eine manuelle Prüfung durch Experten ist daher weiterhin erforderlich. Ein grüner automatisierter Bericht ist ein Ausgangspunkt. Tastaturnavigation, das Verhalten von Screenreadern und die Fokusreihenfolge müssen von einem Menschen geprüft werden.

Die Überschneidung zeigt sich auch im Code. Semantisches HTML ist schlanker und schneller als ein Durcheinander aus div-Elementen. Stabile Layouts helfen Menschen mit kognitiven und motorischen Einschränkungen. Weniger Arbeit auf dem Main Thread hilft Menschen, die assistive Technologien mit älterer Hardware nutzen. Für die SEO-Perspektive dieser Leitfaden zu Barrierefreiheit und SEO verknüpft beide Themen. Unsere eigene Perspektive auf die Designseite finden Sie unter barrierefreies Webdesign für eine inklusive digitale Welt.

Warum sich Geschwindigkeit auszahlt: der geschäftliche Nutzen

Führungskräfte finanzieren selten „besseres LCP“. Sie finanzieren Umsatz, Leads und geringere Akquisekosten. Das stärkste öffentlich bekannte Beispiel ist Farfetch. Laut der Fallstudie von web.devstellte der Händler einen Zusammenhang zwischen den Core Web Vitals und Geschäftskennzahlen her, entwickelte einen „Performance Business Case Calculator“, um Produktentscheidungen zu unterstützen, und nutzte ihn, um teamübergreifend eine Performance-Kultur aufzubauen. Die wichtigste Erkenntnis betrifft weniger einen einzelnen Prozentsatz als die Methode: Verknüpfen Sie jede Geschwindigkeitskennzahl mit einem KPI, den Ihre Führungskräfte bereits verfolgen.

Seien Sie auch bei den Grenzen ehrlich. Die Ergebnisse unterscheiden sich je nach Website und Seitentyp. Eine Analyse des LCP durch Blue Triangle kommt zum selben Schluss: Geschwindigkeit beeinflusst Onlineunternehmen, aber in welchem Ausmaß, hängt vom Design und anderen Faktoren ab. Testen Sie Ihre eigenen Daten, bevor Sie Ihrem Vorstand eine Umsatzsteigerung versprechen. Unser Artikel über die Erstellung von Websites, die konvertieren betrachtet, welchen Stellenwert Geschwindigkeit neben Messaging und UX einnimmt.

Schnell bleiben: eine Performance-Kultur

Die häufigste Entwicklung: Eine Website startet schnell und wird dann innerhalb von 18 Monaten langsamer, während Kampagnen, Plugins und Funktionen hinzukommen. Niemand hat beschlossen, sie langsamer zu machen. Niemand war dafür verantwortlich, sie schnell zu halten.

Die zuvor zitierten Praktiker beschreiben eine „Performance-Kultur“ mit drei Gewohnheiten, denen wir voll und ganz zustimmen:

1. Automatisierte Performance-Budgets, die in CI durchgesetzt werden. Ein Pull Request, der das Bundle oder das LCP über ein vereinbartes Limit hinaus vergrößert, lässt den Build fehlschlagen – genauso wie ein nicht bestandener Test.
2. RUM-Dashboards, die das Unternehmen lesen kann. Stellen Sie Felddaten nicht nur der Entwicklung, sondern auch Marketing und Produktmanagement zur Verfügung.
3. Regelmäßige Abstimmungen zwischen Entwicklung, Produktmanagement und Marketing. Geschwindigkeit ist eine gemeinsame Kennzahl mit Geschäfts-KPIs und keine Aufgabe des Tech-Teams.

Eine konsequente Testpraxis unterstützt dies. Fehleranfällige oder inkonsistente Umgebungen führen zu irreführenden Performance- und Regressionsergebnissen. Deshalb veröffentlichen wir auch einen Leitfaden zur Verwaltung von Testumgebungen.

So legen Sie den Umfang eines hochperformanten Builds fest

Wenn Sie ein Projekt planen, beginnen Sie mit Fragen, die das Briefing realistisch machen:

• Welche Seiten generieren Umsatz oder Leads, und welche Felddaten weisen sie derzeit auf?
• Welche Geräte und Netzwerke verwenden Ihre tatsächlichen Besucher?
• Welche Integrationen befinden sich auf dem kritischen Pfad eines Seitenaufrufs?
• Wer bearbeitet Inhalte, wie oft geschieht das, und wie können diese Personen Inhalte veröffentlichen, ohne die Performance zu beeinträchtigen?
• Welche Anforderungen gelten an Barrierefreiheit und Compliance?
• Wem obliegt die Verantwortung für die Performance-Budgets nach dem Launch?

Für den Budgetkontext bei größeren Projekten finden Sie in unserem Beitrag zu Budgets für individuelle Softwareentwicklung realistische Größenordnungen. Die passende Größe ist besser als das Maximum: Eine gut entwickelte statische Website mit einem Headless-CMS ist oft leistungsfähiger als eine aufwendige Plattform, deren Betrieb dreimal so viel kostet.

Zusammenarbeit mit Ridiculous Engineering

Wenn Sie dies von einem erfahrenen Team umsetzen lassen möchten, das direkt mit Ihnen arbeitet, ist das genau unser Angebot. Ridiculous Engineering ist eine in Colorado ansässige Beratung für Softwareentwicklung mit Hauptsitz in Lafayette. Wir konzipieren, entwickeln und modernisieren Websites und Webanwendungen mit Blick auf die Geschäftsziele – nicht nur auf den Lighthouse-Score. Unser Service für Website-Design und -Entwicklung umfasst Architektur, Frontend-Entwicklung, Arbeiten mit Headless-CMS und UX, und unsere Praxis für UX und Barrierefreiheit stellt sicher, dass inklusives Design im selben Kontext berücksichtigt wird. Wenn Ihre Website Teil eines größeren Systems ist, sehen Sie sich unsere Arbeit im Bereich individuelle Softwareentwicklung an oder sprechen Sie mit uns über eine Überprüfung der Performance.

FAQ

Wie messen Sie die Performance einer Website?

Beginnen Sie mit Felddaten: dem Chrome UX Report und Ihrem eigenen Real-User-Monitoring, bewertet anhand der Schwellenwerte der Core Web Vitals am 75. Perzentil. Verwenden Sie Lighthouse in der CI als schnelle Prüfung auf Regressionen, nicht als abschließende Bewertung. Segmentieren Sie nach Route und Release, damit Sie eine Änderung einem bestimmten Deployment zuordnen können.

Was ist ein guter Core-Web-Vitals-Score?

Laut web.devbedeutet „gut“ einen LCP von höchstens 2,5 Sekunden, einen INP von höchstens 200 Millisekunden und einen CLS von höchstens 0,1 – jeweils am 75. Perzentil. Eine Seite muss alle drei Werte erfüllen, um die Bewertung zu bestehen. Die Schwellenwerte sind für Mobilgeräte und Desktop gleich.

Wie viel kostet es, eine Entwicklerin oder einen Entwickler für eine Website zu beauftragen?

Das hängt vom Umfang, den Integrationen und der Erfahrung des Teams ab. Als Richtwert für die Arbeitskosten nennt das U.S. Bureau of Labor Statistics einen Medianjahreslohn von 92.650 $ für Webentwickler mit Stand Mai 2025. Dabei handelt es sich um ein Gehalt; Gemeinkosten der Agentur, Design, Qualitätssicherung und Projektmanagement sind nicht enthalten. Die Projektkosten variieren stark. Bitten Sie daher jeden Anbieter um eine Aufschlüsselung der enthaltenen Leistungen.

Kann ich mir Webentwicklung selbst beibringen?

Ja, für persönliche Projekte und kleinere Websites. Die Grundlagen von HTML, CSS und JavaScript sind weithin verfügbar. Eine produktive Website mit strengen Anforderungen an Performance, Sicherheit und Barrierefreiheit zu entwickeln, ist jedoch eine andere Aufgabe – und hier verdienen erfahrene Entwicklerinnen und Entwickler ihr Honorar. Die meisten Geschäftsteams profitieren davon, wenn ein erfahrenes Team die Architektur verantwortet und überprüft.

Quellen

• web.dev: Web Vitals
• web.dev: Fallstudie zu Farfetch
• Frontend-Observability und Web Vitals
• Die Wissenschaft moderner Web-Performance
• Siteimprove: Core Web Vitals und WCAG
• Stack Overflow Developer Survey 2025: Berichterstattung (Habr)
• Blue Triangle: Fallstudie zu Core Web Vitals und LCP
• MDN: Web-Performance
• U.S. Bureau of Labor Statistics: Occupational Outlook Handbook

Empfohlen

• Die Kunst der Webbilder meistern: Bilder für den Erfolg im Jahr 2024 auswählen und optimieren
• Von der Komplexität zur Klarheit: Eine moderne Transformation der Website-Performance
• Das moderne Web gestalten: Das Geheimnis erfolgreicher Websites, die konvertieren
• Geschwindigkeit ist entscheidend: Die schnelle Einführung von Technologien meistern