Mobile-First-Performance: Optimierungsstrategien für den mobilen Index 2026

Google indexiert und rankt die mobile Version einer Seite, abgerufen von seinem Smartphone-Crawler. Eine WordPress-Website, die ein Desktop-Layout nur auf Smartphone-Breite zusammenschiebt, kann bei einem kurzen Blick gut aussehen und trotzdem eine schwere, langsame Seite an genau das Gerät schicken, nach dem die Indexierung entschieden wird. Mobile-First-Performance heißt: Jede Seite wird zuerst für ein Smartphone in einem begrenzten Netz gebaut, und für größere Bildschirme kommt nur dort Gewicht hinzu, wo es sich lohnt.

Mehr über WordPress-Geschwindigkeitsoptimierung bei WPPoland, siehe auch unseren Leitfaden zur Geschwindigkeitsoptimierung.

Dieser Leitfaden behandelt, was Googles Mobile-First-Indexierung verlangt, welche Grenzwerte der Core Web Vitals mobil gelten, wie mobile Geschwindigkeit im Labor und im Feld gemessen wird und welche WordPress-Funktionen und Code-Muster LCP, INP, CLS und die Zurück-Navigation auf Smartphones verbessern.

#Zeitleiste der Mobile-First-Indexierung von 2016 bis 2024

Googles Best Practices zur Mobile-First-Indexierung definieren den Begriff in einem Satz: Google verwendet für Indexierung und Ranking die mobile Version der Inhalte einer Website, gecrawlt mit dem Smartphone-Agenten. Bis das gesamte Web so weit war, vergingen acht Jahre.

Im Beitrag vom Oktober 2023 beschrieben John Mueller und Nir Kalush die kleine Gruppe von Websites, die noch beim Desktop-Crawler geblieben war. Die Fehler waren Seiten, die jedem mobilen Nutzer Fehler anzeigen, eine mobile Version, die in der robots.txt gesperrt ist, während die Desktop-Version crawlbar bleibt, und mobile Seiten, die allesamt auf die Startseite weiterleiten. Im Juni 2024 schrieb Mueller, dass eine Website, deren Inhalte mit einem Mobilgerät überhaupt nicht erreichbar sind, nach dem 5. Juli 2024 nicht mehr indexierbar sein würde. Googlebot Desktop taucht für einige Funktionen wie Produkteinträge und Google for Jobs weiterhin in Server-Logs auf. Ein Desktop-User-Agent in Ihrem Access-Log bedeutet also nicht, dass Ihre Website übergangen wurde.

Der “mobile Index 2026” ist daher kein neuer Index. Die Umstellung fand 2023 und 2024 statt. Was sich weiter ändert, sind die Inhalte Ihrer mobilen Seiten und wie schnell sie für echte Besucher sind.

#Was Googles Mobile-First-Dokumentation von WordPress-Websites verlangt

Die Seite mit den Best Practices ist eine Checkliste zur Gleichwertigkeit. Die mobile Version einer Seite sollte der Desktop-Version entsprechen bei:

• dem Hauptinhalt, einschließlich Text, Bildern und Videos
• strukturierten Daten
• dem Title-Element und der Meta-Beschreibung
• Alt-Texten von Bildern
• Robots-Meta-Tags
• Überschriften

Dieselbe Seite warnt davor, primäre Inhalte per Lazy Loading erst nach einer Nutzerinteraktion wie einem Tippen oder Wischen zu laden, weil der Crawler solche Interaktionen nicht ausführt. In WordPress sind die üblichen Verursacher Tabs oder Akkordeons, die ihren Inhalt beim Klick per AJAX nachladen, sowie separate mobile Templates älterer Mobil-Plugins, die Abschnitte, Schema oder Alt-Texte weglassen. Ein responsives Theme, das jedem Gerät dasselbe HTML schickt, besteht die Gleichwertigkeitsprüfung von vornherein. Das ist ein Grund, mit gerätespezifischem HTML vorsichtig zu sein, mehr dazu im Abschnitt zu Client Hints weiter unten.

#Grenzwerte der Core Web Vitals für Mobilgeräte 2026

Die aktuellen Grenzwerte lauten:

Seit März 2024 ist Interaction to Next Paint die Metrik für die Reaktionsfähigkeit. Rick Viscomis Ankündigung auf web.dev führte INP als stabilen Core Web Vital anstelle von First Input Delay ein und gab Entwicklern bis zum 9. September 2024 Zeit, von FID umzusteigen. Ein Leitfaden, der FID noch als Core Web Vital nennt, stammt aus der Zeit vor dieser Änderung.

