Une page qu'on trouve lente. On accuse le back, la base, le réseau, on part optimiser des requêtes SQL. Sauf que le serveur, mesures en main, répond en vingt millisecondes. La page part instantanément. Et pourtant, l'utilisateur reste devant un écran blanc pendant deux bonnes secondes avant que quoi que ce soit n'apparaisse.
Le goulot d'étranglement n'était pas d'obtenir la page. C'était de la dessiner. Un script placé tout en haut bloquait tout le reste, et rien ne pouvait s'afficher tant qu'il n'était pas téléchargé et exécuté. Le réseau était rapide. Le rendu, lui, était à l'arrêt.
Recevoir une page n'est pas l'afficher
Quand la réponse HTTP arrive, le navigateur ne « montre » pas le HTML. Il le construit. Il lit le HTML et en fait le DOM, un arbre de tous les éléments de la page. Il lit le CSS et en fait le CSSOM, l'arbre des styles. Il combine les deux, calcule la mise en page (où va chaque chose, à quelle taille), puis peint : il remplit enfin les pixels. Recevoir, construire l'arbre, calculer, peindre. Le premier pixel n'apparaît qu'au bout de cette chaîne, pas à la réception.
Et cette chaîne, le JavaScript peut la figer net. Un <script> classique posé dans le <head> arrête le navigateur en pleine construction : il ne parse plus, il ne peint plus, il attend que le script soit téléchargé et exécuté. Pourquoi ? Parce qu'un script a le droit de réécrire la page, alors le navigateur n'ose rien afficher qui pourrait être effacé la seconde d'après. C'est ce qu'on appelle un script bloquant. Un réseau parfait plus un script mal placé, et tu obtiens ta page blanche.
Le DOM n'est pas gratuit à toucher
Le DOM n'est pas qu'une étape de départ, c'est aussi ce que ton JavaScript manipule ensuite pour rendre la page vivante. Sauf que chaque fois que tu le modifies, le navigateur peut devoir recalculer la mise en page et repeindre. Touche le DOM une fois, c'est indolore. Touche-le cent fois dans une boucle, et tu déclenches cent recalculs : la page rame, saccade, alors que ton serveur, lui, n'a rien à se reprocher. Le coût est passé du réseau à l'écran, et on continue de chercher au mauvais endroit.
Ce que l'IA ne voit pas dans ton composant
L'assistant te génère un composant impeccable, qui compile et qui marche. Ce qu'il ne te dit pas, c'est où ce composant bloque le premier affichage, pourquoi la mise en page sautille au chargement, ou pourquoi une interaction saccade. Ça ne se lit pas dans le code, ça se lit dans la façon dont le navigateur l'exécute, sous la couche que la génération manipule. Réparer une page lente au serveur rapide, c'est comprendre le chemin de rendu, et ce chemin, aucune complétion ne le commente pour toi. La performance perçue vit en dessous du code généré.
Ce que je te conseille
Quand une page te paraît lente, mesure d'abord où : le temps de réponse du serveur et le temps jusqu'au premier pixel sont deux chiffres différents, et ils n'accusent pas le même coupable. Ne laisse pas un script bloquer ton premier affichage, repousse-le avec defer ou en bas de page. Et touche le DOM avec parcimonie : regroupe tes modifications au lieu de les distiller dans une boucle.
Un utilisateur ne mesure pas la vitesse de ton serveur. Il mesure le temps qu'il passe devant du blanc. Ce sont rarement les mêmes millisecondes.
Ce satellite fait partie du dossier Navigateur. Juste avant lui, la demande de la ressource : Le bug était dans l'enveloppe. Le vocabulaire : le DOM, le CSSOM, le script bloquant et le chemin de rendu critique.