WARUM IHRE WEBSITE SO LANGSAM IST

Wenn Sie die DevTools öffnen, drei Plugins ändern und die Seite neu bereitstellen, ohne sich die Felddaten anzusehen, raten Sie nur und verursachen unnötige Schritte. Langsamkeit beeinträchtigt das Nutzererlebnis. Belegen Sie dies mit Zahlen von echten Nutzern, bevor Sie den Code ändern.

Beginnen Sie mit den Felddaten des Chrome UX Reports in PageSpeed Insights oder den Core Web Vitals der Search Console. Achten Sie auf das 75. Perzentil für „Largest Contentful Paint“, „Interaction to Next Paint“ und „Cumulative Layout Shift“ auf Mobilgeräten. Die Lab-Ergebnisse von Lighthouse sind nützlich für die Fehlerbehebung beim Laden einzelner Seiten. Sie sind jedoch weder die Metrik, die Google für das Ranking verwendet, noch die Metrik, die Ihre Kunden bei einer WLAN-Verbindung im Zug wahrnehmen.

Was sollte in den ersten zehn Minuten vermittelt werden?

URL der langsamen Seite. Geräteklasse (vorrangig Smartphone). Ob es sich um einen Erstbesuch oder einen wiederholten Besuch handelt. Ob sich die Seiten nach der Anmeldung von der öffentlichen Startseite unterscheiden. TTFB, sofern sichtbar. Der Name des LCP-Elements aus dem Diagnosefenster. Diese kurze Liste weist in der Regel bereits in die richtige Richtung, bevor überhaupt über Frameworks diskutiert wird.

Das Wichtigste auf einen Blick: Die Felddaten entscheiden darüber, ob die Website langsam ist. Die Labordaten helfen Ihnen dabei, den Hebel zu finden. Kehren Sie diese Reihenfolge niemals um.

Wenn die Seite langsam ist, bevor überhaupt Inhalte angezeigt werden, liegt das in der Regel am Server: eine lange Zeit bis zum ersten Byte, eine nicht zwischengespeicherte Datenbankabfrage, PHP- oder Node-Rendering bei jeder Anfrage oder ein Host, der einfach nicht leistungsfähig genug ist. Wenn Inhalte zwar angezeigt werden, dann aber ruckeln, hängen bleiben oder sich verschieben, liegt das am Frontend: Bilder, Skripte, Schriftarten und Layout.

Eine hilfreiche Einteilung: Ein TTFB von unter etwa 0,8 Sekunden bedeutet, dass die Quelle größtenteils außerhalb des kritischen Pfades liegt. Liegt der Wert auf einer vermarkteten Seite über 1,2 Sekunden, sollten Sie zunächst Probleme mit dem Hosting, dem Cache oder den Server-Rendering-Kosten beheben, bevor Sie sich mit Bildcodecs beschäftigen. Für große Websites gibt es eine eigene Anleitung in der Core Web Vitals-Checkliste sowie im Leitfaden zur Behebung von LCP-, INP- und CLS-Problemen auf dieser Website.

Das Wichtigste auf einen Blick: Legen Sie zuerst den Arbeitsbereich fest. Für die Server- und die Frontend-Arbeit werden unterschiedliche Mitarbeiter und unterschiedliche Tools benötigt.

In der Reihenfolge, wie oft sie auf den von mir besuchten kommerziellen Websites das eigentliche Problem darstellen:

1. Überdimensionale Hero-Medien

Ein 2 MB großes PNG oder ein unbeschnittenes CMS-Upload als LCP-Element. Lösung: passende Größe, modernes Format (WebP oder AVIF), Attribute für Breite und Höhe, Vorladen der tatsächlichen LCP-URL, Bereitstellung über ein CDN. Eine gute, grundlegende Lösung ist oft besser als zehn kleine Optimierungen.

2. JavaScript, das beim ersten Laden nicht benötigt wird

