Warum ist meine Website langsam? So finden und beheben Sie die Ursache

„Meine Website ist langsam“ kann ganz unterschiedliche Probleme beschreiben. Vielleicht braucht der Server lange, bis er das erste Byte sendet. Vielleicht kommt die Seite schnell an, zeigt ihr Hauptbild aber erst nach einer gefühlten Ewigkeit. Vielleicht sieht sie fertig aus, reagiert aber eine Sekunde lang nicht auf Tippen. Oder sie lädt und springt dann hin und her, weil Anzeigen und Bilder den Text nach unten schieben. Jedes dieser Probleme hat andere Ursachen. Deshalb gilt es zuerst herauszufinden, welches bei Ihnen vorliegt.

Erst messen, dann ändern

Es gibt zwei Arten von Geschwindigkeitsdaten, und sie beantworten unterschiedliche Fragen:

• Felddaten stammen von echten Besuchern mit ihren eigenen Geräten und Verbindungen. Der Chrome UX Report von Google erfasst sie für Websites mit ausreichend Traffic. Sie finden sie in PageSpeed Insights und im Bericht „Core Web Vitals“ der Google Search Console. Sie zeigen, was Menschen tatsächlich erleben.
• Labordaten entstehen, wenn die Seite einmal unter kontrollierten Bedingungen geladen wird, so wie Lighthouse es tut. Sie sind weniger repräsentativ, dafür aber reproduzierbar – und sie erklären, warum eine Seite langsam ist.

Nach Googles Core Web Vitals ist ein Erlebnis gut bei einem Largest Contentful Paint (LCP) von höchstens 2,5 Sekunden, einem Interaction to Next Paint (INP) von höchstens 200 Millisekunden und einem Cumulative Layout Shift (CLS) von höchstens 0,1, gemessen im 75. Perzentil der echten Besuche.

Für die Diagnose führen Sie einen Labortest durch. Der kostenlose Website-Speed-Checker von Rudra lädt Ihre Seite mit Lighthouse und meldet First Contentful Paint, LCP, Total Blocking Time, CLS, Speed Index und Time to Interactive sowie die nicht bestandenen Lighthouse-Prüfungen, die schwerwiegendsten zuerst. Behalten Sie die Grenzen im Blick: Es ist ein einzelner Ladevorgang von unserem Server unter den simulierten Bedingungen von Lighthouse. Die Zahlen stimmen also nicht exakt mit Ihren Felddaten überein, und der INP lässt sich so nicht messen, weil er echte Interaktionen voraussetzt. Die Total Blocking Time ist der Laborwert, der am engsten mit der Reaktionsfähigkeit zusammenhängt.

Testen Sie einige repräsentative Seitentypen (Startseite, eine Produkt- oder Leistungsseite, einen Artikel), jeweils mehrmals, und sehen Sie sich die mobilen Ergebnisse an, nicht nur die für den Desktop.

Die häufigsten Ursachen und wie Sie sie beheben

1. Eine langsame Serverantwort

Nichts anderes kann beginnen, solange der Server das HTML nicht gesendet hat. Ist die Time to First Byte hoch, liegt das meist an billigem oder überlastetem Hosting, an Seiten, die bei jeder Anfrage von Grund auf neu erzeugt werden, an langsamen Datenbankabfragen oder an Besuchern, die weit vom Server entfernt sind. Abhilfe: Aktivieren Sie das Seiten-Caching (die meisten CMS haben dafür ein Plugin oder eine Einstellung), schalten Sie ein CDN vor die Website, entfernen Sie Plugins, die Sie nicht brauchen, und wechseln Sie auf ein besseres Hosting, wenn der Server schlicht zu schwach ist. Google stuft eine TTFB von höchstens 0,8 Sekunden als gut ein. Bei Crawls der gesamten Website meldet Rudra Seiten, deren Server länger als 1,5 Sekunden für die Antwort gebraucht hat, und stuft mehr als 3 Sekunden als kritisch ein.

2. Zu große Bilder

Ein Foto direkt aus der Kamera oder vom Smartphone kann mehrere Megabyte groß und Tausende Pixel breit sein – und wird dann in 800 Pixeln Breite angezeigt. Verkleinern und komprimieren Sie Bilder und nutzen Sie moderne Formate. Unser Leitfaden Bildgröße reduzieren führt Sie Schritt für Schritt hindurch.

3. Zu viel JavaScript

Große Bundles und Tags von Drittanbietern (Analyse, Chat-Widgets, A/B-Tests, Werbeskripte) konkurrieren um den Main-Thread des Browsers. Solange ein langes Skript läuft, kann die Seite nicht auf Tippen reagieren. Das zeigt sich im Labor als hohe Total Blocking Time und im Feld als schlechter INP. Prüfen Sie jedes Drittanbieter-Tag und entfernen Sie alle, die niemand nutzt. Laden Sie verzichtbare Widgets erst, wenn die Seite interaktiv ist oder der Besucher sie anfordert, und teilen Sie große Bundles auf, damit jede Seite nur lädt, was sie braucht.

4. Renderblockierendes CSS und renderblockierende Skripte

