CLS de 0,4 à 0,06 dans un tunnel de réservation de vacances
Les décalages de mise en page se produisaient dans le tunnel de réservation, et la plupart arrivaient après le premier chargement de la page.
Une single page application dont le tunnel de réservation se décalait
Prijsvrij est un site de voyage néerlandais : rechercher, comparer et réserver des vacances. Tout le site est une single page application, et la même équipe gère Prijsvrij.be et D-reizen.
J'ai passé deux journées de 4 heures sur place. Le premier jour, j'ai audité le site. Le deuxième jour, j'ai passé en revue les résultats avec l'équipe et expliqué, étape par étape, comment corriger les problèmes les plus urgents en priorité.
Le premier écran, le tunnel de réservation et les clics
La plupart des décalages de mise en page survenaient lors des soft navigations : l'application remplace le contenu sans charger de nouvelle page. Un test Lighthouse sur la page d'accueil ne les voit jamais. Les vrais visiteurs qui avancent dans une réservation les subissent bien, et CrUX attribue ces décalages à l'URL ouverte au départ.
J'ai livré l'audit fin mars 2026, puis je l'ai passé en revue avec leurs développeurs à Den Bosch le 15 avril, et en ligne une semaine plus tard. Le CLS était le point le plus difficile, avec plus de causes que d'habitude pour une configuration comme celle-ci. Leurs développeurs l'ont corrigé sur les trois sites, et en mai, le CLS sur desktop est passé au vert sur chacun d'eux.
Un matin de juin, leur lead front-end m'a écrit. Il avait passé les semaines précédentes à peaufiner prijsvrij.nl en s'appuyant sur les données de CoreDash via sa connexion Claude Code, et les graphiques allaient dans le bon sens. Pouvait-on ajouter D-reizen aussi ? Dans l'heure, D-reizen et Prijsvrij.be étaient tous les deux dans CoreDash.
Prochaine étape : l'INP. En l'analysant fin juin, j'ai reconnu le schéma : je l'ai vu souvent, et un plan d'action éprouvé permet de le corriger, tant que chaque étape est exécutée avec exactitude. Cela règle le plus gros du problème. C'est seulement après que les causes sous-jacentes apparaissent, et elles sont toujours plus petites. J'ai donc proposé de travailler de façon plus concrète : de petits changements chirurgicaux, moins de théorie, plus de pratique. En juillet, nous nous sommes retrouvés dans leurs bureaux, déjeuner compris, et nous continuons à faire le point chaque trimestre.
Le LCP sur mobile augmente pendant les vacances, lorsqu'une grande partie du trafic provient de personnes elles-mêmes en vacances. Il reste bien en dessous de 2,5 secondes et redescend déjà.
Une animation de chargement ne fait que déplacer le décalage de mise en page
L'animation semblait masquer l'attente. Le décalage arrivait dès qu'elle laissait la place aux détails du vol.
Le tracking dans le clic pénalise chaque clic
Un tag dans le click handler s'exécute avant que l'écran ne puisse changer. Déplacé après la mise à jour, le visiteur voit d'abord le résultat et le tag s'exécute quand même.
Une single page application évolue en permanence
Chaque release apporte des composants et des tags absents du contrôle précédent. C'est pour cela que je reviens chaque trimestre.
Des décalages de mise en page dans une single page application que Lighthouse ne voit jamais ?
Envoyez-moi l'URL de votre tunnel de réservation ou de commande, et je le parcourrai comme un vrai visiteur, soft navigations incluses.
Ou voir le conseil. D'autres résultats sur ma page clients.