Jeder Grenzwert wird am 75. Perzentil der Seitenaufrufe bewertet, getrennt nach Mobilgeräten und Desktop (web.dev, Web Vitals). Mobil und Desktop sind getrennte Grundgesamtheiten, ein schnelles Desktop-Ergebnis sagt also nichts über das Ergebnis auf dem Smartphone aus.

Viele Teams setzen interne Ziele unterhalb der Grenze für “gut”, um Spielraum zu haben, denn Felddaten verschieben sich mit dem Traffic-Mix, mit Kampagnen und mit Skripten von Drittanbietern. Googles eigene Dokumentation zur Nutzerfreundlichkeit von Seiten fügt eine Warnung hinzu: Einer perfekten Punktzahl nur aus SEO-Gründen hinterherzujagen, ist möglicherweise nicht die beste Verwendung Ihrer Zeit.

#Wie Google Signale zur Nutzerfreundlichkeit im Ranking verwendet

Googles Dokumentation zur Nutzerfreundlichkeit von Seiten beantwortet die Ranking-Frage direkt:

• Es gibt kein einzelnes Signal für die Nutzerfreundlichkeit. Die zentralen Ranking-Systeme betrachten eine Vielzahl von Signalen.
• Core Web Vitals werden von Googles Ranking-Systemen verwendet.
• Über die Core Web Vitals hinaus helfen andere Aspekte der Nutzerfreundlichkeit einer Website nicht direkt zu einem besseren Ranking, auch wenn sie die Nutzung angenehmer machen.
• Die Nutzerfreundlichkeit wird in der Regel pro Seite bewertet, mit einigen websiteweiten Bewertungen.
• Google zeigt auch bei schwacher Nutzerfreundlichkeit die relevantesten Inhalte. Eine gute Nutzerfreundlichkeit hilft dort, wo viele Seiten ähnlich hilfreich sind.

Für die mobile Arbeit setzt das Prioritäten. Die Größe der Touch-Ziele, ein aufgeräumtes mobiles Menü und die bfcache-Fähigkeit lohnen sich für Besucher und für die Core Web Vitals, die sie beeinflussen, aber Google beschreibt sie nicht als eigene Ranking-Signale. Dieselbe Seite nennt keine AMP-Pflicht: Ihre Selbstprüfung umfasst Core Web Vitals, HTTPS, die Darstellung auf Mobilgeräten, Werbung, aufdringliche Interstitials und einen klar erkennbaren Hauptinhalt.

#Wie Sie mobile Geschwindigkeit im Labor und im Feld testen

#Einstellungen der mobilen Emulation in Lighthouse

Der Standard-Mobillauf von Lighthouse emuliert ein Moto G Power (2022) mit einem Viewport von 412 mal 823 Pixeln, festgelegt in den Konfigurationskonstanten von Lighthouse. Die Dokumentation zur Drosselung nennt als Netzwerkprofil 150 ms Latenz, 1,6 Mbit/s Download und 750 Kbit/s Upload, bezeichnet als “Slow 4G” und beschrieben als ungefähr das unterste Viertel der 4G-Verbindungen. Die CPU-Drosselung nutzt einen konstanten Faktor 4, der einen leistungsstarken Desktop-Rechner in die Klasse der Mittelklasse-Smartphones verschieben soll. Auf einem langsameren Laptop schießt dieser Faktor über das Ziel hinaus. Prüfen Sie deshalb den Wert “CPU/Memory Power” unten im Bericht, bevor Sie Läufe von verschiedenen Rechnern vergleichen.

• Lighthouse (Chrome DevTools): mobile Emulation mit CPU- und Netzwerkdrosselung
• PageSpeed Insights: echte Nutzerdaten (CrUX) plus ein Lighthouse-Laborlauf
• WebPageTest: Tests auf echten Geräten an verschiedenen Standorten

#Felddaten aus CrUX und Search Console

Felddaten sind das, was die Bewertung der Core Web Vitals verwendet. Die CrUX-Methodik erfasst nur Daten von Chrome-Nutzern, die das Senden von Nutzungsstatistiken aktiviert haben und ihren Browserverlauf synchronisieren, und Chrome unter iOS ist ausgeschlossen. Safari ist kein Chrome und trägt daher ebenfalls nichts bei. Eine Website, deren mobile Besucher überwiegend iPhones nutzen, erhält ihren mobilen Feldwert von ihren Android-Besuchern.

