Considérations générales sur les performances HTML

Pour créer un site Web qui se charge rapidement, la première étape consiste à recevoir rapidement du serveur pour le code HTML d'une page. Lorsque vous saisissez une URL dans le champ barre d'adresse du navigateur, celui-ci envoie une requête GET au serveur pour les récupérer. La première demande pour une page Web concerne une ressource HTML, et S'assurer que le code HTML arrive rapidement avec un délai minimal est l'un des principaux objectifs l'objectif.

Cette demande de code HTML initiale passe par plusieurs étapes, chacune prenant un certain temps. En réduisant le temps passé sur chaque étape, vous pouvez Premier octet (TTFB). Bien que le TTFB n'est pas la seule métrique sur laquelle vous devez vous concentrer lorsque de la vitesse de chargement des pages. Un TTFB élevé diffère en conséquence. le produit désigné par le terme « bon » des seuils pour des métriques comme Largest Contentful Paint (LCP) et First Contentful Paint (FCP).

Limiter le nombre de redirections

Lorsqu'une ressource est demandée, le serveur peut répondre par une redirection : avec une redirection permanente (une réponse 301 Moved Permanently) ou un un (réponse 302 Found).

Les redirections ralentissent le chargement des pages, car elles nécessitent que le navigateur effectue une une requête HTTP supplémentaire au nouvel emplacement pour récupérer la ressource. Il y a deux types de redirections:

1. Les redirections de même origine se produisent entièrement dans votre origine. Ces types vous gardez le contrôle, car la logique de gestion et les stocker entièrement sur votre serveur Web.
2. Redirections d'origine croisée initiées par une autre origine. Ces types de des redirections sont généralement hors de votre contrôle.

Les redirections multi-origines sont souvent utilisées par les annonces, les services de raccourcissement d'URL et d'autres des services tiers. Bien que les redirections multi-origines ne soient pas sous votre contrôle, vous pouvez toujours vérifier que vous évitez les redirections multiples disposer d'une annonce qui renvoie vers une page HTTP qui renvoie à son tour vers son site HTTPS, ou d'une redirection multi-origines arrivant à votre point de départ, mais déclenche une redirection de même origine.

Mettre en cache les réponses HTML

La mise en cache des réponses HTML est difficile, car celles-ci peuvent inclure des liens vers d'autres ressources critiques telles que des fichiers CSS, JavaScript, images et autres de données. Ces ressources peuvent inclure une empreinte unique dans leurs de noms de fichiers, qui changent en fonction du contenu d'un fichier. Autrement dit, les éléments mis en cache Le document HTML peut devenir obsolète après un déploiement, car il contiendrait des références à des sous-ressources obsolètes.

