La Speculation Rules API : rendre le clic sur le CTA d’une landing page vraiment instantané

Un visiteur clique sur le bouton d’appel à l’action d’une landing page — « Réserver une démo », « Rejoindre la liste d’attente », « Voir les tarifs » — et le navigateur affiche un instant la page précédente pendant que la suivante se charge. Quelques centaines de millisecondes, rarement plus d’une seconde : rien qui ferait fuir un visiteur déterminé, mais assez pour introduire une micro-hésitation exactement au moment où elle coûte le plus cher, juste après la décision de cliquer. Réduire ce délai à zéro n’est plus une question de bande passante depuis quelques années : c’est une question d’API navigateur, et la Speculation Rules API de Chrome en est aujourd’hui l’outil le plus abouti.

Ce que Next.js précharge déjà, et ce qu’il ne précharge pas

Le composant <Link> de Next.js précharge automatiquement, dès qu’un lien entre dans le viewport, les données de la route ciblée (le payload React Server Components, ou le segment statique mis en cache). C’est déjà un gain réel : au moment du clic, le navigateur n’a plus besoin d’aller chercher ces données sur le réseau. Mais ce préchargement s’arrête là — il ne construit pas la page dans un onglet invisible, n’exécute pas le JavaScript côté client, ne peint rien à l’écran. Au clic, il reste l’hydratation, l’exécution des scripts et le rendu final à faire, dans le temps qui sépare le clic de l’affichage. Pour une navigation interne classique entre deux pages d’une même application Next.js, l’écart est déjà faible. Il devient sensible dès que la page cible est plus lourde à hydrater, ou qu’elle sort du périmètre que Next.js peut préparer à l’avance — une page de paiement hébergée sur un autre domaine, par exemple.

Ce qu’ajoute la Speculation Rules API

La Speculation Rules API permet de déclarer, dans un bloc <script type="speculationrules">, une liste d’URL que Chrome doit prérendre en arrière-plan : la page cible est chargée, son JavaScript s’exécute, elle est peinte — exactement comme si elle était ouverte dans un onglet invisible. Au clic, le navigateur se contente de « faire apparaître » cet onglet déjà prêt à la place de l’ancien, ce qui donne une navigation perçue comme instantanée, sans le délai habituel de chargement. C’est le successeur direct de l’ancien (et aujourd’hui abandonné) <link rel="prerender">, avec un contrôle beaucoup plus fin sur quand et sur quoi déclencher le prérendu.

Pourquoi ce délai compte particulièrement sur une landing page

Une étude de Fiona Fui-Hoon Nah, publiée en 2004 dans la revue Behaviour & Information Technology (disponible sur Google Scholar), a mesuré le temps d’attente que les internautes tolèrent avant qu’une page leur semble lente : environ deux secondes en l’absence de tout signal de chargement, un seuil qui s’allonge quand un indicateur de progression est présent. Le résultat compte particulièrement ici parce qu’une landing page est, par construction, à un seul clic de sa conversion — la page de réservation d’une démo, la confirmation d’inscription à une liste d’attente, l’écran de paiement. C’est précisément la navigation où ce seuil de tolérance se joue, et celle qu’un prérendu ciblé peut faire passer sous le seuil de perception plutôt que de simplement la raccourcir.

Deux niveaux de déclenchement, deux niveaux de risque

• « moderate » (au survol ou au pointerdown) : le prérendu ne se déclenche que lorsque le visiteur montre une intention réelle de cliquer — la souris survole le lien, ou le doigt touche l’écran avant le relâchement. C’est le réglage le plus sûr pour une landing page : le nombre de pages prérendues pour rien reste faible, et le gain de temps couvre déjà l’essentiel du délai perçu.
• « eager » (dès l’apparition du lien à l’écran) : le prérendu démarre dès que le bouton d’appel à l’action entre dans le viewport, sans attendre un signal d’intention. Le gain de temps est maximal si le visiteur clique effectivement, mais le coût en bande passante et en requêtes serveur inutiles grimpe vite si beaucoup de visiteurs ne cliquent jamais — à réserver aux pages où le taux de clic sur ce lien précis est déjà connu comme élevé.

