Historiquement, le problème de la vitesse de chargement a été considéré uniquement comme une métrique d'ingénierie, mais avec l'introduction des Core Web Vitals dans les algorithmes de recherche et l'augmentation du trafic mobile, il est devenu évident que la performance est une fonctionnalité produit. Les approches classiques pour évaluer l'impact de la vitesse sont confrontées à une endogénéité fondamentale : les utilisateurs avec des appareils rapides et une connexion Internet stable convertissent mieux, indépendamment de l'optimisation du site, ce qui crée une corrélation spurious.
Le problème s'aggrave avec l'utilisation de Edge Computing et des architectures CDN modernes, où il n'est pas possible de garantir une division cohérente du trafic en groupes à cause du caching agressif sur les serveurs de bord. De plus, il existe un effet d'auto-sélection : les utilisateurs avec une connexion lente quittent plus souvent le site avant le chargement, ce qui fausse la distribution de l'échantillon et rend impossible une comparaison A/B pure.
La solution optimale combine le design de discontinuité de régression (RDD) à la frontière du seuil de « bonne » performance (par exemple, LCP = 2,5 secondes) avec des variables instrumentales (IV) comme outil. La proximité géographique de l'utilisateur au serveur de bord le plus proche ou le type de connexion (3G contre 4G) est utilisée comme variable instrumentale, influençant aléatoirement la vitesse, mais ne corrélant pas directement avec l'intention d'achat. Pour l'analyse par cohortes, la méthode du contrôle synthétique est employée, où le groupe de contrôle est construit à partir des données historiques des utilisateurs avec une structure d'appareils et des géolocalisations similaires, permettant d'isoler l'effet pur de l'optimisation de la variation saisonnière et des macro-tendances.
Dans un grand projet de e-commerce, l'équipe frontend a réalisé une révolution : elle a transformé les images au format moderne (WebP, AVIF) avec un lazy-loading et a optimisé le chemin critique de rendu, réduisant le LCP de 4,2 secondes à 1,8 seconde parmi les utilisateurs avec une bonne connexion. L'équipe produit a noté une augmentation de la conversion de 12% dans la tranche « après la sortie », mais des doutes sont apparus sur le lien causal, car simultanément, une campagne publicitaire saisonnière a été lancée et le catalogue de produits a été mis à jour.
Option 1 : Comparaison naïve des cohortes avant et après
Les analystes ont proposé de comparer la conversion des utilisateurs pendant la semaine précédant l'optimisation et la semaine suivante, stratifiant par région. Avantages : simplicité de mise en œuvre et absence de nécessité d'une infrastructure complexe. Inconvénients : ignorance totale de la saisonnalité (semaine pré-fête), différences dans la composition de l'audience (de nouveaux utilisateurs venus de la publicité avec une autre intention) et biais de survie (survivorship bias) — les utilisateurs lents ont « disparu » de l'après-échantillon, créant une illusion de croissance.
Option 2 : Analyse corrélationnelle de la vitesse versus conversion
La deuxième approche a consisté à construire une régression où la variable indépendante était le LCP réel de l'utilisateur, et la variable dépendante était l'événement de conversion. Avantages : utilisation de toutes les données disponibles et granularité jusqu'à la session. Inconvénients : endogénéité fatale : les utilisateurs avec des appareils phares coûteux et un Internet rapide sont initialement plus riches et motivés à acheter, tandis que les utilisateurs avec des appareils bon marché sur 3G ont une faible intention d'achat, indépendamment de la vitesse du site, ce qui donne un coefficient de biais à la hausse de 40-60%.
Option 3 : Design de discontinuité de régression avec instrument géographique
L'équipe a choisi une méthode hybride : elle a utilisé la distance au serveur de bord le plus proche comme variable instrumentale, corrélant avec la vitesse, mais pas avec le comportement d'achat. Les utilisateurs à la limite de la zone de couverture (où le signal « casse » et la vitesse chute brusquement à 2,6-2,8 secondes LCP) ont formé un échantillon aléatoire local autour du seuil de 2,5 secondes. En appliquant l'Effet de traitement moyen local (LATE) dans la fenêtre ±0,3 seconde du seuil, ils ont mesuré l'effet pur de l'amélioration de la vitesse pour les complieurs (utilisateurs dont la vitesse a changé uniquement à cause de l'infrastructure, et non de l'appareil).
Solution choisie et résultat
La méthode RDD+IV a été mise en œuvre avec un filtrage supplémentaire des utilisateurs de retour à travers l'analyse du localStorage à la recherche de ressources mises en cache. L'évaluation finale a montré que l'effet incrémental réel de l'optimisation était de +8,5% en conversion pour les nouveaux utilisateurs et de +3,2% pour les utilisateurs retours (où l'effet de nouveauté est moins prononcé), permettant de justifier les investissements dans l'infrastructure Edge Computing avec un ROI de 340% sur un an.
Pourquoi la régression OLS standard de la performance versus la conversion donne-t-elle des estimations biaisées, et quel mécanisme d'endogénéité domine ici ?
La réponse réside dans le double biais de sélection (double selection bias) : premièrement, les utilisateurs avec des appareils lents sont systématiquement moins susceptibles d'entrer dans l'échantillon des « sessions réussies » (ils abandonnent avant le chargement), créant un biais de troncature ; deuxièmement, la vitesse de l'Internet corrèle avec le statut socio-économique et la géographie, qui influencent directement la capacité de paiement. Sans variables instrumentales ou RDD, la régression mélange l'effet du « Internet rapide comme marqueur de richesse » avec l'effet d'un « site rapide comme déclencheur de conversion », surestimant l'effet causal réel de 1,5 à 2 fois.
Comment le caching côté client (client-side caching) et les visites répétées biaisent-ils l'évaluation de l'effet d'optimisation dans une analyse longitudinale, et quelle méthode permet de filtrer la « contamination du traitement » ?
Les utilisateurs de retour, ayant visité le site avant l'optimisation, disposent dans leur HTTP-cache ou Service Worker de ressources lourdes anciennes; ainsi, pour eux, le « traitement » (la nouvelle version rapide) s'applique partiellement ou totalement, créant une contamination entre traitement et contrôle. Les candidats oublient souvent de vérifier les en-têtes If-None-Match ou d'analyser les first-party cookies avec l'horodateur de la première visite. L'approche correcte est d'analyser l'intent-to-treat (ITT) en séparant les « nouvelles sessions pures » (nouveaux utilisateurs + cache vidé) contre les « retours contaminés », ou d'utiliser difference-in-differences (DiD) avec des effets fixes utilisateur, ce qui isole le changement intra-utilisateur de la sélection entre utilisateurs.
Quelle est la différence entre l'analyse ITT (Intent-to-Treat) et l'analyse TOT (Treatment-on-the-Treated) lors de l'évaluation de l'effet des Core Web Vitals, et pourquoi est-il critique de rapporter précisément l'ITT pour les métriques produit lors de la planification de l'expansion ?
ITT mesure l'effet pour l'ensemble de la population, y compris ceux qui n'ont pas bénéficié d'une amélioration de la vitesse (par exemple, les utilisateurs sur 2G ou avec JavaScript désactivé), tandis que TOT (ou LATE dans le contexte IV) mesure l'effet uniquement pour les « complieurs » — ceux qui ont réellement bénéficié de l'optimisation. Les candidats rapportent souvent à tort à l'entreprise une évaluation TOT (+15% de conversion pour ceux qui obtiendraient un chargement rapide), mais lors de l'extension de l'optimisation à 100% du trafic, l'effet réel sera plus proche de l'ITT (+6-8%), car une partie de l'audience ne pourra pas techniquement bénéficier de l'amélioration (appareils obsolètes, réseaux lents). Pour la planification commerciale et la prévision des revenus, il est critique d'utiliser une estimation ITT conservatrice pour éviter une erreur de surengagement.