WordPress Mobile Performance: Warum Mobile anders tickt als Desktop

Von Manuel Hack, ihp media · Aktualisiert am 20. Juni 2026

Ein WordPress-Blog auf dem Desktop in unter einer Sekunde geladen, auf dem Smartphone aber vier Sekunden Wartezeit bis der Hauptinhalt erscheint: Das ist kein Einzelfall, sondern ein Muster. Mobile Performance und Desktop-Performance folgen unterschiedlichen Gesetzen. Wer das ignoriert, optimiert am falschen Gerät und verliert Besucher und Ranking genau dort, wo der Großteil des Traffics heute herkommt.

Warum Mobile Performance eine eigene Disziplin ist

Drei Faktoren zusammen erklären, warum mobil eine andere Welt ist:

CPU-Leistung

Ein Mittelklasse-Android-Gerät, auf dem der Durchschnittsnutzer surft, bringt einen Bruchteil der Rechenleistung eines Desktop-Rechners mit. JavaScript-Code, der auf dem Laptop in 50 Millisekunden ausgeführt ist, blockiert auf dem Smartphone den Hauptthread für 200 Millisekunden und mehr. Das ist der Grund, warum INP auf Mobile so oft schlechter ausfällt als auf Desktop.

Netzwerk und Latenz

WiFi liefert eine Mindestlatenz von rund 2 Millisekunden, reguläres 4G kommt laut MDN-Latenz-Dokumentation auf mindestens 20 Millisekunden, 3G auf 40 Millisekunden. Bei einer Seite, die 30 externe Ressourcen lädt, multipliziert sich dieser Unterschied. Jede HTTP-Anfrage braucht erst eine Verbindung, und auf mobilem Netz kostet das messbar Zeit. Dazu kommt, dass Bandbreite im Mobilfunk schwankt: eine Seite mit unkomprimierten 3-MB-Bildern ist auf Festnetz kein Problem, auf 3G ein echter Ladezeiten-Killer.

Akku und Wärme

Konstante CPU-Last heizt das Gerät auf. Viele Smartphones drosseln bei Wärme die CPU-Frequenz (Thermal Throttling). Eine JavaScript-intensive Seite, die auf einem frisch aufgeladenen Telefon noch flüssig läuft, kann nach zehn Minuten Video-Streaming deutlich träger reagieren. Das ist kein theoretisches Problem, sondern wirkt sich auf die INP-Werte echter Nutzer aus.

Mobile-First-Indexing: Was Google wirklich bewertet

Mobile-First-Indexing bedeutet konkret: Google nutzt die mobile Version einer Seite als Grundlage für Indexierung und Ranking. Laut Googles Dokumentation zu Mobile-First-Indexing ist der Smartphone-Crawler der primäre Agent. Was auf dem Smartphone nicht sichtbar ist, zählt für Google weniger. Eine Desktop-optimierte Seite mit langsamer mobiler Variante ist aus Suchmaschinen-Sicht eine langsame Seite, ohne Ausnahme.

Direkt damit verknüpft sind die Core Web Vitals. Google nutzt sie als Ranking-Signal (Page Experience Update). Die Messung im Chrome User Experience Report (CrUX) erfasst echte Nutzerdaten von mobilen und Desktop-Besuchen getrennt. Wer mobil schlechte Core-Web-Vitals-Werte hat, bekommt das im Ranking zu spüren.

LCP, INP und CLS: Die drei Metriken auf dem Smartphone

Die Core Web Vitals messen drei Dimensionen der Nutzererfahrung. Seit März 2024 gilt INP als dritte stabile Metrik und hat FID (First Input Delay) abgelöst. Alle drei Schwellenwerte gelten für das 75. Perzentil, also: 75 Prozent aller Besuche müssen im grünen Bereich liegen.

LCP auf Mobile

