Le prefetching au niveau du navigateur existe depuis des années. <link rel="prefetch"> date des années 2010, les librairies façon quicklink préchargent les liens qui entrent dans le viewport, et la plupart des frameworks modernes embarquent une version de « survolez un lien, démarrez le chargement ». Tout ça est utile, et rien de tout ça n’est ce que fait Foresight. La différence est plus grande qu’elle n’en a l’air.

Ce que fait le prefetching heuristique

Le prefetching basé sur le viewport ou le survol suit une seule règle : si un lien est visible, ou si un curseur en est proche, c’est un signal à exploiter. Il coûte peu à implémenter et fonctionne bien sur des pages où la plupart des liens ont autant de chances d’être cliqués, comme un index de blog ou un menu de navigation simple.

Il s’effondre dès que la page se complique.

Il précharge ce qui est à l’écran et ignore ce que veut le visiteur. Une page produit avec 40 liens vers des articles liés précharge les 40 quand ils sont tous dans le viewport, et les visiteurs n’en cliquent que quelques-uns. L’appareil de chaque visiteur dépense de la bande passante pour deviner juste sur une poignée d’entre eux.

Il n’a aucune mémoire de vos schémas de trafic. Il ne peut pas savoir que les visiteurs qui arrivent sur votre page de tarifs depuis une campagne publicitaire précise convertissent sur une page suivante précise dans 60% des cas. Il voit « lien, viewport, prefetch ».

Il passe mal à l’échelle. Plus de liens à l’écran signifie plus de requêtes de prefetch simultanées, qui concurrencent les ressources dont la page actuelle a encore besoin pour finir de s’afficher. Un prefetching heuristique agressif peut ralentir la page où vous êtes en essayant d’accélérer celle où vous n’êtes pas.

Ce que fait différemment un modèle entraîné

Foresight pose une autre question : parmi les visiteurs qui se sont déjà trouvés exactement dans cette situation (même page d’entrée, même source de trafic, même parcours de navigation jusqu’ici), où sont-ils allés ensuite ?

L’heuristique ne peut pas y répondre, parce que la réponse demande un comportement historique, et la proximité d’un curseur n’en contient aucun. Foresight s’entraîne sur vos données de navigation GA4 vers BigQuery pour trouver, pour un contexte de visiteur donné, la page suivante la plus probable, et il ne la précharge que si sa probabilité justifie la bande passante.

La différence se voit dans ce que le navigateur précharge. Un système basé sur le viewport précharge une fraction significative des 30 produits d’une page catégorie. Foresight en précharge peut-être une ou deux, celles que ce type de visiteur clique d’après vos données, et ignore le reste.

Le compromis qui compte : moins de bande passante, plus de précision

Le prefetching heuristique convient aux sites simples avec une poignée d’étapes suivantes évidentes, et il est plus simple à déployer. Quand votre site a assez de trafic et de complexité de navigation pour que « précharger ce qui est visible » précharge des pages que peu de visiteurs cliquent, vous avez dépassé l’heuristique. La donnée de navigation que vous avez déjà règle le problème.

Foresight comble cet écart en préchargeant la bonne page, d’après ce que vos propres visiteurs ont fait avant, plutôt que plus de pages. Si vous faites tourner du prefetching basé sur le viewport et vous demandez s’il justifie son coût, un audit peut vous répondre en une heure d’analyse de vos données.