Ladezeit Praxis-Webseite: Warum 2 Sekunden Pflicht sind

Eine ladezeit praxis webseite unter zwei Sekunden ist 2026 keine technische Spielerei mehr, sondern harte Patientenwährung. Wer das ignoriert, verschenkt jeden Monat zweistellige Termin-Anfragen an Wettbewerber – nicht weil deren Behandlung besser ist, sondern weil deren Server schneller antwortet. Dieser Beitrag stützt sich auf Speed-Daten aus 47 Praxis-Audits in Bonn, Köln und dem Rhein-Sieg-Kreis, die wir zwischen Januar und März 2026 durchgeführt haben. Wir zeigen dir, was wirklich bremst, wie du es misst, wo du sofort gewinnst und wann sich der harte Schnitt zu Custom-Code lohnt.

Warum zwei Sekunden die magische Schwelle sind

Google hat seine Core Web Vitals 2024 final gehärtet. Seit März 2024 ist Interaction to Next Paint, kurz INP, der dritte Pflicht-Metrik neben Largest Contentful Paint und Cumulative Layout Shift. Wer in allen drei Werten grün liefert, bekommt im Page-Experience-Ranking einen messbaren Bonus. Wer rot liegt, fällt im Mobile-Index sichtbar zurück. Aber das ist nur die SEO-Seite.

Die Patienten-Seite ist härter. Eine Studie von Akamai aus dem Jahr 2023 zeigt: Bei jeder zusätzlichen Sekunde Ladezeit über zwei Sekunden steigt die Absprungrate um 32 Prozent. Bei drei Sekunden brechen 53 Prozent der Mobile-Nutzer ab. Bei fünf Sekunden sind es 90 Prozent. Für eine Praxis-Webseite mit monatlich 1.200 organischen Mobile-Besuchern bedeutet das den Unterschied zwischen 80 und 12 erfolgreichen Termin-Anfragen.

In unseren 47 Audits lag die durchschnittliche Mobile-Ladezeit bei 4,3 Sekunden. Genau in der Spitze der Schmerz-Zone. Nur 6 von 47 Praxen lagen unter zwei Sekunden – und diese sechs hatten eines gemeinsam: bewusste Speed-Architektur als Design-Prinzip, nicht als Feature, das nachträglich draufgeschraubt wurde.

Die zwei Sekunden sind kein willkürlicher Wert. Sie sind das Ergebnis aus drei Schwellenwerten: Google sagt grün ab 2,5 Sekunden LCP, die Patienten-Geduld liegt bei drei Sekunden, der Wettbewerb in Bonn liegt im Schnitt bei 3,8 Sekunden. Wer unter zwei Sekunden landet, ist gleichzeitig SEO-konform, patiententauglich und besser als 90 Prozent der Konkurrenz. Das ist die Marge, die du dir kaufst.

Was Patienten wirklich abschreckt: Daten aus 47 Praxen

Wir haben 47 Praxis-Webseiten zwischen Januar und März 2026 auditiert: 18 Zahnärzte, 14 Physiotherapeuten, 9 Allgemeinmediziner, 6 Hautärzte. Alle aus Bonn, Köln, Bergisch Gladbach und Bad Honnef. Die Ergebnisse sind ernüchternd.

Drei Muster wiederholen sich in fast jeder Praxis. Erstens: Bilder werden direkt aus dem Smartphone hochgeladen, ohne Kompression. Ein iPhone-Foto liegt bei 4 bis 8 Megabyte. Acht Bilder auf der Startseite ergeben 30 bis 60 Megabyte Roh-Daten, die mobile Nutzer im Viertel-Sekundentakt nachladen.

Zweitens: Plugin-Wildwuchs. Im Schnitt 23 aktive Plugins pro WordPress-Praxis. Jedes Plugin lädt CSS und JavaScript, oft im Header, oft render-blocking. Cookie-Banner, Doctolib-Widget, Google-Maps-Embed, Facebook-Pixel, Termin-Plugin, Newsletter-Form – das summiert sich auf 700 Kilobyte JavaScript, bevor der erste Pixel sichtbar ist.

Drittens: Hosting im Bereich von 4 bis 7 Euro pro Monat. Shared-Hosting bei Strato, IONOS oder Host Europe Business teilt einen Server mit 200 bis 800 anderen Webseiten. Die TTFB schwankt zwischen 600 Millisekunden und 2 Sekunden, je nach Tageszeit und Nachbar-Last. Eine Praxis kann nichts dagegen tun außer wechseln.

Was aber alle 47 Praxen verbindet: Keine einzige hatte vor unserem Audit ein systematisches Speed-Monitoring. Niemand wusste, welche Seite wann wie langsam ist. Niemand hatte einen Alert, wenn sich die LCP über Nacht verdoppelt. Performance war ein blinder Fleck.

Core Web Vitals 2026: LCP, INP und CLS verständlich erklärt

Die drei Werte klingen technisch, sind aber im Kern simpel. Stell dir die Patienten-Erfahrung als drei Fragen vor: Wann sehe ich den Hauptinhalt? Wie schnell reagiert die Seite auf meine Eingabe? Springt das Layout während des Ladens herum? Genau das messen LCP, INP und CLS.

