Website prüfen - Erreichbarkeit, Tempo und Funktionen richtig bewerten

Eine Website kann erreichbar wirken und trotzdem langsam, fehlerhaft oder für viele Besucher unbenutzbar sein. Ein gründlicher Check der Site sollte deshalb nicht bei der Frage enden, ob eine Startseite geladen wird, sondern auch Antwortzeiten, HTTP-Status, Sicherheit, mobile Darstellung und zentrale Funktionen prüfen. Ich zeige, wie ich dabei vorgehe, welche Messwerte wirklich zählen und welchen Einfluss moderne Frameworks auf die Diagnose haben.

Was bei einer Website-Prüfung tatsächlich gemessen wird

Ich trenne bei jedem Website-Check zuerst zwei Fragen. Ist die Website erreichbar? Und funktioniert sie schnell und zuverlässig genug für echte Nutzer? Uptime beantwortet nur die erste Frage. Performance beschreibt dagegen, wie lange Inhalte sichtbar werden, wie schnell die Seite reagiert und ob sich das Layout während des Ladens verschiebt.

Die technische Prüfung beginnt auf mehreren Ebenen. DNS muss die Domain zur richtigen Infrastruktur führen, die TLS-Verbindung muss gültig sein und der Webserver sollte einen passenden HTTP-Status liefern. Erst danach lohnt sich die Analyse von HTML, JavaScript, Bildern, Datenbankabfragen und Drittanbieter-Diensten.

Ein schneller Test von nur einem Standort kann täuschen. Ein Server in Frankfurt antwortet möglicherweise in 120 Millisekunden, während Besucher aus den USA oder aus ländlichen Regionen deutlich länger warten. Für eine realistische Einschätzung kombiniere ich deshalb einen lokalen Test mit Messungen aus mehreren Regionen und, wenn vorhanden, echten Nutzerdaten.

HTTP-Status, DNS und TLS richtig einordnen

Der HTTP-Status ist einer der schnellsten Hinweise auf die Ursache eines Problems. Ein 200-Status bedeutet, dass eine Ressource erfolgreich ausgeliefert wurde. Ein 301 oder 308 weist auf eine dauerhafte Weiterleitung hin, während 404 für eine nicht gefundene Ressource und 500 für einen Fehler auf dem Server steht.

Warum DNS-Fehler oft wie ein Serverausfall aussehen

Wenn die Domain nicht aufgelöst wird, erreicht der Browser den Webserver gar nicht. Ursachen sind häufig ein falscher A- oder AAAA-Eintrag, ein abgelaufener Nameserver-Vertrag oder eine fehlerhafte Änderung beim Domainumzug. Ein DNS-Problem lässt sich nicht durch schnelleres Frontend-JavaScript beheben, weshalb ich diese Ebene immer zuerst ausschließe.

Das Zertifikat ist mehr als ein grünes Schloss

Ein gültiges TLS-Zertifikat schützt die Verbindung, sagt aber nichts über die Geschwindigkeit oder die Qualität der Website aus. Ich prüfe zusätzlich Ablaufdatum, Zertifikatskette, unterstützte Protokolle und ob alle Ressourcen ebenfalls über HTTPS geladen werden. Gemischte Inhalte können Funktionen blockieren, besonders bei eingebetteten Skripten, Formularen oder Zahlungsdiensten.

Auch Weiterleitungen verdienen Aufmerksamkeit. Eine Kette aus drei oder vier Sprüngen verlängert die Antwortzeit und erschwert Suchmaschinen die Verarbeitung. Eine kanonische HTTPS-Adresse mit höchstens einem notwendigen Redirect ist in der Praxis meist die sauberere Lösung.

Performance mit den richtigen Kennzahlen bewerten

Ein hoher Laborscore sieht gut aus, ersetzt aber keine echte Analyse. Für die Nutzererfahrung achte ich vor allem auf die Core Web Vitals. Sie betrachten, wann der wichtigste Inhalt sichtbar wird, wie schnell die Seite auf Eingaben reagiert und ob sich Elemente beim Laden verschieben.

Diese Werte sollten idealerweise beim 75. Perzentil im grünen Bereich liegen. Das bedeutet, dass mindestens drei Viertel der gemessenen Besuche den Zielwert erreichen. Ein einzelner schneller Test auf einem leistungsfähigen Laptop kann dagegen ein deutlich zu positives Bild vermitteln.

Die häufigsten Bremsen

