Speculation Rules API für WordPress und WooCommerce

Im Jahr 2026 erwarten Nutzer eine Navigation unter 2 Sekunden. Jede zusätzliche Sekunde Ladezeit kostet etwa 4,42% der Conversions (Portent); die kursierenden 7% sind Akamais Zahl und gelten für 100 Millisekunden. Google weiß das und belohnt schnelle Seiten mit besseren Rankings.

Dieser Leitfaden ist keine Theorie. Es ist funktionierender Code und eine Checkliste, die Sie heute auf Ihrer WordPress-Seite oder Ihrem WooCommerce-Shop umsetzen können. Speculation Rules helfen erst, wenn Checkout und Cart Fragments bereits im Griff sind. Wie diese Reihenfolge aussieht, zeigen die Fallstudie zur Wiederherstellung der WooCommerce-Performance und der Leitfaden zur Performance-Optimierung 2026.

#Wie die Ladezeit die Absprungrate beeinflusst

#Absprungrate nach Ladezeit

Quelle: Google und SOASTA, Mobile-Page-Speed-Benchmarks. Die Werte sind der Anstieg der Absprungwahrscheinlichkeit gegenüber einer Sekunde Ladezeit, keine absoluten Absprungraten. Think with Google

Google hat bestätigt: Core Web Vitals sind ein Ranking-Faktor. 2024 wurde FID durch INP (Interaction to Next Paint) ersetzt, eine Metrik, die die Reaktionsfähigkeit der Seite auf Nutzerinteraktionen misst.

#Was wahrgenommene Ladegeschwindigkeit bedeutet

Sie können einen langsamen Server haben (TTFB 800ms), aber wenn der Nutzer Inhalte sofort sieht und die Navigation sich instant anfühlt, ist die wahrgenommene Performance ausgezeichnet.

Genau das macht die Speculation Rules API, sie lädt die nächsten Seiten im Hintergrund vor, bevor der Nutzer klickt.

#JavaScript verzögern, AVIF und TTFB in WordPress

Bevor Sie fortgeschrittene Techniken implementieren, stellen Sie sicher, dass die Grundlagen solide sind.

#JavaScript in functions.php per defer laden

// functions.php - Nicht-kritisches JS verzögern
add_filter('script_loader_tag', function($tag, $handle) {
    $defer_scripts = ['jquery', 'wp-embed', 'comment-reply'];
    if (in_array($handle, $defer_scripts)) {
        return str_replace(' src', ' defer src', $tag);
    }
    return $tag;
}, 10, 2);

#AVIF-Unterstützung in WordPress 6.5+

WordPress 6.5+ unterstützt AVIF nativ. AVIF bietet 20-30% bessere Kompression als WebP.

<img 
  src="produkt.avif" 
  srcset="produkt-400.avif 400w, produkt-800.avif 800w"
  sizes="(max-width: 600px) 400px, 800px"
  loading="lazy"
  decoding="async"
  alt="Produkt"
>

#TTFB unter 200 ms senken

#INP und CLS in WordPress beheben

#INP verbessern durch Aufteilen langer Tasks

INP leidet, wenn der Main Thread blockiert ist. Die üblichen Verursacher:

• Schwere Page Builder (Elementor, Divi)
• Chat-Skripte (Intercom, Zendesk)
• Tracking-Pixel (Facebook, Google Ads)

Lösung: lange Tasks aufteilen

// Lange Tasks in kleinere Abschnitte < 50ms aufteilen
async function longTask(items) {
    for (const item of items) {
        await processItem(item);
        // Main Thread freigeben
        await new Promise(resolve => setTimeout(resolve, 0));
    }
}

#CLS durch Bilder und Anzeigen verhindern

/* Platz für Bilder reservieren */
img {
    aspect-ratio: 16 / 9;
    width: 100%;
    height: auto;
}

/* Platz für Anzeigen reservieren */
.ad-slot {
    min-height: 250px;
}

#Speculation Rules API mit Prefetch und Prerender

