Ist Ihre Website langsam, verlieren Sie Besucher, bevor die erste Zeile Text gelesen wird. Google misst Ladezeiten inzwischen sekundengenau – Ihre Kunden urteilen noch gnadenloser: Ab etwa drei Sekunden bricht rund die Hälfte der mobilen Besucher ab. In den letzten Jahren habe ich Dutzende träge Websites von KMU aus Wien und dem gesamten DACH-Raum analysiert, und die Ursachen wiederholen sich mit erstaunlicher Zuverlässigkeit. Es sind fast nie exotische Probleme. In diesem Artikel zeige ich Ihnen die fünf häufigsten Bremsen, wie Sie selbst in einer Viertelstunde eine saubere Diagnose stellen – und welche Maßnahmen messbar etwas bringen, statt nur den Score in irgendeinem Tool zu schönen.
Die fünf häufigsten Ursachen aus der Praxis
Bevor Sie das nächste Optimierungs-Plugin installieren: Verstehen Sie zuerst, wo die Zeit tatsächlich verloren geht. In neun von zehn Audits, die ich durchführe, steckt das Problem in einer dieser fünf Kategorien – meistens in mehreren gleichzeitig.
1. Billiges Hosting mit langer Server-Antwortzeit
Der erste Wert, den ich bei jeder Analyse prüfe, ist die Time to First Byte (TTFB) – die Zeit, bis der Server überhaupt anfängt zu antworten. Bei solidem Hosting liegt sie für eine WordPress-Seite ohne Cache bei 200 bis 500 Millisekunden. Auf überfüllten Shared-Servern für fünf Euro im Monat messe ich regelmäßig 1,5 bis 2,5 Sekunden – bevor auch nur ein Byte HTML im Browser ankommt. Ab diesem Punkt ist jede weitere Optimierung Kosmetik: Wer auf einem 2-Sekunden-Server Bilder komprimiert, poliert die Türklinke an einem Haus ohne Fundament. Faustregel: Liegt die TTFB dauerhaft über 800 Millisekunden, gehört zuerst das Hosting auf den Prüfstand.
2. Unoptimierte Bilder
Der Klassiker: Das 6000-Pixel-Foto vom Fotografen wandert direkt in die Mediathek und von dort in den Startseiten-Slider – 4 MB für ein Bild, das im Layout 800 Pixel breit angezeigt wird. Ich habe Startseiten mit 15 MB Gesamtgewicht gesehen, davon 13 MB Bilder. Die Lösung ist unspektakulär, aber hochwirksam: Bilder in der tatsächlich benötigten Größe ausliefern, in moderne Formate wie WebP oder AVIF konvertieren (das spart typischerweise 30 bis 70 Prozent gegenüber JPEG) und alles unterhalb des sichtbaren Bereichs per Lazy Loading nachladen. Bei einem Wiener Handwerksbetrieb habe ich die Startseite so von 11 MB auf 1,3 MB gebracht – der Largest Contentful Paint fiel von 6,8 auf 1,9 Sekunden, ohne dass sich am Design ein Pixel geändert hätte.
3. Plugin-Wildwuchs und schwere Themes
Nicht die Anzahl der Plugins ist das Problem, sondern was sie laden. Ein sauber gebautes Plugin mit zwanzig PHP-Dateien ist harmlos; ein einziger Page-Builder oder ein „Mega-Theme“ mit eingebautem Slider, Icon-Bibliothek und drei Tracking-Skripten kann dagegen 2 MB JavaScript auf jede Seite kippen – auch dort, wo nichts davon gebraucht wird. Typisches Bild aus einem Audit: WooCommerce-Shop, 41 aktive Plugins, davon laden 28 ihr CSS und JavaScript auf jeder einzelnen Unterseite. Veraltete und verwaiste Plugins sind obendrein ein Sicherheitsrisiko – warum regelmäßige WordPress-Wartung hier doppelt zählt, habe ich in einem eigenen Beitrag aufgeschrieben.
4. Webfonts als versteckte Bremse
Schriften werden chronisch unterschätzt. Sechs Schnitte einer Google-Schrift plus eine Icon-Font summieren sich schnell auf 500 KB – und weil Fonts das Rendering blockieren können, sieht der Besucher bis dahin: nichts. Was hilft: nur die Schnitte laden, die wirklich im Einsatz sind (meist Regular und Bold), WOFF2 als einziges Format, font-display: swap gegen unsichtbaren Text – und die Dateien lokal hosten statt von Google-Servern. Letzteres beschleunigt den Verbindungsaufbau und ist im DACH-Raum spätestens seit den Abmahnwellen rund um Google Fonts auch aus Datenschutzsicht Pflicht.
5. Fehlendes oder falsch konfiguriertes Caching
WordPress baut jede Seite bei jedem Aufruf neu aus Datenbankabfragen zusammen – völlig unnötig für Inhalte, die sich einmal pro Woche ändern. Ein Page-Cache liefert stattdessen fertiges HTML aus und drückt die Serverantwort von 800 auf unter 100 Millisekunden. Dazu gehören sinnvolle Browser-Cache-Header für statische Dateien und bei Shops ein Object-Cache wie Redis, damit wiederkehrende Abfragen nicht jedes Mal neu laufen. Wichtig zu verstehen: Caching kaschiert langsamen Code nur für den zweiten Besucher – der erste Aufruf, der Warenkorb und alles Dynamische bleiben so langsam wie das Fundament darunter.
Diagnose: Erst messen, dann schrauben
Wer ohne Messung optimiert, optimiert blind. Meine Standard-Werkzeuge sind kostenlos: PageSpeed Insights für den Überblick, WebPageTest für den detaillierten Lade-Wasserfall und die Google Search Console für die Daten echter Besucher. Entscheidend ist dabei der Unterschied zwischen Labordaten (ein einzelner simulierter Test) und Felddaten (echte Chrome-Nutzer der letzten 28 Tage). Für die Rankings zählt bei Google ausschließlich das Feld – gemessen über die Core Web Vitals.
Die drei Werte, auf die es ankommt
- LCP (Largest Contentful Paint): Wann ist das größte sichtbare Element geladen? Ziel: unter 2,5 Sekunden. Der wichtigste Einzelwert – und der, den schwere Bilder und langsame Server ruinieren.
- INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Klicks und Eingaben? Ziel: unter 200 Millisekunden. Hier schlägt zu viel JavaScript zu.
- CLS (Cumulative Layout Shift): Springt das Layout beim Laden? Ziel: unter 0,1. Meist verursacht durch Bilder ohne definierte Größe und nachladende Banner.
Ein Praxistipp zur Messung: Testen Sie immer die mobile Ansicht, nicht die Desktop-Variante. Google bewertet mobil, und die meisten Ihrer Besucher kommen über das Smartphone – oft im Mobilfunknetz statt im Büro-WLAN. Eine Seite, die am Desktop flott wirkt, kann auf einem durchschnittlichen Android-Gerät mit 4G quälend langsam sein. Prüfen Sie außerdem nicht nur die Startseite: Die wichtigste Landingpage oder die umsatzstärkste Produktseite verdient dieselbe Aufmerksamkeit.
Ein Wert wird dabei notorisch missverstanden: Der PageSpeed-Score von 0 bis 100 ist ein Laborwert und kein Ranking-Faktor. Ich habe Seiten mit Score 74 gesehen, die alle Core Web Vitals souverän bestehen – und Seiten mit Score 95, die sich für echte Besucher zäh anfühlen. Wie Performance in die größere SEO-Rechnung einzahlt, lesen Sie im Beitrag über technisches SEO als Basis vor dem Content.
Was wirklich hilft – und was Sie sich sparen können
Die folgende Tabelle ordnet die gängigsten Maßnahmen nach Aufwand und tatsächlicher Wirkung ein – basierend auf dem, was ich in Projekten messe, nicht auf Marketingversprechen der Plugin-Hersteller:
| Maßnahme | Aufwand | Typische Wirkung |
|---|---|---|
| Hosting-Wechsel bei TTFB über 800 ms | Mittel – ein halber Tag inklusive Umzug | Sehr hoch: oft 1–2 Sekunden weniger bei jedem Seitenaufruf |
| Bilder: richtige Größen, WebP/AVIF, Lazy Loading | Gering bis mittel | Hoch: meist der größte LCP-Hebel |
| Page-Cache und Browser-Cache sauber konfigurieren | Gering | Hoch: Serverantwort von 800 auf unter 100 ms |
| Ungenutzte Plugins und Skripte entfernen | Mittel | Mittel bis hoch: weniger JavaScript, besserer INP |
| Fonts reduzieren und lokal hosten | Gering | Mittel: schnellerer Textaufbau, kein Flackern |
| Noch ein „Optimizer“-Plugin auf ungelöste Probleme | Gering | Gering bis negativ: kaschiert Symptome, erzeugt Konflikte |
Drei Mythen, die sich hartnäckig halten
- „Wir brauchen einfach einen stärkeren Server.“ Mehr CPU beschleunigt kein 4-MB-Bild und kein render-blockierendes JavaScript. Erst diagnostizieren, dann skalieren – in dieser Reihenfolge.
- „Ein Caching-Plugin löst das schon.“ Ein Cache verkleinert kein Bild und entfernt kein überflüssiges Skript. Und aggressive Einstellungen wie CSS/JS-Zusammenfassung zerschießen regelmäßig Layouts und Checkout-Prozesse – ich verbringe mehr Zeit damit, kaputt-optimierte Seiten zu reparieren, als langsame zu beschleunigen.
- „CDN drauf, fertig.“ Ein CDN verkürzt Wege zu weit entfernten Besuchern. Wenn Ihre Kunden in Österreich sitzen und der Server in Deutschland steht, gewinnen Sie ein paar Millisekunden – nicht die zwei Sekunden, die ein aufgeblähtes Theme kostet.
Wann Sie einen Spezialisten dazuholen sollten
Vieles aus diesem Artikel können Sie selbst umsetzen: Bilder komprimieren, Plugins ausmisten, ein Caching-Plugin sauber aufsetzen. Es gibt aber Fälle, in denen Selbermachen teurer wird als Hilfe: wenn die TTFB trotz gutem Hosting hoch bleibt (dann steckt das Problem im Code oder in der Datenbank), wenn der Shop ausgerechnet im Checkout lahmt (dort greift kein Cache) oder wenn nach jeder Optimierungsrunde etwas anderes kaputtgeht. Für eine strukturierte Fehlersuche mit klarer Prioritätenliste biete ich eine technische Beratung an; wer das Thema dauerhaft abgeben möchte, ist mit einer laufenden Website-Betreuung besser bedient – dort gehört Performance-Monitoring zum Standard.
Zur Orientierung ein realistischer Rahmen: Eine gründliche Performance-Analyse mit priorisierter Maßnahmenliste ist an ein bis zwei Tagen erledigt, die Umsetzung der wichtigsten Punkte dauert je nach Website ein bis drei weitere Tage. Verglichen mit dem, was eine dauerhaft langsame Website Monat für Monat an Anfragen und Bestellungen kostet, ist das eine überschaubare Investition mit messbarem Ergebnis.
Fazit
Eine langsame Website ist kein Schicksal und selten ein Fall für teurere Server – sondern fast immer die Summe aus schwachem Hosting, schweren Bildern, zu viel JavaScript und fehlendem Caching. Messen Sie zuerst mit PageSpeed Insights und echten Felddaten, beheben Sie dann die größten Bremsen in genau dieser Reihenfolge – und lassen Sie sich von der Jagd nach Score 100 nicht verrückt machen. Entscheidend ist, was Ihre Besucher erleben, nicht was ein Laborwert behauptet.
Sie wollen wissen, wo Ihre Website konkret Zeit verliert? Ich schaue mir das an: Sie bekommen eine ehrliche Diagnose mit Prioritäten statt einer Plugin-Liste von der Stange. Schreiben Sie mir kurz über das Kontaktformular – meist antworte ich noch am selben Werktag.