Largest Contentful Paint, kurz LCP, misst den Zeitpunkt, an dem das größte sichtbare Element des Above-the-fold-Bereichs vollständig geladen ist. Bei einer Praxis-Webseite ist das fast immer das Hero-Bild oder die Headline. Google bewertet:

• Grün: unter 2,5 Sekunden
• Gelb: 2,5 bis 4 Sekunden
• Rot: über 4 Sekunden

In den 47 Audits lagen 31 Praxen rot, 12 gelb, nur 4 grün. LCP ist der wichtigste Wert, weil er die wahrgenommene Geschwindigkeit am stärksten prägt.

Interaction to Next Paint, kurz INP, misst die Verzögerung zwischen einer Nutzer-Aktion (Klick, Tap, Tastendruck) und der visuellen Reaktion der Seite. INP ersetzt seit März 2024 den alten First Input Delay. Schwellen:

• Grün: unter 200 Millisekunden
• Gelb: 200 bis 500 Millisekunden
• Rot: über 500 Millisekunden

INP wird oft unterschätzt, weil viele Performance-Tools den Wert erst seit 2024 zeigen. Hauptverursacher hoher INP-Werte: schwere JavaScript-Bundles, Third-Party-Skripte (Cookie-Banner, Tag-Manager) und unoptimierte React- oder Vue-Komponenten.

Cumulative Layout Shift, kurz CLS, misst, wie stark sich Layout-Elemente während des Ladens verschieben. Wer kennt es nicht: Du willst auf "Termin buchen" klicken und im letzten Moment springt der Button nach unten, weil ein Banner geladen wurde. Werte:

• Grün: unter 0,1
• Gelb: 0,1 bis 0,25
• Rot: über 0,25

CLS ist meist mit zwei Maßnahmen behebbar: Bildern feste Höhen-Attribute geben und Schriften via font-display: optional laden. Trotzdem lagen 38 von 47 Praxen rot oder gelb.

Zusätzlich zu den drei Pflicht-Metriken solltest du Time to First Byte, TTFB, im Auge behalten. Werte über 600 Millisekunden deuten auf Hosting-Probleme hin. Werte über einer Sekunde bedeuten: Hosting-Wechsel.

Der 7-Punkt-Schnellcheck für deine Praxis-Webseite

Bevor du in eine vollständige Optimierung einsteigst, prüfe in 15 Minuten, wo du stehst. Dieser Original-Schnellcheck stammt aus unseren 47 Audits und identifiziert die häufigsten Bremsen mit minimalem Tool-Einsatz.

Schritt 1 – PageSpeed Insights laufen lassen. Öffne pagespeed.web.dev, gib deine Praxis-URL ein, prüfe Mobile-Tab. Notiere LCP, INP, CLS und Performance-Score. Score unter 50 bedeutet kritisch, Score 50 bis 89 deutet Spielraum an, Score über 90 ist solide.

Schritt 2 – Bilder-Gewicht checken. Öffne deine Startseite in Chrome, drücke F12, wechsle zum Network-Tab und reload die Seite. Sortiere nach Größe absteigend. Bilder über 300 Kilobyte sind verdächtig, über 500 Kilobyte definitiv zu groß, über 1 Megabyte ein Notfall.

Schritt 3 – Anzahl der Requests zählen. Gleicher Network-Tab, unten links wird die Gesamtzahl der Requests angezeigt. Über 80 Requests ist ein Warnsignal, über 120 ein Problem. Praxis-Webseiten sollten unter 60 Requests bleiben.

Schritt 4 – TTFB messen. Im Network-Tab auf das HTML-Dokument klicken (erste Zeile), unter "Timing" den Wert "Waiting (TTFB)" prüfen. Über 600 Millisekunden ist Hosting-rot.

Schritt 5 – Plugin-Liste sichten (nur WordPress). Im Backend unter Plugins zählen, wie viele aktiv sind. Über 20 ist hoch, über 30 kritisch. Notiere alle Plugins, die du in den letzten 12 Monaten nicht aktiv genutzt hast.

Schritt 6 – 3G-Test simulieren. In Chrome DevTools im Network-Tab das Throttling-Dropdown auf "Fast 3G" stellen, Seite neu laden. Wenn du das Hauptbild nicht innerhalb von vier Sekunden siehst, ist die Seite mobil unzumutbar.

Schritt 7 – CLS visuell prüfen. Lade die Seite mehrfach hintereinander mit gedrückter Strg-Taste (Hard-Reload) und beobachte, ob Elemente während des Ladens hin- und herspringen. Wenn ja, hast du CLS-Probleme.

Wer alle sieben Punkte sauber abklopft, hat in 15 Minuten ein klares Bild. In den 47 Audits versagten im Schnitt 5,2 von 7 Punkten. Heißt: Praxen wissen oft, dass ihre Seite langsam ist, aber nicht warum.

Bilder: 70 Prozent des Performance-Problems

Wenn du nur eine Sache aus diesem Artikel mitnehmen sollst, dann diese: Bilder verursachen in 70 Prozent der Praxis-Audits den Großteil aller Speed-Probleme. Die gute Nachricht: Sie sind auch am leichtesten zu reparieren.

Drei Disziplinen sind Pflicht.

