Zum Inhalt springen
Kontakt ↗
Probleme & Lösungen

Die Website lädt langsam: Wie findet man den tatsächlichen Engpass?

Robin Matthäi · Veröffentlichung · ca. 9 Minuten Lesezeit

Sie klicken auf eine Seite. Die Registerkarte dreht ihre Runden, die Überschrift lässt auf sich warten und kurz vor dem nächsten Klick rutscht ein Element weg. Wenn Ihre Website langsam lädt, hilft eine gezielte Untersuchung: Wo entsteht die Wartezeit? Was braucht der erste sichtbare Bereich? Und welche Änderung verbessert die Nutzung, ohne Gestaltung oder Funktionen zu beschädigen?

Illustration: Eine Lupe untersucht einen verengten Ladepfad zwischen einer Website und ihren Bild-, Schrift- und Codebausteinen.
Für wen?
Geschäftsführung und Marketingverantwortliche, deren Unternehmenswebsite zu langsam oder beim Laden unruhig wirkt.
Ihr Bedarf
Sie möchten die Ursache eingrenzen und wissen, welche Verbesserung zuerst sinnvoll ist.
Das nehmen Sie mit
Einen Prüfplan, eine Prioritätenmatrix und unsere Erfahrung mit schnellerem, stabilem Seitenaufbau.
Das Wichtigste zuerst

Messen Sie die Wartezeit und prüfen Sie ihre Ursache.

Beginnen Sie mit einer wichtigen Seite, einem mobilen Test und einem dokumentierten Ausgangsstand. PageSpeed Insights liefert Hinweise auf Engpässe. Prüfen Sie anschließend, welche Ressource oder welcher Arbeitsschritt den sichtbaren Inhalt tatsächlich verzögert. Erst danach setzen Sie die passende Änderung um.

Unser redaktioneller Prüfweg: messen, Ursache eingrenzen, nach Wirkung priorisieren, gezielt ändern und erneut prüfen. Beziehen Sie die Gestaltung und Bedienung in den Vergleich ein. Ein besserer Messwert reicht nicht, wenn anschließend die Navigation ihren Dienst quittiert.

Für den ersten Durchgang

Wählen Sie eine Seite, die Interessenten wirklich brauchen, beispielsweise eine wichtige Leistungsseite. Notieren Sie URL, Datum, mobile oder Desktopprüfung und die auffälligsten Werte. Untersuchen Sie zunächst einen nachvollziehbaren Engpass.

Prüfschritt 01

Was zeigt PageSpeed Insights und was bleibt offen?

PageSpeed Insights kombiniert eine Lighthouse-Laborprüfung mit Nutzungsdaten, sofern ausreichend Daten vorhanden sind. Der Labortest simuliert einen Seitenaufruf; die Felddaten bilden Erfahrungen echter Nutzer über einen zurückliegenden Zeitraum ab. Beide Ansichten können unterschiedliche Ergebnisse zeigen. Fehlende Felddaten bedeuten zunächst eine fehlende ausreichende Datenbasis. [1]

Vergleichen Sie mehrere Durchläufe unter ähnlichen Bedingungen. Halten Sie fest, ob Sie Mobil oder Desktop prüfen. Ein bereits gefüllter Browsercache kann den eigenen Aufruf schneller wirken lassen als den ersten Besuch eines Interessenten.

Diese Fragen helfen bei der Einordnung

  • Inhalt: Wann wird der wichtige Einstiegsinhalt sichtbar?
  • Stabilität: Verschiebt sich die Seite während des Ladens?
  • Bedienung: Reagieren Navigation und Kontaktweg zuverlässig?
  • Messbedingungen: Sind Seite, Testmodus und Ausgangslage vergleichbar?

Der Gesamtwert ist eine Orientierung. Die Diagnose entsteht aus den Einzelwerten, den betroffenen Elementen und ihren Ladeabläufen. Hinweise zur möglichen Zeitersparnis sind Schätzungen; sie lassen sich nicht einfach zu einer garantierten Verbesserung addieren.

Prüfschritt 02

Welcher große Inhalt erscheint zu spät?

Largest Contentful Paint, kurz LCP, erfasst, wann das größte relevante Bild oder der größte Textblock im sichtbaren Bereich gerendert wird. Bei Ihrer Seite kann das ein Foto, eine Überschrift oder ein anderer Textblock sein. Der LCP ist deshalb nicht automatisch ein Bildproblem. [2]

Bestimmen Sie zuerst das konkrete Element. Prüfen Sie dann: Wartet der Browser lange auf die Serverantwort? Entdeckt er die benötigte Ressource spät? Dauert ihre Übertragung lange? Oder ist sie bereits geladen, kann aber noch nicht dargestellt werden?

