Publié le 23 janvier 2026
Chrome lance une nouvelle é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 réellement. Cela peut améliorer les futurs chargements de page en effectuant une partie ou la totalité du travail à l'avance. Jusqu'à présent, il permettait 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.
Mais le prérendu ne s'arrête pas là. Il récupère les sous-ressources, puis 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 ait réellement accédé. Par exemple, Analytics peut se déclencher avant qu'un utilisateur 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é du 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 le prérendu jusqu'au script.
Qu'est-ce que le prérendu jusqu'au script ?
La prévisualisation jusqu'au script est une nouvelle approche intermédiaire entre la prélecture et la prévisualisation. 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 à l'emploi 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, le gain par rapport au préchargement est énorme, 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 entièrement prérendue sans ce code JavaScript. Même dans le pire des scénarios (lorsqu'il existe un script bloquant dans <head>), le début du rendu de la page, et en particulier le préchargement des sous-ressources, devrait entraîner un chargement de page beaucoup plus rapide.
Comment utiliser le script de prérendu jusqu'à ?
Commencez par activer la fonctionnalité, puis prérendez jusqu'à ce que le script soit 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 au prérendu jusqu'au 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 prérendu jusqu'au script vers un prérendu complet de cette manière. Toutefois, si ce modèle vous intéresse, ajoutez une étoile à ce bug pour nous le faire savoir.
Tout le code 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. Le message ne sera donc 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 le prérendu jusqu'au script ?
L'option "Prérendu jusqu'au script" est une nouvelle option sur laquelle nous travaillons. Elle est donc susceptible d'être modifiée. Pour l'utiliser, vous devez d'abord l'activer.
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.
La fonctionnalité de prérendu jusqu'au script est également disponible en tant qu'essai Origin Trial à 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.