• Chrome User Experience Report (CrUX): Daten echter Chrome-Nutzer
• Google Search Console (Bericht zu Core Web Vitals): Gruppen für Mobilgeräte und Desktop zu Ihren eigenen URLs
• RUM (Real User Monitoring): Tools wie SpeedCurve, Calibre oder New Relic für kontinuierliches Monitoring über alle Browser hinweg

#Auf welchen echten Smartphones Sie testen sollten

Kein Emulator bildet ein echtes Gerät vollständig nach. Halten Sie mindestens diese Geräte zum Testen bereit:

• ein Smartphone der Mittelklasse (Moto G oder Samsung Galaxy A)
• ein aktuelles High-End-Smartphone (iPhone oder Pixel)
• ein Tablet (iPad oder Samsung Tab)

#Adaptives Laden nach Gerät in WordPress

Adaptives Laden liefert dieselbe Seite in unterschiedlichem Gewicht aus, je nachdem, was das Gerät des Besuchers bewältigen kann.

#Wie Sie Gerätefähigkeiten mit JavaScript erkennen

// Gerätefähigkeiten erkennen, mit Standardwerten, wo eine API fehlt
const getDeviceCapabilities = () => {
  return {
    // CPU-Kerne
    cores: navigator.hardwareConcurrency || 4,
    // Ungefährer Gerätespeicher in GB (nicht in jedem Browser verfügbar)
    memory: navigator.deviceMemory || 4,
    // Effektiver Verbindungstyp
    connection: navigator.connection?.effectiveType || '4g',
    // Präferenz für reduzierte Datennutzung
    saveData: navigator.connection?.saveData || false,
  };
};

MDN kennzeichnet navigator.deviceMemory als eingeschränkt verfügbar, nicht als Baseline, nur über HTTPS verfügbar und bewusst ungenau: Der Wert wird auf eine Zweierpotenz gerundet, um Fingerprinting zu erschweren. Behandeln Sie ihn als Hinweis mit einem sicheren Standardwert. Für die Wahl des Bildformats ist gar keine Erkennung nötig, denn das unten gezeigte picture-Element lässt den Browser selbst zwischen AVIF und WebP wählen.

#Was High-End-, Mittelklasse- und Einsteiger-Smartphones bekommen

Auf Basis der erkannten Fähigkeiten:

High-End-Geräte (8+ Kerne, 8+ GB RAM, schnelle Verbindung):

• AVIF-Bilder in voller Qualität
• vollständiges JavaScript mit Animationen
• breiteres Speculative Loading wahrscheinlicher Folgeseiten
• Videohintergründe, wo sie dem Inhalt dienen

Mittelklasse-Geräte (4 bis 6 Kerne, 4 bis 6 GB RAM, 4G):

• Bilder in mittlerer Qualität
• reduziertes JavaScript, einfache CSS-Animationen
• Speculative Loading nur für Hauptlinks
• statische Bilder statt Videohintergründen

Einsteiger-Geräte (2 bis 4 Kerne, unter 4 GB RAM, langsame Verbindung oder Save-Data):

• stark komprimierte Bilder
• nur unverzichtbares JavaScript
• kein Speculative Loading, um Bandbreite zu sparen
• ein vereinfachtes Layout ohne visuelle Effekte

#Client Hints, Accept-CH und Seiten-Caching in WordPress

Mit Client Hints kann der Server dieselbe Entscheidung treffen, bevor er das HTML sendet. Der Browser schickt sie nicht von sich aus. Laut MDN-Leitfaden zu Client Hints kündigt der Server in einem Accept-CH-Response-Header an, welche Hints er haben möchte, und der Browser fügt sie bei nachfolgenden Anfragen hinzu. Der erste Seitenaufruf eines neuen Besuchers kommt deshalb ohne sie an. Nur die Hints mit niedriger Entropie (Save-Data, Sec-CH-UA, Sec-CH-UA-Mobile und Sec-CH-UA-Platform) dürfen standardmäßig gesendet werden. Der Gerätespeicher wird als Sec-CH-Device-Memory übertragen, die Netzwerkqualität als ECT, RTT und Downlink.

// 1. Den Browser bei späteren Anfragen um Geräte- und Netzwerk-Hints bitten
add_action('send_headers', function () {
    header('Accept-CH: Sec-CH-Device-Memory, ECT');
    header('Vary: Sec-CH-Device-Memory', false);
});