Néanmoins, une courte durée de vie du cache (plutôt que l'absence de mise en cache) peut présenter des avantages. comme autoriser la mise en cache d'une ressource au niveau d'un CDN, ce qui permet de réduire le nombre qui sont diffusées depuis le serveur d'origine et dans le navigateur, les ressources doivent être revalidées plutôt que téléchargées à nouveau. Cette approche fonctionne convient mieux au contenu statique qui ne change dans aucun contexte, et à une configuration la durée de mise en cache des ressources peut être définie sur un nombre de minutes approprié. Cinq minutes pour les ressources HTML statiques constituent un pari et garantit que les mises à jour périodiques ne passent pas inaperçues.

Si le contenu HTML d'une page est personnalisé (par exemple, vous ne souhaitez pas mettre en cache du contenu à diverses préoccupations, y compris concernant la sécurité et l'actualisation. Si une réponse HTML est mis en cache par le navigateur de l'utilisateur, vous ne pouvez pas invalider le cache. Il est il est donc préférable d'éviter la mise en cache du code HTML dans de tels cas.

Une approche prudente de la mise en cache HTML peut consister à utiliser ETag ou En-têtes de réponse Last-Modified. Un élément ETag (également appelé entité) tag : "header" est un identifiant qui représente de manière unique la ressource demandée, souvent en utilisant un hachage du contenu de la ressource:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Chaque fois que la ressource est modifiée, une nouvelle valeur ETag doit être générée. Activé requêtes ultérieures, le navigateur envoie la valeur ETag via la En-tête de requête If-None-Match. Si la valeur ETag sur le serveur correspond à celle envoyé par le navigateur, le serveur renvoie une réponse 304 Not Modified, et le navigateur utilise la ressource du cache. Même si cela entraîne la latence du réseau, une réponse 304 Not Modified est beaucoup plus petite qu'une ressource HTML.

Cependant, la latence réseau impliquée dans la revalidation de l'actualisation d'une ressource est cela reste une sorte d'inconvénient. Comme pour bien d'autres aspects du développement Web, les compromis et les compromis sont inévitables. C'est à vous de déterminer si le un effort supplémentaire de mettre en cache le code HTML de cette façon en vaut la peine, ou s'il est préférable de rester par mesure de sécurité et de ne pas du tout mettre en cache le contenu HTML.

Mesurer les temps de réponse du serveur

Si une réponse n'est pas mise en cache, le temps de réponse du serveur dépend fortement votre fournisseur d'hébergement et votre pile d'applications backend. Une page Web qui diffuse un générée dynamiquement, par exemple pour extraire des données d'une base de données, pour exemple – peut avoir un TTFB plus élevé qu'une page Web statique pouvant être diffusée sans délai de calcul important sur le backend. L'affichage d'un L'icône de chargement, puis la récupération de toutes les données côté client, déplace l'effort d'un environnement côté serveur plus prévisible un côté client. La réduction des efforts côté client se traduit généralement par une amélioration pour les métriques axées sur l'utilisateur.

Si les utilisateurs constatent un TTFB lent sur le terrain, vous pouvez divulguer des informations sur les endroits où le temps a été passé sur le serveur à l'aide du Server-Timing en-tête de réponse:

Server-Timing: auth;dur=55.5, db;dur=220

La valeur d'un en-tête Server-Timing peut inclure plusieurs métriques, ainsi qu'un pour chacune d'entre elles. Ces données peuvent ensuite être recueillies auprès des utilisateurs sur le terrain. à l'aide de l'API Navigation Timing et d'analyser les difficultés rencontrées par les utilisateurs les retards. Dans l'extrait de code précédent, l'en-tête de réponse inclut deux codes temporels:

• Temps d'authentification d'un utilisateur (auth), qui a duré 55,5 millisecondes.
• Temps d'accès à la base de données (db), qui a duré 220 millisecondes

Nous vous conseillons également d'examiner votre infrastructure d'hébergement disposer des ressources adéquates pour gérer le trafic reçu par votre site Web. Partagées les fournisseurs d'hébergement sont souvent sujets à un test de revenus beaucoup plus élevé, et les solutions dédiées qui offrent des temps de réponse plus rapides peut s'avérer plus coûteux.

Compression

Les réponses textuelles, comme les images HTML, JavaScript, CSS et SVG, doivent être compressés pour réduire la taille de leur transfert sur le réseau afin qu'ils puissent télécharger plus rapidement. Les algorithmes de compression les plus utilisés sont gzip et Brotli. Brotli offre une amélioration d'environ 15% à 20% par rapport à gzip.

La compression est souvent configurée automatiquement par la plupart des fournisseurs d'hébergement Web, il y a des points importants à prendre en compte si vous êtes en mesure de configurer ou modifier vous-même les paramètres de compression:

1. Utilisez Brotli si possible. Comme indiqué précédemment, Brotli offre un environnement offre une amélioration notable par rapport à gzip. Brotli est compatible avec tous les principaux navigateurs. Utilisez Brotli lorsque cela est possible, mais si votre site Web enregistre d'utilisateurs sur d'anciens navigateurs, utilisez gzip en remplacement, car toute compression vaut mieux qu'aucune compression.
2. La taille des fichiers est importante. Les très petites ressources (moins de 1 Kio) ne doivent pas être compressées. très bien, ou parfois même pas du tout. Efficacité de tout type de la compression des données nécessite d'avoir une grande quantité de données qu'un l’algorithme de compression peut fonctionner pour trouver plus de bits compressibles de données. Plus le fichier est volumineux, meilleure est la compression. envoient des ressources très volumineuses pour le simple fait qu'elles peuvent être compressées efficacement. Les ressources volumineuses, comme JavaScript et CSS par exemple, beaucoup plus de temps à analyser et à évaluer une fois que le navigateur décompressés et peuvent changer plus souvent, même s'ils n'ont ont légèrement changé, car toute modification entraîne un hachage de fichier différent.
3. Comprenez la compression dynamique et statique. Dynamique et statique la compression sont des approches différentes concernant quand une ressource doit être compressée. La compression dynamique compresse une ressource au moment où elle est demandée, et parfois à chaque fois qu'elle est demandée. Par ailleurs, La compression statique compresse les fichiers à l'avance, ne nécessitant aucune compression. à effectuer au moment de la demande. La compression statique supprime la latence liée à la compression elle-même, ce qui peut augmenter la réponse du serveur. en cas de compression dynamique. Les ressources statiques, telles que Les images JavaScript, CSS et SVG doivent être compressées de manière statique, tandis que les images HTML des ressources, en particulier si elles sont générées dynamiquement pour des opérations d'authentification doivent être compressés de manière dynamique.

Réaliser correctement la compression par vous-même n'est pas une mince affaire, et il est souvent préférable de un réseau de diffusion de contenu (CDN, Content Delivery Network), qui est abordé dans la section suivante, gérer cela pour vous. Cependant, le fait de connaître ces concepts peut vous aider à discerner si votre fournisseur d'hébergement utilise correctement la compression. Ces connaissances peuvent vous aider à trouver des moyens d'améliorer vos paramètres de compression afin de maximiser les bénéfices pour votre site Web.

Réseaux de diffusion de contenu (CDN)

Un réseau de diffusion de contenu (CDN) est un réseau distribué de serveurs qui met en cache les ressources du serveur d'origine et les diffuse à son tour des serveurs physiques plus proches de vos utilisateurs. La proximité physique de votre les utilisateurs réduisent le délai aller-retour (DAR), tandis que les optimisations telles que HTTP/2 ou Le protocole HTTP/3, la mise en cache et la compression permettent au CDN de diffuser le contenu plus rapidement que si elles étaient extraites de votre serveur d'origine. L'utilisation d'un CDN peut améliorer considérablement le TTFB de votre site Web dans certains cas.

Tester vos connaissances

À suivre: comprendre le chemin critique

Maintenant que vous connaissez certaines des considérations liées aux performances avec le code HTML de votre site Web, vous êtes mieux placé pour vous assurer qu'il peut se charger le plus rapidement possible, mais ce n'est qu'un début des performances. Ensuite, la théorie sous-jacente du chemin critique du rendu est abordés. Ce module décrit des concepts clés tels que le blocage de l'affichage qui bloquent l'analyse, ainsi que le rôle qu'elles jouent dans l'obtention de l'URL initiale d'une page s'affiche dans le navigateur aussi rapidement que possible.