En tant que développeurs, et plus particulièrement en tant que développeurs front-end, nous parlons souvent des performances web en mesurant ce qui se passe à partir du moment où du contenu apparaît dans la fenêtre du navigateur et où nous pouvons interagir avec la page. Des indicateurs comme les Core Web Vitals sont essentiels dans cette évaluation :

• First Contentful Paint (FCP) mesure le temps écoulé depuis la navigation initiale jusqu'à l'affichage de la première partie du contenu.
• Largest Contentful Paint (LCP) correspond au moment où le contenu principal de la page est probablement chargé.
• Interaction to Next Paint (INP) mesure la rapidité avec laquelle la page réagit aux interactions des utilisateurs.

Cependant, qu'en est-il des événements qui se produisent avant que le premier octet d'une page ne soit reçu par le navigateur ? Ces événements peuvent-ils être mesurés et optimisés pour accélérer encore davantage le chargement des pages ?

Visualisation des événements pré-TTFB avec Sentry

La vue "Trace" de Sentry capture les événements qui se produisent avant que quoi que ce soit ne soit rendu dans la fenêtre du navigateur, appelés spans du navigateur. Ces événements se déroulent avant le Time to First Byte (TTFB) et incluent : cache, DNS, connexion, TLS/SSL, requête, et réponse. Le TTFB mesure le temps entre la requête d'une page et l'arrivée du premier octet de réponse.

Sentry utilise l'API Performance, notamment l'API Navigation Timing, pour enregistrer ces événements avec des horodatages précis. Même sans configuration supplémentaire, vous pouvez accéder directement à ces données dans le navigateur via la console de développement en tapant window.performance.

Comprendre les événements avant le TTFB

L'API Navigation Timing capture plusieurs événements cruciaux dans le chargement d'une page. Explorons ces événements et leur impact sur les performances :

• Cache du navigateur : Si le navigateur récupère une ressource depuis le cache, cet événement est mesuré entre les timestamps fetchStart et domainLookupStart.
• DNS : La recherche DNS traduit un nom de domaine en adresse IP. Le temps nécessaire pour cette opération est la différence entre domainLookupStart et domainLookupEnd.
• Connexion : Le navigateur ouvre une connexion avec le serveur. Cet événement est mesuré entre connectStart et connectEnd.
• TLS/SSL : Pour les connexions sécurisées via HTTPS, le navigateur et le serveur échangent des messages pour établir une connexion cryptée (TLS), mesurée via secureConnectionStart.
• Requête et réponse : Le navigateur envoie une requête pour une ressource (requestStart), puis reçoit le premier octet de réponse (responseStart), marquant ainsi le TTFB.

Accélérer les événements pré-TTFB

Voici quelques stratégies pour améliorer les performances de ces événements :

• Améliorer le cache du navigateur : Encouragez les utilisateurs à vider régulièrement leur cache, surtout si des performances lentes sont détectées.
• Optimiser la recherche DNS : Investir dans un fournisseur DNS avec un réseau mondial de points de présence (POP) peut réduire la latence. De plus, augmentez la valeur du TTL (Time to Live) des enregistrements DNS pour éviter des recherches DNS trop fréquentes.
• Accélérer la connexion et la négociation TLS : Utilisez des mécanismes comme la reprise de session TLS pour réduire les temps de négociation. L'attribut rel="preconnect" peut aussi aider à initier des connexions avec des ressources externes plus rapidement.

Réduire le TTFB pour des performances optimales

Le TTFB est l'un des éléments que les développeurs peuvent le mieux contrôler. Voici trois méthodes clés pour optimiser ce délai :

• Réduire les cascades de requêtes : Les requêtes en cascade retardent le TTFB. Minimisez les requêtes en série et favorisez les requêtes parallèles ou, mieux encore, servez des pages statiques via un CDN.
• Utiliser le cache : Pour les sites non dynamiques, les réponses HTML peuvent être mises en cache sur des serveurs proches des utilisateurs, réduisant ainsi la latence.
• Utiliser le streaming HTML : Le streaming HTML permet au navigateur de commencer à afficher du contenu avant de recevoir la page entière, ce qui réduit le TTFB.

Comprendre et optimiser les événements avant le TTFB permet d'améliorer considérablement les performances d'un site. Grâce aux outils comme Sentry et l'API Performance, les développeurs peuvent visualiser ces événements et identifier les goulots d'étranglement pour offrir une expérience utilisateur plus rapide et fluide.

Cet article s'inspire d'un article très détaillé publié par Sentry, une plateforme de surveillance des performances web et d'analyse des erreurs. Grâce à ses outils de traçage, Sentry permet de visualiser en détail les événements avant et après le TTFB, offrant ainsi aux développeurs un aperçu précieux pour identifier les goulots d’étranglement. Avec une meilleure compréhension de ces processus, il devient possible de faire des ajustements qui se traduiront par des temps de chargement plus rapides et une meilleure expérience utilisateur.