Große Hero-Bilder, nicht komprimierte Webfonts, zu viele Analyse-Skripte und blockierende CSS-Dateien gehören zu den üblichen Ursachen. Bei dynamischen Websites kommen langsame Datenbankabfragen, überfüllte APIs oder fehlende Caches hinzu. Ich optimiere zuerst den größten Engpass, statt zehn kleine Details gleichzeitig zu verändern.

• Bilder in modernen Formaten ausliefern und passend dimensionieren.
• Critical CSS für den sichtbaren Bereich priorisieren.
• JavaScript aufteilen und nicht benötigte Bibliotheken entfernen.
• Server- und Datenbank-Caching gezielt einsetzen.
• Schriften begrenzen und wichtige Schriftschnitte vorladen.
• Drittanbieter-Skripte nur laden, wenn sie einen klaren Nutzen haben.

Eine Antwortzeit von 200 Millisekunden bedeutet außerdem nicht automatisch, dass die Seite nach 200 Millisekunden benutzbar ist. Der Server kann schnell antworten, während der Browser noch mehrere Megabyte JavaScript verarbeitet. Time to First Byte und tatsächliche Interaktionsfähigkeit müssen deshalb getrennt betrachtet werden.

Welche Rolle Frameworks bei der Diagnose spielen

Frameworks beeinflussen, wie eine Seite gerendert wird, Daten abruft und JavaScript an den Browser übergibt. Bei React, Vue, Next.js oder Nuxt kann eine falsch konfigurierte Client-Ausführung dazu führen, dass zunächst nur eine leere Hülle erscheint. Laravel und Django liefern häufig serverseitig erzeugtes HTML, können aber durch langsame Abfragen oder überladene Templates ebenfalls ausgebremst werden.

Ich sehe das Framework selten als eigentlichen Fehlerverursacher. Häufiger liegt das Problem bei zu großen Bundles, unnötigen API-Aufrufen oder fehlendem Caching. Ein schlankes Projekt mit dem falschen Rendering-Modell kann langsamer sein als eine umfangreiche Anwendung mit sauberer Architektur.

Bei einem Framework-Projekt prüfe ich deshalb das sogenannte Waterfall-Diagramm. Es zeigt, welche Datei auf welche andere wartet. Wenn das Hauptdokument auf eine langsame API wartet und danach erst das Rendering beginnt, ist der Engpass im Backend zu suchen, nicht beim CSS.

Ein verlässlicher Prüfablauf für den Alltag

Für eine erste Diagnose reichen oft 15 bis 30 Minuten, sofern der Umfang klar begrenzt ist. Ich gehe dabei von außen nach innen vor und ändere während der Messung keine Konfiguration. Sonst lässt sich später nicht mehr erkennen, welche Ursache tatsächlich behoben wurde.

1. Erreichbarkeit testen: Domain, www-Variante und wichtige Unterseiten aus mindestens zwei Netzen aufrufen.
2. DNS und TLS prüfen: Auflösung, Zertifikat, Ablaufdatum und HTTPS-Weiterleitung kontrollieren.
3. HTTP-Antwort untersuchen: Statuscode, Antwortzeit und Redirect-Kette dokumentieren.
4. Mobil und Desktop messen: unterschiedliche Bildschirmgrößen und Netzbedingungen verwenden.
5. Core Web Vitals ansehen: Labordaten mit Felddaten aus echten Besuchen vergleichen.
6. Kernfunktionen testen: Navigation, Suche, Kontaktformular, Login und gegebenenfalls Kaufprozess durchspielen.
7. Logs abgleichen: Zeitstempel aus Monitoring, Webserver, Anwendung und Datenbank miteinander vergleichen.

Ein manueller Test findet sichtbare Fehler, aber kein sporadisches Problem um 3 Uhr morgens. Für produktive Websites richte ich deshalb einen synthetischen Monitor ein, der etwa alle fünf Minuten eine öffentliche Seite abfragt. Bei Shops oder Portalen sollte zusätzlich ein echter Ablauf überwacht werden, zum Beispiel Anmeldung oder Produktsuche.

Wichtig ist die Überwachung aus mehreren Regionen. Ein CDN, eine Firewall oder ein lokaler DNS-Fehler kann Anfragen aus Deutschland durchlassen, während Besucher in Österreich oder den Niederlanden eine Fehlermeldung sehen. Ein globaler Ausfall und ein regionales Problem verlangen unterschiedliche Maßnahmen.