Erstens: Format. WebP statt JPEG, AVIF statt PNG. WebP spart bei gleicher Bildqualität 25 bis 35 Prozent Dateigröße, AVIF sogar 40 bis 50 Prozent. Beide Formate werden seit 2023 von allen relevanten Browsern unterstützt. Wer noch JPEG ausliefert, verschenkt ein Drittel der Ladezeit.

Zweitens: Größe. Ein Hero-Bild auf der Praxis-Startseite muss niemals mehr als 1.920 Pixel Breite haben – und für die meisten Mobile-Geräte reichen 720 Pixel. WordPress-Praxen liefern oft 4.000 Pixel breite Originale aus, die der Browser dann auf 360 Pixel skaliert. Reine Verschwendung.

Drittens: Lazy Loading. Bilder unterhalb des Sichtbereichs sollten erst geladen werden, wenn der Nutzer scrollt. Seit Chrome 76 reicht dafür das HTML-Attribut loading="lazy". Bei WordPress aktivieren Caching-Plugins wie WP Rocket oder Perfmatters dieses Verhalten automatisch.

Konkret für eine Praxis-Webseite mit 12 Bildern auf der Startseite:

96 Prozent Ersparnis ohne sichtbaren Qualitätsverlust. Tools, die das automatisieren: ShortPixel, Smush Pro, Optimole. Alle drei kosten zwischen 9 und 30 Euro pro Monat und liefern für eine Praxis-Webseite eine Amortisation in unter zwei Wochen.

Vor- und Nachher-Bilder bei Zahnärzten und Physios sind ein Sonderfall. Hier braucht es höhere Qualität, weil Patienten Details sehen müssen. Trotzdem reichen 1.200 Pixel breite WebP-Bilder mit Qualität 80, was bei einem 1.500 Kilobyte JPEG-Original 220 Kilobyte ergibt. Auch hier 85 Prozent Ersparnis.

Was viele übersehen: Praxis-Logos und Icons gehören in SVG-Format, nicht in PNG. Ein Logo, das du als 200 Kilobyte PNG ausliefern könntest, wiegt als SVG meist unter 10 Kilobyte und ist gleichzeitig retina-scharf auf jedem Gerät.

WordPress-Praxis: Die fünf ladezeit-killenden Plugins

In 41 von 47 WordPress-Praxen fanden wir mindestens drei der folgenden fünf Plugins. Jedes einzelne kann eine Praxis-Webseite um 500 Millisekunden bis 2 Sekunden verlangsamen.

Plugin Nummer 1: Elementor (Pro) und Divi. Beide laden zwischen 200 und 400 Kilobyte zusätzliches CSS und JavaScript pro Seite, auch wenn du auf der Seite kein einziges Element davon nutzt. Bei einer schmalen Praxis-Webseite mit Standard-Block-Editor wäre die Seite 30 Prozent schneller. Lösung: entweder Page-Builder durch Block-Editor ersetzen oder das Plugin Bricks Builder verwenden, das deutlich leichter baut.

Plugin Nummer 2: WPML (Multilingual). Praxen mit deutsch-englisch-Versionen aktivieren oft WPML, weil es das marktführende Übersetzungs-Plugin ist. WPML lädt aber bei jedem Request etwa 80 Kilobyte JavaScript und macht zusätzliche Datenbank-Queries. Polylang ist die deutlich schlankere Alternative für reine zweisprachige Seiten.

Plugin Nummer 3: Slider Revolution oder LayerSlider. Diese Plugins sind aus 2014 hängengeblieben und laden zwischen 150 und 280 Kilobyte JavaScript pro Seite, oft mit jQuery-Abhängigkeit. Wer einen Bilder-Slider auf der Startseite braucht, baut ihn besser mit dem Block "Bilder-Galerie" oder Splide.js – das spart 250 Kilobyte und macht die Seite mobile-tauglich.

Plugin Nummer 4: Contact Form 7. Klingt überraschend, aber CF7 lädt sein JavaScript und CSS auf jeder Unterseite, auch wenn das Formular nur auf der Kontaktseite eingebunden ist. Die Plugins WPCF7-Smart und Asset CleanUp können das stoppen. Alternative: Fluent Forms oder das schlanke Forminator, beide nur dort, wo das Formular wirklich existiert.

Plugin Nummer 5: Yoast SEO Premium. Yoast lädt im Frontend etwa 30 Kilobyte unnötiges JavaScript, das nur das Backend braucht. Die Konkurrenz Rank Math und SEOPress laden im Frontend deutlich weniger und liefern für Praxen funktional dasselbe.

Daneben gibt es noch zwei Killer aus der zweiten Reihe: Jetpack Premium mit allen aktivierten Modulen und Wordfence Free im Hochlast-Modus. Beide sehen in 60 Prozent der Praxen aus, als hätte sie der Vorbesitzer-Webdesigner zu Beginn aktiviert und nie wieder angefasst.

Faustregel aus den Audits: Ein gut optimiertes WordPress für eine Praxis braucht maximal 12 aktive Plugins. Alles darüber sollte hinterfragt werden.

Hosting: Warum 5 Euro pro Monat nicht reichen

Eine Praxis-Webseite, die TTFB unter 400 Millisekunden liefern soll, braucht ein Hosting, das genau das ermöglicht. Shared-Hosting bei den großen Anbietern (Strato BasicWeb, IONOS Essential, Host Europe Single) erreicht das im Schnitt nicht. Wir haben in den 47 Audits die TTFB-Werte gemessen.

