Ich diagnostiziere und behebe LCP, INP und CLS auf Ebene der WordPress-Templates und des Codes — nicht nur einen Lighthouse-Score. Dieser Core-Web-Vitals-Service beginnt mit der Search Console und CrUX und verfolgt dann Render-Pfad, Scripts, CSS, Medien und Serverantwort auf den URLs, die wirklich ranken und konvertieren.
Caching hilft beim TTFB. Die meisten Fehler entstehen trotzdem durch Hero-Elemente, CSS, Main-Thread-Arbeit und Layout Shifts auf den Templates, die ranken und konvertieren.
Hero-Bilder ohne Priorität, spät geladenes CSS, langsames HTML und Tags, die das größte Element verzögern. Optimiere den kritischen Pfad auf organischen Landingpage-Templates – nicht nur auf der Homepage.
Long Tasks durch Builder, Analytics, Chat und jQuery-Handler. Arbeit aufteilen, nicht-kritisches JavaScript verzögern und Scripts entfernen, die auf Produkt- oder Beitragsseiten nie laden sollten.
Bilder ohne feste Maße, spät ladende Fonts, eingeblendete Banner und Sticky Bars. Platz reservieren und Above-the-fold-Komponenten stabilisieren, damit das Layout nach dem ersten Paint nicht springt.
Eine WordPress-Website kann in einem einzelnen Labortest gut aussehen und trotzdem die Feldbewertung verfehlen. Ich arbeite vom Template nach außen: Was entdeckt der Browser zuerst, was blockiert den Main Thread, was verschiebt sich nach dem Paint und welche Plugins oder Drittanbieter laden dort, wo sie nicht sollten?
Die tatsächliche LCP-Ressource früh auffindbar und hoch priorisiert machen, spät ladende Abhängigkeiten entfernen, renderblockierendes CSS reduzieren und TTFB nur dann angehen, wenn die Origin-Antwort Teil der Verzögerung ist.
Long Tasks durch Builder, Analytics, Consent-Tools, Chat, Slider und Legacy-jQuery profilieren. Nicht-kritische Arbeit verzögern oder isolieren und Interaction-Handler klein genug halten, damit die Seite responsiv bleibt.
Maße für Bilder und Embeds reservieren, Webfont-Laden stabilisieren und verhindern, dass Cookie-Banner, Sticky-Promos oder dynamische Blöcke die Seite nach dem ersten Paint verschieben.
Ein Script, das im Checkout gebraucht wird, gehört nicht auf jeden Blogbeitrag. Assets werden pro Template geprüft, damit Elementor, WooCommerce, Formulare und Marketing-Plugins ihre Kosten nur dort verursachen, wo sie Wert schaffen.
Felddaten werden auf Origin- und URL-Ebene geprüft, wo sie verfügbar sind, und anschließend mit reproduzierbaren Lab-Traces kombiniert. So lässt sich ein echtes Nutzerproblem von einem verrauschten einzelnen Lighthouse-Lauf unterscheiden.
Die Übergabe dokumentiert, was geändert wurde, was weiterhin verzögert bleiben muss und welche Templates nach einem Plugin-, Kampagnen-Tag- oder Design-Update erneut geprüft werden sollten.
Lighthouse ist ein kontrollierter Labortest. Die Core-Web-Vitals-Bewertung im Chrome UX Report basiert auf echten Chrome-Besuchen und bewertet das 75. Perzentil über ein rollierendes Felddatenfenster. Deshalb kann eine Website auf deiner Verbindung schnell wirken, während mobile Nutzer, ausgeloggter Traffic, Consent-Scripts oder ein bestimmtes Landingpage-Template weiterhin durchfallen.
Deshalb optimiere ich nicht nur die Homepage. Die Baseline umfasst repräsentative Templates – Landingpages, Beiträge, Produktlisten, Produktseiten und bei Bedarf den Checkout – und testet genau das Element oder die Interaktion, die für LCP, INP oder CLS verantwortlich ist.
Ich arbeite seit mehr als 15 Jahren intensiv mit WordPress und habe über 60 WordPress-Websites ausgeliefert oder betreut. Performance-Projekte werden auf Live-URLs gemessen; Kundennamen bleiben bei NDA-Projekten vertraulich.
Das Projekt ist auch dann sinnvoll, wenn ich nicht alles selbst umsetze und dein internes Team Teile des Plans übernimmt.
Ich starte mit Search Console / CrUX und den URLs, die für Rankings und Umsatz wichtig sind – nicht mit einem einzigen Lighthouse-Lauf der Homepage.
Beginne mit Felddaten, um zu erkennen, welche Templates und Geräte durchfallen, und reproduziere anschließend den Engpass in Lab-Traces. Typische Fixes sind höhere Priorität der LCP-Ressource, Critical CSS, weniger JavaScript, stabile Medienmaße, optimiertes Font-Loading, Kontrolle von Plugin-Assets und Verbesserungen der Serverantwort, wenn TTFB den Paint begrenzt.
PageSpeed Insights kann sowohl Labor- als auch Felddaten anzeigen, aber ein einzelner Lighthouse-Lauf ist nur ein simulierter Labortest. Search Console gruppiert echte CrUX-Nutzerdaten über einen rollierenden Zeitraum, daher können bestimmte Templates, Geräte oder Traffic-Bedingungen weiterhin durchfallen, selbst wenn ein einzelner Labortest grün ist.
Ja, oft ohne Redesign. Entscheidend ist zu kontrollieren, was jedes Template lädt: Above-the-fold-Medien, Builder-CSS, Plugin-JavaScript, Drittanbieter-Tags, WooCommerce-Assets und serverseitige Arbeit. Manche Stacks haben eine niedrigere Obergrenze – das zeigt das Audit, bevor tiefere Änderungen beginnen.
Die meisten fokussierten Projekte dauern ein bis drei Wochen für Audit, Staging-Fixes, Produktions-Deployment und Verifikation. Große WooCommerce-, mehrsprachige oder stark integrierte Websites können länger dauern, weil mehr Templates und Drittanbieter-Abhängigkeiten getestet werden müssen.
Eine Prüfung repräsentativer Live-URLs anhand verfügbarer Felddaten und reproduzierbarer Labortests, die wichtigsten LCP-, INP- und CLS-Engpässe nach Impact priorisiert sowie eine realistische Einschätzung dessen, was auf dem bestehenden Stack verbessert werden kann.
Ich sage dir, was LCP, INP oder CLS tatsächlich begrenzt – und ob sich der Fix jetzt lohnt.
Nutze die metrikspezifischen Seiten, wenn Search Console ein konzentriertes LCP- oder INP-Problem zeigt oder wenn ein Builder/Template der gemeinsame Nenner ist.
Projekt starten
