Une page d'accueil en 3D sans écran de chargement : comment nous avons cessé de déplacer les saccades

Points clés

• Les sites en 3D ambitieux s'ouvrent presque toujours sur un écran de chargement : le navigateur a besoin de temps pour télécharger la scène et la préparer pour la carte graphique. Sur une boutique en ligne, cet écran s'interpose entre le client et les produits.
• Le retirer est facile. Le plus dur, c'est la préparation ponctuelle qu'il cachait : sur ce projet, environ 1,2 s de travail, en blocs de 150 à 500 ms que le navigateur ne peut pas découper.
• Lancer cette préparation au premier défilement, la découper en étapes, attendre les pauses dans le défilement : chaque solution a déplacé les blocages vers une autre partie de la page. Aucune ne les a supprimés.
• La solution a été de ne plus faire ce travail dans le navigateur du visiteur : le film en 3D est désormais rendu à l'avance sous forme de vidéo. La page d'accueil ne charge plus aucune bibliothèque 3D.
• Un mouvement lié au défilement et piloté en JavaScript peut sembler saccadé sur un pavé tactile, même quand les mesures d'images sont parfaites. Les animations CSS liées au défilement ont réglé le problème.

Voici l'histoire d'une page d'accueil, mesurée à chaque étape. Elle s'adresse aux fondateurs, responsables marketing et développeurs qui préparent un site riche en 3D ou en animations, et qui se demandent s'ils doivent accepter un écran de chargement pour l'obtenir.

Le client et la demande

shoporganyc.com est la boutique en ligne de New Tripolis Pharma, distributeur exclusif d'Organyc au Liban. Organyc fabrique des serviettes, protège-slips et tampons en coton biologique. La marque est née en 2008 chez Corman, une entreprise cotonnière fondée en 1947 qui fournissait des bandages aux hôpitaux et pharmacies d'Italie et d'Europe (Organyc, Our Story). Nous avons construit la boutique : catalogue, paiement à la livraison, adresses de livraison sur carte, rubrique éditoriale et l'outil de gestion de contenu qui va avec.