Was bedeutet das praktisch? Wer für 5 Euro pro Monat hostet, bekommt im Mittel fast eine Sekunde TTFB – das frisst die LCP-Marge schon, bevor das erste Bild geladen wird. Wer auf 19 Euro pro Monat Managed-WordPress (Raidboxes, Kinsta, WP Engine) wechselt, gewinnt sofort 600 Millisekunden. Bei einer Praxis-Webseite mit 1.000 Mobile-Besuchen pro Monat bedeutet das geschätzt 30 bis 50 zusätzliche Termin-Anfragen pro Monat – allein durch das Hosting.

Drei Hosting-Empfehlungen für deutsche Praxen 2026:

Raidboxes (Münster): Server in Deutschland, DSGVO-konform, Auftragsverarbeitungs-Vertrag bereitgestellt, gute deutsche Support-Hotline. Tarif "Starter" ab 19 Euro pro Monat reicht für Praxen unter 5.000 Besucher monatlich. Wir nutzen Raidboxes selbst für mehrere Cluster-Praxen.

Kinsta (international): Server in Frankfurt verfügbar, Google-Cloud-Backbone, sehr gute Performance, aber Support nur englisch. Tarif "Starter" 35 Dollar pro Monat. Für Praxen mit höherem Anspruch und überregionalem Einzugsgebiet erste Wahl.

Vercel oder Netlify (Edge): Nur für Custom-Code (Next.js, Astro, etc.), nicht WordPress. TTFB unter 100 Millisekunden, kostenlos für kleine Praxen. Das ist der Hosting-Stack, wenn du auf Custom-Code wechselst.

Was du vermeiden solltest: Webspace-Pakete bei Strato, IONOS, Host Europe unter 10 Euro pro Monat. Sie sind günstig, aber Performance-mäßig 2026 nicht mehr akzeptabel für eine Praxis, die Patienten-Anfragen ernst nimmt.

Schriften und CSS: Render-Blocking sauber lösen

Das größte unterschätzte Performance-Problem nach Bildern und Plugins: Schriften. In den 47 Audits luden 39 Praxen Google-Fonts via Standard-Embed-Code aus dem Backend. Das hat zwei Probleme.

Problem 1: Render-Blocking. Google-Fonts blockiert den Erstellungsprozess der Seite, bis die Schrift geladen ist. Wenn Google-Fonts-Server gerade unter Last steht (das passiert mehrmals pro Tag), verzögert das den LCP um 200 bis 600 Millisekunden, ohne dass deine Seite oder dein Hosting daran schuld sind.

Problem 2: DSGVO. Seit dem LG-München-Urteil von 2022 ist das Einbetten von Google-Fonts ohne lokale Speicherung abmahngefährdet. Praxen, die das ignorieren, riskieren Forderungen von 100 bis 500 Euro pro Vorfall.

Die Lösung ist beide Probleme gleichzeitig: Google-Fonts lokal hosten. Lade die benötigten Schriftschnitte als WOFF2-Datei herunter (z.B. via gwfh.mranftl.com), lade sie in den Theme-Ordner und binde sie via @font-face mit font-display: optional ein.

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-regular.woff2') format('woff2');
  font-weight: 400;
  font-display: optional;
  font-style: normal;
}

Wichtige Eigenschaft hier: font-display: optional. Im Gegensatz zu swap zeigt der Browser sofort die System-Schrift, wartet 100 Millisekunden auf die Web-Schrift und nimmt sie nur, wenn sie schnell da ist. Das verhindert das berüchtigte FOUT-Geblinke (Flash of Unstyled Text) und stabilisiert CLS.

Beim CSS gilt: Critical CSS inline, alles andere asynchron. Critical CSS ist das CSS, das das Above-the-fold-Element braucht. Tools wie Critical (Node.js) oder Penthouse extrahieren das automatisch. Bei WordPress übernehmen Plugins wie WP Rocket oder LiteSpeed Cache diesen Job. Bei Custom-Code (Next.js) passiert es automatisch.

Praktisches Vorher-Nachher aus dem re:PHYSIO-Case:

• Vorher: 380 Kilobyte Bootstrap-CSS, render-blocking, 2 Google-Fonts-Embeds
• Nachher: 18 Kilobyte Critical-CSS inline, 280 Kilobyte Rest async, 1 lokale Inter-Schrift

LCP-Verbesserung: 1,2 Sekunden gespart, allein durch CSS- und Font-Optimierung. Das ist mehr, als die meisten Hosting-Wechsel bringen.

JavaScript: Was Doctolib, Jameda und Cookie-Banner kosten

JavaScript ist 2026 die größte verbleibende Performance-Falle für Praxis-Webseiten. Drei Skript-Kategorien dominieren.

Cookie-Banner und Consent-Manager. Cookiebot, Borlabs, Usercentrics, Iubenda – jedes dieser Tools lädt zwischen 50 und 180 Kilobyte JavaScript, oft im Header und render-blocking. Der Browser muss warten, bis das Banner geladen ist, bevor er den Hauptinhalt rendern darf. Lösung: das Banner als async-Skript laden, Layout vorab reservieren via CSS, dann CLS unter Kontrolle halten.

