Sechs von zehn Praxis-Websites in Heidelberg laden auf dem Handy zu langsam

49 von 81 Seiten sind zu langsam

Gemessen haben wir den Largest Contentful Paint (LCP), also den Moment, in dem der größte sichtbare Inhalt der Startseite fertig dargestellt ist. Meist ist das ein Titelbild oder die erste große Überschrift. Google bewertet diesen Wert bis 2,5 Sekunden als gut und über 4 Sekunden als schlecht.

Im Median brauchen die Heidelberger Praxis-Websites 5,1 Sekunden, im Mittel sogar 7,9 Sekunden, weil einige Ausreißer den Schnitt nach oben ziehen. 18 Seiten liegen über zehn Sekunden, die langsamste bei 50 Sekunden.

Ein Viertel der Seiten ist schnell, ein weiteres Viertel braucht mehr als neun Sekunden. Wer eine dieser Seiten auf dem Handy öffnet, sieht so lange eine leere oder halb aufgebaute Seite.

Warum Sekunden für eine Praxis zählen

Viele Patientinnen und Patienten suchen ihre Praxis auf dem Handy, oft unterwegs und mit wechselndem Netz. Gesucht werden Sprechzeiten, Telefonnummer oder der Weg zur Praxis. Steht nach vier Sekunden noch nichts Brauchbares auf dem Bildschirm, liegt der Wechsel zur nächsten Praxis in den Suchergebnissen nahe.

Für Google ist die Ladezeit Teil der Core Web Vitals, die in die Bewertung von Seiten einfließen. Sie entscheidet selten allein über ein Ranking, gute Inhalte zählen mehr. Bei ähnlich guten Seiten kann sie aber den Ausschlag geben, und für die Besucher zählt sie immer. Welche Werte Google genau erfasst, erklären wir im Beitrag zur technischen SEO.

Vor allem das Gewicht bremst die Seiten

Für eine langsame Seite gibt es zwei typische Ursachen. Entweder braucht der Server lange für die erste Antwort, oder die Seite lädt danach zu viel nach: große Bilder, Schriften, Skripte und den Code von Erweiterungen. Wir haben beides getrennt betrachtet und die 81 Seiten jeweils in drei gleich große Gruppen geteilt.

Das Gewicht wirkt über die ganze Breite. Von Gruppe zu Gruppe verdoppelt sich die Ladezeit ungefähr, von 3,0 über 5,8 auf 11,6 Sekunden. Im Median überträgt eine Startseite 1,33 MB, die schwerste 14,6 MB.

Beim Server ist das Bild gemischter. Die Hälfte der Server antwortet in 0,32 Sekunden oder schneller, und trotzdem liegen von den Seiten mit einer Antwortzeit unter einer halben Sekunde 40 Prozent über vier Sekunden. Ein schneller Server allein macht also noch keine schnelle Seite. Im langsamsten Drittel ab 0,7 Sekunden Antwortzeit sind dagegen 93 Prozent der Seiten zu langsam.

Am deutlichsten wird es, wo beides zusammenkommt. Die 12 Seiten, die schwer sind und deren Server eine Sekunde oder länger braucht, liegen im Median bei 17,5 Sekunden, keine einzige unter vier. Leichte Seiten mit schnellem Server kommen im Median auf 2,7 Sekunden. Rechnerisch erklärt das Gewicht allein gut die Hälfte der Unterschiede, die Antwortzeit des Servers ein Viertel (Details in der Methodik).

Welche Systeme wie schnell laden

Hinter den 96 erreichbaren Websites stecken sehr unterschiedliche Systeme. 38 laufen auf WordPress, 25 davon mit einem Pagebuilder wie Divi, Elementor oder WPBakery. Dazu kommen TYPO3, Homepage-Baukästen von Wix, Jimdo, IONOS und STRATO sowie eine Reihe kleinerer Systeme.

Der fairste Vergleich ist der innerhalb von WordPress, weil das System darunter dasselbe ist. Mit Pagebuilder liegen 20 von 23 gemessenen Seiten über vier Sekunden (87 Prozent), der Median bei 7,5 Sekunden. Ohne Pagebuilder sind es 5 von 11 (45 Prozent) bei einem Median von 3,9 Sekunden. Die Builder-Seiten sind im Median gut dreimal so schwer (2,3 statt 0,7 MB), und ihr Server braucht fast doppelt so lange für die erste Antwort (1,16 statt 0,60 Sekunden).

