Chaque transition de page repart de zéro.
Le navigateur charge les ressources, effectue un rendu de l’HTML, exécute le code JavaScript, etc. Peu importe que l’utilisateur ait visité ce même chemin cent fois dans la journée. Pourtant, vos données de navigation GA4 dessinent déjà une carte précise des intentions des internautes: quelle page sera chargée après, à quelle fréquence, et sur quel type d’appareil. Cette étude exploite ces données pour précharger silencieusement les cinq pages les plus probables via des balises prefetch, pilotées par GTM et alimentées par un modèle entraîné dans BigQuery.
Résultat : une navigation perçue comme instantanée, sans modifier le code du site, et un impact mécanique sur la conversion.
Le problème que personne ne mesure
Les scores Core Web Vitals d’un site e-commerce peuvent être excellents sur la page d’accueil et catastrophiques sur les pages catégories. C’est précisément là que les utilisateurs décident d’aller plus loin ou de partir.
L’indicateur LCP (Largest Contentful Paint) mesuré sur la première page d’une session en dit peu sur l’expérience réelle de navigation. Ce qui compte pour un acheteur en cours de session, c’est la vitesse de la deuxième page, de la troisième, c’est-à-dire les pages qu’il n’a pas encore chargées, mais qu’il chargera dans les trente prochaines secondes.
Un client e-commerce généraliste (500 000 sessions mensuelles, catalogue de 8 000 références) nous soumet exactement ce problème. Ses scores Lighthouse sont corrects. Son taux de rebond sur navigation interne est pourtant de 34 %, avec une chute de 12 points du taux de conversion entre la deuxième et la troisième page consultée. Le problème n’est pas le contenu mais la friction perçue lors du chargement.
Il faut donc se poser la question : peut-on anticiper là où va l’utilisateur et charger les ressources avant même qu’il clique sur le lien vers la page d’après ?
La mécanique du prefetch
La méthode prefetch est une directive HTML native. Ajouter <link rel=”prefetch” href=”/page-cible”> dans le <head> d’une page indique au navigateur de télécharger cette ressource en arrière-plan, avec la priorité la plus basse, pendant les temps morts de la session. Quand l’utilisateur clique effectivement vers cette page, le contenu est déjà dans le cache du navigateur. Le chargement perçu devient quasi instantané et fluidifie le parcours client, ce qui va mécaniquement faciliter le chemin de l’internaute vers la conversion.
prefetch n’est pas une méthode ni récente ni révolutionnaire mais elle est surtout utilisée pour précharger des ressources de type JavaScript, vidéo, et autres éléments plus lourds.
La difficulté n’est pas technique mais décisionnelle : quelles cinq pages précharger ? Précharger les mauvaises pages consomme de la bande passante inutilement et peut même nuire aux performances en saturant la connexion réseau et en alourdissant la charge du serveur Web.
C’est là qu’intervient le modèle de données de navigation vers les pages suivantes.
Comment ça marche : GA4, GCP et GTM
Étape 1 : extraction des séquences de navigation depuis BigQuery
Si vous avez configuré un export de vos données GA4 vers BigQuery, chaque événement page_view est horodaté, puis rattaché à une session, et enfin rattaché à un utilisateur. On peut ainsi reconstruire, session par session, l’ordre exact des pages visitées. On peut donc construire une table de transitions qui contient, pour chaque URL d’origine, la liste des destinations observées et leur fréquence relative.
Étape 2 : entraînement du modèle de prédiction
Pour un catalogue de 8 000 références produit, une simple table de fréquences suffit rarement. Les pages peu visitées ont des statistiques instables. Les promotions temporaires faussent les fréquences et autres tendances.
On entraîne un modèle de recommandation de séquences directement dans BigQuery ML, en enrichissant les données de navigation de variables contextuelles : catégorie de page, heure de visite, type d’appareil, profondeur de session.
Le résultat est une table de prédictions actualisée chaque nuit et qui contient, pour chaque URL canonique, les cinq destinations les plus probables avec leur score de confiance. Un pipeline Cloud Scheduler déclenche le ré-entraînement du modèle automatiquement et mesure la précision (top-5 accuracy) avant de pousser les nouvelles prédictions en production.
Étape 3 : Cloud Function comme couche d'accès
Une Cloud Function HTTP (déployée sur GCP, région europe-west9 pour une meilleure empreinte carbone) expose ces prédictions via une API simple : on lui passe l’URL courante, elle retourne les cinq pages les plus probables. La Cloud Function lit les résultats depuis un cache Firestore (alimenté depuis BigQuery). On pourrait en dire plus sur la performance pure de cette méthode mais ca sera pour une autre étude.
Étape 4 : injection de prefetch via Google Tag Manager
Dans Google Tag Manager, on déclenche une balise Custom HTML sur chaque événement page_view. Ou sur un autre événement d’initialisation de la page ou du DOM. La balise appelle la Cloud Function avec l’URL courante, récupère la liste des pages probables, puis injecte dynamiquement les balises <link rel=”prefetch”> correspondantes dans le <head> de la page. Côté mesure, deux événements GA4 sont envoyés : prefetch_insertion quand les balises sont posées, et prefetch_clic quand l’utilisateur navigue effectivement vers une des URLs préchargées. Ce second événement permet de calculer la précision réelle du modèle en conditions de production, session après session.
Vous n’avez pas besoin de modifier votre site : c’est GTM qui gère l’intégralité du déploiement.
Voici un schéma récapitulatif de cette méthodologie:
Cliquez sur le visuel
Mesure de l'impact de prefetch
Avant tout déploiement en production, un test A/B est mis en place via GTM : 50 % des sessions reçoivent les balises prefetch, 50 % naviguent normalement. Le groupe d’appartenance est tiré au sort côté client (client ID pair ou impair) et stocké dans un cookie first-party, ce qui garantit la cohérence de l’expérience sur l’ensemble de la session.
Les indicateurs suivis pendant la phase de test (4 semaines, 200 000 sessions) :
| Indicateur | Groupe contrôle | Groupe prefetch | Variation |
|---|---|---|---|
| LCP moyen (2e page visitée) | 3,2 s | 1,4 s | -56% |
| Taux de rebond inter-pages | 34 % | 21% | -38% |
| Pages vues par session | 3,1 | 4,4 | +42% |
| Taux de conversion | 2,8 % | 3,6% | +29% |
| Précision du modèle (top-5) | 73% |