Speculation Rules : limites de prefetch et prerender

BotBrowser peut répéter un contexte autorisé et enregistrer les résultats visibles d'une navigation, mais il ne prétend pas activer, forcer ou mesurer Speculation Rules dans une version donnée. La décision utile est plus étroite : utiliser prefetch lorsqu'une réponse future peut être récupérée sans effet indésirable, et prerender seulement si le document caché peut être créé, activé ou abandonné sans opération irréversible. Le navigateur décide l'éligibilité et le cycle de vie ; l'application fournit l'indication et un repli normal.

TL;DR

• prefetch prépare une réponse possible ; prerender crée un document caché qui pourra être activé. Aucune indication ne garantit une récupération ou un rendu.
• L'éligibilité dépend de la règle, de l'URL, de l'origine, de la politique, des ressources et de l'implémentation. Une correspondance ne prouve pas une requête.
• L'activation rend le document spéculatif visible. Un abandon peut arriver avant elle ; l'initialisation doit donc rester réversible.
• Identifiants, cookies, stockage, analytique, médias, WebSockets et écritures délimitent les effets. Les cibles spéculatives doivent être en lecture seule.
• Un fixture synthétique peut enregistrer entrée, intention, activation et abandon sans prétendre qu'un navigateur l'a exécuté.

Contents

• Prefetch et prerender ne promettent pas la même chose
• L'éligibilité est une décision du navigateur
• Activation et abandon forment un cycle
• Identifiants, effets et limites de confidentialité
• Fixture copiable et relevé borné
• Choisir le repli selon la limite observée
• Limite de capacité de BotBrowser
• Conclusion pratique

Prefetch et prerender ne promettent pas la même chose

L'API Speculation Rules de MDN décrit un format JSON pour les navigations probables. Le navigateur peut récupérer une cible ou construire un document caché, sans envoyer à la page une confirmation synchrone. Une règle ne transforme donc pas un lien en navigation garantie.

prefetch demande surtout une récupération pouvant être placée dans le cache. Le document ne devient pas actif parce que des octets ont été reçus. URL, en-têtes, politique, identifiants ou état modifiés peuvent empêcher la réutilisation.

prerender peut créer un contexte caché, charger la cible et exécuter une initialisation limitée avant une éventuelle activation. La documentation Chrome sur le prerender décrit l'activation ou le rejet de cette page. Ce n'est ni un onglet visible ni un worker autorisé à lancer des écritures.

Indication	Action possible du navigateur	Hypothèse permise	Cible sûre
prefetch	Récupérer une ressource candidate	Rien avant la navigation réelle	Document cacheable et en lecture seule
prerender	Construire un document caché	Il peut ne jamais devenir visible	Shell avec écritures différées
Aucune	Naviguer à la demande	Cycle normal	Flux avec intention explicite

Prefetch consomme surtout réseau et cache ; prerender consomme aussi CPU, mémoire et initialisation. Évitez-le pour une commande, un achat, un socket, un courriel ou un jeton à usage unique. Le guide mesurer les performances du navigateur aide à distinguer une marque temporelle de l'activation : une marque cachée ne prouve pas une visite.

L'éligibilité est une décision du navigateur

La spécification WICG Speculation Rules définit la forme des règles et les conditions examinées par l'agent utilisateur. href_matches, selector_matches et eagerness alimentent un algorithme ; ils ne fournissent pas le motif complet d'un refus.

<script type="speculationrules">
  {
    "prefetch": [
      {
        "where": { "href_matches": "/docs/*" },
        "eagerness": "moderate"
      }
    ],
    "prerender": [
      {
        "where": { "selector_matches": "a[data-prerender]" },
        "eagerness": "conservative"
      }
    ]
  }
</script>

Une correspondance peut être écartée par une politique, une pression de ressources, une origine ou une syntaxe partiellement prise en charge. DNS, TLS, redirections ou changement d'état peuvent aussi invalider le résultat. Notez la source de règle, la classe d'URL, les en-têtes, la version, les conditions réseau et le repli, plutôt qu'un verdict universel.

Le guide Navigation API et historique rappelle qu'une URL visible ne prouve pas une visite humaine. Le guide des contextes sécurisés ajoute le contrôle préalable avant de demander une capacité puissante. Une requête spéculative ne doit donc pas déclencher une conversion ni une analytique de page vue.

Activation et abandon forment un cycle

Conservez quatre états : déclaré, éligible, activé et abandonné. Déclaré signifie que le JSON existe ; éligible signifie que le navigateur considère la cible ; activé signifie navigation visible ; abandonné signifie rejet, expiration ou remplacement sans activation. L'état éligible ne prouve pas une récupération.

L'activation est le moment des écritures, de la personnalisation persistante, de l'analytique et des intégrations. L'abandon est normal si une personne choisit un autre lien, si le réseau tombe ou si la mémoire manque. Nettoyez les minuteries et les handles de façon idempotente, sans traiter le cas comme une erreur visible.

État	Preuve qu'un fixture peut conserver	Interprétation dangereuse
Déclaré	Empreinte JSON et classe d'URL	La règle est acceptée
Éligible	Diagnostic, s'il existe	La requête a eu lieu
Activé	Navigation visible ou événement d'application	L'initialisation n'a eu lieu qu'une fois
Abandonné	Cible rejetée ou expirée	La personne a refusé

Les événements peuvent se croiser. Utilisez un identifiant synthétique de fixture et séparez la phase cachée de la phase visible pour les workers et service workers. Le contenu essentiel doit fonctionner même sans signal portable d'activation.

Identifiants, effets et limites de confidentialité