Die Gruppen sind klein, zwischen 9 und 28 Seiten. Die Unterschiede sind deshalb ein deutlicher Hinweis, aber kein Beweis, dass das System allein die Ursache ist. Pagebuilder-Seiten tragen oft auch mehr große Bilder und Animationen, die der Builder bequem möglich macht.

Die Homepage-Baukästen schneiden im Median am besten ab (2,9 Sekunden). Das passt zu den Felddaten des Core Web Vitals Technology Report von HTTP Archive, in dem etwa Wix mobil deutlich häufiger besteht als WordPress. Ausreißer gibt es aber auch hier: Drei der zwölf Baukasten-Seiten brauchen mehr als elf Sekunden.

Der Gegentest: 15 Startseiten schlank nachgebaut

Zahlen über fremde Websites sind das eine. Wir wollten wissen, wie viel sich bei denselben Inhalten tatsächlich ändern lässt. Für 15 der gemessenen Praxen haben wir deshalb die Startseite als nicht öffentliche Vorschau neu aufgebaut: dieselben Texte und Bilder, aber schlanke Technik. Die Vorschauen sind statische Seiten mit Astro, ausgeliefert über das Netz von Cloudflare, mit Bildern in passender Größe und in modernen Formaten, ohne Pagebuilder-Code.

Alte und neue Fassung haben wir jeweils am selben Tag unter denselben Bedingungen gemessen. 13 der 15 alten Seiten liefen auf WordPress, davon sechs mit Divi und fünf mit Elementor.

Alle 15 Vorschauen liegen unter Googles Grenze von 2,5 Sekunden, 7 sogar unter einer Sekunde. Vorher lagen 14 der 15 Seiten über vier Sekunden. Im Median lädt die neue Fassung 12-mal so schnell, im Einzelfall zwischen 6-mal und 45-mal.

Auch das Springen des Layouts verschwindet. Bei 5 alten Seiten verschob sich der Inhalt beim Laden deutlich (Cumulative Layout Shift über 0,1). In drei der Fälle, deren Ursache wir erfasst haben, rutschten Abschnitte des Pagebuilders nach, in einem schob sich eine Cookie-Abfrage ins Bild. In den Vorschauen blieb der Wert bei allen 15 unter dieser Grenze.

Die Grundlagen stimmen fast überall

Bei den technischen Grundlagen sieht es besser aus, als die Ladezeiten vermuten lassen. 91 der 96 erreichbaren Seiten laufen verschlüsselt über HTTPS, 94 sind für Mobilgeräte eingerichtet.

Eine große Lücke gibt es bei den strukturierten Daten: 77 Seiten (80 Prozent) haben kein Schema.org-Markup. Damit fehlen Suchmaschinen und KI-Assistenten maschinenlesbare Angaben zu Praxis, Adresse, Telefonnummer und Sprechzeiten. Ein Ranking-Garant ist das nicht, es hilft aber, die Praxis richtig zuzuordnen. Wie das mit der Suche vor Ort zusammenhängt, erklärt unser Beitrag zur lokalen SEO.

Was Praxen jetzt tun können

1. Selbst messen. Geben Sie Ihre Adresse bei PageSpeed Insights ein, wählen Sie den Reiter für Mobilgeräte und achten Sie auf den Largest Contentful Paint. Unter 2,5 Sekunden ist gut, über 4 Sekunden schlecht.
2. Den ersten Bildschirm prüfen. Große Titelbilder, Slider und Videos ganz oben sind häufige Bremsen. Ein gut komprimiertes Bild in passender Größe reicht meist.
3. Das Gewicht senken. Bilder als WebP oder AVIF, nur die Schriftschnitte, die wirklich genutzt werden, und keine Erweiterungen, die niemand mehr braucht.
4. Die Server-Antwort prüfen. Braucht die erste Antwort eine Sekunde oder länger, fehlt oft ein Seiten-Cache, oder der Hosting-Tarif ist zu knapp bemessen.
5. Bei Pagebuilder-Seiten ehrlich rechnen. Wenn der Builder selbst den Großteil des Codes erzeugt, bringt Feintuning wenig. Dann lohnt sich eher ein Update auf eine schlankere Version oder ein Neubau.
6. Strukturierte Daten ergänzen. Ein sauberes Markup für Praxis, Adresse und Sprechzeiten ist schnell eingebaut.