Das LCP-Element ist häufig das Hero-Bild oder der größte Textblock im sichtbaren Bereich. Auf Desktop lädt es schnell, weil Bandbreite und TTFB stimmen. Auf Mobile zählt jede Millisekunde, die der Browser auf das Bild wartet. Ein Bild ohne fetchpriority="high" und ohne Preload konkurriert mit allen anderen Ressourcen im Download-Queue. Das Ergebnis ist ein LCP von 4 oder 5 Sekunden, obwohl das Bild klein genug wäre. Mehr dazu im Ratgeber LCP verbessern: die wirksamen Hebel.

INP auf Mobile

INP ist die Metrik, bei der Mobile am stärksten von Desktop abweicht. Das Prinzip: INP beobachtet alle Interaktionen während eines Seitenbesuchs, nicht nur die erste. Auf einem leistungsfähigen Desktop-Browser wird ein Klick-Event in 50 Millisekunden verarbeitet. Auf einem Mittelklasse-Smartphone mit voll ausgelastetem Hauptthread kann dasselbe Event 400 Millisekunden warten. Jedes Plugin, das JavaScript in den Hauptthread schiebt, ist auf Mobile ein potenzielles INP-Problem.

CLS auf Mobile

Layoutverschiebungen passieren auf kleinen Viewports besonders auffällig. Wird ein Bild ohne explizite Breite und Höhe geladen, springt der Text darunter beim Bildladen nach unten. Auf einem 390 Pixel breiten Smartphone trifft das den Finger direkt beim Lesen. Wie man das verhindert, zeigt der Ratgeber CLS vermeiden: stabiles Layout.

Die häufigsten mobilen Performance-Fallen

Bilder ohne responsive srcset

Eine Seite, die ein 2.400 Pixel breites Bild als einzige Variante ausliefert, zwingt das Smartphone, ein 1,5-MB-Bild herunterzuladen und auf 390 Pixel Breite zu skalieren. Das Desktop-Auge sieht kein Problem. Der mobile Nutzer wartet. Die Lösung ist das srcset-Attribut, das mehrere Bildgrößen anbietet, und sizes, das dem Browser mitteilt, wie breit das Bild tatsächlich dargestellt wird. Laut web.dev zu Responsive Images machen Bilder im Schnitt über 60 Prozent der geladenen Datenmenge aus. Ohne srcset werden diese Bytes komplett verschwendet.

WordPress generiert srcset-Varianten seit Version 4.4 automatisch, sofern Bilder groß genug hochgeladen werden. Das Problem in der Praxis: viele ältere Bilder oder Bilder, die per CSS als Hintergrundbild gesetzt werden, profitieren nicht davon. Hintergrundbilder, die für den LCP relevant sind, brauchen eine andere Strategie.

Render-blockierendes CSS und JavaScript

Der Browser kann keine Pixel zeichnen, solange er auf ein Stylesheet oder ein synchrones Skript wartet. Auf Desktop mit schnellem Netz ist dieses Warten oft unter 100 Millisekunden. Auf 4G mit 20 Millisekunden Latenz pro Anfrage addiert sich das. Jede externe CSS-Datei im <head> blockiert das Rendering, bis sie vollständig geladen ist. Wie man dieses Problem strukturiert löst, zeigt der Ratgeber Render-blockierendes CSS und JavaScript auflösen.

Schwere Slider und Animationen

Bildkarusselle sind das deutlichste Beispiel für ein Desktop-Denkmuster, das auf Mobile schadet. Ein typischer jQuery-Slider lädt eine eigene JS-Bibliothek, mehrere Bilder auf einmal (auch die nicht sichtbaren) und läuft in einem Animationsloop, der den CPU dauerhaft beschäftigt. Auf einem leistungsschwachen Smartphone wird der Hauptthread blockiert, INP steigt, der Akku leidet. Die Lösung ist oft radikal: Slider ersetzen durch ein statisches Bild mit schnellem Ladeattribut.

Third-Party-Skripte