// 2. Die Hints auslesen und eine Performance-Stufe wählen
function device_aware_content_strategy() {
    $memory = isset($_SERVER['HTTP_SEC_CH_DEVICE_MEMORY'])
        ? (float) $_SERVER['HTTP_SEC_CH_DEVICE_MEMORY']
        : null;

    $ect = $_SERVER['HTTP_ECT'] ?? null;

    if ($memory && $memory >= 8 && $ect === '4g') {
        define('WP_DEVICE_TIER', 'high');
    } elseif (($memory && $memory <= 2) || in_array($ect, ['slow-2g', '2g'], true)) {
        define('WP_DEVICE_TIER', 'low');
    } else {
        define('WP_DEVICE_TIER', 'medium');
    }
}
add_action('init', 'device_aware_content_strategy');

Am Caching scheitert die serverseitige Anpassung meistens. Ein Full-Page-Cache-Plugin oder ein CDN speichert eine Kopie des HTML pro URL, sofern der Cache-Schlüssel den Hint nicht enthält. Ohne ihn wird die für den ersten Besucher gewählte Stufe allen nachfolgenden ausgeliefert. MDN empfiehlt, die Hints, die eine Antwort verändern, im Vary-Header aufzuführen, und warnt, dass Hints mit vielen möglichen Werten wie Downlink und RTT eine Antwort praktisch nicht cachebar machen. Für die meisten WordPress-Websites ist die sicherere Aufteilung, das HTML für jedes Gerät identisch zu halten, srcset und sizes die Bilddateien wählen zu lassen und JavaScript auf dem Client anzupassen. So bleibt auch die Gleichwertigkeit der Inhalte erhalten, die Googles Mobile-First-Dokumentation verlangt.

#Wie Sie den mobilen LCP verbessern

Largest Contentful Paint ist auf Mobilgeräten meist die am schwersten zu verbessernde Metrik, weil sie gleichzeitig vom Netzwerk, von der CPU und von der Größe der Inhalte abhängt.

#Welches Element auf Mobilgeräten das LCP-Element ist

Auf den meisten WordPress-Seiten ist das mobile LCP-Element eines der folgenden:

• das Hero- oder Beitragsbild
• ein Bannerbild in einem Slider
• auf Seiten ohne Bilder der erste lange Textblock

#LCP-Teilbereiche und wohin die Zeit geht

Der web.dev-Leitfaden zur LCP-Optimierung zerlegt die Metrik in vier Teilbereiche: Time to First Byte, Ladeverzögerung der Ressource (von TTFB bis der Browser die LCP-Ressource zu laden beginnt), Ladedauer der Ressource und Renderverzögerung des Elements (vom Ende des Downloads bis das Element vollständig gerendert ist). Laut dem Budget des Leitfadens sollte der größte Teil der Zeit auf das Laden des HTML-Dokuments und der LCP-Ressource entfallen, jeweils etwa 40 Prozent, während jede der beiden Verzögerungen unter 10 Prozent bleibt. Eine lange Ladeverzögerung der Ressource bedeutet fast immer, dass der Browser das Bild spät gefunden hat. Derselbe Leitfaden nennt ein als CSS-Hintergrund gesetztes LCP-Bild als Fall, den der Preload-Scanner im HTML nicht finden kann, und rät, das LCP-Bild nie per Lazy Loading zu laden.

#Wie Sie LCP mit Preload, Format und Bildgröße beschleunigen

LCP-Ressource vorladen:

<link rel="preload" as="image" href="/images/hero-mobile.avif"
      type="image/avif" fetchpriority="high">

Erkennungsketten entfernen: Der Browser sollte die LCP-Ressource so früh wie möglich finden:

1. Das HTML wird heruntergeladen (TTFB)
2. Die LCP-Ressource wird im HTML erkannt
3. Der Download der Ressource beginnt

Wenn Ihr Hero-Bild in einem externen Stylesheet als background-image referenziert ist, entdeckt der Browser es erst, nachdem er das CSS heruntergeladen und geparst hat. Setzen Sie stattdessen ein <img> direkt ins HTML, mit fetchpriority="high".

Optimales Bildformat:

<picture>
  <source srcset="/images/hero-400.avif 400w,
                  /images/hero-800.avif 800w"
          type="image/avif" sizes="100vw">
  <source srcset="/images/hero-400.webp 400w,
                  /images/hero-800.webp 800w"
          type="image/webp" sizes="100vw">
  <img src="/images/hero-800.jpg"
       alt="Passende Beschreibung"
       width="800" height="450"
       fetchpriority="high"
       decoding="async">