Tag-Manager, Chat-Widgets, A/B-Tools, ungenutzte Framework-Initialisierung und Client-Komponenten „für alle Fälle“. Lösung: Drittanbieter-Elemente verzögern oder entfernen, weniger JS auf Marketing-Routen bereitstellen, Interaktionsbereiche klein halten.

3. Hosting und Cache-Fehltreffer

Shared Hosting, unoptimiertes WordPress ohne Seiten-Cache, Next.js-SSR für jede öffentliche URL oder ISR-Muster, die bei jedem Deployment die gesamte Website neu generieren. Lösung: Managed Hosting oder Edge-Cache für WordPress, statische Inhalte oder ISR mit einer vernünftigen Revalidierungsrichtlinie für App-Frameworks.

4. Render-blockierende Schriftarten und CSS

Fünf Schriftstärken einer Display-Schriftart, die aus einer CSS-Datei eines Drittanbieters importiert wurden, blockieren den Text. Lösung: „subset“, „self-host“, „font-display: swap“ oder optionales, kritisches CSS für den Bereich oberhalb der Falz.

5. Unbegrenzte Dritte

Pixel, die noch mehr Pixel einblenden. Lösung: Erst nach einer Interaktion oder im Leerlauf laden; alles entfernen, was sich in einem Konversionstest nicht bewährt hat.

6. Layoutverschiebung durch nachfolgende Inhalte

Anzeigen, Einbettungen und Bilder ohne reservierten Platz. Lösung: Boxen mit festem Seitenverhältnis, reservierte Plätze, Einblenden von Benutzeroberflächen über vorhandenen Inhalten vermeiden.

Das Wichtigste auf einen Blick: Die meisten Beschwerden, dass „das Framework langsam ist“, lassen sich einer dieser sechs Ursachen zuordnen, die sich nur als „Framework-Problem“ tarnen.

Optimieren Sie nicht alles auf einmal. Öffnen Sie den LCP-Eintrag in Ihrer Feld- oder Labordiagnose, suchen Sie das Element, das den LCP ausmacht (in der Regel das Hero-Bild oder die Überschrift), und sorgen Sie dafür, dass genau dieses Element schnell geladen wird: in der richtigen Größe, vorgeladen und über ein CDN bereitgestellt. Messen Sie erneut. Reduzieren Sie dann das JavaScript, das auf dem kritischen Pfad ausgeführt wird. Messen Sie erneut.

Eine sinnvolle Reihenfolge für eine Marketing-Website: LCP-Element, dann JS von Drittanbietern, dann das Laden von Schriftarten, dann Cache und TTFB, dann CLS-Optimierung, dann Mikrooptimierungen. Wenn man nach den ersten beiden Schritten aufhört, erreicht eine kommerzielle Website oft bereits einen akzeptablen CWV-Wert.

Anmerkung zu WordPress: Eine Plugin-Reduzierung und ein echter Seitencache auf Managed Hosting sind oft effektiver als eine Neuprogrammierung des Themes – auch wenn Agenturen dies seltener zugeben, als man denkt. Anmerkung zu Next.js und Astro: Führen Sie kein SSR für die Broschüre durch. Verwenden Sie statisches oder zwischengespeichertes HTML für öffentliche Seiten; reservieren Sie die Serverleistung für authentifizierte Produktbereiche. Details finden Sie im Leitfaden „Next.js vs. Astro vs. WordPress“.

Das Wichtigste auf einen Blick: Ein gut durchdachter LCP-Erfolg ist mehr wert als eine Woche spekulativer Refactorings.

WordPress

Page-Builder, die auf jeder Seite das gesamte CSS aller Widgets ausliefern. Nicht zwischengespeicherte WooCommerce-Vorlagen. Aufwändige Abfragen nach verwandten Beiträgen. Automatisch geladene Optionstabellen, die über Jahre hinweg immer größer geworden sind. Lösungsweg: HTML am Edge zwischenspeichern, Plugins reduzieren, Builder-Abschnitte unterhalb der Falz per Lazy-Load laden, die aufgeblähte automatische Datenladung beheben.

Next.js