La pièce maîtresse de la page d'accueil est une « anatomie » en 3D d'une serviette Organyc : elle se décompose couche par couche, et le texte explique le rôle de chacune. C'est l'argument principal de la marque (ce qu'il y a dans le produit), donc le rendu devait être exceptionnel.

Pourquoi les sites en 3D s'ouvrent sur un écran de chargement

Avant d'écrire une ligne de code, nous avons regardé comment les meilleurs sites en 3D gèrent le chargement. La réponse est presque toujours la même : un écran de chargement.

• Igloo Inc., lauréat d'un Webby Award 2026 pour son design visuel, s'ouvre sur une barre de progression.
• Le studio Lusion s'ouvre sur une barre de chargement et un compteur.
• Active Theory s'ouvre sur un écran noir avec un petit indicateur de chargement.

Il y a une bonne raison à cela. Une scène 3D doit télécharger ses modèles, ses textures et son éclairage, puis le navigateur doit compiler les shaders, ces petits programmes que la carte graphique exécute pour dessiner chaque matière. Tant que ce n'est pas fait, les premières images saccadent. Un écran de chargement cache tout cela, et sur un portfolio ou une expérience de marque, les visiteurs acceptent d'attendre.

Apple prend un autre chemin sur certaines pages produits. Sa célèbre animation au défilement des AirPods Pro est une suite d'images pré-rendues dessinées sur un canvas, pas une scène 3D en direct, comme l'a montré CSS-Tricks en la reproduisant (Jurn van Wissen, 2020). Gardez cela en tête, on y revient à la fin.

Version 1 : l'écran de chargement

La première version, construite le 23 octobre 2026, suivait le marché. Un écran de chargement plein écran retenait la page jusqu'à ce que la vidéo d'en-tête soit prête et que la scène 3D se soit préparée. Une fois la page affichée, tout était fluide.

Notre interlocuteur chez New Tripolis Pharma n'en était pas complètement convaincu. Un écran de chargement sur une boutique, c'est inhabituel, et une cliente venue acheter un paquet de serviettes ne s'attend pas à patienter devant un spectacle. Quand nous lui avons expliqué pourquoi les sites en 3D ambitieux fonctionnent ainsi, il a été convaincu et l'a validé.

Nous n'étions pas satisfaits pour autant. Les chiffres donnaient raison à sa première intuition. Sur un test Lighthouse mobile, la page d'accueil obtenait 41, avec 8,6 s de temps de blocage total (TBT) et 3,3 Mo de poids. (Nous avions déjà compressé la vidéo d'en-tête de 19,5 Mo à 2,2 Mo sans perte visible.) Pour une boutique qui veut se positionner dans Google et convertir sur mobile, c'est beaucoup. Nous nous sommes donc fixé un objectif que le client n'avait pas demandé : garder la 3D, supprimer l'écran de chargement, et ne jamais laisser la page se figer.

Version 2 : sans écran de chargement, une page plus légère

Le matin du 10 novembre, nous avons retiré l'écran de chargement et allégé la page :

• En-tête : une image d'attente qui s'affiche immédiatement, et une vidéo plus légère pour les téléphones (690 Ko).
• Carrousel de produits : il n'envoie plus que les champs affichés sur les cartes, et le HTML de la page d'accueil est passé de 456 Ko à 277 Ko.
• Scène 3D : elle se charge au premier défilement, toucher ou appui sur une touche du visiteur, et non plus avant l'affichage de la page.

Dans nos tests Lighthouse en local, le score mobile est passé de 41 à 70, le TBT de 8,6 s à 0,3 s et le poids de 3,3 Mo à 1,5 Mo. Sur le site en ligne, le score s'est situé entre 60 et 63. Lighthouse est un test de laboratoire, et ses scores varient selon le réseau et la machine qui l'exécute.

Le coût que l'écran de chargement cachait

Puis les saccades sont apparues. La préparation de la 3D (compilation des shaders, préparation de l'éclairage et des reflets) prend environ 1,2 s au total, en blocs de 150 à 500 ms. Pendant chaque bloc, le fil principal du navigateur ne peut rien faire d'autre : ni défilement, ni animation, ni réponse à un toucher. Google considère toute tâche de plus de 50 ms comme une tâche longue, qui rend une page peu réactive (web.dev, Optimize long tasks).

La bibliothèque 3D utilisée, three.js, propose déjà une compilation asynchrone qui s'appuie sur une extension du navigateur pour compiler les shaders en parallèle (code source de three.js, compileAsync). Nous l'avons utilisée. Une partie de la préparation reste pourtant faite de blocs uniques et indivisibles, notamment celle des reflets, que nous avons aussi précompilée.

L'écran de chargement absorbait ce coût. Sans lui, le coût tombait là où se trouvait le visiteur. Voici ce qu'a donné chaque correctif :

La troisième tentative est la plus instructive. Attendre une pause dans le défilement semble malin, mais un bloc ne peut pas être interrompu une fois lancé. Un bloc démarré pendant une pause figeait le défilement qui reprenait un instant plus tard. Et tant que le visiteur continuait à défiler, la préparation glissait toujours plus tard, au-delà du moment où elle était nécessaire.

La leçon : un coût de ce type se déplace, il ne se cache pas. Il doit avoir lieu avant que le visiteur en ait besoin, à un moment où il ne le remarque pas, ou ne pas avoir lieu dans son navigateur du tout.

Une parenthèse : un défilement « par crans » sur pavé tactile

Pendant les tests, nous avons senti le défilement avancer par petits crans sur le pavé tactile d'un ordinateur portable. Les traces de performance de Chrome montraient pourtant une page qui défilait bien : presque toutes les images étaient affichées à temps.

Le coupable était la section suivante, où des cartes glissent au fil du défilement. React déplaçait ces cartes à chaque image de défilement. Or les navigateurs font défiler la page sur un fil séparé et transmettent les événements de défilement au JavaScript de façon asynchrone (Chrome for Developers, scroll-driven animations) : les cartes avaient toujours une image de retard sur la page. Les mesures d'images ne le montrent pas. Une main sur un pavé tactile, si.

Nous avons confié les cartes aux animations CSS liées au défilement (MDN, animation-timeline) : c'est le navigateur lui-même qui les déplace, au rythme du défilement. Les positions des cartes correspondent à l'ancienne version à 1 px près, et le travail JavaScript pendant le défilement de cette section est passé de 319 ms à 103 ms. Les navigateurs qui ne la gèrent pas gardent la version en JavaScript. La fonctionnalité est disponible dans Chrome depuis la version 115, Safari depuis la 26 et Firefox depuis la 159 (données de compatibilité MDN). Sur le même pavé tactile, les crans avaient disparu.

La vidéo d'en-tête était-elle trop compressée ?

La préparation de la 3D tournant désormais pendant l'en-tête, la vidéo d'en-tête saccadait, et le premier soupçon s'est porté sur la compression. Nous avons vérifié au lieu de deviner : comparée image par image à l'original en 4K, la vidéo obtenait un SSIM de 0,992 (1,0 signifie identique), et les 174 images étaient toutes là, aux 24 images par seconde d'origine. Le fichier était bon. Les saccades venaient de la préparation de la 3D : quatre blocages, entre 3,5 et 6 s après le chargement, qui sautaient chacun 3 à 6 images.

C'était tranché. Tant que la scène 3D serait préparée dans le navigateur du visiteur, elle figerait quelque chose.

Version 3 : rendre le film à l'avance

Nous nous sommes posé la question qui devrait sans doute venir en premier sur ce type de projet : le visiteur interagit-il avec la 3D, ou la regarde-t-il seulement ? Ici, il la regardait. Un bouton, « Discover the layers » (découvrir les couches), lance le film sur place, et le visiteur peut le rejouer. Il ne fait jamais tourner la serviette et ne choisit jamais une couche.

Un film que l'on regarde peut être une vidéo. Nous rendons donc la même scène 3D à l'avance, image par image à 60 images par seconde, en deux versions : 4,1 Mo pour ordinateur et 1,6 Mo pour téléphone. La vidéo ne se télécharge qu'à l'approche de la section. L'horloge de la vidéo pilote les animations de texte et de couleur existantes, qui restent ainsi synchronisées avec l'image.

Mesures sur le site en ligne ensuite :

La cause a disparu, elle n'a pas été déplacée. L'ouverture, chaque étape du film, le final et le bouton pour rejouer fonctionnent comme avant.

Les compromis

Rien n'est gratuit. Voici ce que nous avons abandonné :

• La serviette ne passe plus devant le titre. La vidéo est placée sous le texte.
• La serviette est une image fixe en attendant le bouton, au lieu de « respirer » doucement.
• Les écrans qui ne sont pas au format 16:9 rognent les bords de la vidéo.
• Toute modification de la scène 3D impose de refaire le rendu des vidéos. Cela prend moins d'une minute, et les étapes sont scriptées.

Nos tests automatisés ne reproduisent pas fidèlement le défilement tactile : nous avons donc vérifié la version finale à la main sur un téléphone, et le défilement comme le film sont fluides. Nous n'avons pas fait de mesures chronométrées sur téléphone.

Liste de contrôle pour votre page d'accueil en 3D

1. Déterminez si les visiteurs interagissent avec la 3D ou la regardent seulement. S'ils la regardent, une vidéo ou une suite d'images pré-rendues est presque toujours plus légère et plus fluide.
2. Mesurez la préparation, pas seulement le téléchargement. Enregistrez une trace de performance et cherchez les tâches longues après le chargement. Un fichier léger peut cacher une seconde de compilation de shaders.
3. Si vous gardez la 3D en direct, planifiez la préparation délibérément, avant que le visiteur n'atteigne la section et loin de tout ce qui est animé. N'espérez pas la glisser dans les pauses.
4. Pilotez les mouvements liés au défilement en CSS, pas en JavaScript à chaque événement de défilement.
5. Testez sur un pavé tactile et sur un téléphone, pas seulement avec des mesures. On ressent le décalage avant que les outils ne le signalent.
6. Si vous gardez un écran de chargement, faites-en un choix, pour une expérience de marque où les visiteurs l'attendent, et non un réflexe.

Questions fréquentes

Un écran de chargement est-il toujours une mauvaise idée ? Non. Sur un site de marque immersif ou un portfolio, les visiteurs acceptent une courte attente, et les meilleurs sites en 3D en utilisent un. Sur une boutique en ligne ou une page qui doit générer des contacts, chaque seconde avant l'affichage du contenu coûte des visites : cela vaut la peine de travailler davantage pour s'en passer.

Une vidéo ne pèse-t-elle pas plus lourd qu'un modèle 3D ? Parfois. Ici, la version téléphone pèse 1,6 Mo et ne se télécharge qu'à l'approche de la section. Le vrai gain, c'est la préparation que le navigateur n'a plus à faire, et qu'aucun poids de fichier ne montre.

Ne peut-on pas simplement découper la préparation de la 3D en étapes plus petites ? En partie. Certaines étapes, comme la compilation d'un shader complexe, ne peuvent pas être découpées par votre code. Une fois un bloc de 300 ms lancé, la page se fige 300 ms, où que soit le visiteur.

Est-ce mauvais pour le référencement ? C'est l'inverse. La page est plus légère, bloque beaucoup moins le navigateur et affiche son contenu immédiatement, autant d'éléments que Google mesure.

---

FNB Solutions conçoit et développe des sites et des boutiques en ligne ambitieux qui restent rapides. Voir notre offre de sites sur mesure, ou parlez-nous de votre projet.

Sources

• Organyc, Our Story (en anglais)
• The Webby Awards, Igloo Inc, Best Visual Design – Aesthetic, 2026 (en anglais)
• CSS-Tricks, Let's Make One of Those Fancy Scrolling Animations Used on Apple Product Pages, Jurn van Wissen, 2020 (en anglais)
• web.dev, Optimize long tasks (en anglais)
• three.js, WebGLRenderer.compileAsync
• Chrome for Developers, Animate elements on scroll with scroll-driven animations, Bramus, 2023 (en anglais)
• MDN, animation-timeline