Skripte im <head> ohne async oder defer und jedes Stylesheet müssen geladen sein, bevor der Browser irgendetwas darstellen kann. Versehen Sie Skripte, die nicht sofort laufen müssen, mit defer, zum Beispiel <script src="/app.js" defer></script>, fassen Sie unnötige Stylesheets zusammen oder entfernen Sie sie, und erwägen Sie, das wenige CSS für den oberen Seitenbereich inline einzubinden.

5. Keine Komprimierung

Textdateien (HTML, CSS, JavaScript, JSON, SVG) schrumpfen mit gzip oder Brotli enorm. Suchen Sie im Netzwerk-Tab des Browsers in den Antwort-Headern Ihrer Seite nach content-encoding: br oder gzip. Fehlt die Angabe, aktivieren Sie die Komprimierung auf dem Server (in nginx mit gzip on; und einer gzip_types-Liste) oder in Ihrem CDN.

6. Statische Dateien ohne Caching

Wiederkehrende Besucher sollten Ihr Logo und Ihr Stylesheet nicht noch einmal herunterladen müssen. Senden Sie für Dateien, deren Name sich mit dem Inhalt ändert (die meisten Build-Tools hängen einen Hash an, etwa app.3f9a2c.js), den Header Cache-Control: public, max-age=31536000, immutable. HTML sollte nur kurz gecacht oder revalidiert werden, damit Aktualisierungen zügig sichtbar sind.

7. Schwere Webfonts

Mehrere Schriftfamilien in jeweils vielen Schnitten summieren sich schnell, und Text kann unsichtbar bleiben, solange die Schriften laden. Verwenden Sie weniger Schnitte, liefern Sie WOFF2 aus, beschränken Sie die Schriften per Subsetting auf die benötigten Zeichen, ergänzen Sie font-display: swap, damit Text sofort in einer Ersatzschrift erscheint, und laden Sie nur die eine Schrift vorab, die im sofort sichtbaren Bereich verwendet wird. Ein Systemschrift-Stack erspart den Download ganz.

8. Layoutverschiebungen

Wenn Seiten springen, liegt das meist an Bildern und Einbettungen ohne reservierten Platz, an Anzeigen, die in den Inhalt eingefügt werden, oder an Bannern, die nach dem Laden über dem Text auftauchen. Geben Sie jedem Bild die Attribute width und height (oder ein aspect-ratio per CSS), reservieren Sie mit einer min-height Platz für Anzeigen und Einbettungen und blenden Sie Cookie- und Werbebanner als Overlay ein, statt den Inhalt nach unten zu schieben.

9. Aufgeblähte Seiten und zu viele Anfragen

Sehr große HTML-Dokumente (oft durch inline eingebettete Daten oder endlose Produktraster), Dutzende Skripte und doppelt eingebundene Skripte bremsen eine Seite aus. Teilen Sie lange Listen auf mehrere Seiten auf, lagern Sie große Inline-Daten in eigene, gecachte Dateien aus und entfernen Sie doppelte Tags. Der Crawl von Rudra meldet HTML-Dokumente über 1 MB, Seiten mit mehr als 100 referenzierten Ressourcen und Skripte, die mehr als einmal geladen werden.

10. Weiterleitungen, bevor die Seite überhaupt lädt

Wer example.com eintippt und erst zu https://example.com, dann zu https://www.example.com und schließlich zu /home weitergeleitet wird, wartet bei jedem Schritt. Leiten Sie in einem Schritt direkt zur endgültigen URL weiter und verlinken Sie überall auf die endgültigen URLs.

Was Sie zuerst beheben sollten

1. Ist die Serverantwort langsam, fangen Sie dort an. Alle anderen Messwerte hängen davon ab.
2. Ist der LCP schlecht, finden Sie das LCP-Element. Lighthouse nennt es. Meist ist es ein Hero-Bild (komprimieren Sie es, laden Sie es nicht per Lazy Loading und erwägen Sie fetchpriority="high") oder eine Überschrift, die durch Schriften oder renderblockierendes CSS aufgehalten wird.
3. Sind Total Blocking Time oder INP schlecht, sehen Sie sich das JavaScript an, vor allem Drittanbieter-Tags.
4. Ist der CLS schlecht, reservieren Sie Platz für Bilder, Einbettungen, Anzeigen und Banner.
5. Testen Sie nach jeder Änderung erneut, damit Sie wissen, was wirklich geholfen hat.

Was ein Geschwindigkeitstest nicht verrät

Ein Labortest lädt eine einzelne öffentliche URL, ohne Anmeldung, von einem einzigen Standort aus. Er zeigt weder den langsamen Checkout-Schritt hinter dem Login noch die Seite, die nur für Besucher auf einem anderen Kontinent langsam ist, noch das Widget, das erst nach einer Minute Scrollen Ärger macht. Nutzen Sie ihn, um Probleme zu finden und zu erklären, und bestätigen Sie Verbesserungen dann in den folgenden Wochen anhand der Felddaten.

Häufige Fehler

• Einem perfekten Lighthouse-Score nachzujagen statt den Messwerten, die Ihre Besucher spüren.
• Nur auf dem Desktop im schnellen Büro-WLAN zu testen.
• Das Hero-Bild per Lazy Loading zu laden, was den LCP verzögert.
• Mehrere „Speed“- oder Caching-Plugins zu installieren, die sich gegenseitig in die Quere kommen.
• Eine Änderung anhand eines einzigen Testlaufs zu beurteilen – die Ergebnisse schwanken von Lauf zu Lauf.