Rendu préalable des règles de spéculation jusqu'à l'origin trial du script

Publié le 23 janvier 2026

Chrome lance une nouvelle phase d'évaluation de l'origine à partir de Chrome 144 pour l'ajout de prerender until script à l'API Speculation Rules. Cet essai d'origine permet aux sites de tester la nouvelle fonctionnalité avec de vrais utilisateurs. L'objectif est de tester la fonctionnalité sur le terrain et de fournir des commentaires à l'équipe Chrome pour l'aider à la façonner et à décider si nous devons l'ajouter à la plate-forme Web.

Quel problème cette fonctionnalité vise-t-elle à résoudre ?

L'API Speculation Rules permet de lancer le chargement des pages avant que les utilisateurs n'y accèdent. Cela peut améliorer les futurs chargements de page en effectuant une partie ou la totalité du travail à l'avance. Jusqu'à présent, il autorisait deux types de spéculations : la prélecture et le prérendu.

La prélecture ne récupère que le document HTML. Cela permet d'obtenir cette première ressource essentielle à l'avance, ce qui améliore les performances lorsqu'un utilisateur accède à une URL. Il ne charge aucune sous-ressource (par exemple, CSS, JavaScript ou images) et n'exécute pas JavaScript. Le navigateur peut donc encore avoir beaucoup de travail à faire lors du chargement des pages.

Le prérendu fait bien plus. Il récupère les sous-ressources et commence à afficher la page et à exécuter JavaScript, presque comme si la page était ouverte dans un onglet en arrière-plan masqué. Lorsque l'utilisateur clique sur le lien, il peut obtenir une navigation instantanée si le navigateur a terminé tout le travail nécessaire pour afficher la page.

L'option de prérendu est potentiellement beaucoup plus performante, mais elle entraîne des coûts d'implémentation et de ressources supplémentaires. Si vous n'y prêtez pas attention, cela peut également entraîner des effets secondaires inattendus lorsque vous prérendrez complètement une page avant qu'un utilisateur n'y accède. Par exemple, Analytics peut se déclencher avant qu'un utilisateur n'ait navigué, ce qui fausse les statistiques si le fournisseur Analytics ne tient pas compte des spéculations.

Les sites qui utilisent le prérendu doivent également veiller à ne pas proposer aux utilisateurs une page obsolète. Par exemple, si vous spéculez sur une page d'un site d'e-commerce, puis ajoutez un article à votre panier, puis chargez la page précédemment spéculée, vous pouvez voir l'ancienne quantité dans le panier si le site ne prend pas de précautions supplémentaires pour s'assurer qu'elle est mise à jour.

Ces complications existent également pour la prélecture si une partie de cette gestion de l'état se produit côté serveur, mais elles sont souvent plus problématiques pour le prérendu. Il peut être plus compliqué d'utiliser le prérendu sur des sites plus complexes.

Cependant, les développeurs nous ont indiqué qu'ils constataient déjà des gains de performances grâce au préchargement des pages et qu'ils souhaitaient aller plus loin avec les règles de spéculation pour en bénéficier davantage. C'est là qu'intervient prerender until script.

Qu'est-ce que prerender until script ?

prerender until script est une nouvelle approche intermédiaire entre la prélecture et le prérendu. Il précharge le document HTML (comme le fait la prélecture), puis commence à afficher la page, y compris en récupérant toutes les sous-ressources (comme le fait le prérendu). Toutefois, et c'est un point essentiel, le navigateur évitera d'exécuter les éléments <script> (pour les scripts intégrés et les scripts src). Lorsqu'il rencontre une balise <script> bloquante, il met en pause l'analyseur et attend que l'utilisateur accède à la page avant de continuer. En attendant, le scanner de préchargement peut continuer et récupérer les sous-ressources nécessaires à la page afin qu'elles soient prêtes à être utilisées lorsque la page pourra continuer à se charger.

En retenant les éléments <script> bloquants, vous évitez une grande partie de la complexité de l'implémentation. En même temps, en lançant le processus de rendu et en récupérant les sous-ressources, on obtient un gain énorme par rapport au préchargement, potentiellement presque autant que pour un prérendu complet.

Dans le meilleur des cas (lorsqu'il n'y a aucun script sur la page), cette option prérend la page entière. De même, lorsqu'une page ne comporte que des éléments de script dans le pied de page ou uniquement des scripts avec des attributs async ou defer, elle est prérendue entièrement sans ce code JavaScript. Même dans le pire des scénarios (lorsqu'un script bloquant se trouve dans <head>), le début du rendu de la page, et en particulier le préchargement des sous-ressources, devraient entraîner un chargement de page beaucoup plus rapide.

Comment utiliser prerender until script ?

Commencez par activer la fonctionnalité, puis prerender until script est utilisé de la même manière que les autres options de l'API Speculation Rules avec une nouvelle clé prerender_until_script (notez les traits de soulignement pour en faire un nom de clé JSON valide).

Vous pouvez l'utiliser avec des règles de liste d'URL statiques :