Live-Chat-Widgets, Tracking-Pixel, Consent-Management-Tools, Social-Sharing-Buttons, Bewertungs-Widgets: Jedes dieser Skripte wird von einem externen Server geladen, mit eigener DNS-Auflösung, eigenem TCP-Handshake und eigenem Verarbeitungs-Overhead. Auf Desktop mit schnellem Netz fällt das kaum auf. Auf Mobile mit 4G kostet jede externe Domain extra Zeit. In Projekten messen wir häufig, dass Third-Party-Skripte allein 30 bis 60 Prozent der Gesamtladezeit ausmachen, ohne einen einzigen eigenen Byte der Seite zu laden.

Webfonts ohne Fallback-Strategie

Wer eine Custom-Schrift ohne font-display: swap oder optional einbindet, riskiert auf Mobile einen unsichtbaren Text bis der Font geladen ist (FOIT, Flash of Invisible Text). Das Fenster dafür ist standardmäßig 3 Sekunden. Auf mobilem Netz ist der Font in dieser Zeit oft noch nicht da. Der Nutzer sieht eine leere Seite, obwohl der Inhalt längst da ist. Dazu kommt: Jede externe Font-Quelle (Google Fonts per CDN-Link) ist eine weitere externe Verbindung mit Latenz-Overhead.

Fehlende Komprimierung

Gzip oder Brotli auf dem Server halbiert bei Text-Ressourcen (HTML, CSS, JS) die übertragene Datenmenge. Ohne Komprimierung schickt der Server das volle, unkomprimierte HTML über das Netz. Auf mobilem Netz mit begrenzter Bandbreite und höherer Latenz ist das ein unterschätzter Performance-Verlust. Die meisten Hosting-Umgebungen können Brotli oder Gzip serverseitig aktivieren, ohne dass Quelldateien geändert werden müssen.

Diagnose: Wie man mobile Performance richtig misst

Lighthouse Mobile (Labordaten)

Im Chrome DevTools unter dem Lighthouse-Tab wählt man den Modus „Mobile“. Lighthouse simuliert dann ein Mittelklasse-Gerät mit CPU-Throttling (4-fache Verlangsamung) und langsamem 4G-Netz. Das Ergebnis ist reproduzierbar, aber synthetisch: Es zeigt, wie die Seite unter definierten Bedingungen abschneidet, nicht wie sie bei echten Nutzern ankommt. Scores schwanken bei jedem Lauf leicht, weil CPU und Netz auf dem eigenen Rechner nie komplett konstant sind. Deshalb mehrere Läufe durchführen und den Durchschnitt bewerten.

PageSpeed Insights (Feld- und Labordaten)

PageSpeed Insights kombiniert zwei Sichten: oben die CrUX-Felddaten (echte Chrome-Nutzer über 28 Tage, aufgeteilt nach Mobile und Desktop), darunter die Lighthouse-Labordaten. Die Felddaten sind die relevantere Sicht für SEO, weil Google sie für das Ranking-Signal verwendet. Wichtig: CrUX-Daten fehlen, wenn eine Seite zu wenig Traffic hat. Dann stehen dort keine Balken.

Throttled Testing im eigenen Browser

Im Chrome DevTools Network-Tab gibt es einen Throttle-Selektor. „Slow 4G“ oder „3G“ auswählen und dann die Seite auf dem Desktop so laden, wie ein mobiles Gerät im Mobilfunknetz sie sieht. Das ist kein perfekter Ersatz für ein echtes Gerät, gibt aber schnell ein Gespür für die schlimmsten Ladezeiten-Probleme.

Echtes Gerät testen

Der verlässlichste Test bleibt ein echtes Mittelklasse-Smartphone auf einem 4G-Netz. Was dort träge wirkt, ist auch für den Durchschnittsnutzer träge. Kein Simulator ersetzt das vollständig.

<link rel="preload" as="image" href="hero.jpg" fetchpriority="high">
<img src="hero.jpg" alt="…" fetchpriority="high" width="1200" height="600">

