Maintenant, je travaille sur un projet pour un client. Il s'agit d'un site de commerce électronique, donc je suis très intéressé par certains aspects des performances. Pour commencer, ce sont divers indicateurs qui caractérisent le temps de chargement d'un site. Ensuite - c'est l'heure de début du rendu de la page, ce qui est important pour les visiteurs qui, après être entrés sur le site, veulent voir son contenu le plus rapidement possible (naturellement, tous les visiteurs du site entrent dans cette catégorie). Parmi les indicateurs de performance qui m’intéressent, il y a ceux qui reflètent les spécificités des activités de mon client. Par exemple: "À quelle vitesse l'image principale du produit se charge-t-elle?" Une analyse de tous ces indicateurs peut fournir des informations précieuses sur l'état du projet.
Cependant, il existe un indicateur qui, comme il semble, les développeurs frontaux n'accordent souvent pas assez d'attention. Il est temps de passer au premier octet (Time to First Byte, TTFB). Vous pouvez comprendre cela, vous pouvez et au moins partiellement pardonner aux développeurs cette attitude envers TTFB, surtout compte tenu du fait qu'ils voient cet indicateur comme quelque chose qui ne dépend que du backend des projets. Mais si nous essayons d'exprimer littéralement brièvement le problème concernant cet indicateur, nous pouvons dire ce qui suit: "Bien qu'une bonne valeur TTFB ne signifie pas nécessairement que le site Web le démontrant peut être considéré comme rapide, un mauvais indicateur TTFB indique presque certainement des problèmes avec les performances du projet."
Même si nous prenons en compte le fait que le développeur front-end peut être dans une position dans laquelle il n'est pas en mesure d'influencer indépendamment le backend et le TTFB, il est important de prendre en compte le fait que des valeurs TTFB élevées peuvent affecter de manière significative les performances du site. En conséquence, les efforts d'un développeur front-end cherchant à accélérer la vitesse du site Web ressembleront à un jeu de rattrapage. Cela s'applique, par exemple, à l'optimisation d'image, à la minimisation du volume de matériaux qui composent les sections les plus importantes du projet et au téléchargement asynchrone des polices Web. Cela ne veut pas dire que, sachant cela, vous pouvez abandonner et abandonner les optimisations frontales. Mais si le TTFB est trop élevé, toutes ces optimisations rappellent d'essayer de résoudre un problème dans des conditions où il a déjà fait du mal et quand il est trop tard pour résoudre ce problème. En fait, c'est pourquoi il est très important pour ceux qui développent le front-end de suivre de près l'indicateur TTFB, et il est très important, lorsque ses valeurs sont trop élevées, de prendre des mesures pour l'améliorer.
Qu'est-ce que le TTFB?
TTFB ne semble pas très informatif ( image en taille réelle )TTFB est un indicateur qui semble, pour le dire légèrement, opaque. Il est tellement influencé par lui que j'ai le sentiment que nous sommes tout le temps en train de brosser son analyse sérieuse. Beaucoup pensent que le TTFB n'est que le temps qu'il faut au serveur pour préparer une réponse, mais ce n'est, en fait, qu'une petite partie de ce qui affecte le TTFB.
La première chose sur laquelle j'aimerais attirer votre attention, c'est qu'en apprenant ce que les gens sont généralement très surpris. Nous parlons du fait que TTFB inclut le temps que la demande du client passe sur le réseau vers le serveur, et le temps qu'il prend le chemin de réponse du serveur au client. C'est ce que l'on appelle le «temps aller-retour» (Round Trip Time, RTT). TTFB n'est pas seulement un certain temps passé par le serveur à préparer une réponse. C'est aussi le temps consacré à la manière dont les données vont de client en serveur et de serveur en client (ces données contiennent bien entendu le «premier octet» qui nous intéresse).
Maintenant, armé de ces connaissances, nous pouvons facilement comprendre la raison pour laquelle lors de la visualisation de sites à partir d'appareils mobiles, l'indicateur TTFB est souvent simplement indécent. Il est fort possible que plus tôt dans de telles situations, vous ayez posé la question suivante: «Je suis sûr que le serveur ne sait pas que je consulte le site à partir d'un mobile. Comment alors augmente-t-il le TTFB? La raison en est que, en règle générale, les connexions de réseau mobile sont des connexions à latence élevée. Si l'indicateur RTT, qui reflète le temps nécessaire pour que les données passent du téléphone au serveur et vice-versa, est, par exemple, de 250 ms, le TTFB augmentera de la valeur correspondante.
Si je souhaite que les lecteurs de ce document n'en retirent qu'une seule idée majeure, je formulerais cette idée comme suit: «Les retards du réseau affectent le TTFB».
Qu'est-ce qui affecte le TTFB? En fait - beaucoup de tout. Voici une liste loin d'être complète de ce qui contribue à la formation de cet indicateur. Les éléments de cette liste sont dans un ordre aléatoire.
- Retards du réseau. Comme déjà mentionné, TTFB inclut le temps nécessaire pour envoyer une demande au serveur et renvoyer une réponse du serveur. Prenons, par exemple, le temps requis pour une session d'échange de données entre un appareil situé à Londres et un serveur situé à New York. Idéalement, lorsque vous utilisez une connexion à fibre optique, c'est 28 ms. Mais cela est basé sur de nombreuses hypothèses très optimistes. En réalité, vous devriez vous attendre à quelque chose comme 75 ms . C'est pourquoi il est si important d'utiliser CDN. Aujourd'hui encore, à l'ère d'Internet, la proximité géographique d'une certaine entreprise et de ses clients est un atout.
- Acheminement Si vous utilisez CDN (et il devrait en être ainsi!), Alors la demande de votre client, par exemple, de Leeds, peut être redirigée vers le centre de données MAN uniquement afin qu'en conséquence, il s'avère que la ressource dont le client a besoin ne se trouve pas dans le cache PoP correspondant . Ensuite, la demande sera redirigée vers le vrai serveur avec vos documents afin de transmettre néanmoins au client ce dont il a besoin. Si ce serveur est situé, par exemple, en Virginie, tout ce qui précède entraînera une augmentation sérieuse du TTFB sans raison apparente.
- Travaillez avec des fichiers. Même si le serveur lit simplement les données statiques de son système de fichiers, telles que des images ou des fichiers de style, cette opération prend un certain temps. Cette fois fait également partie du TTFB.
- Priorisation Le protocole HTTP / 2 dispose de mécanismes pour hiérarchiser le traitement des demandes. En conséquence, il peut s'avérer que les demandes de faible priorité peuvent être retardées sur le serveur, laissant la place à des demandes de haute priorité. Même si vous ne tenez pas compte des mécanismes de priorisation HTTP / 2 et supposez que tout fonctionne correctement, ces retards attendus peuvent contribuer au TTFB.
- Exécution d'applications. En fait, cela est assez évident, mais je voudrais noter que le temps requis pour exécuter les applications serveur affecte sérieusement TTFB.
- Requêtes de base de données. Si vous devez demander quelque chose à la base de données pour former la page, le temps pour terminer une telle opération sera également inclus dans TTFB.
- Appels API Si des données de certaines API (internes ou externes) sont nécessaires pour préparer la page, les appels à ces API affecteront TTFB.
- Rendu du serveur Il est bien évident que le rendu côté serveur prend du temps, ce temps est facile à évaluer, mais cela n'annule pas la contribution de cette opération au TTFB.
- Hébergement pas cher. Si vous utilisez un hébergement bon marché, en essayant d'économiser autant que possible et en sacrifiant les performances, cela signifie généralement qu'un certain nombre d'autres projets utilisent le serveur sur lequel se trouve votre projet. Peut-être un montant considérable. Par conséquent, une personne qui utilise un hébergement bon marché peut s'attendre à une baisse des performances du serveur, ce qui peut affecter la capacité du projet à traiter les demandes. En fait, nous parlons du fait que la puissance du matériel serveur n'est pas suffisante pour satisfaire les besoins de l'application.
- Attaques DDoS, charge élevée sur le projet. Nous continuons ici le sujet discuté dans le paragraphe précédent de cette liste. À savoir, si la charge sur le serveur augmente et que le projet ne prévoit pas une mise à l'échelle flexible des capacités du serveur, cela conduit au fait que l'équipement commence à fonctionner à la limite. Et, par conséquent, les performances des applications diminuent.
- WAF, équilibreurs de charge. Les services, tels que le WAF ou les équilibreurs de charge situés devant l'application serveur, augmentent le TTFB.
- Certaines fonctionnalités de CDN. L'utilisation de CDN est un facteur qui a certainement un effet bénéfique sur le TTFB, mais certaines fonctionnalités des CDN peuvent aggraver la situation. Par exemple, il s'agit du pliage de demande , ESI , etc.
- Retards au «dernier kilomètre». Lorsque nous parlons d'un ordinateur londonien qui accède à un serveur situé à New York, nous simplifions généralement la situation, la réduisant presque au fait que l'ordinateur et le serveur sont connectés directement l'un à l'autre. Mais en réalité, tout est beaucoup plus compliqué. Le signal entre l'ordinateur et le serveur passe par de nombreux intermédiaires. Notre routeur l'envoie au fournisseur; à partir d'un réseau sans fil, il pénètre dans un câble posé au fond de l'océan ... Les retards sur le "dernier kilomètre" incluent toutes les difficultés qui entravent le transfert de données entre les terminaux.
Un TTFB de 0 ms est un rêve de pipe. Par conséquent, il est important de noter qu'il n'y a rien dans la liste qui affecte toujours négativement le TTFB ou aggrave toujours cet indicateur. Cette liste est mieux comprise comme une description de la structure TTFB d'un projet. Mon objectif n'est pas de critiquer certaines technologies, mais de montrer comment certaines technologies peuvent influencer le TTFB. Et, pour être honnête, étant donné combien de choses se produisent avant que le client ne reçoive le premier octet de la réponse du serveur, il est déjà surprenant que les sites se chargent généralement.
Découvrir le mystère avec TTFB
Maintenant, espérons-le, TTFB ne semble plus aussi mystérieux. Et si vous passez un peu de temps sur l'implémentation de l'API
Server Timing , vous pouvez commencer à mesurer les indicateurs de temps de serveur difficiles et à les envoyer aux systèmes clients. Cela permettra aux développeurs Web de détecter et d'éliminer les goulots d'étranglement potentiels qui étaient auparavant cachés à leurs yeux.
L'API de synchronisation de serveur permet aux développeurs d'étendre les réponses aux requêtes avec l'en
Server-Timing tête HTTP de
Server-Timing facultatif. Il contient des informations temporelles mesurées par l'application elle-même.
C'est ce mécanisme que nous avons utilisé l'année dernière lorsque nous travaillions sur le BBC iPlayer.
Un nouvel en-tête de synchronisation du serveur peut être ajouté à n'importe quelle réponse ( image en taille réelle )
Notez que la synchronisation du serveur met également l'accent sur le système. Au cours de son travail, vous devez mesurer les indicateurs pertinents et remplir l'en
Server-Timing tête
Server-Timing . Le navigateur permet uniquement au développeur frontal de visualiser ces données à l'aide des outils appropriés.
Maintenant, directement dans le navigateur, vous pouvez voir la structure TTFB ( image en taille réelle )Si vous souhaitez implémenter l'API Server Timing, jetez un œil à
ce matériel .
Résumé
Il est très important que les développeurs Web comprennent dans quelle mesure le TTFB affecte ce qu'ils appellent les «performances du site». Le temps du premier octet est une certaine frontière, après le franchissement, dont on peut parler d'optimisation de site Web. Plus cet indicateur est bas, mieux c'est.
Chers lecteurs! Optimisez-vous vos projets web avec TTFB?
