Ladezeit der Kanzleiwebsite prüfen: Was zuerst verbessern?
Wie Sie einen PageSpeed-Bericht einordnen und daraus eine begründete erste Maßnahme für Ihre Kanzleiwebsite ableiten.
Kurz erklärt
Verbessern Sie zuerst einen belegten Engpass auf einer wichtigen Leistungs- oder Kontaktseite. Ein hoher PageSpeed-Wert allein genügt nicht als Ziel. Ordnen Sie den Befund dem Laden, der Bedienung oder springenden Inhalten zu und lassen Sie die konkrete Ursache untersuchen. Erscheint ein Bild spät, kann sein verzögerter Ladestart wichtiger sein als die Dateigröße. Ein nicht funktionierendes Kontaktformular hätte ohnehin Vorrang vor dem nächsten Punkt im Geschwindigkeitstest.
In diesem Artikel
Welcher Befund gehört zu welcher Seite?
Für eine Kanzlei ist die Startseite nicht automatisch der wichtigste Prüfgegenstand. Wer über die Suche auf „Kündigung erhalten“ kommt, muss dort das Beratungsangebot verstehen und den Kontaktweg nutzen können. Eine schnelle Startseite sagt wenig darüber aus, ob diese Leistungsseite oder das anschließende Formular funktioniert.
Beginnen Sie deshalb mit einer Seite, die für einen konkreten Anfrageweg wichtig ist. Öffnen Sie deren vollständige Adresse in PageSpeed Insights und wählen Sie die relevante Geräteansicht. Mobil und Desktop gehören in getrennte Vergleiche. Für den Nachtest benötigen Sie dieselbe Adresse, Geräteauswahl und einen nachvollziehbaren Zustand des Cookie-Banners; sonst vergleichen Sie möglicherweise unterschiedliche Abläufe.
PageSpeed Insights zeigt zwei Datenarten: Felddaten aus realer Nutzung über die vergangenen 28 Tage und einen aktuellen, simulierten Lighthouse-Test. Reichen die Nutzungsdaten für die einzelne URL nicht aus, kann die Anzeige auf den gesamten Ursprung, also die Website, zurückfallen. Manchmal fehlen auch dort Daten. Das beschreibt Google in der Dokumentation zu PageSpeed Insights.
Steht über einem auffälligen Wert „Ursprung“, ist damit noch kein Fehler Ihrer ausgewählten Leistungsseite nachgewiesen. Der Wert umfasst auch andere Seiten. Fehlen Felddaten ganz, bedeutet das ebenfalls weder „schnell“ noch „langsam“. Dann sind ein reproduzierbarer Labortest und die tatsächliche Bedienung die verfügbaren Ausgangspunkte.
Was LCP, INP und CLS für die Priorität bedeuten
Die drei Core Web Vitals betrachten unterschiedliche Probleme:
- LCP – Laden: Wie spät erscheint das größte relevante Inhaltselement im sichtbaren Bereich? Der gute Bereich reicht bis 2,5 Sekunden.
- INP – Reaktion: Wie schnell reagiert die Seite sichtbar auf Bedienhandlungen? Gut sind höchstens 200 Millisekunden.
- CLS – Stabilität: Wie stark verschieben sich Inhalte unerwartet? Gut ist ein Wert von höchstens 0,1; das ist keine Zeitangabe.
Die Bewertung der Felddaten erfolgt am 75. Perzentil, nicht am Durchschnitt. Vereinfacht: Mindestens drei Viertel der erfassten Werte sollen die jeweilige gute Grenze einhalten. Die Definitionen und Grenzwerte stehen in Googles Übersicht zu Web Vitals.
Diese Unterscheidung verhindert den pauschalen Auftrag „Machen Sie die Website schneller“. Bei auffälligem LCP geht es zunächst um den Seitenaufbau. Bei INP muss eine langsame Bedienhandlung eingegrenzt werden. Bei CLS suchen Sie nach dem Element, das andere Inhalte verschiebt. Erst der dazu passende technische Befund bestimmt die Maßnahme.
Beispiel: Das Bild ist spät da, aber schnell heruntergeladen
Betrachten wir eine fiktive Arbeitsrechtskanzlei. Alle folgenden Messwerte sind erfunden, um die Entscheidung zu erklären; sie stammen weder von KanzleiPerformance noch aus einem Kundenprojekt. Die untersuchte Seite erklärt das Beratungsangebot nach einer Kündigung und führt zu einem Kontaktformular.
Für genau diese URL zeigt der mobile Feldbericht einen LCP von 4,1 Sekunden, einen INP von 160 Millisekunden und einen CLS von 0,05. Laden ist hier der auffällige Bereich; Reaktion und Stabilität liegen anhand dieser Werte im guten Bereich. Sofern der Kontaktweg funktioniert und kein anderer akuter Fehler vorliegt, würden wir zuerst den langsamen Seitenaufbau untersuchen lassen.
Im getrennten Labortest identifiziert die Website-Betreuung das große Einstiegsbild als LCP-Element. Die vier Sekunden bis zu seiner Darstellung verteilen sich in unserem Beispiel so:
| Abschnitt des Ladevorgangs | Beispielwert | Bedeutung für die Entscheidung |
|---|---|---|
| Bis zum ersten Byte der HTML-Antwort | 0,6 Sekunden | Ein Hostingwechsel wäre durch diesen Anteil allein noch nicht begründet. |
| Danach bis zum Start des Bilddownloads | 2,5 Sekunden | Hier liegt der größte Zeitanteil: Warum beginnt das Laden so spät? |
| Übertragung der Bilddatei | 0,4 Sekunden | Weitere Kompression betrifft zunächst diesen vergleichsweise kurzen Abschnitt. |
| Danach bis zur Darstellung des Bildes | 0,5 Sekunden | Auch nach dem Download vergeht noch Zeit, die bei Bedarf untersucht werden kann. |
Tabelle seitlich verschieben, um alle Spalten zu lesen.
Die Summe beträgt vier Sekunden. Der Labortest ist eine eigene Messsituation und muss nicht den Feldwert von 4,1 Sekunden reproduzieren. Entscheidend für diesen Befund ist: Der Browser wartet lange, bevor er das Bild überhaupt anfordert.
Die zusätzliche technische Untersuchung zeigt im Beispiel, dass eine Erweiterung die Bildadresse erst verzögert per Skript bereitstellt. Damit ist die Ursache genauer eingegrenzt als durch die Zeitanteile allein. Unser erster Auftrag wäre, dieses sofort sichtbare Einstiegsbild früher für den Browser verfügbar zu machen und von dieser verzögerten Einbindung auszunehmen. Die Erweiterung pauschal für die ganze Website abzuschalten wäre dafür kein notwendiger erster Schritt.
Google empfiehlt, LCP nach seinen Zeitanteilen zu untersuchen und ein LCP-Bild nicht verzögert per „Lazy Loading“ zu laden. Das bedeutet, Bilder erst bei Bedarf nachzuladen; beim sofort sichtbaren Hauptbild kann genau das im Weg stehen. Der Leitfaden zur LCP-Optimierung erklärt die Zusammenhänge.
Würde im Befund stattdessen die Übertragung der Datei den größten Anteil ausmachen, wäre deren Größe ein naheliegender Ansatz. In unserem Fall beseitigt eine kleinere Datei jedoch nicht die vorausgehende Wartezeit. Aus dem rechnerischen Anteil lässt sich auch keine feste Zeitersparnis versprechen: Nach einer Änderung können andere Abhängigkeiten den Ausschlag geben.
Wenn die Seite schnell erscheint, aber das Formular stockt
Ein zügiger Seitenaufbau schließt langsame Bedienung nicht aus. Für eine Kanzlei kann etwa der Wechsel zwischen Formularschritten wichtig sein. Wird die nächste Frage nach dem Antippen erst verzögert sichtbar, sollte genau diese Handlung untersucht werden. Eine beliebige weitere Bildoptimierung beantwortet diese Frage nicht.
Ein gewöhnlicher Lighthouse-Ladetest misst ohne Nutzereingaben keinen INP. Sein Wert „Total Blocking Time“, kurz TBT, kann auf Probleme hinweisen, ist aber kein Ersatz für den INP-Feldwert. Für die Diagnose braucht es die konkrete Interaktion. Googles Anleitung zur INP-Optimierung beschreibt, wie reale Befunde mit nachstellbaren Bedienabläufen verbunden werden.
Für unseren Anfrageweg bedeutet das: Leistungsseite öffnen, Kontakt aufrufen und die vorgesehenen Formularschritte auf dem Smartphone bedienen. Die Reaktion der Oberfläche und die erfolgreiche Übermittlung sind dabei zwei verschiedene Prüfungen. Eine sofort sichtbare Bestätigung beweist für sich allein noch nicht, dass die Anfrage im vorgesehenen Postfach oder System angekommen ist.
Verwenden Sie für einen vereinbarten Funktionstest eindeutig gekennzeichnete Testdaten. Ein echter Mandantenvorgang ist dafür nicht erforderlich. Ein eingebetteter Terminplaner darf während der Optimierung nicht einfach entfallen, wenn er der vorgesehene Kontaktweg ist; dann muss seine Einbindung untersucht oder eine funktionierende Alternative bereitgestellt werden.
Woran Sie eine sinnvolle Verbesserung erkennen
Für den Bildfall lautet der Nachtest konkret: Wird dieselbe Bilddatei nun früher angefordert, erscheint das Einstiegsbild früher und bleibt die mobile Leistungsseite vollständig bedienbar? Der Bericht sollte den geänderten Ladebeginn zeigen. Nur auf eine höhere Gesamtpunktzahl zu schauen würde die ursprüngliche Frage offenlassen.
Vergleichen Sie unter möglichst gleichen Testbedingungen und wiederholen Sie auffällig schwankende Ergebnisse. Datum, URL, Geräteansicht, geänderte Einstellung und Vorher-nachher-Bericht reichen als Grundlage für die Besprechung. Eine allgemeine Pflichtzahl von Testläufen gibt es für diesen Arbeitsauftrag nicht. Mehr Messungen helfen vor allem dann, wenn sie eine offene Ursache oder Schwankung klären.
Ein aktueller Labortest kann eine Änderung sofort abbilden. Der zurückblickende Feldbericht enthält zunächst weiterhin Besuche vor der Umstellung. Ein noch unveränderter Feldwert direkt nach der Veröffentlichung widerlegt den technischen Nachtest deshalb nicht. Umgekehrt ersetzt ein besserer Laborwert die spätere Beobachtung der realen Nutzung nicht.
Beauftragen Sie die nächste Maßnahme erst anhand des verbleibenden Problems. Im Beispiel wäre das möglicherweise die Zeit zwischen Bilddownload und Darstellung; ein funktionierender Kontaktweg bleibt daneben eine eigene Anforderung. Im Kanzleimarketing unterstützt diese technische Arbeit den Weg vom Beratungsangebot zur Anfrage. Welche Leistungen wir beim Aufbau und der Umsetzung übernehmen, steht unter Webdesign für Rechtsanwälte.
Technische Grundlagen der Website prüfen
Erfahren Sie, wie wir Aufbau und technische Umsetzung Ihrer Kanzleiwebsite bearbeiten.
Quellen und Einordnung
- Google: About PageSpeed Insights. Abgerufen am 08.10.2026. Felddaten der vergangenen 28 Tage, einzelne URL und gesamte Website; Unterschiede zum simulierten Labortest.
- web.dev: Web Vitals. Abgerufen am 08.10.2026. Laden, Reaktion und Layoutstabilität: Grenzwerte, 75. Perzentil und Grenzen eines Lighthouse-Ladetests.
- web.dev: Optimize Largest Contentful Paint. Abgerufen am 08.10.2026. Vier Zeitanteile des LCP; verspäteter Ladestart, Lazy Loading und Grenzen einer kleineren Bilddatei.
- web.dev: Optimize Interaction to Next Paint. Abgerufen am 08.10.2026. Langsame Bedienhandlungen erkennen und anhand konkreter Abläufe untersuchen.
Redaktion
Redaktion KanzleiPerformance · Aktualisiert am 08.10.2026