<?php
/**
 * IHP: fetchpriority="high" am LCP-Bild setzen.
 * Greift fuer Seiten, auf denen WordPress das LCP-Bild nicht
 * automatisch erkennt (z. B. Page-Builder, Custom-Themes).
 *
 * Platzierung: wp-content/mu-plugins/ihp-lcp-priority.php
 */
add_filter( 'wp_get_attachment_image_attributes', 'ihp_set_lcp_fetchpriority', 10, 3 );

function ihp_set_lcp_fetchpriority( $attr, $attachment, $size ) {
    // Nur auf Singular-Seiten und nur beim ersten Aufruf dieses Filters.
    static $already_set = false;
    if ( ! is_singular() || $already_set ) {
        return $attr;
    }
    // Kein lazy loading am LCP-Bild.
    $attr['loading']       = 'eager';
    $attr['fetchpriority'] = 'high';
    $already_set           = true;
    return $attr;
}

Praxisbeispiel aus einem WordPress-Projekt

In einem Projekt für einen Dienstleister hatte die Website auf Desktop einen Lighthouse-Score von 84, auf Mobile hingegen 41. Das war kein Messfehler, sondern ein typisches Muster. Die Ursachen nach Diagnose:

• Das Hero-Bild hatte keine srcset-Varianten und keine Dimensionsangaben. Auf Mobile lud der Browser ein 2,1-MB-JPEG in voller Desktop-Auflösung. LCP: 5,8 Sekunden auf 4G.
• Zwei externe Webfonts ohne font-display: swap. Unsichtbarer Text für bis zu 3 Sekunden auf 4G.
• Ein Chat-Widget lud 280 KB JavaScript synchron im <head>, noch bevor das erste Pixel gerendert war.
• Das Caching-Plugin war installiert, aber Brotli-Komprimierung auf dem Server deaktiviert.

Die Korrekturen: Hero-Bild durch WordPress-srcset-konforme Bilder ersetzt, fetchpriority="high" gesetzt, Chat-Widget auf Facade-Pattern umgestellt, Webfont-Einbindung auf font-display: swap umgestellt, Brotli auf dem Hosting aktiviert. Danach: LCP 2,1 Sekunden, Lighthouse Mobile 74. Kein Neuaufbau, keine Plugin-Explosion, sondern gezielte Eingriffe an den richtigen Stellen.

Was bei diesem Projekt auffiel: Desktop war schon vorher grün. Mobile war rot. Wer nur den Desktop-Score schaut, sieht das Problem nicht.

• Lighthouse Mobile (nicht Desktop) als primären Maßstab nutzen
• PageSpeed Insights öffnen, CrUX-Felddaten Mobile lesen
• LCP-Element identifizieren (meist das Hero-Bild) und mit fetchpriority="high" priorisieren
• LCP-Bild mit width und height-Attributen ausstatten, kein loading="lazy" daran
• Alle anderen Bilder mit srcset und loading="lazy" versehen
• Render-blockierende Skripte im <head> auf defer oder async umstellen
• Third-Party-Skripte auflisten: Welche sind auf jeder Seite wirklich nötig?
• Webfonts mit font-display: swap oder lokal hosten
• Gzip oder Brotli auf dem Server aktivieren
• Caching testen: Feld-Daten zeigen, ob Nutzer die gecachte Version bekommen
• Echtes Mittelklasse-Smartphone auf 4G als finalen Kontrolltest nutzen

Häufige Fragen

Was ist der Unterschied zwischen Lighthouse Mobile Score und PageSpeed Insights Felddaten?

Lighthouse Mobile simuliert unter kontrollierten Bedingungen ein Mittelklasse-Gerät mit gedrosseltem Netz und CPU. PageSpeed Insights Felddaten kommen aus dem Chrome User Experience Report (CrUX) und zeigen echte Nutzerwerte über 28 Tage. Beide Sichten braucht man: Lighthouse findet Optimierungspotenziale, Felddaten zeigen, ob echte Nutzer die Seite als schnell erleben. Für das Google-Ranking-Signal zählen die Felddaten.