</picture>

Bildgrößen speziell für Mobilgeräte: Schicken Sie Smartphones und Desktops nicht dieselbe Datei. Ein 400 Pixel breiter Smartphone-Bildschirm braucht kein 1920 Pixel breites Bild (mehr dazu in unserem Leitfaden zu Bildoptimierung und Critical CSS):

// Bildgrößen für mobile Layouts hinzufügen
function add_mobile_image_sizes() {
    add_image_size('mobile-hero', 480, 270, true);
    add_image_size('mobile-thumbnail', 320, 180, true);
}
add_action('after_setup_theme', 'add_mobile_image_sizes');

#WordPress-Kernfunktionen für responsive Bilder und Lazy Loading

Ein großer Teil der oben beschriebenen Bildarbeit steckt bereits im WordPress-Kern, und ein Plugin, das sie wiederholt, kann stören.

• WordPress 4.4 (2015): srcset und sizes. Joe McGills Dev Note erklärt, dass WordPress dem von ihm erzeugten Bild-Markup srcset und sizes hinzufügt, damit der Browser die passendste Größe herunterladen kann. Der Standardwert für sizes geht davon aus, dass das Bild in seiner eigenen Breite bis maximal zur vollen Viewport-Breite angezeigt wird, und die Note rät Themes, ihn mit dem Filter wp_calculate_image_sizes anzupassen (wp_calculate_image_srcset ändert die Kandidatenliste). Der Filter max_srcset_image_width begrenzt die einbezogenen Breiten, standardmäßig auf 1600 Pixel. Mit derselben Version kam die Größe medium_large hinzu, 768 Pixel breit ohne Höhenbegrenzung, die nur für neue Uploads oder beim Neugenerieren der Größen erzeugt wird.
• WordPress 5.5: natives Lazy Loading. Das Attribut loading wird über wp_lazy_loading_enabled gesteuert, eingeführt in 5.5 und seit 5.7 standardmäßig auch für iframes aktiviert.
• WordPress 6.3: Attribute zur Ladeoptimierung. wp_get_loading_optimization_attributes entscheidet, ob ein Bild loading="lazy", fetchpriority="high" oder decoding="async" erhält. Bereits vorhandene Attribute lässt die Funktion unverändert, und sie gibt eine Warnung aus, wenn ein Element sowohl Lazy Loading als auch hohe Priorität bekäme. Seit 7.0 akzeptiert sie außerdem fetchpriority="low" und fetchpriority="auto", sodass kein Lazy Loading hinzugefügt wird.

Die praktische Prüfung erfolgt im gerenderten HTML einer echten Seite im Smartphone-Viewport: Das Hero-Bild sollte fetchpriority="high" tragen und kein loading="lazy", und sein sizes-Wert sollte dem Platz entsprechen, den das Bild im mobilen Layout tatsächlich einnimmt. Ein Theme, das das Hero-Bild als CSS-Hintergrund ausgibt, umgeht all das.

#Speculative Loading in WordPress 6.8

WordPress 6.8 hat Speculative Loading über die Speculation Rules API des Browsers aktiviert. Felix Arntz’ Dev Note beschreibt die Standardeinstellungen:

• Es ist im Frontend aller Websites aktiviert, außer für angemeldete Nutzer und für Websites mit deaktivierten sprechenden Permalinks.
• URLs werden mit der Eagerness-Stufe conservative vorab abgerufen, die auslöst, wenn ein Nutzer beginnt, auf einen Link zu klicken.
• URLs mit Query-Parametern werden automatisch ausgeschlossen, was die meisten “Aktions-URLs” abdeckt, die bei einer GET-Anfrage einen Zustand ändern.
• Chrome, Edge und Opera unterstützen die API; andere Browser ignorieren sie, es geht also nichts kaputt.

Die Note berichtet, dass das Feature-Plugin vor der Übernahme in den Kern auf über 50.000 Websites lief und dass Websites, die es nutzten, ihre LCP-Bestehensquote im Median um etwa 1,9 Prozent verbesserten, gemessen mit Daten von HTTP Archive und CrUX. Auf Mobilgeräten, wo Tippen auf Zurück, Vor und Links das gesamte Navigationsmodell ausmacht, zählt das mehr als auf dem Desktop. Plugins mit eigenen Aktionspfaden, etwa einem Warenkorb, sollten diese ausschließen:

