Pourquoi j’utiliserais Three.js et Pixi.js

Une page navigateur est un document : titres, boutons, formulaires, liens qu’un crawler lit. CSS, GSAP et Framer Motion bougent ce document. C’est le bon outil pour presque chaque site marketing que je livre. Three.js et Pixi.js existent pour l’autre métier : une scène que le GPU peint, pas un arbre de div. Les équipes y vont quand le DOM perd des frames, quand l’objet est un SKU 3D, ou quand deux mille pièces doivent rester à l’écran à 60 fps.

J’ai déjà écrit quand GSAP et Framer Motion valent leur place sur un passage Figma vers le code. Ce n’est pas cet article. Ici : quand je quitterais le DOM, à quoi sert vraiment chaque lib, et la facture en Core Web Vitals, SEO et accessibilité si vous posez un canvas WebGL sur une URL métier.

1. Le DOM est un document. Un canvas est une surface de dessin

Chaque nœud DOM porte layout, style, hit-testing et une place dans l’arbre d’accessibilité. Ce coût est le sens du web : le texte se sélectionne, le formulaire se tabbe, Google indexe le titre. C’est aussi pourquoi mille div en position absolute saccadent sur un téléphone milieu de gamme. Un canvas est un bitmap. Vous dites au GPU quoi dessiner cette frame. Un sprite n’a pas de layout. Il n’a pas non plus de titre pour le crawler ni de nom pour le lecteur d’écran, sauf si vous construisez ça à côté du canvas.

Le WebGL brut (et maintenant WebGPU) ce sont des caméras, des buffers, des shaders et des draw calls. On peut l’écrire. La plupart des équipes produit ne devraient pas. Three.js et Pixi.js enveloppent cette surface dans un graphe de scène, des loaders et un vivier de recrutement. Vous payez le poids du bundle et une boîte noire au milieu de la page. La question n’est jamais « le rendu GPU est-il cool ». C’est : le produit a-t-il vraiment besoin d’une scène.

2. Three.js : un monde 3D dans l’onglet

Three.js est un moteur 3D pour le navigateur. Vous avez une scène, une caméra, des lumières, des meshes, des matériaux et des textures. La lib parle à WebGL ; un renderer WebGPU existe pour les GPU plus récents. On l’utilise parce qu’un modèle GLTF de canapé, de cuisine ou de turbine coûte moins cher à faire tourner dans l’onglet que de filmer chaque angle, et parce qu’une caméra qu’on peut orbiter vend mieux qu’un carrousel de PNG.

Le travail typique que je vois : configurateurs produit (couleur, tissu, options), visites d’architecture, données scientifiques ou financières dans l’espace, stands WebXR, scènes hero sur un site de marque qui doivent donner l’impression d’un photogramme qu’on peut toucher. Babylon.js est une vraie alternative, avec un éditeur plus fort. Three.js a gagné les exemples, les réponses Stack Overflow et React Three Fiber - c’est comme ça que je brancherais une scène dans une app Next.js qui pense déjà en composants.

• Three.js quand l’objet a de la profondeur : orbiter, éclater une pièce, changer un matériau, marcher dans une pièce.
• Gardez le GLTF maigre. Un canapé de 40 Mo tue le mobile. LOD, textures compressées, et une image poster avant que la scène démarre.
• Ne mettez pas le prix, le CTA ni le checkout dans le canvas. Du HTML à côté. La scène vend l’objet ; le document ferme la vente.

3. Pixi.js : du 2D à 60 fps, pas un moteur de jeu

Pixi.js est un renderer 2D. Sprites, display list, filtres, systèmes de particules, animation squelettique façon Spine. Il batch les draw calls sur le GPU, donc un rouleau de slot, un tableau d’apprentissage pour enfants ou une carte avec quelques milliers de pins ne fond pas le main thread comme une liste DOM. On l’utilise parce que Canvas 2D est trop lent à ce volume, et parce que l’app web est déjà là - on ne veut pas adopter un framework de jeu complet juste pour peindre vite.

