Mesurer le chargement avec les API Navigation et Resource Timing

Les outils de laboratoire comme Lighthouse ou la limitation de connexion des outils pour développeurs sont précieux pour comparer des optimisations dans des conditions stables. Mais ils ne disent rien de la vitesse réellement vécue par vos visiteurs, sur leurs appareils et leurs réseaux. Pour cela, il faut des données de terrain, c’est-à-dire des mesures collectées directement chez les utilisateurs pendant qu’ils naviguent.

Les API Navigation Timing et Resource Timing donnent accès à ces durées dans le navigateur, en JavaScript. Pour le SEO, l’enjeu est direct : ces mesures alimentent vos Core Web Vitals de terrain, que vous pouvez ainsi mesurer sur le terrain, et vous aident à repérer précisément ce qui ralentit le chargement, là où les tests synthétiques restent muets. Vous passez du ressenti à la donnée chiffrée.

Navigation Timing et Resource Timing se ressemblent beaucoup mais ne mesurent pas la même chose. La première décrit la requête du document HTML lui-même, c’est-à-dire la navigation vers la page. La seconde décrit chaque ressource dépendante : fichiers CSS, JavaScript, images, polices et autres. Les deux exposent leurs durées dans un tampon de performances que vous interrogez avec JavaScript.

Une requête réseau passe par des phases distinctes : résolution DNS, négociation de la connexion (avec la poignée de main TLS en HTTPS), envoi de la requête puis réception de la réponse. Ce délai avant le premier octet correspond de près au TTFB, et savoir comprendre et mesurer le TTFB aide à isoler la part serveur du ralentissement. Chaque phase est exposée sous forme d’horodatage haute résolution. En soustrayant le début de la fin d’une phase, vous obtenez sa durée. Attention toutefois : certaines valeurs peuvent valoir zéro, par exemple lorsque le DNS provient d’un cache local ou pour les ressources d’autres origines qui n’autorisent pas le partage des durées.

Les méthodes getEntriesByType, getEntriesByName et getEntries conviennent pour une analyse ponctuelle, mais elles peuvent surcharger le thread principal si vous itérez sur de nombreuses entrées. L’approche recommandée est PerformanceObserver : il écoute les entrées au fur et à mesure et vous les transmet sans interrogation répétée. L’option buffered garantit que les entrées arrivées avant la création de l’observateur restent visibles.

Une fois les durées collectées, vous les transmettez à un point de terminaison pour les analyser, puis déboguer les performances sur le terrain. Privilégiez navigator.sendBeacon ou un fetch avec l’option keepalive : ces deux méthodes envoient la requête sans bloquer la page et survivent à la fermeture de l’onglet si nécessaire. Côté serveur, vous recevez une charge utile que vous pouvez décoder, traiter et stocker. Pensez à limiter le volume envoyé : transmettre l’intégralité des entrées à chaque visite serait excessif.