Fiktives Beispiel

Eine Überschrift wird erst sichtbar, wenn ihre Webschrift geladen ist. Das große Foto weiter unten zu verkleinern kann Daten sparen, löst aber nicht zwingend die Verzögerung dieser Überschrift. Der Prüfhinweis muss zur Ursache passen.

Bei einem Text-LCP untersuchen Sie die Schriftdatei, ihre Ladepriorität und das Verhalten vor ihrer Verfügbarkeit. Bei einem Bild-LCP prüfen Sie Größe, Format und Ladebeginn. Ein wichtiges Einstiegsbild soll nicht erst durch verzögertes Laden angefordert werden.

Prüfschritt 03

Was lädt die Seite, obwohl der Besucher es noch nicht braucht?

Prüfen Sie im Netzwerkprotokoll, welche Bilder, Schriftdateien, Stylesheets und Skripte angefordert werden. Ordnen Sie sie einem sichtbaren Inhalt oder einer tatsächlich benötigten Funktion zu. Auch der Server und eingebundene Drittanbieter gehören zur Untersuchung.

Bilder passend ausliefern

Ein Smartphone braucht für eine kleine Vorschau nicht dieselbe Bildauflösung wie ein großer Bildschirm. Mit passenden Breitenvarianten, srcset und sizes kann der Browser eine geeignete Datei wählen. Kontrollieren Sie die tatsächliche Auswahl; allein die Anzahl vorhandener Varianten beweist noch keine passende Auslieferung. [3]

In unserem Projekt erzeugen wir responsive WebP-Dateien und komprimierte Fallbacks. Bilder im Einstieg werden priorisiert, nachrangige Bilder verzögert geladen. Die benötigten Größen richten sich nach Bildrolle und Darstellung; eine feste Zahl von Varianten ist kein allgemeiner Standard.

CSS und JavaScript nach ihrem Nutzen prüfen

Eine Gestaltungsvorlage oder Erweiterung kann zusätzliche Ressourcen und Abhängigkeiten mitbringen. Entscheidend sind die tatsächlich geladenen Dateien und ihre Arbeit im Browser. Viele Plugins sind ein Prüfhinweis, aber für sich allein keine Diagnose.

Bei SQUAREMOON wird CSS pro Seite auf die benötigten Regeln reduziert. JavaScript wird minifiziert und komprimiert ausgeliefert. Wiederholte Layoutmessungen in Animationen wurden durch gebündelte Messungen und zwischengespeicherte Werte ersetzt. Kleine Dateien und wenig Rechenarbeit ergänzen sich dabei.

Ein Systemwechsel ist eine eigene Entscheidung. Wenn Sie diesen erwägen, hilft unser Vergleich von WordPress und statischen Websites, auch Pflege und Teamarbeit einzuordnen.

Prüfschritt 04

Bleibt der Inhalt beim Laden an seinem Platz?

Cumulative Layout Shift, kurz CLS, beschreibt unerwartete Layoutverschiebungen. Ein nachladendes Bild, ein zusätzlich eingeblendeter Bereich oder ein Schriftwechsel kann Inhalt verschieben. Das stört beim Lesen und kann den geplanten Klick erschweren. [4]

Reservieren Sie den benötigten Platz für Medien über echte Abmessungen oder ein passendes Seitenverhältnis. Berücksichtigen Sie auch dynamische Bereiche und den Wechsel zwischen Ersatzschrift und Markenschrift. Text bleibt responsiv; eine starre Höhe für sämtliche Inhalte kann neue Probleme erzeugen.

Prüfen Sie den Aufbau mit leerem Cache und langsamerer Verbindung. Beobachten Sie den Schriftwechsel, Bilder und fixierte Elemente. Eine gute Momentaufnahme beweist noch nicht, dass die gesamte Ladephase stabil bleibt.

Prüfschritt 05

Unveränderte Dateien dürfen wiederverwendet werden.

Ein Browsercache kann bereits geladene Dateien wiederverwenden. Das hilft bei Folgebesuchen und Seitenwechseln mit gemeinsamen Ressourcen. Der erste Besuch und der Aufruf mit gefülltem Cache müssen deshalb getrennt betrachtet werden. [5]

Bei SQUAREMOON erhalten öffentliche Bilder, Schriften und Skripte eine vom Dateiinhalt abhängige Versionskennung. Unveränderte Dateien bleiben lange nutzbar; eine geänderte Datei erhält eine neue URL. HTML wird vor der Wiederverwendung beim Server geprüft. So gehören schnelle Wiederverwendung und ein aktueller Seitenstand zusammen.

Cachefehler erkennen