Phaser est un framework de jeu : scènes, physique, input, audio. Pixi est la couche en dessous quand React, le routing et l’auth sont déjà à vous. Pubs interactives, mini-jeux de marque, dashboards avec plus de points que SVG ne devrait porter, et UI façon casino : le brief habituel. Si le produit est un vrai jeu avec des niveaux et un monde physique, partez d’un moteur de jeu. Si le produit est une app Next.js qui a besoin d’une scène 2D chaude sur une route, Pixi est la lib que je prendrais.

• Pixi quand le problème est le volume et la fluidité en 2D : particules, sprite sheets, filtres, une scène redessinée chaque frame.
• Mettez les sprites en atlas. Dix mille PNG épars bloquent le chargement même si le GPU est content ensuite.
• Mettez le ticker en pause quand l’onglet est caché. Une scène Pixi qui tourne en fond, c’est une plainte batterie qui n’a pas encore été écrite.

4. Comment je choisis : CSS, GSAP, Pixi, Three

L’erreur chère, c’est d’utiliser un moteur 3D pour faire fondre un bouton. J’ai déjà écrit : le scroll storytelling premium, c’est GSAP et ScrollTrigger ; l’état d’une UI React, c’est Framer Motion. Ces libs animent des nœuds qui restent dans le document. Three et Pixi créent un monde qui n’est pas le document. Les mélanger, oui. Remplacer la mauvaise couche : voilà comment une landing livre un hero WebGL de 800 Ko que personne n’a demandé d’orbiter.

• Hover, accordéon, transition de page, feedback de formulaire : CSS ou Framer Motion. Restez dans le DOM.
• Sections épinglées, timeline scrubbée, scroll cinéma : GSAP. Toujours le document, juste chorégraphié.
• Des milliers d’objets 2D, des particules, une scène qui doit tenir 60 fps : Pixi.js.
• Profondeur, caméra, lumières, un modèle à orbiter : Three.js. Pas un rouleau de slot 2D.

5. La facture : vitals, SEO, a11y, téléphones bon marché

Un canvas WebGL est invisible pour un crawler. Ce que l’utilisateur doit lire - nom produit, prix, mentions, FAQ - vit dans le HTML autour de la scène, pas peint dans une texture. J’ai déjà écrit comment les Core Web Vitals bougent le chiffre. Un hero 3D impatient sur la home, c’est un but contre son camp classique sur LCP et INP : le GLTF se bat avec le first paint, puis la boucle de rendu vole l’input. Lazy-loadez la scène une fois le document utile. Un poster statique d’abord. Détruisez le renderer au unmount, sinon le GPU fuit à travers les navigations client.

L’accessibilité est une UI parallèle, pas un attribut canvas. Orbite clavier, alternative texte pour le modèle, reduced-motion qui arrête la boucle. Un Android bon marché bride thermiquement un fragment shader occupé. Plafonnez le pixel ratio, offrez un repli « photos 2D », et ne faites pas du contexte WebGL qui n’a pas démarré le seul chemin vers le SKU.

6. Next.js : île client, pas un Server Component

Il n’y a pas de WebGL sur le serveur. La scène est un client component, chargé avec next/dynamic et ssr: false, derrière un poster ou un skeleton. React Three Fiber si le reste de l’app est React. @pixi/react si la scène doit parler au même arbre d’état. Je ne ferais pas de SSR d’un canvas « pour le SEO » : le crawler voit quand même un bitmap vide. Mettez le texte dans le HTML rendu serveur. Laissez l’île démarrer quand l’utilisateur est prêt à jouer avec l’objet.

Conclusion : choisissez la surface qui va avec l’objet

Les équipes prennent Three.js parce qu’un SKU 3D se vend mieux quand le client peut l’orbiter. Elles prennent Pixi.js parce que deux mille sprites à 60 fps ne survivront pas en div. Aucune lib ne remplace CSS, GSAP ou un document rapide. Si le brief est « rendez ça premium », je commence par le mouvement dans le DOM. Si le brief est « faites tourner cette cuisine » ou « gardez les pièces à l’écran », je quitte le DOM exprès, j’isole le canvas, et je laisse dans le HTML le texte dont Google et un lecteur d’écran ont besoin. Je clos ça en ingénieure web senior : îles Next.js, WebGL paresseux, GSAP là où la page est encore une page. Écrivez via le formulaire le nombre d’objets, si c’est 2D ou 3D, et si la même URL doit se classer. On ne commencera pas en posant un canvas sur la home « pour faire moderne ».