add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $href_exclude_paths ) {
    $href_exclude_paths[] = '/cart/*';
    return $href_exclude_paths;
} );

#Wie Sie den mobilen INP verbessern

INP misst, wie schnell die Seite auf Nutzereingaben reagiert. Der INP-Artikel auf web.dev zählt drei Interaktionstypen: Mausklicks, Tippen auf einem Touchscreen und Tastendrücke auf einer physischen oder Bildschirmtastatur. Hovern, Zoomen und Scrollen werden nicht erfasst. Die Latenz jeder Interaktion besteht aus drei Teilen: der Eingabeverzögerung, bevor ein Handler läuft, der Verarbeitungszeit der Handler und der Darstellungsverzögerung, bis der nächste Frame gezeichnet ist. Auf einem Smartphone ist jede Interaktion ein Tippen, und die CPU ist langsamer, also wachsen alle drei Teile.

#Hauptursachen für schlechten mobilen INP

1. Schweres JavaScript im Main Thread: Skripte von Drittanbietern (Analytics, Chat, Werbung), die Interaktionen blockieren.
2. Framework-Hydration: React, Vue oder Angular hydrieren Komponenten nach dem ersten Laden.
3. Aufwendige Event-Handler: Listener, die beim Tippen schwere Berechnungen ausführen.
4. Lange Tasks: Der web.dev-Leitfaden zur Optimierung langer Tasks definiert einen langen Task als jeden Task, der länger als 50 ms dauert.

#Wie Sie INP durch verzögertes JavaScript senken

Nicht kritisches JavaScript verzögern:

<!-- Analytics nach der ersten Nutzerinteraktion laden -->
<script>
  let analyticsLoaded = false;
  function loadAnalytics() {
    if (analyticsLoaded) return;
    analyticsLoaded = true;
    const script = document.createElement('script');
    script.src = '/analytics.js';
    document.head.appendChild(script);
  }

  // Beim ersten Tippen, Scrollen oder Tastendruck laden, sonst nach 5 Sekunden
  ['touchstart', 'scroll', 'keydown'].forEach(event => {
    document.addEventListener(event, loadAnalytics, { once: true, passive: true });
  });
  setTimeout(loadAnalytics, 5000);
</script>

requestIdleCallback für nicht dringende Arbeit nutzen:

// Nicht kritische Arbeit ausführen, während der Browser untätig ist
requestIdleCallback((deadline) => {
  while (deadline.timeRemaining() > 0) {
    processNonCriticalTask();
  }
});

In Event-Handlern die Kontrolle abgeben:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

button.addEventListener('click', async () => {
  showSpinner();        // sichtbares Feedback im nächsten Frame
  await yieldToMain();  // den Browser zuerst zeichnen lassen
  heavyCalculation();   // der langsame Teil läuft in einem späteren Task
});

Die schwere Arbeit in requestAnimationFrame zu verpacken, hilft nicht, weil dieser Callback unmittelbar vor dem nächsten Zeichnen läuft und den Frame trotzdem aufhält. Das Abgeben der Kontrolle teilt die Arbeit auf, sodass der Browser zuerst die Reaktion auf das Tippen zeichnen kann. Der Leitfaden zu langen Tasks weist darauf hin, dass scheduler.yield() in Chrome und Edge 129 sowie Firefox 142 unterstützt wird, nicht aber in Safari. Deshalb gibt es den Fallback mit setTimeout.

#Wie Sie mobilen CLS in WordPress verhindern

Cumulative Layout Shift (CLS) schadet auf dem Smartphone am meisten, weil der Bildschirm klein ist und jede Bewegung auffällt. Auf einem Smartphone stört eine Verschiebung um 10 Pixel weit mehr als auf einem 27-Zoll-Monitor.

#Was auf Mobilgeräten CLS verursacht

• Bilder ohne explizite Abmessungen
• Webfonts, die FOUT oder FOIT auslösen
• Werbung und dynamisch eingefügte Inhalte
• Navigationsleisten, die beim Scrollen ihre Größe ändern
• die Bildschirmtastatur, die Inhalte verschiebt

#Wie Sie Platz für Bilder, Schriften und Werbung reservieren

Platz für Bilder reservieren:

/* Boxen mit Seitenverhältnis für Bilder */
.wp-post-image {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
  object-fit: cover;
}

Kritische Schriften vorladen:

<link rel="preload" href="/fonts/main-font.woff2"
      as="font" type="font/woff2" crossorigin>

