Eine langsame Website ist ein stiller Kostenfaktor, der in keiner Rechnung auftaucht: Ein Kunde aus Bydgoszcz klickt bei Google auf Ihr Unternehmen, wartet ein paar Sekunden, kehrt zu den Ergebnissen zurück und wählt die Konkurrenz. Deshalb ist die Ladegeschwindigkeit einer WordPress-Website in Bydgoszcz keine Frage des Ehrgeizes eines Entwicklers, sondern von Umsatz und Sichtbarkeit. In diesem Ratgeber zeigen wir, wie Sie sie messen, was WordPress üblicherweise ausbremst und wie Sie das Schritt für Schritt beheben.
Google bewertet die Nutzererfahrung unter anderem anhand der Core Web Vitals, also dreier Kennzahlen: Ladezeit des Hauptinhalts, Reaktionsfähigkeit auf Klicks und Stabilität des Layouts. Eine langsame Seite kann alles zunichtemachen, was Sie in SEO und Werbung investiert haben.
Warum eine langsame Website Ihr Unternehmen Kunden und Positionen kostet
Es gibt zwei Mechanismen, und beide wirken gleichzeitig. Der erste ist das Verhalten der Menschen: Je länger sie auf den ersten Inhalt warten, desto häufiger springen sie ab, besonders auf dem Smartphone und bei schlechterem Empfang. Bei einer Praxis in Fordon oder einem Geschäft in Śródmieście kommen die meisten Besuche ohnehin vom Handy.
Der zweite Mechanismus ist Google. Die Core Web Vitals sind Teil der Bewertung der „Page Experience“. Konkrete Positionen versprechen wir nicht, da sie von Konkurrenz und Zeit abhängen, aber die Geschwindigkeit ist einer der wenigen Faktoren, die Sie vollständig selbst kontrollieren. Mehr zum Thema Suchmaschinenoptimierung schreiben wir im Artikel über datenbasierte Suchmaschinenoptimierung in Bydgoszcz.
Core Web Vitals: drei Schwellenwerte, die Sie kennen sollten
Google legt für die Bewertung „gut“ folgende Schwellenwerte fest:
- LCP (Largest Contentful Paint) bis 2,5 s – die Zeit, nach der das größte Element des ersten Bildschirms sichtbar ist, meist ein Foto oder eine große Überschrift.
- INP (Interaction to Next Paint) bis 200 ms – wie schnell die Seite auf Klicks, Berührungen oder Texteingaben reagiert. INP hat die frühere Kennzahl FID abgelöst.
- CLS (Cumulative Layout Shift) bis 0,1 – wie viele Elemente beim Laden „springen“, zum Beispiel ein Button, der von einem spät geladenen Banner verschoben wird.
Die Definitionen der Kennzahlen finden Sie in der Dokumentation web.dev zu den Core Web Vitals.
Labor- und Felddaten: warum die Ergebnisse abweichen
Die häufigste Überraschung für Inhaber: PageSpeed zeigt 95 Punkte, und die Search Console meldet Probleme. Das ist kein Fehler, sondern zwei verschiedene Arten von Daten.
Labordaten sind ein einmaliger Test unter kontrollierten Bedingungen (Lighthouse in PageSpeed Insights): hervorragend für die Ursachensuche und Vorher-nachher-Vergleiche, aber eine Simulation eines einzelnen Geräts. Felddaten sind Messungen aus echten Chrome-Browsern über mehrere Wochen (CrUX-Bericht), sichtbar in der Search Console. Das Labor dient der Diagnose, das Feld der Beurteilung, ob das Problem tatsächlich besteht.
Diagnose Schritt für Schritt
Messen Sie, bevor Sie irgendetwas installieren.
- Basismessung durchführen. Starten Sie PageSpeed Insights getrennt für Smartphone und Desktop, für die Startseite und zwei bis drei wichtige Unterseiten (Leistung, Kontakt, im Shop ein Produkt). Notieren Sie LCP, INP, CLS und die Serverantwortzeit.
- Felddaten prüfen in der Search Console, im Bericht „Core Web Vitals“.
- Das größte LCP-Element finden. PageSpeed nennt es direkt. Sehr oft ist es ein nicht optimiertes Bild im Slider oder im Hintergrund.
- Den Reiter „Network“ in den Browser-Tools durchsehen. Achten Sie auf große Dateien, externe Skripte und eine lange Zeit bis zum ersten Byte (TTFB).
Wenn Sie einen schnellen, kostenlosen Ausgangspunkt möchten, nutzen Sie unseren kostenlosen SEO-Audit. Er prüft unter anderem die Performance anhand von PageSpeed. Ein vollständigeres Bild (SEO, Sicherheit, DSGVO (RODO), Barrierefreiheit, Performance) liefert der Vollständige Website-Audit für 150 PLN mit Ergebnis in wenigen Minuten.
Hosting für ein Unternehmen aus Bydgoszcz und die PHP-Version
Kein Plugin repariert einen Server, der erst nach einer Sekunde antwortet. Ist die TTFB trotz Cache hoch, liegt das Problem im Hosting: einem überlasteten Server, einer schwachen Festplatte oder zu wenigen Ressourcen.
Worauf Sie bei der Wahl eines Hostings für eine Firmenwebsite in Bydgoszcz und Umgebung (Toruń, Inowrocław, Nakło, Solec Kujawski) achten sollten:
- Server in Polen oder Europa mit SSD-/NVMe-Festplatten,
- Möglichkeit, eine aktuelle, unterstützte PHP-Version zu wählen,
- Unterstützung für Object Cache (Redis oder Memcached), wenn Sie einen Shop betreiben,
- automatische Backups und einfache Wiederherstellung.
Die PHP-Version ist wichtig: Neuere, unterstützte Versionen sind in der Regel deutlich leistungsfähiger als alte und erhalten Sicherheitspatches. Testen Sie die Website vor einem Versionssprung auf einer Staging-Umgebung. Mehr dazu im Ratgeber zur Sicherheit von WordPress-Websites.
Cache: Seiten-Cache und Object Cache
Seiten-Cache
Standardmäßig führt WordPress bei jedem Besuch PHP aus und stellt Datenbankabfragen. Der Seiten-Cache speichert fertiges HTML und liefert es ohne diesen Aufwand aus, was die Antwortzeit in der Regel stark verkürzt. Das ist der rentabelste erste Schritt (aktivieren Sie nicht zwei Cache-Plugins gleichzeitig).
Object Cache
Redis oder Memcached speichern die Ergebnisse häufig wiederholter Abfragen. Das hilft besonders im Administrationsbereich, bei der Suche und in WooCommerce, also dort, wo ein vollständiger Seiten-Cache nicht funktionieren kann.
Bilder: der häufigste Übeltäter für schlechtes LCP
Schwere Fotos, die direkt vom Smartphone hochgeladen wurden, sind der häufigste Grund für eine langsame Startseite. Was Sie tun können:
- Passen Sie die Abmessungen an die Verwendungsstelle an.
- Nutzen Sie moderne Formate – WebP und, wo möglich, AVIF – die bei gleicher Qualität kleiner sind als JPEG. WordPress unterstützt WebP nativ.
- Ergänzen Sie die Attribute width und height (oder aspect-ratio), damit der Browser Platz reserviert und keine Layoutsprünge (CLS) verursacht.
- Aktivieren Sie Lazy Loading für Bilder unterhalb des ersten Bildschirms (loading=”lazy”). Wenden Sie es aber nicht auf das LCP-Bild an.
- Für das LCP-Bild setzen Sie eine Priorität: fetchpriority=”high” oder <link rel=”preload”>.
Schriftarten: lokal und mit font-display
Schriftarten von externen Servern erzeugen zusätzliche Verbindungen und sind manchmal die Ursache für flackernden Text. Hosten Sie die Schriftdateien lokal (Format WOFF2), beschränken Sie die Zahl der Schnitte und Stärken auf die, die Sie wirklich nutzen, und ergänzen Sie in der Deklaration font-display: swap (oder optional), damit der Text sofort sichtbar ist.
CSS und JavaScript: weniger, später, klüger
Der Browser zeichnet die Seite erst, wenn er blockierendes CSS und Skripte verarbeitet hat. Typische Maßnahmen:
- Critical CSS – die für den ersten Bildschirm nötigen Stile werden direkt in den Seitencode eingefügt, der Rest wird asynchron geladen.
- Verzögern und Aufschieben von Skripten (defer, Laden nach Interaktion) für Elemente, die nicht sofort gebraucht werden: Chat, Social-Media-Widgets, Werbepixel.
- Entfernen von ungenutztem Code – viele Plugins laden ihre Stile und Skripte auf jeder Unterseite, obwohl sie nur auf einer arbeiten. Es lohnt sich, sie bedingt zu deaktivieren.
- Kontrolle externer Skripte – jedes weitere kostet INP und LCP.
Plugins und Theme: leichtes eigenes Theme oder Page Builder
Die Zahl der Plugins ist für sich genommen kein Problem, entscheidend sind die Qualität und das, was jedes einzelne lädt. Entfernen Sie ungenutzte und messen Sie den Einfluss der übrigen. Das Theme ist noch wichtiger: Universelle Themes mit Page Buildern laden enorme Mengen an CSS, JavaScript und Markup, weil sie Tausende von Szenarien abdecken müssen, die Ihre Website nie nutzen wird.
Deshalb entwickeln wir eigene, leichte WordPress-Themes, die für ein bestimmtes Unternehmen konzipiert sind und nicht als fertige Vorlage mit Hunderten unnötiger Optionen. In unserem Angebot ist jede Unterseite bereits auf Code-Ebene für SEO und Core Web Vitals optimiert. Inhalte bearbeiten Sie weiterhin im visuellen WordPress-Editor, und der Code bleibt Ihr Eigentum. Wie der Leistungsumfang aussieht, sehen Sie im Leistungsangebot, Beispiele finden Sie auf der Seite unserer Referenzen.
Datenbank: Aufräumen, das sich lohnt
Mit der Zeit bläht sich die Datenbank auf: Revisionen, abgelaufene Transients, Spam, Überreste gelöschter Plugins. Erstellen Sie ein Backup, begrenzen Sie Revisionen, räumen Sie überflüssige Daten auf und prüfen Sie automatisch geladene Optionen (Autoload), denn ein Überschuss verlängert jede Anfrage.
WooCommerce: Warenkorb und Kasse ohne Cache
Die Seiten für Warenkorb, Kasse und Kundenkonto sind dynamisch und für jeden Nutzer einzigartig, daher müssen sie vom Seiten-Cache ausgenommen werden. Andernfalls treten Fehler auf, z. B. ein leerer Warenkorb.
- Prüfen Sie, ob das Skript „cart fragments“ nicht auf jeder Unterseite geladen wird, wenn es nicht benötigt wird.
- Nutzen Sie bei einem größeren Katalog Object Cache (Redis).
Mehr zum Betrieb von Shops schreiben wir im Artikel über die Nutzung von WooCommerce in Onlineshops, und den Zustand Ihres Shops können Sie mit dem Tool Gesundheitscheck für WooCommerce-Shops prüfen.
Mobile-first: messen, wie der Kunde die Seite sieht
Google indexiert Websites vorrangig in der mobilen Version, und Smartphones haben schwächere Prozessoren. Testen Sie im mobilen Modus, am besten auch auf einem älteren Telefon. Mehr zur lokalen Sichtbarkeit im Text über lokale SEO für Unternehmen aus Bydgoszcz.
Die häufigsten Probleme: Tabelle
| Problem | Symptom | Typische Lösung |
|---|---|---|
| Langsamer Server oder veraltetes PHP | Hohe TTFB, langsames Admin-Panel | Besseres Hosting, aktuelle PHP-Version, Object Cache |
| Schwere Fotos | Schlechtes LCP, lange Ladezeit des ersten Bildschirms | WebP/AVIF, passende Abmessungen, Preload des LCP-Bildes |
| Fehlende Bildabmessungen und spät geladene Werbung | Elemente „springen“, hoher CLS | Attribute width/height, reservierter Platz für Banner |
| Schriftarten von externen Servern | Flackernder oder unsichtbarer Text | Lokale WOFF2-Schriften, font-display: swap, Preload |
| Blockierendes CSS und JS | Weißer Bildschirm vor der Anzeige des Inhalts | Critical CSS, defer, Entfernen ungenutzter Skripte |
| Schweres externes Skript (Chat, Pixel) | Hoher INP, verzögerte Reaktion auf Klicks | Verzögertes Laden, weniger Tags |
| Umfangreicher Page Builder und universelles Theme | Großer DOM, viel ungenutztes CSS | Einstellungen verschlanken oder leichtes eigenes Theme |
| Aufgeblähte Datenbank | Langsame Abfragen, lange Seitengenerierung | Revisionen und Transients bereinigen, Autoload kontrollieren |
| Cache bei Warenkorb und Kasse in WooCommerce | Warenkorbfehler, leere Kasse | Diese Seiten vom Cache ausnehmen, Fragmente kontrollieren |
Monitoring nach der Umsetzung
Jedes neue Plugin, jeder Banner und jede Kampagne kann das Ergebnis verschlechtern. Deshalb nach der Umsetzung:
- prüfen Sie den Core-Web-Vitals-Bericht in der Search Console jeden Monat (die Daten ändern sich mit einigen Wochen Verzögerung),
- testen Sie Plugin-Updates zuerst auf der Staging-Umgebung.
Bei uns ist nach Projektstart der erste Monat Support (Updates, kleine Änderungen, Monitoring) im Preis enthalten, danach kann ein optionaler SLA-Vertrag gewählt werden. Die Google-Dokumentation zur Suche finden Sie in der Google Search Central.
Häufige Fragen
Wie schnell sollte eine WordPress-Website sein, damit Google sie gut bewertet?
Peilen Sie die Schwellenwerte der Core Web Vitals an: LCP bis 2,5 s, INP bis 200 ms und CLS bis 0,1, gemessen an Felddaten. Wichtiger als eine einzelne Zahl in PageSpeed ist, ob die Mehrheit der echten Nutzer innerhalb dieser Grenzen liegt.
Warum liefert PageSpeed ein anderes Ergebnis als die Search Console?
PageSpeed zeigt einen Labortest eines einzelnen Geräts, die Search Console dagegen Felddaten aus echten Besuchen über mehrere Wochen. Das Labor dient der Diagnose, die Felddaten der Bewertung des tatsächlichen Zustands.
Genügt es, ein Cache-Plugin zu installieren, um die Website zu beschleunigen?
Oft ist das ein guter Anfang, aber selten die ganze Lösung. Ein Cache repariert weder schwere Fotos noch externe Skripte oder langsames Hosting. Am besten wirkt die Kombination: guter Server, Cache, leichte Bilder und Kontrolle der Skripte.
Bremst ein Page Builder die Website immer aus?
Nicht immer, aber er bringt meist Code mit, der optimiert werden muss. Ein eigenes, leichtes Theme startet mit weniger Code, sodass sich gute Kennzahlen leichter halten lassen.
Wie beschleunige ich einen WooCommerce-Shop?
Nehmen Sie Warenkorb, Kasse und Kundenkonto vom Seiten-Cache aus, sorgen Sie für gutes Hosting, Object Cache und leichte Produktbilder. Testen Sie Änderungen auf der Staging-Umgebung.
Wie lange dauert die Geschwindigkeitsoptimierung und was kostet sie?
Das hängt vom Zustand der Website, des Themes, der Plugins und des Hostings ab. Nach einem kurzen Gespräch und einer Durchsicht der Website erstellen wir ein Pauschalangebot. Eine orientierende Kalkulation können Sie auch im Online-Kalkulator vornehmen.
Sprechen wir über die Geschwindigkeit Ihrer Website
Wenn Ihre Website langsam lädt oder Sie nicht wissen, was sie genau ausbremst, vereinbaren Sie mit uns ein kostenloses Gespräch (30–60 Minuten, unverbindlich). Wir sehen uns die Ergebnisse an, zeigen die größten Probleme auf und schlagen ein Pauschalangebot vor. Sie können auch mit dem kostenlosen SEO-Audit beginnen oder uns über das Kontaktformular schreiben.
Kreatywna Agencja (Canpol Bis Sp. z o.o.)
ul. Gimnazjalna 2, 85-007 Bydgoszcz
Tel. +48 502 811 949
E-Mail: biuro@kreatywnaagencja.com.pl
kreatywnaagencja.com.pl