Wenn eine Änderung auf einem frischen Gerät funktioniert und im gewohnten Browser nicht, prüfen Sie die ausgelieferten Dateiversionen. Den Browsercache manuell zu leeren ist ein Diagnoseschritt. Besucher sollten das nicht regelmäßig tun müssen.

Aus unserer eigenen Websitearbeit

Was bei SQUAREMOON spürbar geholfen hat.

Unsere frühere WordPress-Website nutzte unter anderem Enfold und verschiedene Plugins. Robin empfand die Abhängigkeiten dieses Aufbaus als Hürde bei der Optimierung. Heute betreut er überwiegend statische Seiten mit Codex und kann gezielt festlegen, welche Funktionen und Ressourcen wir benötigen. Diese Erfahrung beschreibt unseren damaligen und heutigen Aufbau. Sie belegt nicht, dass WordPress grundsätzlich langsam ist oder Enfold immer sämtliche Funktionen lädt.

Robin hat sowohl Lighthouse als auch PageSpeed Insights genutzt. Zusätzlich fiel ihm im Alltag auf, dass Seitenwechsel auf der neuen Website unmittelbar wirkten, während er beim früheren Aufbau deutlich auf das Laden wartete. Das ist seine persönliche Beobachtung. Ein belastbarer Vorher-nachher-Vergleich beider Systeme unter identischen Bedingungen liegt diesem Artikel nicht zugrunde.

Ein Textelement führte uns zur Schrift

Besonders deutlich erinnert sich Robin an die Verbesserung des LCP durch die Schriftoptimierung. Im dokumentierten Prüfstand war der Above-the-Fold-Text das LCP-Element. Wir reduzierten die Startseiten-Schrift auf die tatsächlich benötigten Zeichen und Gewichte und sorgten für einen passenden Ladebeginn.

Die dokumentierte WOFF2-Teildatei sank von rund 63 KB über einen Zwischenstand auf 20.904 Byte, also rund 21 KB. Das ist eine belegte Verringerung der Dateigrösse. Wir leiten daraus keine erfundene Ersparnis in Sekunden ab. Die Markenschrift und ihr freigegebenes Erscheinungsbild sollten erhalten bleiben.

Layoutstabilität gehörte zur selben Aufgabe

Ebenso wichtig war Robin, dass beim Laden nichts mehr unerwartet verrutscht. Wir reservierten Platz für Medien und prüften die Geometrie des Einstiegs. Für die mobile Ersatzschrift wurden die Metriken an die Markenschrift angepasst.

Bei einem dokumentierten Kaltstarttest mit um 800 Millisekunden verzögerter Schriftantwort blieben Überschrift und Teaser auf Smartphone, Tablet und Desktop geometrisch unverändert. Der mobile CLS lag in diesem Test bei 0. Das ist ein Ergebnis dieses Prüfstands und keine Garantie für jeden Aufruf oder jede spätere Seite.

Wissen macht den nächsten Auftrag konkreter

Heute würde Robin zuerst PageSpeed Insights öffnen und die auffälligen Engpässe prüfen. Für eine von uns mit Codex betreute Website gibt er die Performance-Wissensdatei als Arbeitsgrundlage vor: Lighthouse-Test durchführen, die Ursache untersuchen und anhand der dokumentierten Regeln optimieren. Er muss die technischen Einzelschritte dadurch nicht jedes Mal neu formulieren.

Zur Fertigstellung gehören dennoch Vergleichsmessungen und Funktionsprüfungen. Die CI bleibt erhalten. Animationen müssen funktionieren, Sprungmarken ihre Ziele erreichen und fixierte Elemente ihr vorgesehenes Verhalten behalten. Diese Anforderungen sind Teil unseres Optimierungsauftrags.

Vom Befund zur Maßnahme

Welche Änderung bearbeiten Sie zuerst?

Die folgende Matrix ist unsere redaktionelle Arbeitshilfe. Beginnen Sie mit einem nachvollziehbaren Befund auf einer wichtigen Seite. Prüfen Sie die erwartete Wirkung, den Aufwand und das Risiko für die vorhandene Gestaltung.

Vom beobachteten Problem zum ersten Prüfschritt
BeobachtungZuerst prüfenMögliche Maßnahme
Der erste Inhalt erscheint spätServerantwort und blockierende RessourcenBestätigte Wartezeit an Server oder Ladepfad reduzieren
Die Überschrift erscheint spätText-LCP und benötigte SchriftdateiSchriftumfang und Ladebeginn gezielt optimieren
Das Einstiegsbild erscheint spätTatsächliche Bilddatei, Größe und AnforderungsbeginnPassende Variante ausliefern und rechtzeitig laden
Inhalt springt beim LadenMedienabmessungen, Schriftwechsel und dynamische BereichePlatz reservieren und Layoutwechsel verhindern
Die Bedienung stocktLang laufende Skripte und wiederholte LayoutarbeitUnnötige Arbeit entfernen und Messungen bündeln
Folgebesuche laden dieselben Dateien neuCacheheader und DateiversionenUnveränderte Ressourcen kontrolliert wiederverwenden