/* font-display: swap mit einer metrisch angepassten Ersatzschrift */
@font-face {
  font-family: 'MainFont';
  src: url('/fonts/main-font.woff2') format('woff2');
  font-display: swap;
  size-adjust: 98%;
  ascent-override: 95%;
  descent-override: 22%;
}

Platz für Werbung reservieren:

.ad-slot {
  min-height: 250px; /* Erwartete Höhe der Anzeige */
  background: #f5f5f5;
  contain: layout;
}

#Wie Sie WordPress-Seiten bfcache-fähig machen

Der Back/Forward Cache hält einen vollständigen Schnappschuss einer Seite im Speicher, einschließlich des JavaScript-Heaps, sodass die Zurück-Navigation ihn fast sofort wiederherstellt, ohne das Netzwerk zu berühren. Der bfcache-Leitfaden auf web.dev von Philip Walton und Barry Pollard zitiert Chrome-Nutzungsdaten, nach denen auf Mobilgeräten jede fünfte Navigation eine Zurück- oder Vor-Navigation ist, auf dem Desktop jede zehnte. Alle großen Browser haben einen bfcache, Chrome seit Version 96.

#Was den bfcache blockiert

• unload-Listener. Auf dem Desktop machen Chrome und Firefox eine Seite mit einem unload-Listener ungeeignet. Auf Mobilgeräten versuchen Chrome und Safari weiterhin, solche Seiten zu cachen, der Handler wird dann aber unzuverlässig. Verwenden Sie stattdessen pagehide; Lighthouse hat ein Audit no-unload-listeners, das auch Code von Drittanbietern erfasst.
• Cache-Control: no-store für das HTML. Browser haben solche Seiten bisher nicht in den bfcache aufgenommen. Für Inhalte, die aktuell bleiben müssen, aber nicht sensibel sind, empfiehlt der Leitfaden no-cache oder max-age=0, die die Eignung nicht beeinträchtigen.
• window.opener-Referenzen. Eine Seite, die mit window.open() geöffnet und von ihrem Opener gesteuert wird, kann nicht gecacht werden. rel="noopener" verhindert das und ist inzwischen der Browser-Standard für target="_blank".
• Offene Verbindungen. Manche Browser überspringen Seiten mit einer offenen IndexedDB-Verbindung, einem laufenden fetch() oder XMLHttpRequest oder einer offenen WebSocket- oder WebRTC-Verbindung. Der Leitfaden merkt an, dass Chrome (ab Version 149) und Safari bei offenen WebSockets nicht mehr blockieren. Schließen Sie Verbindungen bei pagehide und öffnen Sie sie bei pageshow wieder.

Mobile Nutzer navigieren ständig mit dem Zurück-Button. Kommt eine Seite aus dem bfcache zurück, erscheint sie ohne neue Anfrage.

#Wie Sie prüfen, ob eine Seite aus dem bfcache wiederhergestellt wurde

// Prüfen, ob die Seite aus dem bfcache wiederhergestellt wurde
window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('Page restored from bfcache');
    // Dynamische Inhalte wie die Anzahl im Warenkorb bei Bedarf aktualisieren
    refreshDynamicContent();
  }
});

Der Leitfaden empfiehlt außerdem, veraltete oder sensible Daten bei pageshow zu aktualisieren, wenn persisted wahr ist, etwa eine Warenkorbsumme, nachdem der Nutzer sie auf einer anderen Seite geändert hat.

#WordPress-Einstellungen für den bfcache

// Cache- und Policy-Header vor jeder Ausgabe senden
add_action('send_headers', function () {
    if (!is_user_logged_in()) {
        header('Cache-Control: public, max-age=300');
        // Unload-Handler ablehnen, auch die von Drittanbietern
        header('Permissions-Policy: unload=()');
    }
});

// Ein Plugin-Skript entfernen, das bekanntermaßen einen Unload-Handler registriert
add_action('wp_enqueue_scripts', function () {
    wp_dequeue_script('plugin-with-unload-handler');
}, 99);

Header gehören in send_headers, weil wp_enqueue_scripts innerhalb von wp_head läuft, also nachdem die Ausgabe begonnen hat. Die Zeile mit der Permissions Policy folgt dem Rat des bfcache-Leitfadens für Websites, die unload überhaupt nicht verwenden. Chrome DevTools bietet im Bereich Application einen Test für den Back/Forward Cache, der den genauen Grund nennt, warum eine Seite blockiert wird.

#Touch-Ziele und mobile Menüs, die sich leicht antippen lassen