Cookies, cache, autorisation, client hints, referrer policy et service workers influencent la réponse. Le comportement exact dépend de l'origine, du mode d'identifiants, de la politique et du navigateur. Ne mettez jamais un compte réel ou un jeton de production dans le fixture.

Séparez les routes de lecture et d'écriture. Un shell public est plus adapté qu'une URL qui modifie un panier ou consomme un jeton ; même GET peut avoir un effet serveur. L'autorisation et l'idempotence restent des décisions du serveur.

Un document prerenderisé peut envoyer une télémétrie avant d'être visible. Retardez l'analytique irréversible jusqu'à la navigation visible. Le guide prévenir les fuites DNS explique pourquoi les recherches auxiliaires ont leur propre chemin ; prefetch et prerender doivent aussi figurer dans la politique réseau déclarée.

Employez test-user-17, order-synthetic-42 et un récepteur possédé par l'équipe. Rédigez les en-têtes et paramètres lors de la capture, limitez la conservation et définissez un responsable de suppression.

Fixture copiable et relevé borné

Ce fixture est déclaratif : il ne prouve ni acceptation, ni téléchargement, ni activation.

<script type="speculationrules">
  {
    "prefetch": [
      {
        "urls": ["/fixture/read-only-shell.html"],
        "eagerness": "immediate"
      }
    ],
    "prerender": [
      {
        "urls": ["/fixture/activation-shell.html"],
        "eagerness": "conservative"
      }
    ]
  }
</script>
<a href="/fixture/read-only-shell.html" data-case="prefetch">Read-only shell</a>
<a href="/fixture/activation-shell.html" data-case="prerender">Activation shell</a>
<output id="speculation-status">not observed</output>

{
  "fixture": "speculation-boundary-v1",
  "candidate": "/fixture/activation-shell.html",
  "hint": "prerender",
  "browser": "declared product, version, channel, and OS",
  "policy": "response and permissions policy revision",
  "credentials": "synthetic, no account cookie",
  "declared": true,
  "eligible": "unknown until a run records it",
  "activated": "unknown until a visible navigation records it",
  "abandoned": "unknown until the lifecycle ends",
  "observed": null,
  "fallback": "ordinary navigation remains available",
  "dataClass": "synthetic"
}

Testez un shell en lecture seule et une cible qui ne fait qu'afficher un marqueur d'activation. Une URL absente peut vérifier que le lien normal reste utilisable, mais son absence ne prouve pas un blocage. Une exécution réelle doit ajouter version, politique, résultat et raison d'abandon dans une preuve contrôlée.

Choisir le repli selon la limite observée

Situation	Décision	Motif
Cible cacheable en lecture seule	Préférer prefetch ou navigation normale	Coût et effets réduits
Shell avec écritures différées	Envisager prerender prudent	Initialisation réversible
Mutation au chargement	Ne pas prerender	Le rejet peut déjà agir
Identifiants sensibles avant activation	Navigation et autorisation explicites	Limite de divulgation
Support ou politique inconnus	Garder le lien normal	Une indication n'est pas une garantie

Comparez règle, réponse finale, URL, origine, mode d'identifiants, version et politique avant de modifier la règle. WICG, MDN et Chrome décrivent syntaxe et limites, mais ne constituent pas une mesure pour une version arbitraire.

Limite de capacité de BotBrowser

BotBrowser peut ouvrir un profil autorisé, répéter un contexte déclaré et exposer le résultat d'un fixture appartenant à l'équipe. Il ne peut pas forcer l'éligibilité, activer un prerender, lire une décision privée du navigateur ni garantir l'absence de requête chez un tiers. La documentation des fonctions avancées de BotBrowser n'annonce pas d'implémentation Speculation Rules.

Un résultat futur doit rester limité au profil, à la version, au système, à la politique et à la révision du fixture. Une page chargée ne prouve pas que tous les candidats étaient éligibles. Ne faites pas de la spéculation un moyen de contourner autorisation, consentement, confidentialité ou limites fournisseur.

FAQ

Prefetch signifie-t-il une visite ?

Non. La réponse peut être récupérée sans navigation visible puis abandonnée. Comptez une visite seulement après activation.

Prerender est-il toujours plus rapide ?

Non. Il peut réduire le travail visible, mais consomme davantage de mémoire, CPU et initialisation, et peut être rejeté.

Une requête spéculative peut-elle utiliser des identifiants ?

Elle dépend des règles d'identifiants, d'origine, de cache et du worker de service. Utilisez des valeurs synthétiques ou aucune valeur.

Quand envoyer l'analytique ?

Après confirmation de la navigation visible, afin de ne pas compter un document abandonné.

Que faire si l'éligibilité est inconnue ?

Garder le lien normal et marquer le résultat non vérifié. Le contenu requis ne dépend pas de la spéculation.

Sources

• Spécification WICG Speculation Rules
• MDN : Speculation Rules API
• Chrome : Prerender pages
• BotBrowser : Advanced features

Conclusion pratique

Choisissez prefetch pour une réponse en lecture seule tolérant une récupération anticipée ; choisissez prerender uniquement pour un document caché qui peut être activé ou abandonné sans écriture irréversible. L'éligibilité appartient au navigateur, l'activation établit l'intention visible et la requête spéculative reste une activité candidate. Les identifiants, écritures et analyses attendent une autorisation explicite.

L'action sûre consiste à placer le fixture sur une origine contrôlée, conserver les liens normaux et enregistrer séparément déclaré, éligible, activé et abandonné. Un essai futur décrira une version précise ; il ne prouvera pas un support universel ni ne fera de BotBrowser une implémentation Speculation Rules.