- Le test compare le même accueil avec trois rendus du visuel principal.
- La 3D a été réellement active dans les 20 essais WebGL.
- Ces mesures de laboratoire ne démontrent ni un gain de conversion ni la performance de tous les appareils.
La question : quelle place donner au mouvement ?
Une animation doit soutenir la compréhension et laisser le visiteur accéder rapidement au contenu. Pour ce site, nous avons réalisé le 13 septembre 2026 un benchmark de trois variantes du même accueil. Les mesures portent sur le rendu du contenu principal, la stabilité de la mise en page et les longues tâches du fil principal.
Les seuils Core Web Vitals publiés par web.dev servent de repères généraux. Leur évaluation de terrain repose notamment sur le 75e percentile des visites. Notre petit échantillon local n’est pas un rapport de terrain et ne remplace pas une mesure sur les appareils des visiteurs. Il permet d’examiner un choix d’implémentation dans un environnement décrit.
Un contenu identique, trois variantes
La variante statique affiche un anneau dessiné en CSS sans animation de cet anneau. La deuxième anime le même visuel avec une transformation CSS. La troisième remplace progressivement ce visuel de secours par un rendu WebGL exécuté dans un worker, hors du fil principal. Les textes, liens, dimensions et autres composants restent communs.
Le worker limite le rendu à environ vingt images par seconde et reçoit les états de visibilité et de pause. Sur le site livré, le mobile utilise par défaut la variante légère ; la préférence de réduction des mouvements active un rendu statique. Le benchmark force chaque variante pour permettre sa comparaison dans les deux profils.
Le protocole réellement exécuté
Nous avons exécuté dix navigations par variante et par profil, soit soixante observations, dans Chrome 153 sur un même Mac et un serveur local de production Next.js. Le profil ordinateur utilise une fenêtre de 1440 × 1000, un débit de téléchargement de 10 Mib/s, une latence configurée de 40 ms et aucun ralentissement CPU. Le profil mobile utilise 390 × 844, 1,6 Mib/s, 150 ms et un ralentissement CPU ×4.
Le cache réseau est désactivé. La mesure se termine 3,5 secondes après l’événement load. Les variantes sont testées dans l’ordre statique, CSS puis WebGL, d’abord sur ordinateur puis en émulation mobile. Cet ordre non aléatoire et la réutilisation du navigateur peuvent introduire un effet d’échauffement. Le profil mobile est une émulation, pas un téléphone physique.
Ce que montrent les observations
Sur ordinateur, les LCP médians observés sont de 272 ms en statique, 220 ms en CSS et 222 ms en WebGL. Dans le profil mobile, ils sont respectivement de 822, 834 et 864 ms. Le tableau présente aussi l’intervalle entre les 25e et 75e percentiles pour rendre la dispersion visible. Ces écarts descriptifs ne prouvent pas qu’une variante est intrinsèquement plus rapide.
Le rendu WebGL était actif à la fin des vingt essais concernés. Le blocage médian observé sur le fil principal est nul dans les six groupes ; certaines observations mobiles comportent néanmoins des longues tâches. Le CLS maximal relevé atteint environ 0,054. Les données brutes permettent d’examiner chaque essai au lieu de ne retenir que les médianes.
Les limites à garder avec les chiffres
Le LCP concerne ici le texte principal, pas l’instant où l’animation 3D devient visible. Le blocage présenté est la somme de la portion des longues tâches dépassant 50 ms pendant notre fenêtre d’observation ; ce n’est pas le TBT calculé par Lighthouse sur sa propre fenêtre. Le protocole ne mesure pas l’INP, la consommation GPU, la batterie ou la fluidité prolongée.
Un serveur local réduit la part d’infrastructure réelle. L’émulation réseau et CPU ne reproduit pas toutes les caractéristiques d’un appareil. Nous n’avons effectué ni test statistique d’effet causal ni expérience de conversion avec des prospects. Les résultats Lighthouse, CrUX et les visites réelles doivent être analysés séparément avec leur propre méthode.
La décision de design retenue
Nous conservons la scène 3D sur ordinateur, avec un secours CSS et des contrôles de mouvement, et privilégions une animation légère sur mobile. Ce choix tient compte de la lisibilité, des ressources et de l’usage tactile ; il ne repose pas sur une promesse de conversion issue de ce benchmark.
Pour reproduire l’essai, les variantes sont accessibles sur l’accueil avec les paramètres visual=static, visual=2d et visual=3d. Le code et le protocole accompagnent la livraison du projet. Les fichiers téléchargeables ci-dessous contiennent les soixante observations, leurs métadonnées et les statistiques descriptives. Les mises à jour ultérieures du site peuvent modifier les résultats.
| Profil / variante | Essais | LCP médian | LCP P25–P75 | Blocage médian | CLS maximal |
|---|---|---|---|---|---|
| Ordinateur / Statique | 10 | 272 ms | 260–299 ms | 0 ms | 0 |
| Ordinateur / CSS | 10 | 220 ms | 216–224 ms | 0 ms | 0 |
| Ordinateur / WebGL | 10 | 222 ms | 216–228 ms | 0 ms | 0 |
| Mobile émulé / Statique | 10 | 822 ms | 813–835 ms | 0 ms | 0.054 |
| Mobile émulé / CSS | 10 | 834 ms | 820–852 ms | 0 ms | 0.054 |
| Mobile émulé / WebGL | 10 | 864 ms | 842–900 ms | 0 ms | 0.054 |
Sources & méthode
Cette perspective associe les publications citées à une analyse éditoriale. Les exemples illustratifs ne constituent pas des résultats clients. Les fonctionnalités et conditions des fournisseurs peuvent évoluer.