Ihre Website fühlt sich langsam an, und Sie müssen eine Entscheidung treffen. Sie können weiter raten, welche Korrekturen helfen, oder Sie können herausfinden, was Sie tatsächlich Conversions kostet, bevor Sie einen Sprint für das Falsche verschwenden.
Ein Web-Performance-Audit ist eine strukturierte Diagnose dessen, was eine Website langsam macht. Es misst die tatsächliche Nutzererfahrung, die Serverantwort, das Gewicht der Assets und die Last durch Drittanbieter-Skripte und ordnet dann jeden Engpass danach ein, wie stark er Geschwindigkeit und Umsatz beeinträchtigt. Das Ergebnis ist eine kurze, geordnete Liste, wohin Entwicklungszeit fließen sollte und wohin nicht.
Der Einsatz ist messbar. Ein Benchmark zur Website-Performance im Einzelhandel aus dem Jahr 2025, der die fünfzig größten Einzelhändler der Welt umfasst, ergab, dass ein Händler mit einem Jahresumsatz von mehr als 50 Milliarden US-Dollar 9,4 Sekunden benötigt, um seine Startseite zu laden, und dadurch potenziell zwischen 3,4 und 24,1 Milliarden US-Dollar an entgangenen Conversions pro Jahr verliert. Geschwindigkeit ist Geld, das durch Ihren Funnel fließt, und eine langsame Seite lässt es jeden Tag still und leise entweichen.
Warum die meisten Web-Performance-Audits am Punktestand enden
Die meisten Teams führen ein kostenloses Tool aus, sehen eine grüne Zahl und machen weiter. Genau bei dieser grünen Zahl sollte die eigentliche Arbeit beginnen. Ein hoher Lighthouse-Score misst einen einzelnen simulierten Ladevorgang auf einem schnellen Rechner in einem Rechenzentrum, was selten dem Smartphone entspricht, das Ihr Kunde mit einer langsamen Mobilverbindung in der Hand hält.
Die Lücke zwischen beiden zeigt sich in den Daten. Laut dem HTTP Archive Web Almanac 2025 bestehen nur 48 % der mobilen Ursprünge alle drei Core Web Vitals, gegenüber 56 % auf Desktop, und die Ladegeschwindigkeit ist die Kennzahl, an der Websites am häufigsten scheitern. Ein makelloser Lab-Score kann über Felddaten liegen, die eine ganz andere Geschichte erzählen, und genau so kann ein Audit, das beim Punktestand endet, trotzdem eine langsame Website ausliefern.
Wir sehen dieses Muster ständig, wenn wir ein ins Stocken geratenes Projekt übernehmen. Das vorherige Team hat für das Tool optimiert, die Startseite für die Präsentation optimiert und den Checkout-Prozess, das Dashboard für angemeldete Nutzer und Mobilgeräte unangetastet gelassen. Ein Audit, das sich lohnt, betrachtet die Nutzerpfade, die Umsatz bringen, auf den Geräten, die Ihre Nutzer tatsächlich verwenden.
Was ein Website-Performance-Audit prüft
Ein gründliches Audit arbeitet in Schichten, von den Symptomen, die Ihre Nutzer spüren, bis hinunter zu den Systemen, die sie verursachen. Jede Schicht beantwortet eine andere Frage, und wer eine überspringt, optimiert am Ende etwas, das nie die eigentliche Einschränkung war. In den drei folgenden Bereichen verbirgt sich fast jeder echte Engpass.
Core Web Vitals, die für Nutzer spürbaren Symptome
Die Core Web Vitals sind Googles drei Feldmetriken dafür, wie sich eine Seite für eine reale Person anfühlt. Largest Contentful Paint (LCP) misst das Laden, und Google bewertet 2,5 Sekunden oder weniger als gut. Interaction to Next Paint (INP) misst die Reaktionsfähigkeit, mit einem Zielwert von 200 Millisekunden. Cumulative Layout Shift (CLS) misst die visuelle Stabilität, und Inhalte, die während des Ladens umherspringen, schneiden schlecht ab.
Dies sind Symptome und keine Ursachen, und dieser Unterschied verändert, wie Sie sie lesen sollten. Ein schlechter LCP-Wert sagt Ihnen, dass sich die Seite langsam anfühlt, verrät aber für sich genommen nicht, ob der Übeltäter ein überladenes Hero-Bild, ein langsamer Server oder ein render-blockierendes Skript ist. In den Felddaten von 2025 ist LCP die Kennzahl, an der mobile Websites am häufigsten scheitern, weshalb ein gutes Audit meist bei der Ladegeschwindigkeit zu graben beginnt.
Serverantwort und Asset-Gewicht
Bevor ein Browser überhaupt etwas darstellen kann, muss er eine Antwort von Ihrem Server erhalten. Time to First Byte (TTFB) erfasst diese Wartezeit, und eine langsame TTFB vergiftet jede nachgelagerte Kennzahl, weil nichts anderes beginnen kann, bevor das erste Byte eintrifft. Häufige Ursachen sind nicht indizierte Datenbankabfragen, ein Ursprungsserver ohne Caching-Schicht und ein Server, der in einer Region steht, während Ihre Nutzer in einer anderen sind.
Das Asset-Gewicht ist die andere Hälfte dieser Schicht. Übergroße Bilder, unkomprimierte Schriftarten und Megabytes an JavaScript müssen alle über eine Mobilverbindung übertragen werden, bevor die Seite nutzbar wird. Wenn sich die Wartezeit auf Hosting, Kapazität oder Konfiguration statt auf Code zurückführen lässt, wird aus einer Frontend-Überprüfung ein IT-Infrastruktur-Audit, das die Server, Pipelines und Cloud-Ausgaben untersucht, die der Website zugrunde liegen.
Render-blockierende Ressourcen und Drittanbieter-Skripte
Selbst mit einem schnellen Server und leichten Assets kann eine Seite ins Stocken geraten, weil dem Browser gesagt wurde, er solle warten. Render-blockierendes CSS und JavaScript zwingen den Browser, Dateien herunterzuladen und zu verarbeiten, bevor er irgendetwas anzeigt, sodass ein einziges großes Stylesheet oder ein synchrones Skript im Dokument-Head eine ansonsten schnelle Seite einfrieren lassen kann. Die Abhilfe besteht meist darin, nur das, was die erste Ansicht wirklich braucht, zu verzögern, aufzuteilen oder inline einzubinden.
Drittanbieter-Skripte sind der leisere Übeltäter. Analytics-Tags, Chat-Widgets, A/B-Testing-Tools und Werbe-Pixel öffnen jeweils Verbindungen und führen Code aus, den Sie nicht kontrollieren, und sie neigen dazu, sich anzuhäufen, weil niemand die Verantwortung für ihre Entfernung übernimmt. Ein diszipliniertes Team für individuelle Webentwicklung kann oft eine Sekunde oder mehr zurückgewinnen, indem es einfach prüft, welche Tags noch ihre Daseinsberechtigung haben, und den Rest asynchron lädt.
Wie man die Performance einer Website auditiert
Zu wissen, wie man eine Website auditiert, läuft auf eine wiederholbare Methode hinaus und nicht auf ein Lieblingstool. Das Ziel ist, ehrlich zu messen, jede langsame Kennzahl auf ihre Grundursache zurückzuführen und zu belegen, dass die Korrektur funktioniert hat, bevor man sie als erledigt betrachtet. Die beiden folgenden Schritte verwandeln einen Haufen Zahlen in einen Plan, den Sie einem Entwicklungsteam übergeben können.
Mit Lab- und Felddaten messen
Lab-Daten stammen aus einem kontrollierten Test, etwa wenn Lighthouse oder WebPageTest eine Seite unter festen Bedingungen ausführt. Sie sind wiederholbar und hervorragend zum Debuggen geeignet, weil Sie eine Sache ändern und denselben Test erneut ausführen können. Der Haken ist, dass sie nur eine Maschine auf einer Verbindung abbilden, sodass ein Lab-Score für sich genommen in die Irre führen kann.
Felddaten stammen von echten Nutzern und werden über den Chrome User Experience Report oder Ihr eigenes Real-User-Monitoring erfasst. Sie erfassen die gesamte Bandbreite an Geräten, Netzwerken und Standorten Ihres Publikums, einschließlich der langsamen. Ein glaubwürdiges Audit betrachtet beide gemeinsam und nutzt Felddaten, um zu entscheiden, was wichtig ist, und Lab-Daten, um herauszufinden, warum.
Nachverfolgen, priorisieren, verifizieren
Sobald Sie Zahlen haben, wird die Arbeit zu disziplinierter Detektivarbeit. Jede langsame Kennzahl wird auf eine konkrete Ursache zurückgeführt, nach Wirkung eingestuft und nach der Änderung bestätigt. In der Praxis sieht das so aus:
- Nachverfolgen. Öffnen Sie die Performance-Ablaufverfolgung des Browsers und verfolgen Sie die langsame Kennzahl bis zu ihrer Quelle, sei es eine lange Serverwartezeit, ein schweres Skript oder ein Bild, das spät lädt.
- Priorisieren. Stufen Sie Korrekturen nach der Nutzerwirkung im Verhältnis zum Entwicklungsaufwand ein, sodass ein einzeiliger Caching-Header, der 400 Millisekunden spart, ein zweiwöchiges Refactoring schlägt, das 50 Millisekunden spart.
- Verifizieren. Bringen Sie die Korrektur live und messen Sie in den folgenden Wochen erneut im Feld, denn eine Änderung, die im Labor glänzt, kann für echte Nutzer wirkungslos bleiben.
Genau in dieser Schleife beweist ein ehrliches Audit seinen Wert. Es ersetzt Meinung durch Belege und verhindert, dass ein Team seine besten Stunden mit einer Änderung verbrennt, die sich wichtig anfühlte, aber keine Kennzahl bewegt hat.
Häufige Übeltäter und ihre Lösungen
Nach genügend Audits tauchen immer wieder dieselben Übeltäter auf. Die folgende Tabelle ordnet die am häufigsten gefundenen Ursachen der Korrektur zu, die sie meist behebt, zusammen mit der Kennzahl, die jede davon in der Regel ruiniert. Es ist eine schnelle Möglichkeit, Ihre eigene Website in der Liste zu erkennen, bevor sich auch nur eine einzige Codezeile ändert.
Nicht optimierte Bilder
LCP, Gesamtgewicht der Seite
Moderne Formate wie WebP oder AVIF ausliefern, auf Anzeigegröße skalieren, alles unterhalb des sichtbaren Bereichs per Lazy Loading laden
Render-blockierendes JavaScript
LCP, INP
Skripte verzögern oder aufteilen, nur kritischen Code inline einbinden, ungenutzte Bundles löschen
Kein Caching oder CDN
TTFB, Geschwindigkeit bei wiederholten Besuchen
Browser- und Edge-Caching hinzufügen, statische Assets über ein CDN in Nutzernähe ausliefern
Zu viele Drittanbieter-Skripte
INP, Gesamtladezeit
Jedes Tag prüfen, ungenutzte entfernen, den Rest asynchron laden
Langsame Datenbankabfragen
TTFB
Indizes hinzufügen, teure Abfragen zwischenspeichern, N+1-Abfragemuster beheben
Layoutverschiebung durch spät geladene Assets
CLS
Platz für Bilder und Anzeigen reservieren, Schriftarten vorab laden, keinen Inhalt mehr oberhalb von bestehendem Inhalt einfügen
Durch diese Korrekturen zieht sich ein Muster. Den größten Teil der Geschwindigkeit, die eine normale Website verliert, gewinnt man zurück, indem man Gewicht entfernt und weniger wartet, bevor überhaupt jemand die Anwendung neu schreibt. Das Audit existiert, um Ihnen zu sagen, welche dieser Zeilen Sie tatsächlich etwas kostet, damit Sie in der Reihenfolge der Wirkung korrigieren, statt eine allgemeine Checkliste abzuarbeiten.
Wenn der Engpass unterhalb des Frontends liegt
Manchmal ist das Frontend unschuldig. Sie komprimieren jedes Bild, verzögern jedes Skript, und die Website ist trotzdem langsam, was das Signal dafür ist, dass die Einschränkung tiefer im Stack liegt. Dies ist die Schicht, die Teams am liebsten nicht öffnen möchten, weil die Korrekturen mehr kosten als ein Caching-Header.
Unterhalb des Frontends sind die üblichen Verdächtigen eine überlastete Datenbank, ein Monolith, der sich nicht horizontal skalieren lässt, synchrone Aufrufe an langsame Dienste und eine Architektur, die beim Traffic zum Launch in Ordnung war, aber unter realer Last einknickt. Dies sind Designfragen und keine Optimierungsfragen, und es sind dieselben Fragen, die wir durcharbeiten, wenn wir skalierbare Softwarearchitektur für ein wachsendes Produkt planen. Ein Lasttest, der einen Traffic-Spike nachbildet, deckt sie in der Regel schneller auf als jeder Einzelseiten-Score.
Wenn die Beweise so tief hinweisen, gehört die Korrektur in den Bereich der Architektur, und der richtige nächste Schritt ist ein umfassenderes Software-Entwicklungs-Audit, das Codebasis, Datenmodell und Infrastruktur gemeinsam untersucht, damit Sie die Ursache einmal lösen, statt das Symptom jedes Quartal zu flicken. Offenheit spart hier Geld, denn eine Abfrage neu zu schreiben ist günstig, eine Plattform unter Notfalllast neu aufzubauen ist teuer.
Heute Symptome, morgen Systeme
Ein Performance-Problem, das Sie heute beheben, ist eine Systemfrage, die Sie für morgen beantworten. Jeder Befund ist auch ein Signal dafür, wie Ihr Produkt gebaut ist und wo es unter Druck geraten wird, wenn Sie wachsen. Teams, die Geschwindigkeit als wiederkehrende Praxis behandeln statt als einmalige Aufräumaktion vor dem Launch, halten ihre Websites schnell, während Traffic und Funktionen sich häufen.
Der praktische Schritt besteht darin, ein Audit durchzuführen, bevor Sie annehmen, dass Sie einen Neuaufbau brauchen, und es nach jedem größeren Release erneut durchzuführen. Messen Sie, was Ihre echten Nutzer spüren, verfolgen Sie jede langsame Kennzahl zu ihrer Ursache und korrigieren Sie in der Reihenfolge der Wirkung. Diese Gewohnheit verwandelt Performance von einem Brand, den Sie bekämpfen, in einen Wert, den Sie besitzen.
Wenn sich Ihre Website langsam anfühlt und Sie ein erfahrenes Team möchten, das die eigentliche Ursache findet, bevor Sie ein ganzes Quartal mit Raten verbringen, nehmen Sie Kontakt mit uns auf, und wir helfen Ihnen, die Zahlen zu lesen und das zu korrigieren, was wirklich zählt.
FAQ
Was umfasst ein Web-Performance-Audit?
Ein Performance-Audit deckt vier Schichten ab: Feldmetriken echter Nutzer wie die Core Web Vitals, die Serverantwortzeit, das Gewicht und die Auslieferung von Assets sowie Drittanbieter-Skripte. Ein gründliches Audit führt zudem Lasttests am Backend durch und überprüft die Architektur, um Ihnen anschließend eine priorisierte Liste von Korrekturen zu übergeben, eingestuft nach ihrer Wirkung auf Geschwindigkeit und Umsatz.
Wie lange dauert ein Website-Performance-Audit?
Für eine typische mittelgroße Website dauert eine fokussierte Überprüfung drei bis fünf Werktage: ein bis zwei Tage, um Lab- und Felddaten zu sammeln, ein paar Tage, um Grundursachen nachzuverfolgen, und eine Sitzung, um Korrekturen zu priorisieren. Tiefgehende Lasttests am Backend oder an der Architektur können ein bis zwei Wochen hinzufügen.
Wie oft sollte man ein Performance-Audit durchführen?
Führen Sie mindestens ein- bis zweimal jährlich ein vollständiges Audit durch, zusätzlich zu einer leichteren Prüfung nach jedem größeren Release, Redesign oder jeder neuen Drittanbieter-Integration. Kontinuierliches Real-User-Monitoring zwischendurch erkennt Regressionen frühzeitig, sodass eine langsame Seite Sie nie in Ihrer geschäftigsten Woche überrascht.
Warum ist meine Website langsam, obwohl mein Lighthouse-Score hoch ist?
Ein hoher Lighthouse-Score spiegelt einen einzelnen simulierten Ladevorgang auf einem schnellen Rechner wider, während Ihre Besucher echte Smartphones und Netzwerke nutzen, weshalb ihre Felddaten oft schlechter aussehen. Langsame Server, schwere Drittanbieter-Skripte und Seiten für angemeldete Nutzer, die Lighthouse nie testet, sind die üblichen Gründe für diese Diskrepanz.
Erfahren Sie, wie wir Recruit Media beim Aufbau eines Recruitment-SaaS geholfen haben, das von einem Nasdaq-notierten Unternehmen mit einer Marktkapitalisierung von über 250 Mio. übernommen wurde