Client-Komponenten, die ganze Seiten umschließen. Eine Flut aufeinanderfolgender Wartezeiten. Bilder, die über den falschen Loader geladen werden. ISR oder SSR auf Seiten, die nie personalisiert werden. Lösungsansatz: Standardmäßig Serverkomponenten verwenden, statische Inhalte wo möglich einsetzen, das JS-Bundle pro Route überprüfen.

Astro und andere statische Stacks

In der Regel schnell, es sei denn, man führt wieder eine SPA-Insel in der Größe einer Produkt-App ein oder verlinkt riesige CMS-Medien per Hotlink. Lösung: Inseln klein halten, Bilder in der Pipeline verarbeiten, keine WordPress-Gewohnheiten in eine statische Website übertragen.

Das Wichtigste auf einen Blick: Passen Sie die Lösung an die Plattform an. Ein Plattformwechsel ist selten der erste Schritt zur Leistungsoptimierung.

Zielwerte, gemessen anhand der tatsächlichen Besucher im 75. Perzentil auf Mobilgeräten: „Largest Contentful Paint“ unter 2,5 Sekunden, „Interaction to Next Paint“ unter 200 Millisekunden, „Cumulative Layout Shift“ unter 0,1. Die Zeit bis zum ersten Byte sollte unter etwa 0,8 Sekunden liegen, damit der Server nicht in den kritischen Pfad gerät.

Wenn du diese Punkte beachtest, ist die Website in keiner Weise langsam, sodass weder Besucher noch Google sie abstrafen würden – ganz gleich, was ein künstlicher Vanity-Score auch immer aussagt. Alles, was schneller ist, ist nur noch Feinarbeit. Bring das Produkt auf den Markt, anstatt nach der 100er-Marke zu jagen.

Wenn Sie eine Checkliste für diese Aufgabe benötigen, nutzen Sie die „Core Web Vitals“-Checkliste. Wenn Sie gezielte Maßnahmen für einzelne Kennzahlen benötigen, nutzen Sie den Leitfaden zur Behebung von LCP-, INP- und CLS-Problemen. Wenn es sich bei dem Business Case um eine Neugestaltung handelt, beginnen Sie mit der Säule „Leistung“ und nicht mit einer Neugestaltungspräsentation.

Das Wichtigste auf einen Blick: Das Bestehen des Feldes „CWV“ ist die Ziellinie bei der Frage „Ist es langsam?“, nicht ein perfekter Lighthouse-Screenshot.

DIY reicht aus, wenn das LCP-Problem offensichtlich ist, es nur wenige Drittanbieter gibt und Sie die Kontrolle über das Hosting haben. Holen Sie sich Hilfe, wenn die Felddaten nach zwei ernsthaften Optimierungsrunden weiterhin im roten Bereich liegen, wenn es sich um einen Hybrid-Stack handelt, für den niemand im Team die Verantwortung übernimmt, oder wenn die Umsatzseiten keine weitere Woche mit spekulativen Änderungen verkraften können.

Eine nützliche Übersicht für Außenstehende: die drei wichtigen URLs, die Screenshots der Felder, die Namen der LCP-Elemente, der Host und das CDN sowie die Liste der Tags, die nicht entfernt werden dürfen. Mit diesem Paket lässt sich ein vages „Die Website ist langsam“ in eine Aufgabe verwandeln, die in einem einzigen Sprint erledigt werden kann.

Sollte sich das Gespräch in Richtung einer kompletten Neugestaltung entwickeln, halten Sie inne. Maßnahmen zur Leistungsoptimierung und Neugestaltungsarbeiten lassen sich nur schwer miteinander vereinbaren, es sei denn, für die Neugestaltung steht ein explizites CWV-Budget zur Verfügung. Optimieren Sie zunächst die aktuellen Vorlagen, solange das Unternehmen noch auf diese angewiesen ist.

Das Wichtigste auf einen Blick: Zwei erfolglose Fehlerbehebungszyklen oder das Fehlen eines klaren Verantwortlichen sind die Grenze zwischen „Selbermachen“ und einem kostenpflichtigen Performance-Pass.