Touch-Ziele sind für Bedienbarkeit und Barrierefreiheit wichtig. Google beschreibt sie nicht als Ranking-Signal.

#Mindestgröße für Touch-Ziele

• WCAG 2.2, Erfolgskriterium 2.5.8 (Stufe AA): Das Understanding-Dokument verlangt Zeigerziele von mindestens 24 mal 24 CSS-Pixeln, mit Ausnahmen für Abstände, ein gleichwertiges Bedienelement, Ziele im Fließtext, Bedienelemente des User Agents und unverzichtbare Fälle. Für wichtige Bedienelemente verweist es auf das strengere Kriterium 2.5.5 Target Size (Enhanced).
• Lighthouse-Hinweise zu Tap-Zielen: Die Audit-Dokumentation besagt, dass Ziele von 48 mal 48 Pixeln nie durchfallen und 8 Pixel Abstand zwischen Zielen ein guter Ausgangspunkt sind.

Die Ausnahme für Ziele im Fließtext ist für CSS wichtig. Links innerhalb von Absätzen brauchen keine Mindesthöhe, wenden Sie die Größenvorgaben also nur auf Navigation, Buttons und Formularelemente an:

/* Mindestgröße für Touch-Ziele bei Bedienelementen, nicht bei Links im Text */
nav a, button, input, select, textarea, .wp-block-button__link {
  min-height: 48px;
  min-width: 48px;
  padding: 12px;
}

#Wie Sie ein mobiles Menü leicht antippbar machen

Mobile Navigationsmenüs brauchen bei Touch-Zielen besondere Sorgfalt:

.mobile-nav a {
  display: block;
  padding: 16px 24px;
  min-height: 48px;
  font-size: 16px; /* Ohne Zoomen lesbar */
  line-height: 1.5;
}

.mobile-nav li + li {
  border-top: 1px solid #eee;
}

#Optimierung der mobilen Core Web Vitals bei WPPoland

Bei WPPoland bauen wir für das Gerät in der Hand des Nutzers, nicht für den Monitor auf unserem Schreibtisch.

1. Adaptives Laden: Wir halten das HTML auf allen Geräten identisch und passen Bilder und Skripte dort an, wo die Messungen einen Gewinn zeigen.
2. Mobile Audits: Wir testen auf echten Mobilgeräten, nicht nur in der Browser-Emulation.
3. Felddaten zuerst: Wir arbeiten mit dem mobilen CrUX-Bericht und bringen URL-Gruppen von “Schlecht” oder “Verbesserungswürdig” auf “Gut”.

#Häufige Fragen zur mobilen Performance

1. Brauche ich mit einer mobilen App keine schnelle mobile Website? Doch. Der Großteil Ihres Traffics kommt weiterhin über Suchmaschinen und Links aus sozialen Medien. Ist Ihre mobile Website langsam, gehen Besucher, bevor sie den Link zu Ihrer App überhaupt sehen.
2. Ist Dynamic Serving besser als Responsive Design? In der Praxis ist die Antwort oft ein Hybrid. HTML und CSS bleiben responsiv und für jedes Gerät identisch, während Bilddateien, JavaScript und nicht kritische Funktionen an Gerät und Verbindung angepasst werden.
3. Welches LCP-Ziel gilt 2026 für Mobilgeräte? Der Grenzwert für “gut” liegt bei 2,5 s am 75. Perzentil der mobilen Seitenaufrufe. Zielen Sie mit so viel Abstand darunter, dass eine Woche mit einer schwereren Kampagne die Seite nicht über die Grenze schiebt.

#Fazit

Google crawlt und indexiert das Web als Smartphone, seit die Umstellung 2023 und 2024 abgeschlossen wurde. Mobile Performance-Arbeit für WordPress läuft heute auf wenige messbare Punkte hinaus: dieselben Inhalte auf jedem Gerät, ein LCP-Bild, das der Browser im HTML findet, kurze Tasks rund um jedes Tippen, reservierter Platz für alles, was spät lädt, und Seiten, die der bfcache halten kann. Messen Sie diese Punkte in CrUX für Ihre mobilen Besucher, prüfen Sie sie mit Lighthouse in einem gedrosselten Profil und beheben Sie jede Core-Web-Vitals-Metrik in dieser Reihenfolge. Speziell zu INP finden Sie mehr im Leitfaden zur INP-Optimierung.

Wenn Ihre mobilen Core Web Vitals Ihr Ranking ausbremsen, kontaktieren Sie WPPoland für ein mobiles Audit.