Sie ahnen es vielleicht schon: Ihre WordPress-Seite könnte schneller sein. Aber haben Sie sie schon auf dem Smartphone geprüft?
Nehmen Sie Ihr Telefon heraus und laden Sie Ihre eigene Website. Zählen Sie die Sekunden. Beobachten Sie, wie das Layout springt und Bilder in falschen Größen erscheinen. Genau das erleben 60 % Ihrer Besucher, denn so groß ist der Anteil des mobilen Web-Traffics im Jahr 2026.
Google schaut ebenfalls hin.
Mobile-First-Indexierung: Warum mobile Geschwindigkeit den größten Hebel hat
Seit 2021 verwendet Google Mobile-First-Indexierung für alle Seiten im Web. Das bedeutet: Google bewertet Ihre Seite anhand ihrer mobilen Performance, nicht der Desktop-Performance.
Desktop-Performance spielt für viele B2B-Strecken weiterhin eine Rolle, doch Googles Index ist mobile-first; mobile Geschwindigkeit hat mehr SEO-Gewicht. Ein mobiler PageSpeed von 45 ist die Zahl, die Googles Crawler priorisiert. Sie entscheidet maßgeblich darüber, ob Sie auf Seite eins oder Seite drei landen.
Viele WordPress-Seiten erreichen 35 bis 55 Punkte im mobilen PageSpeed ohne gezielte Performance-Arbeit. Das liegt unterhalb von Googles empfohlenem Schwellenwert und kann zu einem echten Geschäftsproblem werden.
Warum WordPress-Seiten auf Mobilgeräten kämpfen
Themes wurden nicht für Mobile-First entwickelt
Die meisten WordPress-Themes sind desktop-orientiert gestaltet und werden anschließend per CSS-Media-Queries responsive gemacht. Das Ergebnis: Das Smartphone lädt dieselben schweren Assets wie ein Desktop-Browser und blendet dann aus, was es nicht benötigt. Die Daten werden trotzdem übertragen. Das JavaScript wird trotzdem ausgeführt. Man sieht es nur nicht.
Eine echte Mobile-First-Seite sendet nur das, was das Gerät braucht. Die meisten WordPress-Themes leisten das nicht von Haus aus, auch wenn es mit sorgfältiger Theme-Auswahl und Konfiguration erreichbar ist.
Render-blockierendes CSS und JavaScript
Eine durchschnittliche WordPress-Seite lädt 15 bis 25 separate CSS- und JavaScript-Dateien, bevor irgendetwas auf dem Bildschirm erscheint. Jede Datei bedeutet einen zusätzlichen Server-Roundtrip. In Mobilfunknetzen, selbst bei schnellem 4G, können so 2 bis 4 Sekunden reines Warten entstehen, bevor ein einziger Pixel gerendert wird.
Caching-Plugins versuchen, diese Dateien zu bündeln und zu minifizieren. Das Grundproblem lässt sich damit aber nicht beheben: WordPress lädt alles im Voraus, weil Plugins nicht miteinander koordinieren.
Bilder sind der größte Schwachpunkt
WordPress erzeugt mehrere Bildgrößen, liefert aber selten die passende für das jeweilige Gerät. Ein 2000 Pixel breites Hero-Bild wird an einen 390 Pixel schmalen Smartphone-Bildschirm geschickt. Selbst mit Lazy-Loading-Plugins liefert WordPress moderne Formate wie WebP oder AVIF nicht standardmäßig aus und nutzt keinen CDN-Edge-Knoten in der Nähe des Besuchers.
Auf Mobilgeräten machen Bilder oft 60 bis 80 % des gesamten Seitengewichts aus. Wer das falsch handhabt, macht alle anderen Maßnahmen zunichte.
Page-Builder erzeugen massiven Overhead
Elementor, Divi, WPBakery: Diese Tools erleichtern das Gestalten in WordPress. Page-Builder-JavaScript kann 500 kb bis 1,5 MB pro Seite hinzufügen; Seiten mit mehreren Page-Buildern laden auf mittelklassigen Mobilgeräten über 4G häufig 5 bis 8 Sekunden lang. Mit schneller Desktop-Verbindung fällt der Unterschied kaum auf.
Shared Hosting kommt bei mobilem Traffic-Ansturm nicht mit
Mobile Nutzer sind ungeduldig und erwarten Seiten in unter 2 Sekunden. Shared-Hosting-Server, die allein für die erste Antwort 800 ms benötigen, haben die Hälfte dieses Zeitbudgets verbraucht, bevor ein einziges Asset geladen wurde.
Reale Zahlen: WordPress vs. Next.js auf Mobilgeräten
Nach Dutzenden Migrationen von WordPress zu Next.js sehen die mobilen Werte in der Regel so aus:
| Kennzahl | WordPress (ohne Optimierung) | Next.js auf Vercel |
|---|---|---|
| Mobile PageSpeed | 35-55 | 90-99 |
| First Contentful Paint | 3,0-5,5 s | 0,3-0,8 s |
| Largest Contentful Paint | 4,0-8,0 s | 0,6-1,2 s |
| Cumulative Layout Shift | 0,15-0,35 | 0,01-0,05 |
| Gesamtseitengewicht | 2-5 MB | 200-500 kb |
Gleiche Inhalte. Gleiches Branding. Der Unterschied liegt in der Architektur.
Was Mobile-First-Architektur in der Praxis bedeutet
Next.js-Seiten funktionieren grundlegend anders:
Statische Generierung. Seiten werden beim Deployment als HTML-Dateien vorgebaut. Besucht ein mobiler Nutzer die Seite, erhält er eine statische Datei vom CDN, ohne Server-Verarbeitung, ohne Datenbankabfrage, ohne PHP-Ausführung. Antwortzeit: circa 50 ms weltweit.
Responsive Bilder als Standard. Next.js verfügt über eine eingebaute Image-Komponente, die automatisch die korrekte Größe im Format WebP oder AVIF, lazy-loaded, vom Edge-Knoten ausliefert. Ein mobiler Nutzer mit einem 390 Pixel breiten Bildschirm bekommt ein 390 Pixel breites Bild, kein 2000-Pixel-Bild in einem kleinen Viewport.
Edge-CDN-Deployment. Vercel stellt Seiten von über 100 globalen Edge-Standorten bereit. Ein mobiler Nutzer in München erhält die Seite aus Frankfurt, nicht von einem Shared-Server in Dallas. Allein die physische Distanz kann 200 bis 400 ms einsparen.
Minimales JavaScript. Kein jQuery. Keine Plugin-Kette. Kein Page-Builder-Runtime. Eine typische Next.js-Unternehmensseite liefert 50 bis 100 kb JavaScript insgesamt, deutlich weniger als typische WordPress-Builds, die oft 500 kb bis 1,5 MB erreichen.
Was Sie jetzt tun können
Prüfen Sie zunächst Ihren mobilen Score. Wer seinen aktuellen mobilen PageSpeed-Score nicht kennt, navigiert im Blindflug. Den kostenlosen WordPress Health Report erhalten Sie unter webvise.io/wp-health-report: Er zeigt Ihren realen mobilen Score, Sicherheitshinweise und den zu erwartenden Score nach einem Rebuild.
Überlegen Sie, ob weitere WordPress-Optimierungen Sie ans Ziel bringen. Liegt Ihr mobiler Score unter 60, ist es mit Plugins allein kaum möglich, 90 und mehr zu erreichen. Caching-Plugins, Bildoptimierer und CDN-Abonnements kosten Geld und Zeit, und dennoch stagniert die Performance oft in den 60ern. Ab einem gewissen Punkt wird die Architektur selbst zur Begrenzung.
Ziehen Sie einen Rebuild in Betracht. Eine WordPress-zu-Next.js-Migration richtet sich nach Seitenkomplexität, Inhaltsvolumen, SEO-Risiko und Integrationen und beseitigt die architektonischen Ursachen mobiler Performance-Probleme. Korrekt umgesetzt erzielen Seiten beim Launch in der Regel 90 Punkte und mehr auf Mobilgeräten. Kein Plugin-Wartungsaufwand; die Performance verschlechtert sich nicht durch Plugin- oder Theme-Updates, obwohl Framework- und Dependency-Updates weiterhin anfallen.
Mobile Besucher und Googles mobiler Crawler bemerken den Unterschied.
Neugierig, wie Ihre Seite auf Mobilgeräten abschneidet? Den kostenlosen WordPress Health Report gibt es unter webvise.io/wp-health-report, in 60 Sekunden, ohne Anmeldung.