Website schneller machen: die sechs Ursachen aus meinen Messungen - und was du selbst beheben kannst
Warum lädt deine Website so langsam? Die sechs Ursachen aus 40 geprüften Seiten, was du selbst beheben kannst und wie du mit PageSpeed Insights misst.

Inhalt
- Warum lädt meine Website so langsam?
- Wie messe ich, wie schnell meine Website ist?
- Welche Ursachen kommen am häufigsten vor?
- Wie richte ich Browser-Caching ein?
- Wie mache ich Bilder kleiner, ohne dass sie schlechter aussehen?
- Bremsen Schriften meine Website aus?
- Wie viele Plugins sind zu viele?
- Bremsen Cookie-Banner, Chat und Karten die Seite?
- Liegt es am Hosting?
- In welcher Reihenfolge gehe ich vor?
- Wenn du es nicht selbst machen willst
- Häufige Fragen
- Wie schnell sollte meine Website laden?
- Reicht es, nur den Desktop-Wert zu verbessern?
- Warum schwankt mein Ergebnis bei jeder Messung?
- Wie schnell ist deine eigene Seite?
Kurz gesagt: Langsame Seiten scheitern fast immer an denselben Stellen. In meinem Scan vom 3. September 2026 fehlte bei 23 von 25 behebbaren Seiten das Browser-Caching, bei 19 waren die Bilder zu schwer. Beides kannst du oft selbst angehen. Miss zuerst mit PageSpeed Insights, behebe eine Ursache nach der anderen und miss danach mit demselben Werkzeug nach. Ein langsamer Server war nur ein einziges Mal der Grund.
Ich messe regelmäßig fremde Websites. Nicht aus Neugier, sondern weil ich anbiete, sie schneller zu machen. Dabei habe ich gelernt: Die Gründe sind selten exotisch. Es sind fast immer dieselben sechs. In diesem Artikel zeige ich dir, welche das sind, wie du sie bei deiner Seite findest und welche du ohne Entwickler beheben kannst.
Warum lädt meine Website so langsam?
Eine Seite ist langsam, wenn der Browser zu viel laden muss, zu lange auf etwas wartet oder dieselben Dateien bei jedem Besuch neu holt. Das klingt banal. In der Praxis steckt es in Fotos direkt aus der Kamera, in Themes, die alles mitbringen, und in Server-Einstellungen, die nie jemand angefasst hat.
Woher ich das weiß: Am 3. September 2026 habe ich 1.351 Betriebe aus OpenStreetMap gezogen. 1.036 Seiten davon waren erreichbar und auswertbar. Die 40 mit dem größten Rückstand habe ich einzeln durch Google PageSpeed Insights geschickt, im Mobilprofil. 14 davon standen gut genug da - die habe ich nie angeschrieben. Eine Messung brach ab. Bei 25 Seiten ließ sich der Rückstand ohne Umbau beheben. Auf diese 25 beziehen sich die Zahlen unten. Sie sind nicht hochgerechnet und nicht gerundet. Eine Seite hatte meist mehrere Befunde gleichzeitig.
Wie messe ich, wie schnell meine Website ist?
Öffne PageSpeed Insights, gib deine Adresse ein und warte etwa eine Minute. Dann schau auf drei Dinge:
- Den Reiter "Mobil". Er misst mit gedrosselter Verbindung und gedrosselter CPU. Das entspricht dem Handy auf der Straße. Der Desktop-Wert ist fast immer schöner und fast immer weniger wichtig.
- Die Leistungsbewertung. Google stuft 90 bis 100 als gut ein, 50 bis 89 als verbesserungswürdig und alles unter 50 als schlecht.
- Largest Contentful Paint (LCP). Die Zeit, bis das größte sichtbare Element steht, meist ein Bild oder die Überschrift. Laut web.dev sind 2,5 Sekunden oder weniger gut, über 4,0 Sekunden schlecht.
Ganz oben zeigt PageSpeed Insights manchmal Daten echter Besucher, darunter die Labormessung. Beides ist nicht dasselbe. Was der Unterschied bedeutet und warum bei kleinen Seiten oft nur das Labor da ist, erkläre ich in Core Web Vitals erklärt.
Ein Tipp aus meinen eigenen Läufen: Miss mehrmals, mit ein paar Minuten Abstand. Ein einzelner Lauf streut mobil um mehrere Punkte. Kommt das Ergebnis nach einer Sekunde zurück, war es oft die zwischengespeicherte Antwort des vorigen Laufs.
Scroll danach im Bericht nach unten zur Diagnose. Dort steht, was bremst - meist mit geschätzter Einsparung. Genau diese Liste arbeitest du ab.
Welche Ursachen kommen am häufigsten vor?
| Befund | Häufigkeit (von 25) | Selbst machbar? |
|---|---|---|
| Browser-Caching fehlt | 23 | oft, wenn du an die Server-Einstellungen kommst |
| Bilder unoptimiert | 19 | ja |
| Ungenutztes CSS | 17 | teilweise |
| Ungenutztes JavaScript | 8 | teilweise |
| Code blockiert den Aufbau | 5 | selten ohne Entwickler |
| Server antwortet langsam | 1 | nur durch Wechsel des Hostings |
Die Reihenfolge ist auch eine Empfehlung: Fang oben an. Was am häufigsten vorkommt, ist meist auch am einfachsten zu beheben.
Wie richte ich Browser-Caching ein?
Caching heißt: Der Browser legt Bilder, Schriften und Skripte nach dem ersten Besuch ab und holt sie beim nächsten Mal nicht neu. Fehlt die Anweisung dazu, lädt jeder Besuch alles von vorn. PageSpeed Insights meldet das im Bericht als Hinweis zur Cache-Dauer und listet die betroffenen Dateien auf.
Die Anweisung ist ein Header namens Cache-Control. Google empfiehlt in der Lighthouse-Dokumentation, unveränderliche Dateien lange zu cachen, etwa ein Jahr. Der Wert dafür ist max-age=31536000.
- WordPress: Ein Caching-Plugin setzt diese Header meist mit einem Haken. Prüf danach im Bericht, ob der Punkt verschwunden ist.
- Eigenes Hosting mit Apache: Die Regeln stehen in der Datei
.htaccess. Mach vorher eine Kopie. - Baukasten: Hier hast du keinen Zugriff. Das ist kein Fehler von dir, sondern eine Grenze des Systems.
Eine Falle: Wer Dateien ein Jahr cachen lässt und sie dann ändert, sieht bei Stammbesuchern die alte Fassung. Moderne Systeme hängen deshalb eine Prüfsumme an den Dateinamen. Bei einer selbst gebastelten Seite solltest du das wissen, bevor du den Wert hochdrehst.
Wie mache ich Bilder kleiner, ohne dass sie schlechter aussehen?
Das typische Bild auf einer langsamen Seite ist ein Handyfoto in voller Auflösung, angezeigt in einer Box, die halb so breit ist wie dein Bildschirm. Der Browser lädt das ganze Foto und wirft den Großteil weg.
- Größe anpassen. Exportiere das Bild in der Breite, in der es angezeigt wird. Für ein Bild über die volle Breite reicht meist eine Fassung, die etwas breiter ist als ein großer Monitor.
- Modernes Format. WebP oder AVIF statt JPEG oder PNG. Kostenlose Werkzeuge wie Squoosh im Browser erledigen das ohne Installation. Laut web.dev verkürzen kleinere Dateien die Ladedauer des LCP-Elements direkt.
- Breite und Höhe angeben. Sonst springt die Seite, sobald das Bild da ist. Das misst Google als Layout-Verschiebung.
- Das erste große Bild nicht verzögert laden. "Lazy Loading" ist für Bilder weiter unten gut. Für das Bild ganz oben ist es falsch: web.dev schreibt ausdrücklich, das LCP-Bild nie verzögert zu laden.
Wie viel das bei dir bringt, steht im Bericht. Google weist das Einsparpotenzial je Punkt aus.
Bremsen Schriften meine Website aus?
Schriften sind seltener der Hauptgrund, aber ein häufiger Nebengrund. Jeder Schnitt ist eine eigene Datei: normal, fett, kursiv, fett-kursiv. Vier Schnitte von zwei Schriften sind acht Downloads, bevor der Text richtig steht.
- Weniger Schnitte. Prüf, welche du wirklich benutzt. Den Rest löschst du aus der Einbindung.
- WOFF2. Laut web.dev das Format mit der besten Kompression.
font-display: swap. Damit zeigt der Browser den Text sofort in einer Ersatzschrift, statt weiß zu bleiben.
Ob du Schriften selbst hostest oder von Google Fonts lädst, ist laut web.dev für das Tempo weniger eindeutig, als oft behauptet wird. Ich hoste Schriften trotzdem selbst: Dann baut der Browser keine Verbindung zu einem fremden Server auf, nur um Text anzuzeigen.
Wie viele Plugins sind zu viele?
Es gibt keine feste Zahl. Entscheidend ist, was ein Plugin auf jeder Seite mitlädt. In meinem Scan hatten 17 von 25 Seiten ungenutztes CSS und 8 ungenutztes JavaScript. Das sind Gestaltungsregeln und Programmcode für Bausteine, die auf der Seite gar nicht vorkommen. Typisch bei zugekauften Themes und bei Erweiterungen, die irgendwann jemand ausprobiert und nie wieder entfernt hat.
So gehst du vor:
- Liste alle Plugins auf und schreib daneben, wofür du sie brauchst.
- Was du nicht erklären kannst, deaktivierst du testweise. Nicht löschen, erst deaktivieren.
- Miss danach neu. Ist nichts kaputt und der Wert besser, löschst du das Plugin.
Bei 5 von 25 Seiten blockierte Code den Aufbau: Der Browser hatte den Text schon, durfte ihn aber nicht zeigen, weil er auf eine Datei wartete. Das zu lösen heißt, die Ladereihenfolge zu ändern. Ohne Erfahrung im Code rate ich dir hier ab - es geht schnell etwas kaputt, das du erst Tage später bemerkst.
Bremsen Cookie-Banner, Chat und Karten die Seite?
Alles, was von einem fremden Server kommt, lädt der Browser zusätzlich: Cookie-Banner, Chat-Fenster, eingebettete Karten, Videos, Bewertungs-Widgets, Tracking. Jedes davon ist eine eigene Verbindung, oft mit eigenem JavaScript.
- Eine eingebettete Karte braucht kaum jemand auf der Startseite. Ein Link "Route planen" tut es auch.
- Ein Video kann als Vorschaubild starten und erst beim Klick laden.
- Tracking-Skripte, deren Auswertung du nie anschaust, kannst du entfernen.
PageSpeed Insights weist im Bericht aus, welche Drittanbieter-Skripte auf deiner Seite laufen und wie viel sie laden. Das ist die ehrlichste Liste, die du bekommst.
Liegt es am Hosting?
Seltener, als viele glauben. In meinem Scan war ein langsamer Server genau 1 Mal von 25 der Befund. Im Bericht siehst du das an der Zeit bis zur ersten Antwort des Servers. Laut web.dev macht dieser Teil typischerweise einen großen Teil des LCP aus. Ist er auch nach Caching und Bildern noch hoch, liegt es am Paket. Dann hilft nur ein Wechsel - kein Plugin der Welt macht einen langsamen Server schnell.
In welcher Reihenfolge gehe ich vor?
- Mobil messen, drei Läufe, Mittelwert notieren.
- Caching einschalten.
- Die größten Bilder verkleinern und umwandeln.
- Plugins und fremde Skripte ausmisten.
- Schriften reduzieren.
- Nach jedem Schritt neu messen. Nur so weißt du, was gewirkt hat.
- Erst wenn die Serverantwort danach noch langsam ist: Hosting prüfen.
Und eine ehrliche Grenze: Manche Seiten sind nicht langsam, weil etwas falsch eingestellt ist, sondern weil der Unterbau zu schwer ist. Ein überladenes Theme, ein Baukasten, zwanzig Erweiterungen. Da holst du Sekunden heraus und kommst trotzdem nicht auf einen guten Wert. Dann ist ein Neubau die bessere Rechnung - mehr dazu in Website-Relaunch: Kosten und auf meiner Seite zur Webentwicklung.
Wenn du es nicht selbst machen willst
Dafür gibt es Website schneller machen. Ich messe deine Startseite mit PageSpeed Insights und schicke dir den Befund auf einer Seite. Das kostet nichts. Erst danach nenne ich dir einen Festpreis: 490 Euro für die Punkte, die die Messung als behebbar ausweist. Kein Abo, keine Folgekosten. Nach der Arbeit messe ich mit demselben Werkzeug nach, und du bekommst beide Berichte.
Lässt sich nichts ohne Umbau beheben, sage ich dir das und berechne nichts. Was ich dir nicht verspreche: eine bestimmte Position bei Google. Ladezeit ist ein Faktor unter vielen.
Häufige Fragen
Wie schnell sollte meine Website laden?
Als Maßstab nimmt Google den LCP: bis 2,5 Sekunden gilt als gut. Miss mobil, nicht am Desktop.
Reicht es, nur den Desktop-Wert zu verbessern?
Nein. Google bewertet Handy und Desktop getrennt. Der mobile Wert ist der härtere, und an ihm scheitern die meisten Seiten.
Warum schwankt mein Ergebnis bei jeder Messung?
Ein einzelner Lauf streut mobil um mehrere Punkte, das sehe ich bei meinen eigenen Messungen regelmäßig. Miss dreimal mit ein paar Minuten Abstand und nimm den mittleren Wert.
Wie schnell ist deine eigene Seite?
comole-digital.de (meine eigene Seite): Am 19. September 2026 mit Google PageSpeed Insights gemessen, mobil 86 von 100 bei 3,75 Sekunden Labor-LCP, Desktop 100 von 100 bei 0,80 Sekunden. Selbst nachmessen.
Der mobile LCP liegt damit in der Stufe "verbesserungswürdig". Ich nenne den Wert trotzdem, weil der Desktop-Wert allein die schönere Hälfte wäre.
Edilson Comole, Webentwickler aus Monheim am Rhein. Ich baue Websites für Läden, Gastronomie und Dienstleister - mit Next.js und React, ohne Baukasten.
Noch mehr aus dem Journal.
Vom Lesen zum Rechnen
Dein Fall, durchgerechnet.
Zwei Minuten Erstcheck: du beschreibst dein Vorhaben, ich melde mich werktags binnen 24 Stunden mit einer ehrlichen Einschätzung - ab 690 € einmalig plus 29 € im Monat für Betrieb und Betreuung. Auch dann, wenn die Antwort Nein lautet.
Lieber klassisch? Projekt anfragen