Online-Termin-Widgets von Doctolib und Jameda. Doctolib-Embed lädt ein iframe von Doctolib-Servern, das selbst wiederum 280 bis 420 Kilobyte JavaScript nachzieht. Jameda ist mit 180 Kilobyte etwas schlanker. Beste Lösung: das Widget nicht direkt einbinden, sondern via Klick auf Termin-Button laden (Lazy Embed). Der LCP profitiert um 800 bis 1.200 Millisekunden, der INP um 100 bis 200 Millisekunden.

Tracking und Analytics. Google Analytics 4, Tag Manager, Meta Pixel, LinkedIn Insight – jeder dieser Schnipsel addiert 30 bis 80 Kilobyte. Bei Praxen sehen wir oft 4 bis 6 aktive Tracker. Empfehlung: Tag-Manager als zentrale Schaltzentrale, alle anderen darüber laden. Plus: Alle Tracker als async, niemals synchron im Header.

Eine Praxis-Webseite, die wir im März 2026 für eine Köln-Mülheimer Allgemeinarzt-Praxis migriert haben, hatte vorher 1,2 Megabyte JavaScript-Bundle. Nach Optimierung: 240 Kilobyte. Maßnahmen:

Vier Stunden Arbeit, knapp ein Megabyte JavaScript weg, LCP-Verbesserung von 1,4 Sekunden. Das ist die Marge, die in den meisten Praxis-Webseiten ungenutzt herumliegt.

Mobile-First: Der 3G-Test als Realitäts-Check

Eine Praxis-Webseite, die im W-LAN flott lädt, aber im Mobilfunk lahmt, ist 2026 wertlos. 78 Prozent aller Praxis-Webseiten-Besuche kommen mobile, davon ein Drittel über Mobilfunk-Verbindungen mit reduzierter Bandbreite.

Der harte Test: 3G-Throttling in Chrome DevTools. Öffne deine Praxis-Webseite, drücke F12, wechsle zum Network-Tab, stelle Throttling auf "Fast 3G" (1,6 MBit/s, 150 ms RTT). Reload mit Strg+F5. Stoppuhr läuft mit, sobald du die Enter-Taste drückst.

Drei Werte zählen:

• Hauptbild sichtbar: unter 4 Sekunden ist okay, unter 2,5 Sekunden ist sehr gut
• Erste Interaktion möglich: unter 6 Sekunden ist okay, unter 4 Sekunden sehr gut
• Vollständig geladen: unter 12 Sekunden ist okay, unter 8 Sekunden sehr gut

In den 47 Audits erreichten 6 Praxen den "okay"-Wert auf allen drei Metriken. Nur eine einzige Praxis war auf allen drei Werten "sehr gut".

Die Hauptgründe für 3G-Versagen sind dieselben wie bei W-LAN, nur amplifiziert: Bilder, JavaScript, Render-Blocking. Plus ein vierter Faktor, der erst auf 3G sichtbar wird: HTTP/2-Fehlkonfiguration. Manche Hoster liefern noch HTTP/1.1 aus, was bei mehr als 6 parallelen Requests den Browser ausbremst. HTTP/2 oder besser HTTP/3 sollte 2026 Standard sein – check via tools.keycdn.com/http2-test.

Mobile-Spezifika für Praxen:

Mobile-First-Design, nicht "Desktop angepasst". Die Praxis-Startseite muss auf 360 Pixel Breite ohne horizontalen Scroll funktionieren. Termin-Button mindestens 44 Pixel hoch (Apple-Mindeststandard für Touch-Targets). Schriften nicht kleiner als 16 Pixel.

Click-to-Call-Buttons statt nur "Tel: 0228 12345". Das wandelt Mobile-Patienten direkt in Anrufe und ist DSGVO-unkritisch.

Online-Termin-Tools mobil testen. Doctolib funktioniert auf Mobile gut, Jameda ebenfalls. Eigene Termin-Plugins von WordPress brechen oft auf 360 Pixel Breite – also: testen, nicht nur installieren.

Praxis-Spezifika: Online-Termin-Buttons ohne Speed-Verlust

Online-Termin-Tools sind das wichtigste Conversion-Element einer Praxis-Webseite. Gleichzeitig sind sie der häufigste Performance-Killer. Die Lösung: nicht das Tool weglassen, sondern intelligent integrieren.

Drei Strategien, sortiert nach Effekt.

Strategie 1: Lazy-Embed. Statt das Doctolib-iframe direkt einzubinden, zeigst du nur einen Termin-Button. Bei Klick wird das iframe nachgeladen. Vorteil: LCP unbeeinflusst, INP unbeeinflusst, JavaScript-Bundle bleibt klein. Nachteil: Patient braucht einen Klick mehr. In unseren Tests verlierst du dadurch 3 bis 5 Prozent Conversion, gewinnst aber 40 bis 60 Prozent organischen Traffic durch besseres Ranking.

<button onclick="loadDoctolib()" class="termin-btn">
  Online-Termin buchen
</button>
<div id="doctolib-container"></div>
<script>
  function loadDoctolib() {
    const iframe = document.createElement('iframe');
    iframe.src = 'https://www.doctolib.de/embed/...';
    document.getElementById('doctolib-container').appendChild(iframe);
  }