Hier liegt der Kern dieses Leitfadens. Die Speculation Rules API ist eine native Browser-Funktion, die das Vorladen von Seiten im Hintergrund ermöglicht.

#Prefetch-Regel für alle internen Links

<script type="speculationrules">
{
  "prefetch": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/wp-admin/*" } },
          { "not": { "href_matches": "*.pdf" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

#Prerender für Warenkorb, Kasse und Produktseiten

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/warenkorb/", "/kasse/"],
      "eagerness": "immediate"
    },
    {
      "source": "document",
      "where": {
        "or": [
          { "href_matches": "/produkt/*" },
          { "selector_matches": ".wichtiger-link" }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

#Prefetch vs. Prerender im Vergleich

#Eagerness-Stufen der Speculation Rules erklärt

• conservative: beim Drücken von Maustaste oder Finger auf den Link, Standard für Document Rules
• moderate: auf dem Desktop nach 200 ms Hover (oder früher beim Drücken auf den Link); auf Mobilgeräten 500 ms nach dem Ende des Scrollens, für große Links in der Nähe des letzten Tippens
• eager: seit Chrome 143 nach 10 ms Hover auf dem Desktop und auf Mobilgeräten 50 ms, nachdem ein Link in den Viewport gelangt
• immediate: sobald der Browser die Regeln liest, Standard für List Rules

Die Zeiten stammen aus dem Chrome-Leitfaden zu Prerender. Vor Chrome 143 verhielt sich eager wie immediate. Ältere Artikel, die eager als “sofort und aggressiv” beschreiben, geben also das frühere Verhalten wieder.

#Spekulatives Laden in WordPress 6.8: Standardverhalten

Seit WordPress 6.8 gehört die Speculation Rules API zum Core. Die Funktion stammt aus dem Plugin Speculative Loading, das vor der Übernahme auf mehr als 50.000 Websites lief. Laut Dev Note des Core-Teams verbesserten Websites mit dem Plugin ihre LCP-Bestehensquote im Median um etwa 1,9%, gemessen mit Daten aus HTTP Archive und CrUX. Dieselbe Notiz nennt mehr als 8% aller Chrome-Navigationen, die bereits Speculation Rules nutzen.

#Standardeinstellungen für spekulatives Laden im WordPress-Core

Ohne weitere Konfiguration gibt der Core im Frontend ein Regelset mit dem Modus prefetch und der Eagerness conservative aus. Beide Werte sind als auto gespeichert, sodass ein künftiges Release ändern kann, wofür auto steht, ohne Ihre Konfiguration zu brechen. Der Prefetch startet, wenn der Nutzer den Zeiger auf einem Link drückt. Das bringt einen kleinen Vorsprung von einigen hundert Millisekunden und kostet kaum verschwendete Anfragen.

In drei Fällen schaltet der Core die Funktion ab:

• für angemeldete Nutzer, damit Toolbar, Vorschauen und Admin-Links nie spekulativ geladen werden,
• auf Websites ohne sprechende Permalinks,
• für URLs mit Query-Parametern, die standardmäßig von Prefetch und Prerender ausgenommen sind.

Die letzte Regel ist für WooCommerce wichtig. Links zum Hinzufügen in den Warenkorb nutzen einen Query-String, daher lädt die Standardkonfiguration sie nie vorab. Ein Plugin, das andere “Aktions-URLs” bereitstellt (GET-Anfragen, die einen Zustand ändern), muss diese trotzdem selbst ausschließen, vor allem wenn Sie die Eagerness erhöhen.

#Spekulatives Laden mit WordPress-Filtern anpassen

Der Core stellt zwei Filter und eine Action bereit. wp_speculation_rules_configuration erhält ein Array mit mode und eagerness oder null, wenn die Spekulation für die Anfrage deaktiviert ist. Gültige Modi sind auto, prefetch und prerender; gültige Eagerness-Werte sind auto, conservative, moderate und eager. immediate wird bewusst abgelehnt, weil davon für Document Rules dringend abgeraten wird.

// Core-Regel auf Prerender bei Hover umstellen
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
    if ( is_array( $config ) ) {
        $config['mode']      = 'prerender';
        $config['eagerness'] = 'moderate';
    }
    return $config;
} );

// Personalisierte Pfade nur vom Prerender ausschließen
add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths, $mode ) {
    if ( 'prerender' === $mode ) {
        $paths[] = '/my-account/*';
    }
    return $paths;
}, 10, 2 );

// Zusätzliche Regel neben der Core-Regel hinzufügen
add_action( 'wp_load_speculation_rules', function ( WP_Speculation_Rules $rules ) {
    $rules->add_rule( 'prerender', 'shop-cart', array(
        'source'    => 'list',
        'urls'      => array( '/cart/' ),
        'eagerness' => 'moderate',
    ) );
} );

Der Filter für ausgeschlossene Pfade erwartet Muster in URL-Pattern-Syntax, relativ zum Frontend der Website, und ein optionales Argument $mode. Die Action wp_load_speculation_rules übergibt Ihnen ein Objekt WP_Speculation_Rules, und add_rule() akzeptiert sowohl List Rules als auch Document Rules mit einer where-Bedingung. Gibt der Konfigurationsfilter null zurück, ist die Spekulation für diese Anfrage abgeschaltet.

#Links mit den Klassen no-prefetch und no-prerender ausschließen

Redakteure können einzelne Links ohne Code ausnehmen. Tragen Sie im Bereich “Erweitert” eines Blocks im Feld für zusätzliche CSS-Klassen no-prefetch ein, um seine Links ganz vom spekulativen Laden auszuschließen, oder no-prerender, um Prefetch zu erlauben, Prerender aber zu blockieren. Weil Prefetch Teil von Prerender ist, deckt no-prefetch beide Modi ab. Das ist die schnellste Lösung, wenn ein einzelnes Widget, etwa ein Buchungskalender, nach einem Prerender Probleme macht.

#Einstellungen des Plugins Speculative Loading im Vergleich zum Core

Das Plugin Speculative Loading des WordPress Performance Teams gibt es weiterhin, und es geht aggressiver vor als der Core. Seine Standardwerte sind Prerender mit Eagerness moderate, sodass eine Seite bereits im Hintergrund gerendert wird, wenn der Nutzer mit der Maus über einen Link fährt. Modus und Eagerness lassen sich unter Einstellungen, Lesen konfigurieren.

Das Plugin warnt, wenn Sie die Spekulation für angemeldete Nutzer ohne persistenten Object Cache aktivieren, denn dann kostet jede spekulativ geladene Seite eine vollständige, ungecachte PHP-Anfrage. Sein Ausschlussfilter heißt plsr_speculation_rules_href_exclude_paths. In einem WooCommerce-Shop mit vielen angemeldeten Besuchern sollte die Spekulation für angemeldete Nutzer aus bleiben, bis ein Object Cache wie Redis läuft.

#Speculation Rules in WordPress einbinden

#Methode 1: Speculation Rules als eigenes Plugin

Ab WordPress 6.8 gibt der Core bereits ein eigenes speculationrules-Skript aus. Ein eigenes Skript in wp_head fügt daneben ein zweites Regelset hinzu. Nutzen Sie diese Methode deshalb nur auf älteren Versionen, oder schalten Sie zuerst die Core-Regel ab, indem wp_speculation_rules_configuration den Wert null zurückgibt. Auf aktuellen Versionen sind die oben gezeigten Filter der sauberere Weg.

<?php
/**
 * Plugin Name: Speculation Rules API
 */
add_action('wp_head', function() {
    if (is_admin()) return;
    ?>
    <script type="speculationrules">
    {
      "prefetch": [
        {
          "source": "document",
          "where": {
            "and": [
              { "href_matches": "/*" },
              { "not": { "href_matches": "/wp-*" } }
            ]
          },
          "eagerness": "moderate"
        }
      ]
    }
    </script>
    <?php
});

#Methode 2: dynamische Regeln für Warenkorb und Paginierung

add_action('wp_head', function() {
    $prerender_urls = [];
    
    // Produkte aus dem Warenkorb prerendern
    if (function_exists('WC') && WC()->cart) {
        foreach (WC()->cart->get_cart() as $item) {
            $prerender_urls[] = get_permalink($item['product_id']);
        }
    }
    
    // Nächste Archivseite prerendern
    if (is_archive() || is_home()) {
        $next_link = get_next_posts_link();
        if ($next_link) {
            preg_match('/href="([^"]+)"/', $next_link, $matches);
            if (!empty($matches[1])) {
                $prerender_urls[] = $matches[1];
            }
        }
    }
    
    if (empty($prerender_urls)) return;
    
    $rules = [
        'prerender' => [[
            'source' => 'list',
            'urls' => array_unique($prerender_urls),
            'eagerness' => 'moderate'
        ]]
    ];
    
    echo '<script type="speculationrules">' . json_encode($rules) . '</script>';
});

#Ergebnisse mit Speculation Rules im WooCommerce-Shop und im Blog

#Fallstudie 1: WooCommerce-Shop (500 Produkte)

Problem: Die Navigation von der Kategorie zum Produkt dauerte mehrere Sekunden

Lösung:

• Prefetch für Links im Viewport
• Prerender für “In den Warenkorb” und “Kasse”

Ergebnis:

• Vorher: mehrere Sekunden Wartezeit
• Nachher: als sofort wahrgenommen
• Bounce Rate: spürbar gesunken

#Fallstudie 2: WordPress-Blog (1000+ Artikel)

Problem: INP außerhalb des grünen Bereichs, Nutzer spürten Verzögerungen

Lösung:

• Alle Skripte per defer laden
• Prerender für “Weiterlesen”
• Object Cache (Redis)

Ergebnis:

• INP: in den grünen Bereich gerückt
• LCP: in den grünen Bereich gerückt
• Organischer Traffic: gewachsen

#Einschränkungen der Speculation Rules und Risiken

#Welche Seiten man nicht prerendern sollte

• Seiten mit Authentifizierung (Login, Nutzerpanel)
• Seiten mit Seiteneffekten (Abonnements, Zahlungen)
• Externe URLs

#Data Saver, Browser-Support und Prerender-Limit

• Data Saver deaktiviert die Spekulation, die vollständige Liste der blockierenden Bedingungen finden Sie weiter unten
• Nicht unterstützende Browser (Firefox und Safari ohne experimentelles Flag) ignorieren die Regeln
• Prerender-Limit: Chrome erlaubt 10 Prerenders für immediate-Regeln und nur 2 für eager, moderate und conservative, wobei der älteste zuerst verworfen wird

#Limits für Speculation Rules in Chrome je Eagerness-Stufe

Chrome begrenzt, wie viele Spekulationen eine Seite gleichzeitig halten darf, und die Grenze hängt von der Eagerness ab. Die Werte unten stammen aus dem Chrome-Leitfaden zu Prerender.

Für die drei interaktionsbasierten Stufen arbeitet die Warteschlange nach dem FIFO-Prinzip: Eine neue Spekulation bricht die älteste ab. Eine abgebrochene URL kann später erneut spekulativ geladen werden, und ihre cachebaren Ressourcen liegen meist noch im HTTP-Cache. Wer ein Skript mit List Rules von der Seite entfernt, macht Kapazität für immediate frei. Das hilft, wenn eine Warenkorb-Regel nach dem Checkout einer anderen Regel weichen soll.

#Wann Chrome Speculation Rules ignoriert

Speculation Rules sind ein Hinweis, und Chrome verwirft sie, wenn:

• der Nutzer Save-Data aktiviert hat,
• der Energiesparmodus aktiv und der Akku schwach ist,
• das Gerät wenig Arbeitsspeicher hat,
• die Einstellung zum Vorabladen von Seiten aus ist, was manche Erweiterungen wie uBlock Origin tun,
• die Seite in einem Hintergrund-Tab geöffnet ist.

Vorgerenderte Seiten halten außerdem Cross-Origin-iframes bis zur Aktivierung zurück, sodass eine eingebettete Karte oder ein Videoplayer erst lädt, wenn der Nutzer auf der Seite ankommt. Speculation Rules innerhalb einer vorgerenderten Seite werden erst nach deren Aktivierung verarbeitet, und Regeln in iframes werden ignoriert.

#Prefetch-Fallback für Browser ohne Unterstützung

if (!HTMLScriptElement.supports?.('speculationrules')) {
    // Fallback: klassischer Prefetch
    document.querySelectorAll('a[href^="/"]').forEach(link => {
        link.addEventListener('mouseenter', () => {
            const prefetch = document.createElement('link');
            prefetch.rel = 'prefetch';
            prefetch.href = link.href;
            document.head.appendChild(prefetch);
        }, { once: true });
    });
}

#WooCommerce-Seiten sicher für Prerender machen

Eine vorgerenderte Seite führt ihr JavaScript aus, bevor der Nutzer sie sieht. Deshalb fühlt sie sich sofort an, und deshalb kann sie einen Shop beschädigen, wenn der Code von einem echten Besuch ausgeht.

#Welche WooCommerce-URLs für Prefetch und Prerender unsicher sind

MDN stuft URLs mit serverseitigen Nebenwirkungen als unsicher für Prefetch und Prerender ein: Abmelden, Sprachwechsel, In den Warenkorb, Versand von Einmal-Codes per SMS, Verbrauch von Kontingenten und Conversion-Tracking für Anzeigen. In einem WooCommerce-Shop betrifft das den Logout-Link unter “Mein Konto”, einen Währungs- oder Sprachumschalter, der als GET-Link umgesetzt ist, und jede eigene “Jetzt kaufen”-URL. Für Prerender sind Seiten zusätzlich unsicher, wenn ihre Skripte clientseitigen Speicher beschreiben, den andere offene Tabs lesen, oder wenn sie Analytics-Daten oder Anzeigenimpressionen senden, bevor der Nutzer die Seite gesehen hat.

Vorgerenderte Seiten können auch veralten. Eine Seite, die vorgerendert wurde, während der Besucher abgemeldet war, zeigt weiterhin die abgemeldete Ansicht, wenn er sich in einem anderen Tab anmeldet. Chrome kann eine per Prefetch geladene Seite etwa fünf Minuten lang vorhalten, der Inhalt kann beim Anzeigen also bis zu diesem Alter haben.

#Spekulativ geladene Seiten nach dem Hinzufügen zum Warenkorb verwerfen

Der Response-Header Clear-Site-Data akzeptiert die Werte prefetchCache und prerenderCache. Auf einer beliebigen Same-Site-Anfrage gesendet, etwa dem AJAX-Aufruf, der ein Produkt in den Warenkorb legt, verwirft er Spekulationen, die vor der Änderung des Warenkorbs entstanden sind. Beim nächsten Hover lädt der Browser dann eine frische Warenkorb- oder Kassenseite, statt die alte anzuzeigen.

// Veraltete Spekulationen verwerfen, nachdem WooCommerce den Warenkorb ändert
add_action( 'woocommerce_add_to_cart', function () {
    if ( ! headers_sent() ) {
        header( 'Clear-Site-Data: "prefetchCache", "prerenderCache"' );
    }
} );

#Spekulative Anfragen auf dem Server erkennen

Chrome kennzeichnet spekulative Anfragen mit dem Request-Header Sec-Purpose. Ein Prefetch sendet Sec-Purpose: prefetch, ein Prerender sendet Sec-Purpose: prefetch;prerender. Jede endgültige Antwort außerhalb des Bereichs 200 bis 299 nach Weiterleitungen stoppt die Spekulation, und die Statuscodes 204 oder 205 stoppen einen Prerender, lassen einen Prefetch aber zu. Einen Fehler zurückzugeben ist der gröbste Weg, die Spekulation für eine Route zu blockieren. MDN empfiehlt stattdessen, die Anfrage zuzulassen und Nebenwirkungen in JavaScript zu verschieben, denn eine blockierte Spekulation ist ein verlorener Geschwindigkeitsgewinn.

#Analytics verzögern, bis eine vorgerenderte Seite angezeigt wird

document.prerendering ist true, solange die Seite im Hintergrund rendert, und das Event prerenderingchange feuert, wenn der Nutzer sie aktiviert. Umschließen Sie damit Analytics, Anzeigenimpressionen und alles andere, was einen echten Seitenaufruf zählen soll:

function initTracking() {
    // Analytics, Anzeigenimpressionen, Chat-Widgets
}

if (document.prerendering) {
    document.addEventListener('prerenderingchange', initTracking, { once: true });
} else {
    initTracking();
}

Mehrere Browser-APIs warten von selbst auf die Aktivierung. Laut MDN liefern Geolocation, Anfragen zur Benachrichtigungsberechtigung, die Registrierung eines Service Workers und der Kamerazugriff ein ausstehendes Promise, bis die Seite angezeigt wird, während alert() sofort zurückkehrt und confirm() den Wert false liefert. Code, der sich beim Laden der Seite auf diese Ergebnisse verlässt, braucht dieselbe Absicherung.

#Browser-Unterstützung für Speculation Rules 2026

Die Versionen stammen aus den Kompatibilitätsdaten von MDN, die die Funktion weiterhin als experimentell und nicht Baseline führen. In der Praxis beschleunigen die Regeln Chromium-Nutzer und bewirken anderswo nichts. Deshalb behandelt der WordPress-Core sie als Progressive Enhancement.

#Speculation Rules mit Content Security Policy nutzen

#Speculation Rules unter einer strikten CSP erlauben

Ein Speculation-Rules-Block ist ein <script>-Element, daher blockiert eine strikte script-src-Richtlinie ihn wie jedes Inline-Skript. MDN nennt drei Wege, ihn zu erlauben: eine Nonce, einen Hash oder das Schlüsselwort 'inline-speculation-rules'. Der Chrome-Leitfaden ergänzt, dass das Schlüsselwort Regeln abdeckt, die über ein Skript mit Hash oder Nonce eingefügt werden. Auf Websites mit strikter CSP werden die Regeln deshalb meist per JavaScript eingefügt. Zeigt das Panel Speculative loads auf einer Website mit Sicherheits-Plugin keine Regeln, prüfen Sie als Erstes den CSP-Header.

#Speculation Rules über den Header Speculation-Rules ausliefern

Regeln können auch in einer JSON-Datei liegen, auf die ein HTTP-Response-Header verweist. So bleiben sie aus dem HTML heraus und umgehen das CSP-Problem. Die URL im Header muss in Anführungszeichen stehen, die Datei muss den MIME-Typ application/speculationrules+json haben, und eine Cross-Origin-Datei muss eine CORS-Prüfung bestehen. Relative URLs in der Datei werden standardmäßig gegen die JSON-Datei aufgelöst. Ergänzen Sie daher "relative_to": "document" in einer Regel, wenn ihre Pfade relativ zur Seite gemeint sind.

Speculation-Rules: "/speculationrules.json"

Regeln aus dem Header und Inline-Regeln werden zu einem Satz zusammengeführt. Chrome 136 hat das Feld tag eingeführt, das im Request-Header Sec-Speculation-Tags mitgesendet wird. So erkennen CDN oder Server, welches Regelset eine Anfrage ausgelöst hat, und können sie anders behandeln.

#Welche Cross-Origin-Spekulationen Chrome erlaubt

Prerender ist standardmäßig auf denselben Origin beschränkt. Eine Subdomain derselben Website, etwa ein Shop auf eigener Subdomain, lässt sich nur prerendern, wenn sie mit dem Header Supports-Loading-Mode: credentialed-prerender antwortet. Cross-Site-Prerender ist gar nicht möglich. Cross-Site-Prefetch funktioniert nur, wenn der Nutzer keine Cookies für die Zielseite hat, was Tracking verhindert. Abgelehnte Spekulationen dieser Art erscheinen in den DevTools im Panel Speculative loads.

#Speculation Rules und Prefetches überwachen

#Tools zum Prüfen spekulativer Ladevorgänge

• Chrome DevTools: das Panel Speculative loads im Tab Application
• Lighthouse CI: automatisierte Performance-Tests
• WebPageTest: echte Tests von verschiedenen Standorten
• DebugBear: Real User Monitoring (RUM)

#Spekulative Treffer in GA4 messen

Resource Timing kennt keinen Initiator-Typ für Spekulationen, daher lässt sich ein spekulativer Ladevorgang auf der auslösenden Seite nicht beobachten. Messen Sie stattdessen auf der Seite, auf der der Nutzer landet: Ein activationStart über null bedeutet, dass die Seite vorgerendert wurde, und ein deliveryType mit dem Wert navigational-prefetch bedeutet, dass sie aus einem Prefetch stammt. Beide Felder sind auf MDN dokumentiert.

// Melden, wie die aktuelle Seite ausgeliefert wurde
const nav = performance.getEntriesByType('navigation')[0];
let delivery = 'normal';
if (nav.activationStart > 0) {
    delivery = 'prerender';
} else if (nav.deliveryType === 'navigational-prefetch') {
    delivery = 'prefetch';
}
gtag('event', 'page_delivery', { delivery_type: delivery });

Vergleichen Sie die Zahl der Treffer für prerender und prefetch mit der Zahl spekulativer Anfragen in Ihren Server-Logs (siehe den Header Sec-Purpose oben). Die Differenz ist die Verschwendung. Chrome misst die Core Web Vitals einer vorgerenderten Seite ab der Aktivierung, nicht ab dem Start des Prerenders, und die Bibliothek web-vitals meldet solche Navigationen ab Version 3.1.0 mit dem navigationType prerender, so der Chrome-Leitfaden zu Prerender. Segmentieren Sie Ihre Felddaten nach diesem Wert, sonst verdeckt der LCP nahe null der vorgerenderten Aufrufe eine langsame normale Navigation.

#Checkliste für Speculation Rules in WordPress

#Vor der Implementierung

• Basis-Lighthouse-Score messen
• TTFB < 200ms prüfen
• Object Cache ist aktiv
• Bilder werden als AVIF ausgeliefert

#Während der Implementierung

• Basis-Prefetch hinzufügen (moderate)
• Heatmaps analysieren (Hotjar, Clarity)
• Top 3 Navigationspfade identifizieren
• Prerender für High-Intent-Links hinzufügen
• Auf 10% Traffic testen (A/B)
• “Verschwendete” Prefetches überwachen

#Nach der Implementierung

• LCP, INP und Navigationszeit vergleichen
• Cache-Trefferquote prüfen
• Langfristig: Bounce Rate, Conversion Rate

#Zusammenfassung

Speculation Rules API bringt 2026 praxisrelevantes Prefetching in Chromium: der Browser kann Routen laden, ohne dass Hosting oder CDN zuerst neu verdrahtet werden müssen. Für Shop-Betreiber fühlt sich das oft wie weniger leere Bildschirme zwischen Klicks an.

Wichtigste Erkenntnisse:

1. Starten Sie mit Prefetch mit moderate Eagerness, das ist sicher
2. Fügen Sie Prerender für den Checkout-Flow im E-Commerce hinzu
3. Metriken überwachen, nicht raten, messen

Professionelle Optimierung gebraucht? Als WordPress-Spezialist helfe ich bei der Beschleunigung von WordPress- und WooCommerce-Seiten. Siehe auch WordPress Geschwindigkeitsoptimierung.