WARUM DEINE WEBSITE LANGSAM IST
Die Handvoll Ursachen hinter fast jeder langsamen Website, wie man beweist, welche man hat, und die Reihenfolge, die tatsächlich Felddaten bewegt.
← Guides All guides in this topic
Messe, bevor du rätst
Wenn du DevTools öffnest, drei Plugins wechselst und neu deployst, ohne dir Felddaten anzusehen, rätst du mit zusätzlichen Schritten. Langsam ist eine Besuchererfahrung. Beweise es mit Zahlen von echten Nutzern, bevor du Code anfasst.
Starte mit Chrome UX Report-Felddaten in PageSpeed Insights oder Search Console Core Web Vitals. Du willst das 75. Perzentil für Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift auf dem Mobilgerät. Lab-Scores von Lighthouse sind nützlich zum Debuggen eines einzelnen Seitenladegangs. Sie sind nicht die Metrik, die Google zum Ranking verwendet, und nicht die Metrik, die deine Käufer in einer Flughafen-WLAN-Verbindung spüren.
Was in den ersten zehn Minuten zu erfassen ist
URL der langsamen Seite. Geräte klasse (zuerst Mobiltelefon). Ob das Problem beim ersten Besuch oder beim Wiederholungsbesuch auftritt. Ob sich angemeldete Seiten von der öffentlichen Homepage unterscheiden. TTFB, falls sichtbar. Der LCP-Elementname aus dem Diagnose panel. Diese kurze Liste zeigt meist die richtige Spur, bevor jemand über Frameworks diskutiert.
Wichtigste Erkenntnis: Felddaten entscheiden, ob die Website langsam ist. Lab-Daten helfen dir, den Hebel zu finden. Kehre diese Reihenfolge niemals um.
Frontend oder Server?
Wenn die Seite langsam ist, bevor Inhalte angezeigt werden, ist es meist der Server: hohe Time to First Byte, eine nicht gecachte Datenbankabfrage, PHP oder Node-Rendering bei jeder Anfrage, oder ein einfach unterversorgter Host. Wenn Inhalte erscheinen und dann ruckeln, steckenbleiben oder sich verschieben, ist es das Front-End: Bilder, Skripte, Schriftarten und Layout.
Eine nützliche Aufteilung: TTFB unter etwa 0,8 Sekunden bedeutet, der Ursprung ist größtenteils aus dem kritischen Pfad. Über 1,2 Sekunden auf einer beworbenen Seite: Behebe Hosting, Cache oder Server-Render-Kosten, bevor du dich auf Image-Codecs versteifst. Bei großen Websites hat die Diagnose ihr eigenes Playbook in der Core Web Vitals-Checkliste und dem LCP-, INP-, CLS-Fix-Guide auf dieser Website.
| Symptom | Likely lane | First check |
|---|---|---|
| Blank screen, then everything | Server / TTFB | Host, cache hit rate, SSR cost |
| Hero late, rest fine | Front-end LCP | Hero image size, preload, CDN |
| Taps feel sticky | Front-end INP | JS weight, long tasks, third parties |
| Page jumps while loading | Front-end CLS | Image dimensions, font swap, ads |
Wichtigste Erkenntnis: Benenne zunächst die Spur. Server-Arbeit und Front-End-Arbeit brauchen unterschiedliche Personen und unterschiedliche Tools.
Die üblichen sechs Verdächtigen
In der Reihenfolge, wie oft sie auf kommerziellen Websites das eigentliche Problem sind:
1. Übergroße Hero-Medien
Eine 2MB PNG oder ein nicht zugeschnittenes CMS-Upload als LCP-Element. Lösung: richtige Größe, modernes Format (WebP oder AVIF), width- und height-Attribute, preload der eigentlichen LCP-URL, Bereitstellung über ein CDN. Eine gute Hero-Optimierung schlägt oft zehn Mikro-Tweaks.
2. JavaScript, das du beim ersten Paint nicht brauchst
Tag Manager, Chat-Widgets, A/B-Tools, unnötige Framework-Hydration und „für den Fall der Fälle" Client-Komponenten. Lösung: Third-Party-Scripts defer oder entfernen, weniger JS auf Marketing-Routes laden, Interaktivitäts-Islands klein halten.
3. Hosting und Cache-Misses
Shared Hosts, kalte WordPress ohne Page Cache, Next.js SSR auf jeder öffentlichen URL oder ISR-Muster, die bei jedem Deploy die ganze Welt neubauen. Lösung: Managed Hosting oder Edge-Cache für WordPress, Static oder ISR mit einer sinnvollen Revalidate-Policy für App-Frameworks.
4. Render-blockierende Fonts und CSS
Fünf Gewichtungen einer Display-Font, importiert aus einer Third-Party-CSS-Datei, blockiert Text. Lösung: subsetten, selbst hosten, font-display swap oder optional, kritisches CSS für Above-the-Fold.
5. Unbegrenzte Third Parties
Pixel, die mehr Pixel einschleusen. Lösung: nach Benutzerinteraktion oder im Leerlauf laden, alles löschen, das sich nicht in einem Konversions-Test bewährt.
6. Layout-Verschiebung durch verspätete Inhalte
Anzeigen, Einbettungen und Bilder ohne reservierten Platz. Lösung: Seitenverhältnis-Boxen, reservierte Slots, UI nicht über vorhandenen Inhalten einfügen.
Wichtigste Erkenntnis: Die meisten „das Framework ist langsam"-Beschwerden sind eines dieser sechs Probleme im Framework-Gewand.
Repariere zuerst das Größte
Optimiere nicht alles gleichzeitig. Öffne den LCP-Eintrag in deinen Felddiagnosen oder Lab-Diagnosen, finde das Element, das das LCP ist (normalerweise das Hero-Bild oder die Überschrift), und mache genau dieses eine Ding schnell: richtig skaliert, vorgeladen, von einem CDN bereitgestellt. Erneut messen. Dann entferne JavaScript, das auf dem Critical Path läuft. Erneut messen.
Eine praktische Reihenfolge für eine Marketing-Website: LCP-Element, dann Third-Party-JS, dann Font-Loading, dann Cache und TTFB, dann CLS-Bereinigung, dann Mikro-Optimierungen. Nach den ersten beiden oft schon im angestrebten CWV-Bereich.
WordPress-Hinweis: Eine Plugin-Diät und echter Page-Cache auf verwaltetes Hosting schlagen einen Theme-Neuschreiben häufiger als Agenturen zugeben. Next.js- und Astro-Hinweis: SSR nicht für die Broschüre verwenden. Statisches oder gecachtes HTML für öffentliche Seiten; Server-Arbeit für authentifizierte Produktoberflächen reservieren. Details stehen im Next.js vs Astro vs WordPress Guide.
Wichtigste Erkenntnis: Ein gemessener LCP-Gewinn schlägt eine Woche spekulativer Refaktorierung.
Stack-spezifische Fehlermodi
WordPress
Page Builder versenden bei jedem Aufruf das komplette Widget-CSS. Ungecachte WooCommerce-Templates. Schwere Related-Posts-Abfragen. Autoload-Optionstabellen, die sich über Jahre aufgebaut haben. Lösungsweg: HTML am Edge cachen, Plugins reduzieren, Builder-Abschnitte unterhalb des Viewports lazy-loaden, Datenbank-Autoload-Bloat beheben.
Next.js
Client Components, die ganze Seiten umhüllen. Wasserfälle von sequenziellen Awaits. Bilder durch den falschen Loader. ISR oder SSR auf Seiten, die sich nie personalisieren. Lösungsweg: Server Components standardmäßig, statisch wo möglich, JavaScript-Bundle pro Route überprüfen.
Astro und andere Static-Stacks
Normalerweise schnell, es sei denn, du führst eine SPA-Island ein, die die Größe einer Product-App hat, oder verlinkst große CMS-Medien direkt. Lösungsweg: Islands klein halten, Bilder in der Pipeline verarbeiten, WordPress-Gewohnheiten nicht in eine statische Site kopieren.
Haupterkenntnis: Passe die Lösung an den Stack an. Ein Plattformwechsel ist selten der erste Performance-Schritt.
So sieht es richtig aus
Ziele, gemessen bei echten Besuchern beim 75. Perzentil auf dem Mobilgerät: Largest Contentful Paint unter 2,5 Sekunden, Interaction to Next Paint unter 200 Millisekunden, Cumulative Layout Shift unter 0,1. Time to First Byte unter etwa 0,8 Sekunden halten, damit der Server nicht im kritischen Pfad liegt.
Wenn du diese Werte erreichst, ist die Site in keiner Weise langsam – weder für Besucher noch für Google –, egal was ein synthetischer Vanity-Score sagt. Alles Schnellere ist Feinschliff. Liefere das Produkt statt 100er zu jagen.
Wenn du die Checklisten-Form dieser Arbeit willst, nutze die Core Web Vitals Checkliste. Wenn du eine Punkt-für-Punkt-Reparatur brauchst, nutze die LCP-, INP- und CLS-Anleitung. Wenn der Business Case ein Rebuild ist, starte vom Performance-Pillar statt von einem Redesign-Deck.
Haupterkenntnis: Das Bestehen von CWV im Feld ist die Ziellinie für „ist es langsam?", nicht ein perfektes Lighthouse-Screenshot.
Wann man mit DIY aufhören und Hilfe holen sollte
DIY reicht aus, wenn das LCP-Element offensichtlich ist, es wenige Drittanbieter gibt und du das Hosting kontrollierst. Hole dir Hilfe, wenn die Field-Daten nach zwei ehrlichen Fix-Zyklen immer noch rot sind, wenn der Stack ein Hybrid ist, den niemand im Team versteht, oder wenn Revenue-Seiten keine weitere Woche mit spekulativen Änderungen verkraften können.
Ein nützliches Briefing für einen Außenstehenden: die drei URLs, die zählen, die Field-Screenshots, die Namen der LCP-Elemente, der Host und das CDN, und die Liste der Tags, die du nicht entfernen darfst. Dieses Paket verwandelt ein vages „die Seite ist langsam" in einen Job für einen Sprint.
Wenn das Gespräch in einen vollständigen Redesign übergeht, mache eine Pause. Performance-Arbeit und Redesign-Arbeit passen schlecht zusammen, es sei denn, der Redesign hat ein explizites CWV-Budget. Behebe zuerst die aktuellen Templates, wenn das Business noch davon abhängt.
Wichtigste Erkenntnis: Zwei gescheiterte Fix-Zyklen oder kein klarer Verantwortlicher sind die Grenze zwischen DIY und einem bezahlten Performance-Engagement.