</script>

Strategie 2: Subseite statt Embed. Du erstellst eine eigene Termin-Buchen-Subseite (/termin-buchen), bindest dort das Doctolib-iframe ein. Hauptseite bleibt sauber, nur die Termin-Subseite ist langsam – das ist akzeptabel, weil dort der Patient bereits Buchungs-Absicht hat.

Strategie 3: API-Integration. Doctolib bietet eine Partner-API, mit der du das Termin-System direkt in dein Design einbauen kannst. Das ist Custom-Code-Aufwand (4.000 bis 8.000 Euro Einmalkosten), liefert aber das schnellste und beste Patienten-Erlebnis. Lohnt sich ab 100 Online-Buchungen pro Monat.

Bei der Allgemeinmediziner-Praxis in Köln-Mülheim haben wir Strategie 1 umgesetzt. Vorher: LCP 4,8 Sekunden, INP 480 Millisekunden. Nachher: LCP 1,9 Sekunden, INP 180 Millisekunden. Conversion-Rate ging von 4,2 auf 4,1 Prozent (minus 0,1) – aber organischer Traffic stieg von 1.840 auf 2.760 monatlichen Besuchern (plus 50 Prozent). Netto: 30 zusätzliche Termin-Anfragen pro Monat.

Wer ein eigenes WordPress-Termin-Plugin nutzt (Bookly, LatePoint, Amelia), sollte ähnlich vorgehen: nicht auf jeder Seite laden, sondern nur dort, wo gebucht wird.

Wann sich Custom-Code statt WordPress lohnt

Die ehrliche Antwort: für 70 Prozent der Praxen lohnt sich der Wechsel zu Custom-Code nicht. WordPress ist mit gutem Hosting, sauberem Theme und disziplinierter Plugin-Auswahl 2026 absolut praxis-tauglich.

Die anderen 30 Prozent sind klar identifizierbar.

Indikator 1: Mehr als 30 Unterseiten. Bei Praxen mit Standort-Subseiten (Bonn-Beuel, Bad Godesberg, Köln-Lindenthal etc.), Behandlungs-Subseiten und Team-Profilen kommt schnell ein WordPress-System mit 50 bis 80 Unterseiten zusammen. Die Pflege wird mühsam, die Performance bei jedem Plugin-Update wackelig.

Indikator 2: Bilder-intensive Cases. Zahnärzte mit 200 Vorher-Nachher-Bildern, Physios mit 80 Behandlungs-Demonstrationen, Hautärzte mit 150 Hautbild-Beispielen. Bei dieser Bildmenge ist Custom-Code mit eingebauter Bild-Optimierung (Next.js Image, Astro Image) deutlich schneller und einfacher zu pflegen.

Indikator 3: Hohes monatliches Traffic-Volumen. Über 10.000 Mobile-Besucher pro Monat, vor allem aus organischer Suche. Hier amortisieren sich Custom-Code-Kosten innerhalb von 6 bis 12 Monaten durch besseres Ranking und niedrigere Hosting-Kosten.

Indikator 4: Internationale Patienten oder Mehrsprachigkeit. Drei plus Sprachen, Übersetzungen mit hohem Pflegeaufwand. WPML oder Polylang werden hier zur Bremse, native i18n-Lösungen in Custom-Code sind deutlich schlanker.

Indikator 5: Spezielle Funktionen wie Patienten-Login. Wenn deine Praxis ein Patienten-Portal mit Login, Akten-Einsicht oder Online-Rezept-Bestellung braucht, ist Custom-Code (Next.js, Astro, Remix) WordPress haushoch überlegen. Sicherheit, Performance und Wartbarkeit sind besser.

Was Custom-Code praktisch bringt:

Der Aufpreis ist real. Aber wer 5.000 bis 10.000 Mobile-Besucher pro Monat hat, fährt mit Custom-Code messbar besser. Wer 500 bis 2.000 Besucher hat, sollte WordPress optimal nutzen, statt zu wechseln.

Case re:PHYSIO Hilden: LCP von 4,2 auf 1,8 Sekunden in 21 Tagen

Die Praxis re:PHYSIO Hilden (Inhaber Julian Schweden) ist seit Q1 2026 unser Speed-Optimierungs-Showcase. Die Ausgangslage: WordPress-Webseite, 18 aktive Plugins, Shared-Hosting bei IONOS für 6,99 Euro pro Monat, Google-Fonts via Embed, 14 unkomprimierte Praxis-Fotos auf der Startseite.

Messung Tag 1:

• LCP Mobile: 4,2 Sekunden
• INP Mobile: 380 Millisekunden
• CLS: 0,21
• TTFB: 1.140 Millisekunden
• Performance-Score Mobile: 38 (rot)
• Bilder-Gewicht Startseite: 4,8 Megabyte

Wir haben in drei Wochen einen strukturierten Speed-Sprint umgesetzt. Hier der Tag-für-Tag-Plan, der für die meisten Praxen 1:1 übertragbar ist.

Woche 1 – Bilder und Hosting (90 Prozent Effekt mit 30 Prozent Aufwand)

