# Speculation-Rules en en-tête : des règles de préchargement sans balise inline

> Déclarer les règles de Speculative Loading via un en-tête HTTP Speculation-Rules plutôt qu'une balise script inline permet d'appliquer une politique identique à toutes les pages depuis un CDN.

- Auteur : WordPress Développement
- Publié le : 2026-10-12
- Mis à jour le : 2026-09-30
- Catégorie : Performance
- URL : https://www.wpmoderne.fr/performance/speculation-rules-en-tete/

## L’essentiel

- La balise script type=speculationrules reste posée par page, l'en-tête s'applique en amont depuis le serveur ou le CDN
- L'en-tête pointe vers une ressource JSON externe plutôt que d'embarquer les règles inline
- Le support reste limité aux navigateurs basés sur Chromium à ce jour

Comparons deux façons de déployer la même politique de préchargement anticipé sur un site à plusieurs milliers de pages : poser une balise `<script type="speculationrules">` dans chaque gabarit de page rendu par WordPress, ou déclarer une seule fois cette politique en amont, au niveau du serveur ou d'un CDN, via un en-tête HTTP qui s'applique uniformément à toute réponse sans qu'aucun code PHP n'ait besoin de générer la balise correspondante.

## Ce que propose l'en-tête Speculation-Rules

La Speculation Rules API, à l'origine de la fonctionnalité de Speculative Loading intégrée nativement à WordPress depuis la version 6.8, permet de déclarer des règles indiquant au navigateur quelles pages précharger ou pré-rendre par anticipation, en fonction de motifs d'URL ou d'un score de probabilité de navigation. La méthode d'origine consiste à insérer directement dans le document une balise `<script type="speculationrules">` contenant ces règles au format JSON.

Les navigateurs basés sur Chromium supportent également une méthode alternative : un en-tête de réponse HTTP nommé `Speculation-Rules`, qui ne contient pas les règles elles-mêmes mais une référence vers une ressource externe qui les héberge :

```
Speculation-Rules: "https://exemple.fr/regles-speculation.json"
```

Le fichier JSON référencé suit exactement la même structure que le contenu qui serait autrement placé dans la balise inline :

```
{
  "prefetch": [
    {
      "source": "document",
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ]
}
```

## Pourquoi passer par un CDN plutôt que par le cœur WordPress

> L'essentiel à retenir : La balise script type=speculationrules reste posée par page, l'en-tête s'applique en amont depuis le serveur ou le CDN ; L'en-tête pointe vers une ressource JSON externe plutôt que d'embarquer les règles inline ; Le support reste limité aux navigateurs basés sur Chromium à ce jour

La fonctionnalité native de WordPress 6.8 génère la balise inline directement dans le code source de chaque page, avec une configuration ajustable via les réglages du site ou des filtres dédiés. Cette approche reste parfaitement adaptée à la majorité des sites, où PHP a déjà la main sur la génération de la page.

L'intérêt de l'en-tête HTTP se révèle dans une architecture différente, où une part significative des pages est servie directement depuis le cache d'un CDN sans repasser par WordPress à chaque requête. Dans ce contexte, ajouter une balise inline à chaque page nécessiterait soit de régénérer le cache de chaque page pour y insérer la balise, soit de renoncer à ce niveau de mise en cache pour permettre à PHP d'intervenir sur chaque réponse. L'en-tête HTTP, lui, peut être ajouté directement au niveau de la configuration du CDN ou du serveur, sur toutes les réponses sans exception, indépendamment de ce que PHP a généré, y compris sur une réponse entièrement servie depuis un cache statique :

```
# Exemple Nginx : ajouter l'en-tête sur toute réponse HTML servie
location / {
    add_header Speculation-Rules '"https://exemple.fr/regles-speculation.json"';
}
```

Cette centralisation présente un autre avantage pratique : une seule mise à jour du fichier JSON référencé propage instantanément la nouvelle politique à toutes les pages du site, sans nécessiter la moindre invalidation du cache de page lui-même, puisque l'en-tête reste indépendant du contenu HTML mis en cache.

## Ce qu'il faut vérifier avant de généraliser cette approche

Le support de cet en-tête reste, à ce jour, limité aux navigateurs basés sur Chromium, exactement comme pour la balise inline d'ailleurs : la Speculation Rules API dans son ensemble n'est pas encore universellement implémentée. Cette limite ne disqualifie pas la fonctionnalité, mais impose de la considérer comme une amélioration progressive, sans effet négatif pour les navigateurs qui l'ignorent simplement.

Un second point de vigilance concerne le fichier JSON référencé lui-même : il doit être servi avec un type de contenu cohérent et rester accessible publiquement, sans authentification, puisque c'est le navigateur qui va directement le récupérer. Une erreur de configuration sur ce fichier (une réponse 404, ou un type de contenu incorrect) rend l'en-tête inopérant sans qu'aucune erreur visible n'apparaisse dans le rendu de la page elle-même.

- Réserver l'en-tête aux architectures où une part significative des pages est servie sans repasser par PHP à chaque requête
- Vérifier que le fichier JSON référencé reste accessible publiquement et sans en-tête d'authentification
- Ne pas dupliquer la balise inline de WordPress 6.8 en même temps que l'en-tête sur la même page, pour éviter des règles contradictoires
- Garder une eagerness modérée plutôt que conservative sur un site à fort trafic, pour ne pas précharger des pages jamais visitées

> Une règle de préchargement posée une fois au niveau du CDN évite de la régénérer à chaque publication d'article, ce qu'une balise inline imposerait mécaniquement.

## Une alternative d'échelle, pas une fonctionnalité concurrente

L'en-tête Speculation-Rules ne remplace pas la configuration native de Speculative Loading intégrée au cœur de WordPress, il en propose une variante mieux adaptée aux architectures fortement mises en cache en amont du serveur applicatif. Le choix entre les deux méthodes dépend directement de l'endroit où se situe le goulot d'étranglement pour appliquer une politique uniforme : dans le rendu PHP de chaque page, ou dans la configuration du CDN qui sert la majorité du trafic sans jamais solliciter WordPress.