Nicht jede langsame Seite braucht einen Neubau, oft bringen schon die ersten Schritte viel. Wie wir Praxis-Websites aufbauen, zeigt unsere Seite Webdesign für Ärzte und Arztpraxen.

Methodik

Datengrundlage

Ausgangspunkt sind alle Einträge für Arztpraxen in OpenStreetMap innerhalb der Stadtgrenze Heidelbergs (Kategorien amenity=doctors und healthcare=doctor), Stand 22. September 2026. Von 204 Einträgen hatten 103 eine Website hinterlegt, 96 davon waren erreichbar. 81 Startseiten ließen sich vollständig messen. Bei den übrigen 15 brach die Messung mit Zeitüberschreitungen ab, vermutlich weil ein gemeinsamer Hoster die dichten Abrufe gedrosselt hat. Sie fehlen in den Ladezeiten, sind bei Server-Antwortzeit und Grundlagen aber enthalten. Praxisliste: © OpenStreetMap-Mitwirkende, ODbL.

Messung

Jede Startseite wurde in Chromium (über Playwright) geladen, eingestellt wie ein iPhone 13 in einem gedrosselten Mobilnetz: 1,6 Mbit/s, 150 Millisekunden Latenz, Prozessor vierfach verlangsamt. Das entspricht dem Mobilprofil, mit dem auch Googles Lighthouse misst. Erfasst wurden der Largest Contentful Paint, die übertragene Datenmenge und die Zahl der Anfragen, je Seite in einem Durchgang. Zwei Seiten haben wir zur Kontrolle erneut gemessen, die Abweichung lag unter drei Prozent.

Die Server-Antwortzeit (Time to First Byte) stammt aus einem einfachen Abruf der Startseite ohne Drosselung. Sie wurde getrennt gemessen und lässt sich deshalb nicht einfach von der Ladezeit im Mobilprofil abziehen.

Systeme

Das System jeder Seite haben wir aus Merkmalen im Quelltext und dem Generator-Tag bestimmt. Widersprach das Generator-Tag den Merkmalen, galt das Generator-Tag, das betraf zwei Seiten. Die Divi-Version stammt aus den Adressen der Theme-Dateien. Gruppen mit weniger als neun gemessenen Seiten sind in Abb. 3 unter „Übrige oder nicht erkannt“ zusammengefasst.

Auswertung

Für Abb. 2 haben wir die 81 Seiten einmal nach Gewicht und einmal nach Server-Antwortzeit in Drittel zu je 27 Seiten geteilt. Eine lineare Regression auf die logarithmierten Werte erklärt mit dem Gewicht allein 53 Prozent der Streuung der Ladezeit, mit der Server-Antwortzeit allein 26 Prozent und mit beiden zusammen 62 Prozent. Das beschreibt einen Zusammenhang, keine nachgewiesene Ursache.

Grenzen

• Es sind Labordaten, keine Felddaten echter Besucher. Auf einem neuen Handy im WLAN laden dieselben Seiten schneller.
• Jede Seite der Liste wurde einmal gemessen. Auslastung des Hosters und Tageszeit können einzelne Werte verschieben.
• OpenStreetMap ist nicht vollständig. Praxen ohne Eintrag oder ohne hinterlegte Website fehlen.
• Gemessen wurde nur die Startseite, Unterseiten können schneller oder langsamer sein.
• Die Vorschauen im Gegentest enthalten keine Cookie-Abfrage, keine Terminbuchung und keine Karte.

Die Auswertung ist anonym. Wir nennen keine Praxen und zeigen keine Einzelwerte, die sich einer Praxis zuordnen lassen.

Häufige Fragen zur Ladezeit von Praxis-Websites

Daan Bachmann

WordPress & Design Lead

Daan verantwortet bei STARK alle WordPress- und Design-Themen. Er hat die Messung aufgesetzt und ausgewertet.

Verwandte Artikel