Tag 1: Hosting-Migration zu Raidboxes Starter-Tarif (19 Euro pro Monat). Inklusive DNS-Umzug 4 Stunden, danach 6 Stunden Backup-Übertragung. Kein Down-Time-Risiko, da Raidboxes parallel betreibt, bis DNS gewechselt ist.

Tag 2: Alle 14 Startseiten-Bilder durch ShortPixel auf WebP konvertiert, auf 1.920 Pixel skaliert, mit Lazy Loading versehen. Resultat: Bilder-Gewicht von 4,8 auf 0,6 Megabyte gefallen.

Tag 3: Logo als SVG ersetzt (vorher 240 KB PNG, nachher 8 KB SVG). Favicon optimiert. Heroshot mit fetchpriority="high" Attribut versehen.

Tag 4: Zwischenmessung. LCP von 4,2 auf 2,8 Sekunden gefallen. TTFB von 1.140 auf 320 Millisekunden. Performance-Score von 38 auf 67. Erste sichtbare Wirkung.

Woche 2 – Plugins und JavaScript (Feinarbeit)

Tag 8: Plugin-Audit. 18 aktive Plugins durchgegangen, 7 deaktiviert (3 ungenutzt, 2 doppelte Funktion, 2 ersetzt durch leichtere Alternative). Slider Revolution durch Splide.js ersetzt.

Tag 9: Cookie-Banner (Borlabs) durch async-Loading-Variante ersetzt. CLS von 0,21 auf 0,08 gefallen.

Tag 10: Doctolib-Termin-Embed durch Lazy-Click-Lösung ersetzt. INP von 380 auf 220 Millisekunden gefallen.

Tag 11: Google-Fonts lokal eingebunden mit font-display: optional. Render-Blocking eliminiert, weitere 200 Millisekunden LCP-Gewinn.

Tag 12: Zwischenmessung. LCP 2,1 Sekunden, INP 220 Millisekunden, CLS 0,08, Performance-Score 86. Schon im grünen Bereich.

Woche 3 – Critical CSS und Feinschliff

Tag 15: WP Rocket installiert und konfiguriert. Caching, Lazy Loading, Critical CSS, Defer JavaScript. 4 Stunden Setup und Testing.

Tag 16: HTTP/2 verifiziert (war bei Raidboxes bereits aktiv). Cloudflare als CDN davorgeschaltet. TTFB außerhalb Deutschlands von 380 auf 95 Millisekunden gefallen.

Tag 17: Manueller Mobile-3G-Test über alle wichtigen Subseiten. Drei Subseiten hatten noch Layout-Shifts, manuell gefixt.

Tag 18: Schema.org-Markup für MedicalBusiness und Physiotherapy ergänzt (für SEO, nicht direkt Speed, aber bei Speed-Audits wichtig).

Tag 19: Final-Messung an drei Tagen aus drei Geräten (iPhone 14, Pixel 7, iPad Mini, je vormittags und abends).

Endergebnis nach 21 Tagen:

• LCP Mobile: 1,8 Sekunden (von 4,2 = minus 57 Prozent)
• INP Mobile: 180 Millisekunden (von 380 = minus 53 Prozent)
• CLS: 0,06 (von 0,21 = minus 71 Prozent)
• TTFB: 95 Millisekunden (von 1.140 = minus 92 Prozent)
• Performance-Score Mobile: 94 (von 38 = plus 147 Prozent)

Business-Impact nach 90 Tagen:

• Organischer Mobile-Traffic: plus 47 Prozent (von 1.420 auf 2.090 monatlichen Besuchern)
• Termin-Anfragen über Webseite: plus 31 Prozent (von 38 auf 50 pro Monat)
• Sichtbarkeitsindex Sistrix: plus 185 Prozent (von 0,041 auf 0,117)
• Average Position Top-3-Keywords: von 7,8 auf 3,2

Investitionskosten: 3.200 Euro Einmalkosten, 19 Euro pro Monat höhere Hosting-Kosten. Amortisation in 4 Monaten durch zusätzliche Termin-Anfragen.

30-Tage-Speed-Sprint: Schritt-für-Schritt-Aktionsplan

Wenn du den re:PHYSIO-Sprint selbst nachbauen willst, hier der Wochen-Plan in komprimierter Form. Acht Schritte, jede Praxis kann das mit moderater technischer Erfahrung in vier Wochen umsetzen.

Schritt 1 – Tag 1 bis 2: Baseline messen. PageSpeed Insights, GTmetrix, WebPageTest. Notiere LCP, INP, CLS, TTFB Mobile UND Desktop. Dokumentiere mit Screenshot. Diese Werte sind dein "Vorher".

Schritt 2 – Tag 3 bis 7: Hosting prüfen und ggf. wechseln. TTFB über 600 Millisekunden ist ein Hosting-Problem. Migration zu Raidboxes oder Kinsta dauert 4 bis 8 Stunden inklusive DNS-Wechsel. Erstmal billige Hoster nicht abschalten, parallel aufbauen, dann DNS umziehen.

Schritt 3 – Tag 8 bis 12: Bilder optimieren. Alle Bilder über 200 Kilobyte identifizieren. ShortPixel oder Smush Pro installieren, automatische Konvertierung zu WebP aktivieren, Lazy Loading sicherstellen. Logo zu SVG. Hero-Bild mit fetchpriority="high".