Was hat sich mit INP im März 2024 geändert?

INP (Interaction to Next Paint) hat FID (First Input Delay) als stabile Core-Web-Vitals-Metrik abgelöst. FID maß nur die erste Interaktion auf einer Seite. INP misst alle Interaktionen über den gesamten Besuch und ist damit ein deutlich strengerer Maßstab. Auf mobilen Geräten mit schwächerem Prozessor fällt INP meistens schlechter aus als auf Desktop, weil JavaScript-Event-Handler länger auf CPU-Zeit warten.

Warum hat meine Seite auf Desktop einen guten Score, auf Mobile aber nicht?

Das ist das häufigste Muster. Desktop profitiert von schnellerem Netz, mehr CPU-Leistung und oft größeren Viewports, die Lazy Loading effizienter machen. Auf Mobile kommen höhere Netzlatenz, schwächere CPU und engere Bandbreite zusammen. Viele Optimierungen, die auf Desktop keinen messbaren Unterschied machen, entscheiden auf Mobile über Grün oder Rot.

Was bewirkt fetchpriority=“high“ am Bild?

Das Attribut signalisiert dem Browser, diese Ressource mit hoher Priorität zu laden. Ohne das Attribut konkurriert das LCP-Bild mit allen anderen Ressourcen im Ladequeue. Mit fetchpriority="high" wird es vorgezogen. Das Ergebnis ist ein früherer Start des Bilddownloads, was den LCP-Wert verbessert. Wichtig: Nur an dem einen Bild setzen, das tatsächlich das LCP-Element ist. An allen anderen Bildern bleibt das Attribut weg oder bekommt low.

Sind Third-Party-Skripte wirklich so ein großes Problem?

Ja, auf Mobile besonders. Jede externe Domain bedeutet eine separate DNS-Auflösung, TCP-Verbindung und auf mobilem Netz zusätzliche Latenz. Ein typisches WordPress-Projekt mit Live-Chat, Tracking-Pixel, Consent-Tool und Social-Sharing lädt vier bis sechs externe Verbindungen pro Seite. Auf 4G kann das zusammen 500 Millisekunden und mehr kosten, bevor die eigentliche Seite überhaupt lädt.

Hilft ein Caching-Plugin wirklich bei mobiler Performance?

Ein gutes Caching-Plugin hilft, aber es löst nicht alle Probleme. Caching verbessert die TTFB (Time to First Byte), weil der Server keine Datenbankabfragen mehr macht. Das ist eine wichtige Basis. Aber Bilder ohne srcset, render-blockierende Skripte und schwere Third-Party-Ressourcen bleiben Probleme, die Caching nicht behebt. Caching ist eine notwendige, aber keine hinreichende Bedingung für gute Mobile Performance. Mehr zum Thema im Ratgeber Caching verständlich erklärt.

Muss ich meine Seite von Grund auf neu bauen, um mobil schnell zu sein?

In den meisten Fällen nicht. Die größten Gewinne kommen oft aus gezielten Eingriffen: LCP-Bild optimieren, render-blockierende Ressourcen entfernen, unnötige Third-Party-Skripte streichen. Einen Neuaufbau braucht man erst, wenn das Theme strukturell gegen Performance arbeitet, also zum Beispiel Dutzende von Skripten lädt, die sich nicht deaktivieren lassen. Die Diagnose zeigt, was wirklich das Problem ist. Das ist der sinnvolle erste Schritt, bevor Geld in Maßnahmen fließt.

Wie oft sollte ich die mobile Performance prüfen?

Nach jeder größeren Änderung: neues Theme, neue Plugin-Installation, neuer Seitentyp, neue Werbeeinbindung. Jede dieser Änderungen kann neue Ressourcen einschleusen. Darüber hinaus lohnt ein monatlicher Blick auf PageSpeed Insights, besonders auf die CrUX-Felddaten. Wenn ein neues Plugin die Seite für echte Nutzer langsamer macht, sieht man es dort nach ein bis zwei Wochen.