Pourquoi une page semble lente alors que tous les métriques du serveur indiquent qu'elle est rapide

Quelqu’un dit que votre site est lent. Vous ouvrez le tableau de bord et tout est au vert. Les temps de réponse dans les bas centaines de millisecondes, pas d’erreurs, pas de saturation, rien au-dessus du seuil n’importe où.

Vous avez tous les deux raison, et la raison n’est pas subtile une fois que vous la voyez. Vos métriques de serveur et votre visiteur mesurent deux choses différentes, et le chevauchement entre elles est plus petit que presque n’importe qui ne l’attend.

Deux horloges, commencées à des moments différents

L’horloge de votre serveur commence quand une demande arrive et s’arrête quand elle finit d’écrire une réponse. Cet intervalle est celui que votre surveillance rapporte, et c’est une vraie mesure d’une vraie chose.

L’horloge du visiteur commence quand il clique, et elle ne s’arrête pas jusqu’à ce que la page ait dessiné quelque chose pour laquelle il est venu. Entre ces deux moments s’intercalent une recherche DNS, une connexion TCP, une poignée de main TLS, le travail de votre serveur, la réponse qui revient, l’analyse HTML, les feuilles de style et les polices et les scripts que HTML demande ensuite, dont chacun répète la plupart de ce qui précède, et finalement le rendu.

Votre serveur a été impliqué dans une étape de cela. Une page peut passer 80 millisecondes sur votre serveur et quatre secondes à devenir utile, et rien dans votre surveillance applicative n’est incorrect quand elle dit 80 millisecondes.

Le nombre qui décrit le serveur et ceux qui décrivent l’expérience

Le nombre côté serveur est Time to First Byte, que Google décrit comme mesurant « le temps entre commencer à naviguer vers une page et le moment où le premier octet d’une réponse commence à arriver ». Leurs conseils sont que « la plupart des sites devraient s’efforcer d’avoir un TTFB de 0,8 secondes ou moins ».

Mais ils sont explicites sur ses limites: « Parce que TTFB n’est pas une métrique Core Web Vitals, il n’est pas absolument nécessaire que les sites atteindent le seuil « bon » TTFB, à condition que cela ne compromette pas leur capacité à bien scorer sur les métriques qui comptent. »

Les métriques qui comptent sont les trois Core Web Vitals, et chacune répond à une question qu’une personne reconnaîtrait réellement.

Largest Contentful Paint est le moment où la plus grande chose à l’écran finit de se dessiner, ce qui est le proxy machine le plus proche pour « la page est apparue ». L’objectif est que « LCP devrait se produire dans les 2,5 secondes à partir du moment où la page commence à charger ».

Interaction to Next Paint est le temps que la page met à répondre visiblement après que quelqu’un interagisse avec elle: « les pages devraient avoir un INP de 200 millisecondes ou moins ». Elle a remplacé First Input Delay en tant que Core Web Vital stable en 2024, et le changement compte, car FID mesurait uniquement le délai avant le début du traitement tandis que INP mesure tout le chemin jusqu’au prochain affichage. Une page qui acceptait votre clic instantanément et puis gela a obtenu un bon score sur l’ancienne métrique.

Cumulative Layout Shift n’a rien à voir avec la vitesse. Elle mesure la quantité de mouvement de la page pendant le chargement, et l’objectif est « 0,1 ou moins ». Elle est dans cette liste parce qu’une page qui saute sous votre doigt semble cassée d’une manière qui se lit pour la personne comme lente, même quand rien ne l’était.

Le détail qui résout la plupart de ces arguments

Core Web Vitals sont évaluées au « 75ème percentile des chargements de page, segmentées entre les appareils mobiles et de bureau ».

Pas la moyenne. Le 75ème percentile, ce qui signifie qu’une visite sur quatre est pire que le nombre que vous regardez, et c’est délibéré. Une moyenne est dominée par les gens qui avaient déjà une bonne expérience. Vos propres visites sont dans cette majorité confortable presque par construction, puisque vous êtes près de vos serveurs, sur une bonne connexion, sur une machine rapide, avec un cache chaud.

Donc, quand un visiteur dit que le site est lent et votre tableau de bord dit qu’il est rapide, l’interprétation honnête n’est pas que l’un de vous se trompe. C’est que vous regardez la moyenne d’une distribution dont la queue est la plainte entière.

Faible

« Le site est lent. » Vérifié le tableau de bord, temps de réponse p50 90 ms, fermeture car impossible à reproduire.

Mieux

« Lent sur la page produit, environ 6 secondes avant que quelque chose apparaisse, sur données mobiles. » LCP est la métrique, TTFB était correct, donc le temps se passe quelque part après l'arrivée de la réponse.

Où le temps va réellement

Une fois que vous acceptez que l’écart est réel, il y a seulement quelques endroits où il se cache, et ce sont les mêmes quelques fois chaque fois.

Ressources bloquantes de rendu. Le HTML est arrivé rapidement puis a demandé une feuille de style, et le navigateur ne peindra pas jusqu’à ce qu’il l’ait. Chaque requête bloquante dans la tête s’ajoute au temps avant que quelque chose n’apparaisse.

Polices. Une police web qui n’est pas préchargée peut laisser le texte invisible ou restyé bien après que la mise en page soit autrement terminée, ce qui retarde à la fois le plus grand affichage et, s’il reflue, alimente le décalage de mise en page.

Images sans dimensions. La cause unique la plus commune du décalage de mise en page. Le navigateur ne peut pas réserver l’espace, donc tout ce qui est en dessous bouge quand l’image arrive.

JavaScript, sur un appareil lent. Celui-ci est invisible sur une machine de développement par construction. L’analyse et l’exécution d’un gros bundle coûtent une fraction de seconde sur un ordinateur portable et plusieurs secondes sur un téléphone milieu de gamme, et la page ne répond pas aux appuis pour la totalité de celui-ci.

La distance. Un visiteur de l’autre côté du monde paie le trajet aller-retour plusieurs fois avant même que votre serveur rapide ne soit demandé, ce qui est la même raison qu’une dégradation en amont vous retombe dessus plutôt que sur celui qui l’a causée.

Ce qu’il faut demander au lieu de « pouvez-vous être plus spécifique »

« C’est lent » ne peut pas être agi, mais les trois choses qui le rendent actif sont toutes faciles à demander, et aucune d’elles n’exige que le rapporteur comprenne ce qui précède.

• Quelle page et ce qu’ils attendaient. Lent à apparaître du tout, lent à répondre après un appui, ou bouger autour pendant qu’il chargeait. Ce sont trois métriques différentes et trois causes différentes.
• Sur quoi et sur quelle connexion. Un Android vieux de cinq ans sur données mobiles et un bureau sur la fibre ne sont pas le même site.
• À peu près combien de temps et si c’est toujours. La différence entre « toujours environ six secondes » et « parfois il s’accroche » est la différence entre une page lourde et un défaut intermittent, et ils ne partagent aucune solutions.

Et celui qui élimine entièrement la devinette est un enregistrement des demandes telles qu’elles se sont réellement produites sur leur machine, car le journal réseau montre où les secondes se sont écoulées plutôt que où vous supposez qu’elles se sont écoulées.

Ce qu’il faut en tirer

Un tableau de bord vert n’est pas la preuve que le site est rapide. C’est la preuve que la partie que vous avez instrumentée est rapide, et cette partie est une étape dans une séquence que le visiteur expérimente entièrement.

Mesurez ce qu’ils expérimentent, au percentile où vivent les plaintes plutôt qu’à la moyenne, et traitez votre propre expérience de votre propre site comme le point de données le moins représentatif auquel vous avez accès.