<script type="speculationrules">
{
  "prerender_until_script": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Il peut également être utilisé avec des règles liées à un document où les URL à spéculer sont disponibles sous forme de liens sur la page :

<script type="speculationrules">
{
  "prerender_until_script": [{
    "where": { "href_matches": "/*" }
  }]
}
</script>

prerender until script peut ensuite être utilisé avec les options habituelles de l'API Speculation Rules, y compris les différentes valeurs d'empressement.

Comme JavaScript ne s'exécutera pas, document.prerendering ne pourra pas être lu, pas plus que l'événement prerenderingchange. Toutefois, la durée activationStart sera non nulle.

L'exemple suivant montre comment déployer l'exemple précédent avec un préchargement de remplacement pour les navigateurs qui ne sont pas compatibles avec prerender_until_script :

<script type="speculationrules">
{
  "prerender_until_script": [{
    "where": { "href_matches": "/*" }
  }],
  "prefetch": [{
    "where": { "href_matches": "/*" }
  }]
}
</script>

Chrome gérera cette duplication sans problème et exécutera la règle la plus appropriée pour chaque paramètre d'empressement.

Vous pouvez également les utiliser avec différents niveaux d'empressement pour précharger de manière anticipée, puis passer à prerender until script avec plus de signaux comme suggéré précédemment avec la prélecture/le prérendu :

<script type="speculationrules">
{
  "prefetch": [{
    "where": { "href_matches": "/*" },
    "eagerness": "eager"
  }],
  "prerender_until_script": [{
    "where": { "href_matches": "/*" },
    "eagerness": "moderate"
  }]
}
</script>

Notez que vous ne pouvez pas mettre à niveau un prerender until script vers un prérendu complet de cette manière, mais faites-le nous savoir si vous souhaitez que Chrome prenne en charge ce modèle en ajoutant une étoile à ce bug.

Tout le JavaScript est-il mis en veille ?

Non, seul l'élément <script> entraîne la mise en veille du parseur. Cela signifie que les gestionnaires de script intégrés (par exemple, onload) ou les URL javascript: n'entraînent pas de pause et peuvent s'exécuter.

Par exemple, cela peut enregistrer Hero image is now loaded dans la console avant d'accéder à la page :

<img src="hero.jpg"
     onload="console.log('Hero image is now loaded!')"
     alt="Example Photo">

En revanche, si l'écouteur d'événements est ajouté avec un <script>, Hero image is now loaded ne sera pas consigné dans la console tant que la page n'aura pas été activée :

<img src="hero.jpg" id="hero-image" alt="Example Photo">
<script>
  const heroImage = document.querySelector('#hero-image');
  if (heroImage.complete) {
        console.log('Hero image is now loaded');
  } else {
    heroImage.addEventListener('load',
      (event) => {
        console.log('Hero image is now loaded');
      }
    );
  }
</script>

Cela peut sembler contre-intuitif, mais dans de nombreux cas (comme dans l'exemple précédent), il est probablement préférable d'agir immédiatement, car le report de l'action peut entraîner des complications plus inattendues.

De plus, la plupart des événements intégrés nécessitent une action de l'utilisateur (par exemple, onclick, onhover) et ne seront donc pas exécutés tant que l'utilisateur ne pourra pas interagir avec la page.

Enfin, les scripts de blocage précédents mettront en pause l'analyseur et empêcheront ainsi la découverte des gestionnaires d'événements intégrés. Ainsi, le message ne sera pas chargé dans la console tant que l'événement ne sera pas activé, même s'il s'agit d'un gestionnaire d'événements intégré :

<script>...</script>
<img src="hero.jpg"
     onload="console.log('Hero image is now loaded!')"
     alt="Example Photo">

Cela est particulièrement pertinent pour les gestionnaires de scripts intégrés qui utilisent du code défini précédemment et qui continueront de fonctionner comme prévu :

<script>
imageLoadFunction() = {
   ...
}
</script>
<img src="hero.jpg" onload="imageLoadFunction" alt="Example Photo">

Qu'en est-il des scripts avec les attributs async et defer ?

Les scripts avec les attributs async et defer sont retardés jusqu'à l'activation, mais n'empêchent pas l'analyseur de continuer à traiter le reste de la page. Les scripts sont téléchargés, mais ne sont pas exécutés tant que l'utilisateur n'accède pas à la page.

Comment activer prerender until script ?

prerender until script est une nouvelle option sur laquelle nous travaillons. Elle est susceptible d'être modifiée. Vous ne pouvez donc pas l'utiliser sans l'activer au préalable.

Les développeurs peuvent l'activer en local à l'aide de l'indicateur Chrome chrome://flags/#prerender-until-script ou de l'indicateur de ligne de commande --enable-features=PrerenderUntilScript.

prerender until script est également disponible en tant que phase d'évaluation de l'origine à partir de Chrome 144. Les versions d'essai des origines permettent aux propriétaires de sites d'activer une fonctionnalité sur leurs sites pour que les utilisateurs réels puissent l'utiliser sans avoir à l'activer manuellement. Cela permet de mesurer l'impact de la fonctionnalité sur les utilisateurs réels pour s'assurer qu'elle fonctionne comme prévu.

Testez-la et faites-nous part de vos commentaires

Nous sommes ravis de cette proposition d'ajout à l'API Speculation Rules et nous encourageons les propriétaires de sites à la tester.

Partagez vos commentaires sur la proposition dans le dépôt GitHub. Pour nous faire part de vos commentaires sur l'implémentation de Chrome, signalez un bug Chromium.