Le prérendu spéculatif n’est pas gratuit

L’idée de deviner à l’avance ce qu’un visiteur va demander pour le lui servir plus vite n’est pas nouvelle : dès 1995, une étude d’Azer Bestavros, présentée à la conférence ACM CIKM et consacrée à la spéculation pour réduire la charge serveur et le temps de service sur le Web (disponible sur Google Scholar), posait déjà le compromis central de toute stratégie de préchargement prédictif : anticiper une requête que le visiteur ne fera finalement jamais consomme de la bande passante et des ressources serveur pour rien, et ce coût grandit avec le nombre de pages spéculées. Sur une landing page, ce compromis se traduit concrètement : chaque URL ajoutée aux règles de spéculation est une page potentiellement chargée, exécutée et rendue en pure perte si le visiteur ne clique pas — d’où l’intérêt de limiter la liste au strict chemin de conversion plutôt que de spéculer sur l’ensemble des liens de la page.

L’implémenter sur une landing page Next.js

Concrètement, un bloc de règles de spéculation s’ajoute directement dans le <head> généré par app/layout.tsx, ciblant uniquement l’URL de la prochaine étape de conversion :

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["/checkout", "/merci"],
    "eagerness": "moderate"
  }]
}
</script>

Le support navigateur reste, à ce jour, limité à Chrome, Edge et Opera (les navigateurs à moteur Chromium) — Safari et Firefox ignorent silencieusement ce bloc, sans erreur ni régression. C’est une amélioration progressive au sens strict : les visiteurs sur un navigateur qui ne la comprend pas retombent simplement sur le comportement normal, prefetch Next.js compris. Elle prend d’autant plus son sens quand la page ciblée par le CTA sort du périmètre que Next.js peut déjà précharger lui-même — une page de paiement hébergée sur un domaine tiers, ou une page statique servie hors de l’application.

Les pièges à connaître avant de l’activer

• Une page prérendue peut exécuter des scripts de tracking avant même d’être vue. Un pixel Meta ou un événement GA4 placé au chargement de la page se déclenche dès le prérendu, pas au clic réel — ce qui peut gonfler artificiellement les statistiques si beaucoup de prérendus ne sont jamais activés. La bonne pratique consiste à écouter l’événement prerenderingchange pour ne déclencher le tracking qu’au moment où la page devient réellement visible.
• Une page avec un effet de bord au chargement (génération d’un jeton unique, appel API qui modifie une donnée) ne doit jamais être ajoutée aux règles de spéculation sans revoir ce comportement : le prérendu peut exécuter ce code plusieurs fois, ou pour des visiteurs qui ne concrétisent jamais la navigation.
• Chrome respecte déjà le mode économie de données (Data Saver, en-tête Save-Data) et désactive de lui-même le prérendu spéculatif pour les visiteurs concernés — un garde-fou intégré qui limite le risque de gaspiller la connexion mobile d’un visiteur en 3G, mais qui ne dispense pas de garder la liste des URL ciblées volontairement courte.

Sur les dix templates React/Next.js LanderKit, ce réglage a le plus de sens sur la seule URL qui compte réellement : celle vers laquelle pointe le bouton d’appel à l’action principal — la page de démonstration du template SaaS Waitlist, une confirmation d’inscription, ou une page de paiement. Le gain se cumule avec les optimisations réseau déjà en place : notre article sur preconnect et preload couvre la préparation des connexions vers des domaines tiers, tandis que le TTFB et le LCP restent les indicateurs à surveiller pour vérifier que l’effet se mesure vraiment en production, et pas seulement en théorie. Le déploiement lui-même est couvert dans notre guide sur Next.js et Vercel.