Mesurer le temps de chargement des pages web avec les Performance Timings

Il y a quelques semaines, nous apprenions le retour du support de l’API Navigation Timing par Safari. Cette API, accessible en JavaScript et aujourd’hui disponible sur les principaux navigateurs web, implémente une recommandation du W3C. Elle permet de consulter des métriques indispensables à la compréhension des différents temps forts du chargement de vos pages, notamment via les performance timings.

Performance Timings

Les performance timings font partie de la recommandation Navigation Timings. Leur but : pouvoir détailler les principales étapes techniques du chargement d’une page, et ce de la prise en charge de la requête à la fin du chargement de toutes les ressources (exceptées celles chargées de façon asynchrones après l’événement onload).

Voici un récapitulatif de ces événements dans le temps :

récapitulatif performance timing

On dénombre pas moins de 20 événements, pouvant être regroupés en 3 grandes phases :

  1. ce qui se passe avant l’envoi de la requête HTTP vers le serveur
  2. l’envoi de la requête/la réception de la réponse
  3. le traitement de la réponse et la construction de la page web

Pour chaque événement, un timestamp est disponible (nombre de millisecondes depuis le 01/01/1970). Pour obtenir le délai entre 2 événements, il suffit alors de calculer la différence entre leurs valeurs. Nous vous proposons maintenant de découvrir le détail de ces 3 grandes phases

Préparation de la requête

Pour commencer, le navigateur prend en charge la demande de l’internaute d’accéder à une page web (navigationStart). Ensuite, viennent les temps liés aux éventuelles redirections nécessaires pour accéder à la page de destination, à condition que ces redirections opèrent sur le même domaine (redirectStart et redirectEnd).

Puis arrive le fetchStart, qui indique que le navigateur s’apprête à vérifier s’il dispose de la ressource souhaitée dans son cache.

En l’absence de redirection sur le même domaine et si la ressource était absente du cache, on trouvera le temps de résolution du domaine (domainLookupStart et domainLookupEnd). S’en suivra le délai requis pour établir la connexion au serveur (connectStart et connectEnd), incluant potentiellement un événement supplémentaire dans le cas d’une connexion sécurisée (secureConnectionStart).

Exécution de la requête/réception de la réponse

La deuxième phase des performance timings est certainement la plus simple à appréhender. La connexion au serveur distant est établie, il reste à envoyer la requête HTTP (requestStart), et recevoir sa réponse (responseStart et responseEnd). La différence entre responseStart et requestStart permet d’obtenir le Time To First Byte. Vous aurez une idée précise du temps de traitement niveau serveur en enlevant la latence à cette valeur.

Traitements navigateur

Reste la dernière étape du chargement, à la fois la plus complexe et celle regroupant 90% de l’attente perçue par l’internaute selon la règle d’or établie par Steve Souders : les traitements frontend. Le navigateur reçoit une réponse sous forme textuelle, qu’il reste à interpréter et à compléter de nouveaux contenus pour pouvoir afficher la page finale.

La première étape consiste à transformer le code HTML en une arborescence (DOM) pouvant être interprétée  et manipulée par le navigateur. La durée de cette construction s’obtient en calculant la différence entre domLoading et domInteractive.

Ensuite vient l’événement domContentLoaded, qui permet de déterminer à partir de quand les arbres DOM et CSSOM sont tous les deux prêts. A cet instant, les scripts synchrones et ceux déclarés en defer ont été exécutés.

Une fois toutes les ressources de la page chargées et interprétées, l’événement domComplete est déclenché. Vient alors la dernière étape : le navigateur lance son événement onload  (loadEventStart et loadEventEnd), qui peut entraîner le déclenchement de nouveaux comportements asynchrones.

 

On notera qu’à tout moment, l’utilisateur peut stopper le chargement de la page. Vous disposerez alors des événements unloadEventStart et unloadEventEnd.

 

Les performance timings fournissent ainsi de bonnes bases pour détecter les goulots d’étranglement du chargement de votre page. Mais ces derniers sont loin de vous permettre de comprendre le chargement du point de vue utilisateur, puisque ne donnant pas d’indication sur l’interactivité ni le rendu de la page.

Le start render, le speed index ou encore le Visually Complete sont autant de métriques précieuses qui vous aideront dans vos démarches d’optimisation, et qui seront très bientôt l’objet d’un nouvel article.