Tous les autres écrans de cette appli, c'est toi qui as choisi de les ouvrir. Celui-ci, non — tu as tapé autre chose, et c'est le blocage qui t'a rattrapé à la place. Cette différence change complètement le cahier des charges technique. Un écran que tu as demandé peut mettre un instant à arriver ; personne ne regarde un chronomètre. Un écran qui t'interrompt n'a qu'une seule chance de ne pas donner l'impression que le téléphone a buggé, et il doit le prouver en moins d'un tiers de seconde.
La seule mesure qui compte
Pas la durée de l'animation d'intro — le délai avant qu'elle ne démarre. Porte, entrée, sol, plafond, tableau, enseigne, horloge : la séquence suit un calendrier fixe, et chacun de ces délais a été choisi puis vérifié à la main. Rien de tout ça ne compte si le tap lui-même produit un accroc juste avant. Une entrée magnifique de 800ms cachée derrière un écran blanc vide de 400ms se lit comme « cette appli est lente », un point c'est tout — la finition n'est jamais vue, parce que le verdict est déjà tombé sur l'écran vide.
La vraie cible n'est donc pas « l'animation paraît fluide ». C'est « quelque chose apparaît avant que l'utilisateur ait le temps de se demander si son tap a été pris en compte ». C'est à peu près le même budget qu'un changement d'appli au niveau système — quelques centaines de millisecondes — et c'est une barre bien plus stricte que celle imposée à la plupart des transitions internes d'une appli.
Ne jamais bloquer le blocage
La salle de classe ne peut pas attendre le réseau. Quelle que soit la question posée, elle doit venir de données déjà présentes sur l'appareil avant même que tu appuies — récupérées et mises en cache à l'avance, selon nos conditions, et non demandées au moment précis où tu es déjà agacé, les yeux rivés sur une roue de chargement. Si ce cache est un jour vide, l'échec honnête est une carte de question plus simple et statique, pas une roue de chargement devant un professeur qui n'a pas encore fait son entrée.
La même règle s'applique aux ressources. Une requête de police ou un chargement d'image sur le chemin critique, c'est une dépendance au fait que le réseau soit rapide exactement au moment où tu es en pleine interruption — c'est-à-dire précisément quand ta patience est la plus mince. Héberger nous-mêmes les quatre polices de ce site répond au même instinct appliqué à l'appli : rien de ce dont l'intro a besoin ne devrait pouvoir échouer parce que quelqu'un est sur le mauvais Wi-Fi d'un hôtel.
Où vont vraiment les images
Uniquement des propriétés d'animation peu coûteuses — position et opacité, celles qu'un téléphone peut faire bouger sans recalculer la mise en page en dessous, jamais rien qui force un reflow en pleine séquence. Une salle de classe qui doit apparaître aussi souvent ne peut se permettre aucune propriété coûteuse sur un appareil ancien, parce qu'« appareil ancien » n'est pas un cas marginal ici — c'est une large part de ceux qui tiennent leur téléphone au moment précis où ils tendent la main vers quelque chose de bloqué.
Le corollaire, c'est que la majeure partie de ce qui ressemble à du mouvement dans l'intro est en réalité très peu de mouvement, mis en scène avec soin. Une porte qui s'ouvre, une silhouette qui fait quatre pas, un tableau qui bascule en place — rien de tout ça ne change beaucoup de pixels, ce sont surtout des pixels *chronométrés* qui changent, ce qui est une astuce moins coûteuse qu'elle n'y paraît de l'extérieur.
Ce dont on n'est pas encore sûrs
Le démarrage à froid, c'est l'écart honnête. La toute première interruption après un redémarrage du téléphone ou après que l'appli a été tuée en arrière-plan est plus lente que toutes celles qui suivent, parce que rien n'est encore « chaud » — pas de question en cache, pas de polices déjà analysées, pas de bundle JS déjà en mémoire. On n'a pas de solution propre à cette taxe du premier tap, à part garder l'appli aussi légère que possible et espérer que l'OS ne l'évince pas trop vite. Si ton tout premier blocage de la journée semble un poil plus lent que les suivants, c'est pour ça — et ce n'est pas quelque chose qu'on a choisi d'ignorer.
L'Android d'entrée de gamme est l'autre question ouverte — les téléphones pour lesquels ça compte le plus, puisqu'un accroc de deux secondes représente une part bien plus grande d'un budget de 300ms là-bas que sur un haut de gamme. On construit contre cette contrainte, pas contre l'appareil qu'on a par hasard entre les mains.