Warum eine geladene Startseite noch keine Entwarnung ist

Viele Prüfungen senden nur eine einfache Anfrage an die Startseite. Das ist nützlich, erkennt aber nicht, ob ein Cookie-Banner die Navigation blockiert, ein Formular keine E-Mail versendet oder ein Zahlungsschritt nach der Eingabe hängen bleibt. Für geschäftlich wichtige Websites ist ein sogenannter synthetischer Test mit einem realen Nutzungsszenario deutlich aussagekräftiger.

Lesen Sie auch: Alt-Texte richtig schreiben - barrierefrei in HTML und CMS

Typische Fehlinterpretationen

• „Status 200 bedeutet alles funktioniert“: Der Server kann eine Fehlerseite mit Status 200 ausliefern.
• „Ein Lighthouse-Score von 100 ist ausreichend“: Labortests zeigen eine kontrollierte Umgebung und nicht jeden echten Besuch.
• „Nur die Startseite zählt“: Produktseiten, Login und Checkout haben oft ganz andere Lastprofile.
• „Mehr Caching löst jedes Problem“: Veraltete Inhalte oder personalisierte Daten können dadurch falsch ausgeliefert werden.
• „Das Framework ist zu langsam“: Meist sind Konfiguration, Datenzugriffe oder JavaScript-Bundles der konkretere Ansatzpunkt.

Auch Sicherheitsprüfungen gehören in den Ablauf, allerdings mit Augenmaß. Ich kontrolliere HTTPS, sicherheitsrelevante Header, veraltete Abhängigkeiten und auffällige Weiterleitungen. Ein kostenloser Scanner kann Hinweise liefern, ersetzt aber keine autorisierte Prüfung des eigenen Systems und sollte niemals fremde Infrastruktur aggressiv testen.

Nach jeder Änderung messe ich erneut unter möglichst ähnlichen Bedingungen. Eine Verbesserung von 2,8 auf 2,4 Sekunden beim LCP ist relevant, aber nur dann belastbar, wenn Gerät, Standort und Testseite vergleichbar geblieben sind.

Aus einem einzelnen Check wird erst durch Monitoring ein verlässliches Bild

Ein Einzeltest beantwortet die Frage, wie die Website genau jetzt reagiert. Monitoring zeigt dagegen Muster. Ich würde für eine kleine Unternehmensseite mindestens Erreichbarkeit, HTTP-Status und Antwortzeit überwachen. Bei einer Webanwendung kommen Kernfunktionen, Zertifikatsablauf, Fehlerquote und zentrale Geschäftsmetriken hinzu.

Eine sinnvolle Alarmierung braucht klare Schwellenwerte. Ein kurzer Ausreißer von zwei Sekunden ist nicht automatisch ein Notfall. Kritischer sind beispielsweise fünf aufeinanderfolgende Fehlversuche, ein wiederkehrender 5xx-Fehler oder ein Zertifikat, das in weniger als 14 Tagen abläuft.

Die Ergebnisse sollten in einem einfachen Protokoll landen. Datum, URL, Standort, Messwert, vermutete Ursache und durchgeführte Änderung reichen oft aus. So entsteht mit der Zeit eine belastbare Basis und nicht nur eine Sammlung einzelner Scores.

Was nach dem Website-Check den größten Unterschied macht

Ich würde Verbesserungen nach geschäftlicher Wirkung ordnen. Ein defektes Kontaktformular ist dringender als ein leicht zu großes Bild, und ein wiederkehrender 500-Fehler verdient mehr Aufmerksamkeit als ein kleiner Unterschied im Performance-Score.

• Zuerst Ausfälle, Sicherheitsprobleme und nicht funktionierende Kernprozesse beheben.
• Danach Ladezeiten und mobile Bedienbarkeit verbessern.
• Anschließend SEO-, Accessibility- und Komfortdetails verfeinern.
• Nach jeder größeren Änderung erneut messen und die Ergebnisse dokumentieren.

Wer diese Reihenfolge einhält, bekommt aus einer scheinbar einfachen Statusprüfung eine echte technische Entscheidungshilfe. Die Website muss nicht in jeder Kennzahl perfekt sein. Sie sollte erreichbar, schnell genug, sicher und für die wichtigsten Aufgaben zuverlässig sein. Genau diese Kombination liefert die Grundlage für nachhaltige Webentwicklung und eine bessere digitale Strategie.