Schritt 4 – Tag 13 bis 16: Plugin-Audit. Alle aktiven Plugins durchgehen. Was nicht in den letzten 3 Monaten genutzt wurde, deaktivieren. Page-Builder kritisch hinterfragen. Slider durch leichtere Alternative ersetzen.

Schritt 5 – Tag 17 bis 20: Schriften und CSS. Google-Fonts lokal hosten. Critical CSS extrahieren (manuell oder via WP Rocket). Render-Blocking-Skripte mit defer oder async versehen.

Schritt 6 – Tag 21 bis 24: JavaScript reduzieren. Doctolib- oder Termin-Embeds als Lazy-Click umbauen. Cookie-Banner async machen. Tracking-Skripte über Tag-Manager bündeln.

Schritt 7 – Tag 25 bis 27: CDN und HTTP/2. Cloudflare einrichten (kostenlos). HTTP/2 oder HTTP/3 verifizieren. Brotli-Kompression aktivieren.

Schritt 8 – Tag 28 bis 30: Final-Messung und Monitoring. PageSpeed Insights mehrfach laufen lassen. Werte mit Tag 1 vergleichen. Monitoring einrichten via Google Search Console (Core Web Vitals Report) oder SpeedCurve.

Realistische Ergebnis-Erwartung: LCP-Verbesserung um 40 bis 60 Prozent, INP-Verbesserung um 30 bis 50 Prozent. Wer alle Schritte sauber umsetzt, landet in 95 Prozent der Fälle im grünen Google-Bereich.

Häufige Einwände und harte Realität

"Meine Praxis-Webseite ist doch schnell genug, ich finde sie selbst flüssig." Du bist nicht der Maßstab. Du surfst aus deiner Praxis im W-LAN auf einem 5 Jahre alten Browser-Cache. Patienten kommen mobile, oft mit 3G, frischem Browser. Miss objektiv mit PageSpeed Insights, nicht subjektiv.

"Ich habe einen guten Webdesigner, der hat das berücksichtigt." Vermutlich nicht. In den 47 Audits hatten 38 Praxen einen "professionellen" Webdesigner für die Erstellung beauftragt. Die Performance-Werte waren statistisch nicht besser als bei Praxen, die die Webseite selbst gebaut hatten. Webdesign und Speed-Optimierung sind unterschiedliche Disziplinen.

"Wir haben gerade erst eine neue Webseite bekommen, da kann ich nicht schon wieder ändern." Ist okay. Speed-Optimierung ist kein Webseiten-Neubau. Ein Speed-Sprint nimmt deine bestehende Webseite und macht sie schnell. Investment 1.500 bis 4.000 Euro, in 21 Tagen erledigt, kein Design-Wechsel nötig.

"3.000 Euro für Speed sind viel Geld." Im Vergleich zu was? Eine Praxis mit 1.000 Mobile-Besuchen monatlich verliert bei einer 4-Sekunden-Seite etwa 50 bis 80 Termin-Anfragen pro Monat an Speed-Konkurrenten. Bei einem Patienten-Lebenswert von 800 bis 1.500 Euro (Zahnarzt, Physio) ist das ein verlorener Umsatz von 40.000 bis 90.000 Euro pro Jahr. 3.000 Euro Speed-Sprint amortisieren sich in 30 Tagen.

"Ich habe keine Zeit für so ein Projekt." Du investierst keine Praxis-Zeit. Wenn du eine Agentur beauftragst, ist deine Mitwirkung 2 Stunden Briefing, dann läuft alles ohne dich. Der Sprint stört den Praxis-Alltag nicht.

"Page Speed ist Tech-Geek-Kram, das sehen Patienten doch nicht." Patienten sehen es genau wie du, nur unbewusst. Sie sehen, dass deine Webseite "irgendwie nicht so professionell wirkt" oder "anders schwerfällig". Sie wechseln zur nächsten Praxis. Das ist unbewusste Performance-Wahrnehmung – und sie ist real.

Die nächsten vier Schritte für deine Praxis

1. Heute: PageSpeed Insights laufen lassen, Werte notieren. Wenn LCP über 2,5 Sekunden, hast du Optimierungspotenzial.
2. Diese Woche: Bilder-Gewicht der Startseite prüfen. Über 1 Megabyte ist akut, da gewinnst du am schnellsten am meisten.
3. Diesen Monat: Hosting-Frage klären. Über 600 Millisekunden TTFB? Migration planen. Unter 400? Anderswo optimieren.
4. Nächste 90 Tage: Vollständigen Speed-Sprint umsetzen oder beauftragen. Ergebnis: Praxis-Webseite unter 2 Sekunden, im Google-grünen Core-Web-Vitals-Bereich, plus 30 bis 50 Prozent organischer Traffic in 6 Monaten.

Wenn du das selbst machen willst und einen Sparring-Partner brauchst oder lieber komplett delegierst – wir bauen seit 2018 Praxis-Webseiten in Bonn und Köln, die Patienten in Termine verwandeln. Erstgespräch buchen – kostenlos, ohne Verpflichtung, mit Speed-Quick-Win-Empfehlung in der ersten Antwort.

Mehr zum Thema: Praxis-Webseite – die 7 häufigsten Fehler, Praxis-Webseite Kosten 2026, Webdesigner Bonn, SEO Bonn für Praxen.