Setzen Sie die Hinweise in Beziehung zur tatsächlichen Nutzung. Ein kleiner Dateigewinn weit unten auf der Seite kann weniger dringlich sein als eine verzögerte Überschrift oder ein stockender Kontaktweg. Die Matrix ersetzt keine Untersuchung Ihrer konkreten Website.

Eine kompakte Arbeitsliste

So wird aus dem Test ein nachvollziehbarer Auftrag.

1. Ausgangsstand sichern

URL, Datum, Testmodus und Einzelwerte festhalten. Ergänzen Sie die beobachtete Hürde und das gewünschte Besucherziel.

2. Ursache bestätigen

Betroffenes Element und Ladeablauf untersuchen. Welche Datei oder welcher Arbeitsschritt verursacht die Verzögerung?

3. Eine Priorität wählen

Wirkung, Aufwand und Risiken abwägen. Ein begrenzter Auftrag erleichtert die Zuordnung der anschliessenden Veränderung.

4. Änderung vergleichen

Mehrere ähnliche Testläufe durchführen. Einzelwerte, Ladefilm und sichtbares Verhalten mit dem Ausgangsstand vergleichen.

5. Bedienung erhalten

Menü, Animationen, Sprungmarken, fixierte Elemente und Kontaktweg auf Smartphone, Tablet und Desktop prüfen.

6. Ergebnis dokumentieren

Bestätigte Ursache, Lösung, Messbedingungen und Grenzen festhalten. Die Erkenntnis in künftige Seitenarbeit übernehmen.

Unser Prüfweg für mobile Website-Hürden ergänzt die Ladeprüfung um Orientierung und Bedienung. Eine schnelle Seite muss ihre Besucher auch zum passenden Inhalt führen.

Der nächste sinnvolle Schritt

Verbessern Sie den Engpass und prüfen Sie das Gesamtergebnis.

Wenn eine Website langsam lädt, beginnen Sie mit einer relevanten Seite und einer nachvollziehbaren Messung. Untersuchen Sie den tatsächlichen Ladepfad, statt vorsorglich Bilder, Schriften und Funktionen zu streichen. Bei SQUAREMOON waren unter anderem Schriftumfang, Ladepriorität und stabiler Seitenaufbau wichtige Ansatzpunkte.

Eine gelungene Optimierung verbindet weniger Wartezeit mit der vorgesehenen Gestaltung und zuverlässiger Bedienung. Wenn Sie die Ursache und den nächsten Schritt klären möchten, lässt sich die technische Weiterentwicklung Ihrer Website auf dieser Grundlage gezielt planen.

Wo verliert Ihre Website beim Laden Zeit?

Bringen Sie eine wichtige Seite und vorhandene PageSpeed-Ergebnisse mit. Gemeinsam klären wir, welcher Engpass zuerst untersucht werden sollte und welche Gestaltung und Funktionen erhalten bleiben müssen.

Website-Performance besprechen
Zum Nachlesen

Quellen und redaktionelle Einordnung

Die verlinkten Primärquellen ergänzen die Empfehlungen dieses Artikels. Die Entscheidungshilfen und Prüfwege sind unsere redaktionelle Einordnung, kein von den Quellen belegtes Erfolgsversprechen. Fiktive Beispiele sind im Text gekennzeichnet. Quellen zuletzt geprüft am 03.10.2026.

  1. Google: About PageSpeed Insights

    Erklärt Labor- und Felddaten, Messschwankungen und die Einordnung der PageSpeed-Ergebnisse.

  2. web.dev: Optimize Largest Contentful Paint

    Grundlage zur Bestimmung des LCP-Elements und zur Untersuchung der einzelnen Verzögerungen im Ladepfad.

  3. MDN: Using responsive images in HTML

    Erklärt Bildvarianten sowie die Auswahl mit srcset und sizes.

  4. web.dev: Optimize Cumulative Layout Shift

    Grundlagen zu Layoutverschiebungen, reserviertem Medienplatz und Schriftwechseln.

  5. MDN: HTTP caching

    Erklärt Wiederverwendung, Revalidierung und die Versionierung langlebig gecachter Ressourcen.

Autorenfoto: SQUAREMOON.

Weitere Probleme & Lösungen