Dans l'article sur les micro-interactions, j'écrivais que transform et opacity s'animent sur le thread de composition, donc même une page lourde ne devrait pas saccader l'animation d'un bouton. C'est toujours vrai – avec une réserve que cet article-là passait sous silence : si le thread principal est bloqué par une longue tâche JS, l'animation risque de ne jamais avoir la chance de démarrer, car le handler de clic lui-même attend dans la file. L'INP est la métrique qui mesure exactement cet écart – et scheduler.yield() est l'un des rares moyens de réellement le combler.
Le bouton « J'aime » réagit instantanément, le cœur se remplit, le compteur augmente – avant même que le serveur ait répondu. Ce n'est pas l'illusion de rapidité de l'article sur les micro-interactions, c'est quelque chose qui va plus loin : l'interface affiche un état qui n'existe pas encore, en supposant qu'il existera bientôt. J'examine comment construire cela en toute sécurité – avec un vrai retour en arrière quand l'hypothèse ne se vérifie pas – et pourquoi un setState manuel plus un catch est une version dégradée de ce qu'offre useOptimistic.
Deux boutiques, le même produit, le même temps de réponse serveur – et pourtant l'une semble plus rapide et plus digne de confiance que l'autre. La différence tient aux micro-interactions : quelques centaines de millisecondes d'animation qui décident si l'utilisateur croit ce qu'il voit à l'écran. Je décortique le sujet depuis les fondamentaux – le modèle déclencheur/feedback, ce qui se passe réellement dans le moteur de rendu du navigateur, et prefers-reduced-motion.
CSS Houdini n'est pas une seule technologie, mais un ensemble de spécifications à des degrés de maturité très différents. Découvrez quelle partie est aujourd'hui prête pour la production, comment fonctionnent réellement @property et le paint worklet, et pourquoi le reste demeure expérimental.
