Performances de chargement initiales pour les développeurs React : analyse approfondie

Discussion approfondie sur les performances de chargement du premier écran de la page Web et les stratégies d'optimisation

Table des matières

1. Introduction aux indicateurs de performance de chargement initial
2. Présentation des outils de développement de performances
   1. Paramètres du projet
   2. Explorez les DevTools essentiels
3. Explorez différentes conditions de réseau
   1. Serveur très lent
   2. Simulation de différentes bandes passantes et latences
   3. Importance du CDN
4. Répéter les performances d'accès
   1. Contrôlez le cache du navigateur à l'aide de l'en-tête Cache-Control
   2. Cache-Control et outils de regroupement modernes
   3. Mon cas d'utilisation simple a-t-il vraiment besoin de savoir tout cela ?

Avec l'essor de la génération de code basée sur l'IA, l'importance de l'écriture de code React diminue. Désormais, n’importe qui et n’importe quoi peut écrire des applications dans React. Mais écrire du code n’a toujours été qu’une partie du puzzle. Nous devons encore déployer nos applications quelque part, les exposer aux utilisateurs, les rendre robustes, rapides et faire un million d'autres choses. Aucune IA ne peut les prendre en charge. Du moins pas encore.

Concentrons-nous donc sur la manière de rendre votre candidature rapide aujourd'hui. Pour ce faire, nous devons nous éloigner de React pendant un certain temps. Parce qu'avant de faire quelque chose de rapide, nous devons d'abord savoir ce qu'est le « rapide », comment le mesurer et ce qui peut affecter ce « rapide ».

Alerte spoiler : React n'apparaîtra pas dans cet article, sauf pour les projets d'apprentissage. Aujourd'hui, nous nous concentrerons sur les bases : comment utiliser les outils de performance, une introduction à Core Web Vitals, le panneau de performances de Chrome, ce qu'est la performance de chargement initiale, quelles métriques peuvent la mesurer et comment les contrôles de cache et les différentes conditions du réseau l'affectent.

Introduction aux indicateurs de performance de chargement initial

Que se passe-t-il lorsque j'ouvre mon navigateur et que j'essaie d'accéder à mon site Web préféré ? Je tape "https://www.php.cn/link/63ea3fef646010a7255aec506626ea32 dans la barre d'adresse pour faire une requête GET et recevoir une page HTML en retour.

Le temps nécessaire pour faire cela est appelé « Time To First Byte » (TTFB) : le temps entre le moment où la requête est envoyée et le moment où les résultats commencent à arriver. Après avoir reçu le HTML, le navigateur doit maintenant convertir ce HTML en un site Web utilisable le plus rapidement possible.

Il restitue d'abord ce qu'on appelle le « chemin critique » à l'écran : le contenu le plus petit et le plus important pouvant être montré à l'utilisateur.

Ce qui doit être inclus dans le chemin clé est un problème complexe. Idéalement, tout doit permettre aux utilisateurs de voir immédiatement l'expérience complète. Mais le même - rien, car il doit être aussi rapide que possible car il s'agit d'un chemin "clé". Les deux sont impossibles en même temps, vous devez donc faire des compromis.

Le compromis est comme ça. Le navigateur suppose de créer un "chemin clé", il a certainement besoin au moins des types de ressources suivants:

• Le HTML initial qu'il a reçu du serveur-UTISER pour créer des éléments DOM réels et construire des expériences.
• Les fichiers CSS importants de ces éléments initiaux - ailleurs, si elle continue sans les attendre, les utilisateurs verront un contenu étrangement indicible "scintillant" au début.
• Les fichiers JavaScript clés sont modifiés simultanément.

Le navigateur obtient le premier (HTML) dans la demande initiale du serveur. Il a commencé à l'analyser et à extraire les liens des fichiers CSS et JS qui doivent terminer le "chemin clé" dans ce processus. Ensuite, il envoie une demande pour les obtenir du serveur, attendez qu'ils les téléchargent, les traitent, combinent tous ces éléments ensemble et dessinent les pixels "Chemin de clé" à l'écran à un certain moment.

Étant donné que le navigateur ne peut pas terminer le rendu initial sans ces ressources clés, ils sont appelés "Rendu les ressources de blocage". Bien sûr, toutes les ressources CSS et JS ne sont pas bloquées. Habituellement uniquement:

La plupart des CS, qu'il s'agisse d'une union intérieure ou de la balise
• .
L'étiquette n'est pas des ressources JavaScript asynchrones ou retardées.

L'ensemble du processus de rendu du "chemin clé" est approfondi dans:

Le navigateur commence à analyser le HTML initial
Dans le processus, il extrait les liens des ressources CSS et JS de l'étiquette.
Ensuite, il démarre le processus de téléchargement et attend les ressources de blocage pour terminer le téléchargement.
En attendant, si possible, il continuera de gérer HTML.
Après avoir reçu toutes les ressources clés, ils les géreront également.
Enfin, il complète les pixels réels de l'interface.

Cette fois est ce que nous appelons

dessiner (fp) pour la première fois. C'est la première fois que les utilisateurs ont la possibilité de voir quelque chose à l'écran. La question de savoir si cela se produira dépend du HTML envoyé par le serveur. S'il y a des choses significatives, telles que du texte ou des images, ce sera également le moment du premier dessin de contenu (FCP). Si HTML est juste une div vide, le FCP se produira plus tard.

Le premier dessin de contenu (FCP)

est l'un des indicateurs de performance les plus importants, car il mesure le chargement initial de

perçu . Fondamentalement, il s'agit d'une impression préliminaire de la vitesse du site Web des utilisateurs.

jusqu'à ce moment, l'utilisateur regardait simplement l'écran vide pour mordre les ongles. Selon Google, le bon numéro FCP est en dessous de 1,8 seconde . Après cela, l'utilisateur commencera à perdre son intérêt pour le contenu que votre site Web peut fournir et peut commencer à partir.

Cependant, le FCP n'est pas parfait. Si le site Web commence à se charger avec un rotor ou un écran de chargement, l'indicateur FCP représentera le contenu. Mais il est peu probable que les utilisateurs ne soient que sur le site Web pour afficher l'écran de chargement de fantaisie. La plupart du temps, ils veulent accéder au contenu.

Pour cette raison, le navigateur doit terminer son début. Il attend le reste du JavaScript non bloquant, l'exécute et applique ses modifications au DOM à l'écran, télécharger des images et améliorer l'expérience utilisateur d'autres manières.

À un certain point du processus, le temps de dessin de contenu maximal se produira. Ce n'est pas le premier élément comme FCP, mais le plus grand texte, image ou vidéo visible dans la zone de contenu principale de la page - le port visible. Selon Google, ce nombre doit être inférieur à 2,5 secondes . Plus que ce nombre, les utilisateurs penseront que le site Web est lent.

Tous ces indicateurs font partie des vitaux Web de Google - un ensemble d'index pour l'expérience utilisateur sur la page. LCP est l'un des trois Core Web vitals

-trois indicateurs représentent les différentes parties de l'expérience utilisateur. LCP responsable Performance de chargement . Ces indicateurs peuvent être mesurés via un phare. Lighthouse est un outil de performance Google. Vous pouvez l'utiliser comme module de nœud afin qu'ils puissent l'exécuter pendant la construction et les détecter avant de revenir dans l'environnement de production. Utilisez la version intégrée Devtools pour le débogage et les tests locaux. Et la version Web pour vérifier les performances des concurrents.

Overvtools Présentation

Ce qui précède est une explication très brève et simplifiée du processus. Mais il existe de nombreuses abréviations et théories qui font confondre les gens. Pour moi personnellement, lire un tel contenu est inutile. À moins que je puisse le voir en action et que je puisse le faire fonctionner moi-même, j'oublierai immédiatement tout.

Pour ce thème spécifique, je trouve que le moyen le plus simple de comprendre pleinement ces concepts est de simuler différentes scènes sur la page semi-dire et de voir comment elles changent les résultats. Donc, avant d'autres théories (il y en a beaucoup!), Faisons-le.

Paramètres du projet

Si vous le souhaitez, vous pouvez effectuer toute la simulation suivante sur votre propre projet - les résultats devraient être plus ou moins. Cependant, afin d'être plus contrôlable et simplifié, je vous suggère d'utiliser le projet d'apprentissage que j'ai préparé pour cet article. Vous pouvez le visiter ici:

https://www.php.cn/link/def14e8541708294d7558fdf2126ef27

Installez d'abord toutes les dépendances:

<code>npm install</code>

Projet de construction :

<code>npm run build</code>

Démarrez le serveur :

<code>npm run start</code>

Vous devriez aller sur "https://www.php.cn/link/66e8d052ec2230c66bd11ee6b5a0e3c8.

Explorez les DevTools essentiels

Ouvrez le site Web que vous souhaitez analyser dans Chrome et ouvrez Chrome DevTools. Trouvez-y les panneaux Performance et Lighthouse et assemblez-les. Nous avons besoin des deux.

De plus, avant de faire quoi que ce soit d'autre dans cet article, assurez-vous que la case « Désactiver le cache » est activée. Il devrait se trouver dans le panneau Réseau le plus haut.

De cette façon, nous pouvons simuler les nouveaux visiteurs - des personnes qui n'ont jamais visité notre site Web et qui n'ont pas encore mis en cache de ressources.

Explorez le panneau Phare

Ouvrez maintenant le panneau Phare. Vous devriez y voir certains paramètres et un bouton « Analyser le chargement de la page ».

Pour cette section, nous nous intéressons au pattern "Navigation" - qui fournira une analyse détaillée du chargement initial de la page. Le rapport vous donnera un score comme celui-ci :

Les performances locales sont impeccables, pas de surprise : tout "fonctionne sur ma machine".

Il y aura également les indicateurs suivants :

Les valeurs FCP et LCP dont nous avons besoin pour cet article se trouvent tout en haut.

Ci-dessous, vous verrez une liste de suggestions qui peuvent vous aider à améliorer votre score.

Chaque suggestion peut être développée, où vous trouverez des informations plus détaillées et parfois des liens expliquant ce sujet spécifique. Tous ces éléments ne sont pas exploitables, mais c'est un excellent outil pour commencer à en apprendre davantage sur les performances et à comprendre les différents éléments qui peuvent les améliorer. Vous pourriez passer des heures à lire ces rapports et les liens associés.

Cependant, Lighthouse ne fournit que des informations de surface et ne vous permet pas de simuler différents scénarios tels qu'un réseau lent ou un processeur faible. C'est simplement un excellent point d'entrée et un excellent outil pour suivre les performances au fil du temps. Pour mieux comprendre ce qui se passe, nous avons besoin du panneau Performances.

Explorez le panneau de performances

Lors du premier chargement, le panneau Performances devrait ressembler à ceci :

Il affiche trois métriques Web Vitals de base, dont notre LCP, vous permettant de simuler des réseaux et des processeurs lents, ainsi que la possibilité d'enregistrer les détails des performances au fil du temps.

Recherchez et cochez la case "Capture d'écran" en haut du panneau, puis cliquez sur le bouton "Enregistrer et recharger" et lorsque le site Web se recharge, arrêtez l'enregistrement. Ce sera votre rapport détaillé de ce qui est arrivé à votre page lors de son chargement initial.

Ce rapport contiendra plusieurs sections.

Tout en haut se trouve la section habituelle « Aperçu de la chronologie » .

Ici, vous verrez quelque chose se passer sur le site, mais rien de plus. Lorsque vous le survolez, une capture d'écran de ce qui se passe s'affichera et vous pourrez sélectionner et zoomer sur une plage spécifique pour un examen plus approfondi.

En dessous se trouve la section Réseau. Une fois développé, vous verrez toutes les ressources externes en cours de téléchargement et leur heure exacte sur la chronologie. Lorsque vous survolez une ressource spécifique, vous verrez des détails sur le temps passé à chaque étape du téléchargement. Les ressources avec un coin rouge indiqueront des ressources bloquantes.

Si vous utilisez le projet d'apprentissage, vous verrez exactement la même image, et celle-ci correspond mot pour mot à ce que nous avons vu dans la section précédente :

• Au début, il y a un bloc bleu - une demande pour obtenir le HTML du site
• Une fois le chargement terminé, il y a une brève pause (analyse du code HTML) et deux demandes de ressources supplémentaires sont effectuées.
• L'un d'eux (jaune) est destiné à JavaScript - non bloquant.
• L'autre (violet) est pour CSS, qui est bloquant.

Si vous ouvrez maintenant le code de votre projet d'apprentissage et affichez le dossier dist, le code source correspondra à ce comportement :

• Il y aura un fichier index.html et des fichiers .css et .js dans le dossier des actifs
Dans la section
• du fichier index.html, il y aura une balise pointant vers le fichier CSS. Comme nous le savons, les ressources CSS dans les balises bloquent le rendu, cela peut donc être vérifié.
• De plus, il y a une balise <script> pointant vers le fichier JavaScript dans le dossier des ressources. Ce n'est ni différé ni asynchrone, mais il a type="module". Ceux-ci sont automatiquement différés, ce qui vérifie également cela : les fichiers JavaScript dans les panneaux ne sont pas bloquants. </script>

Exercices supplémentaires

Si vous travaillez sur un projet, prenez note de ses performances de chargement initiales et regardez le panneau Réseau. Vous verrez peut-être plus de ressources téléchargées.

• De combien de ressources bloquant le rendu disposez-vous ? Est-ce que tout cela est nécessaire ?
• Savez-vous où se trouve le point « d'entrée » du projet et comment les ressources bloquantes apparaissent dans la section <script> ? Essayez de créer le projet avec vos variantes de construction npm et recherchez-les. Conseils : - Si vous avez un projet purement basé sur Webpack, recherchez le fichier webpack.config.js. Le chemin d'accès au point d'entrée HTML doit être à l'intérieur. </script>
• Si vous utilisez Vite, regardez dans le dossier dist - identique au projet d'apprentissage
• Si vous utilisez Next.js App Router, veuillez consulter .next/server/app

Sous la section "Réseau", vous trouverez les sections "Frames" et "Timing".

Ce sont plutôt cool. Dans la section « Timing », vous pouvez voir toutes les métriques dont nous avons parlé précédemment (FP, FCP, LCP), ainsi que certaines dont nous n'avons pas encore discuté. Lorsque vous passez votre souris sur la métrique, vous pouvez voir le temps exact qu'il a fallu. En cliquant dessus, vous mettrez à jour l'onglet « Résumé » tout en bas, où vous trouverez des informations sur cette métrique et des liens pour en savoir plus. DevTools vise désormais à éduquer les gens.

Enfin, la partie principale. C'est ce qui se passe dans le fil principal pendant la chronologie enregistrée.

Ici, nous pouvons voir des choses comme « Analyser le HTML » ou « Mise en page » et combien de temps cela a pris. Les parties jaunes sont liées au JavaScript, elles sont un peu inutiles puisque nous utilisons la version de production avec du JavaScript minifié. Mais même dans cet état, cela nous donne une idée approximative du temps que prend l'exécution de JavaScript par rapport à l'analyse HTML et à la mise en page des dessins, par exemple.

Il est particulièrement utile pour l'analyse des performances lorsque Réseau et Principal sont ouverts et agrandis pour occuper tout l'écran.

De là, je peux voir que mon serveur est très rapide et que les bundles sont très rapides et petits. Aucune tâche réseau ne constitue un goulot d'étranglement ; elles ne nécessitent pas beaucoup de temps, et entre elles, le navigateur se contente de traîner et de faire son propre travail. Donc, si je veux accélérer le chargement initial ici, je dois chercher pourquoi "Analyser le HTML" est si lent - c'est la tâche la plus longue du graphique.

Ou, si nous regardons les chiffres absolus, je ne devrais rien faire ici, en termes de performances. Le temps de chargement initial total est inférieur à 200 ms, bien en dessous du seuil recommandé par Google ? Mais cela se produit parce que j'exécute ce test localement (il n'y a donc pas de coût réseau réel), sur un ordinateur portable très rapide et qu'il utilise un serveur très basique.

Il est temps de simuler la vraie vie.

Explorez différentes conditions de réseau

serveur très lent

Tout d'abord, rendons le serveur plus réaliste. Maintenant, la première étape "bleue" est d'environ 50 millisecondes, dont 40 millisecondes attendent.

Dans la vraie vie, le serveur effectuera certaines opérations, vérifiera les autorisations, générera un certain contenu et vérifiera à nouveau les autorisations (car elle a beaucoup de codes restants et les chèques sont perdus en trois fois), sinon il sera très occupé.

backend / index.ts file (

https://www.php.cn/link/def14e8541708294d7558fdf2126ef27). Trouvez les commentaires > // attendez le sommeil (500) et annulez l'annotation. Cela retardera le serveur 500 millisecondes avant de retourner HTML - Cela semble raisonnable pour les anciens serveurs complexes. Re -Contructer le projet (NPM Run build), redémarrer It (NPM Run start) et re -run l'enregistrement de performance.

à l'exception de la ligne bleue initiale, il n'y a pas de changement sur la chronologie comparée avec le reste, il est très long maintenant.

Cette situation met en évidence l'importance de vérifier les goulots d'étranglement globaux et d'identifier avant d'effectuer une optimisation des performances. La valeur LCP est d'environ 650 millisecondes, dont environ 560 millisecondes sont utilisées pour attendre le HTML initial. Sa partie de réaction est d'environ 50 millisecondes. Même si j'essaie de le réduire et de le réduire à 25 millisecondes, il ne représente que 4% dans la situation globale. La réduction de celui-ci nécessitera beaucoup d'efforts . Une stratégie plus efficace peut être de se concentrer sur le serveur et de découvrir pourquoi elle est si lente.

Simuler différentes bande passantes et retard Tout le monde ne vit pas dans un monde d'une connexion Gigabit. Par exemple, en Australie, 50 billions / secondes est l'une des connexions Internet à grande vitesse, et vous dépenserez environ 90 $ par mois. Bien sûr, ce n'est pas de la 3G, et beaucoup de gens dans le monde sont piégés. Mais encore, chaque fois que j'entends le plan Internet des Européens 1 Gigabit 1 / Second ou 10 Euro, je vais pleurer.

Quoi qu'il en soit. Simulons cet Internet australien désagréable et voyons ce qui se passe dans les indicateurs de performance. À cette fin, effacez les enregistrements existants dans l'onglet Performance (rechargement et bouton près du bouton d'enregistrement). Le panneau de réglage réseau doit être affiché:

S'il n'apparaît pas dans votre version Chrome, les mêmes paramètres doivent être disponibles dans l'onglet "réseau".

Ajoutez un nouveau fichier de configuration au menu "réseau" Drop -Down, utilisez les numéros suivants:

• Nom du fichier de configuration: "Bande passante Internet moyenne"
• Télécharger: 50000 (50 Mbps)
• Télécharger: 15000 (15 Mbps)
• retard: 40 (la valeur moyenne de la connexion Internet générale)

Sélectionnez maintenant le fichier de configuration dans le menu Drop -Down et exécutez à nouveau l'enregistrement des performances.

Qu'avez-vous vu? Pour moi, ça ressemble à ça.

LCP

La valeur n'a presque aucun changement - légèrement augmenté de 640 millisecondes à 700 millisecondes. La partie "Server" bleue initiale n'a aucun changement, ce qui peut être expliqué: il n'envoie que le HTML le plus basique, donc le téléchargement ne devrait pas prendre beaucoup de temps. Mais la relation entre les ressources téléchargeables et le fil principal a considérablement changé.

Je peux clairement voir l'influence de Rendre le blocage CSS

. La mission "Analyse HTML" est terminée, mais le navigateur est inactif et attend CSS -Il ne peut dessiner aucun contenu avant le téléchargement. Comparez-le avec les images précédentes.

Après cela, techniquement, le navigateur peut être dessiné du contenu - mais aucun contenu, nous n'envoyons qu'un div vide dans le fichier html. Par conséquent, le navigateur se poursuit jusqu'à télécharger et exécuter le fichier JavaScript.

L'écart d'attente d'environ 60 millisecondes est l'augmentation de

LCP

J'ai vu.

Réduisez davantage la vitesse pour visualiser ses progrès. Créez un nouveau fichier de configuration réseau, nommez-le "basse bande passante Internet", copiez le numéro de téléchargement / téléchargement à partir du fichier de configuration "basse bande passante Internet" et définissez le retard sur 40 millisecondes.

et exécutez à nouveau le test.

La valeur LCP est maintenant passée à près de 500 millisecondes. JavaScript télécharge environ 300 millisecondes. Relativement parlant, l'importance de la tâche "HTML analytique" et la tâche d'exécution de JavaScript diminue.

Exercice supplémentaire

Si vous avez votre propre projet, essayez d'exécuter ce test dessus.

• Combien de temps faut-il pour télécharger toutes les ressources clés du chemin?
• Combien de temps faut-il pour télécharger tous les fichiers JavaScript?
• Combien de téléchargement du téléchargement après la tâche "d'analyse HTML"?
• Dans le fil principal, combien coûte le téléchargement des ressources de "Analyse de HTML" et JavaScript pour le téléchargement des ressources?
• Comment cela affecte-t-il l'indice LCP?

Ce qui s'est passé à l'intérieur de la barre de ressources est également très intéressant. Accrochez la souris sur la barre Javascript jaune. Vous devriez voir ce contenu là-bas:

La partie la plus intéressante ici est "Envoi des demandes et en attente", qui prend environ 40 millisecondes. Accrocher la souris sur les ressources du réseau restantes - toutes celles-ci l'ont. C'est notre latence, nous avons fixé un retard de réseau à 40. Beaucoup de choses affectent les nombres de retards. Le type de connexion réseau en fait partie. Par exemple, la bande passante moyenne de connexion 3G est de 10/1 Mbps, retardée entre 100 et 300 millisecondes.

Pour simuler ceci, veuillez créer un nouveau fichier de configuration réseau, nommez-le "moyen 3G", copiez le numéro de téléchargement / téléchargement à partir du fichier de configuration "basse bande passante" et définissez le retard sur 300 millisecondes.

Exécutez à nouveau. Les «demandes d'envoi et d'attente» de toutes les ressources du réseau doivent être portées à environ 300 millisecondes. Cela favorisera en outre LCP

Nombres: il est 1,2 secondes pour moi. est maintenant une partie intéressante: que se passera-t-il si je restaure la bande passante à la vitesse ultra-haute mais que je garde le faible délai? Essayons ce paramètre:

Télécharger

: 1000 Mbps
• Télécharger : 100 Mbps
• retard : 300 millisecondes
• Si votre serveur est situé quelque part en Norvège et que le client est riche en Australiens, cela est facile à se produire. C'est le résultat:

LCP

Le nombre est d'environ

960 millisecondes

. C'est pire que le plus lent sur Internet que nous avons essayé auparavant! Dans ce cas, la taille de l'emballage groupé n'est pas importante et la taille du CSS n'est pas du tout importante. Même si vous moins les deux, l'indicateur LCP se déplacera à peine. Un retard élevé est meilleur que tout.

Cela me rappelle la première amélioration des performances que tout le monde devrait réaliser, si elles ne l'ont pas encore réalisée. Il est appelé "assurer des ressources statiques

toujours

pour fournir des services via CDN." L'importance de CDN CDN (Network de distribution de contenu) est essentiellement la 0ème étape de tout travail de performances avant, et même avant de commencer à considérer des choses plus sophistiquées (telles que la segmentation de code ou le composant serveur).

L'objectif principal de tout CDN (réseau de distribution de contenu) est de réduire le retard et de fournir le contenu à l'utilisateur final dès que possible. Ils ont mis en œuvre une variété de stratégies pour cela. Les deux plus importants de cet article sont les «serveurs distribués» et «cache».

Un fournisseur CDN aura plusieurs serveurs dans différents emplacements géographiques. Ces serveurs peuvent stocker des copies de ressources statiques et les envoyer aux utilisateurs lorsque le navigateur les demande. Un CDN est essentiellement une couche souple autour de votre serveur d'origine, le protégeant des influences extérieures et minimisant son interaction avec le monde extérieur. C'est un peu comme un assistant IA pour les introvertis, capable de gérer des conversations typiques sans impliquer une personne réelle.

Dans l'exemple ci-dessus, notre serveur est en Norvège et le client est en Australie, nous avons une image comme celle-ci :

Avec un CDN au milieu, l'image change. Le CDN disposera d'un serveur plus proche de l'utilisateur, par exemple également quelque part en Australie. À un moment donné, le CDN recevra une copie de la ressource statique du serveur d'origine. Les utilisateurs d'Australie ou de n'importe où à proximité recevront alors ces copies au lieu des originaux du serveur norvégien.

Il réalise deux choses importantes. Premièrement, la charge sur le serveur d’origine est réduite car les utilisateurs n’ont plus besoin d’y accéder directement. Deuxièmement, les utilisateurs peuvent désormais obtenir ces ressources plus rapidement, car ils n'ont plus besoin de traverser un océan pour télécharger certains fichiers JavaScript.

Et la valeur LCP dans notre simulation ci-dessus est passée de 960 ms à 640 ms ?.

Répéter les performances d'accès

Jusqu’à présent, nous n’avons abordé que les performances lors de la première visite – les performances pour les personnes qui n’ont jamais visité votre site. Mais j'espère que le site est si bon que la plupart des nouveaux visiteurs deviendront des visiteurs réguliers. Ou du moins, ils ne partiront pas après le premier chargement, ne parcourront pas quelques pages et n'achèteront peut-être pas quelque chose. Dans ce cas, nous nous attendons généralement à ce que le navigateur mette en cache les ressources statiques (comme CSS et JS), c'est-à-dire qu'il en enregistre une copie localement plutôt que de toujours les télécharger.

Voyons comment le graphique de performances et les chiffres changent dans ce cas.

Ouvrez à nouveau le projet d'apprentissage. Dans les outils de développement, définissez le réseau sur "3G moyen" que nous avons créé précédemment - avec une latence élevée et une faible bande passante afin que nous puissions voir la différence immédiatement. Et assurez-vous que la case « Désactiver le cache réseau » n'est pas cochée.

Tout d’abord, actualisez votre navigateur pour vous assurer que nous éliminons les nouveaux visiteurs. Ensuite, actualisez et mesurez les performances.

Si vous utilisez un projet d'apprentissage, le résultat final peut être un peu surprenant car il ressemblera à ceci :

Les fichiers CSS et JavaScript sont toujours très importants dans l'onglet réseau. En conséquence, LCP n'est pas aussi faible que possible, et lorsque le navigateur attend juste de bloquer le CSS, j'ai un écart de 300 millisecondes.

Que s'est-il passé? Le navigateur ne devrait-il pas cache ces choses?

Utilisez l'en-tête de contrôle du cache pour contrôler le cache du navigateur

Nous devons utiliser le panneau "réseau" pour apprendre ce qui s'est passé. Ouvrez-le et trouvez le fichier CSS là-bas. Il doit être illustré ci-dessous:

La chose la plus intéressante ici est la colonne "d'état" et la "taille". Dans "Taille", ce n'est certainement pas la taille de l'ensemble du fichier CSS. C'est trop petit. Dans "State", ce n'est pas notre état de 200 "tout" habituel, mais des choses différentes -304.

Il y a deux questions ici - pourquoi est 304 au lieu de 200, et pourquoi envoyez-vous une demande? Pourquoi le cache ne peut-il pas fonctionner?

Premièrement,

304 réponse. Il s'agit d'une réponse envoyée par un bon serveur comme demande conditionnelle - où la réponse change en fonction de diverses règles. Ces demandes sont souvent utilisées pour contrôler le cache du navigateur.

Par exemple, lorsque le serveur reçoit une demande de fichier CSS, il peut vérifier l'heure du dernier fichier de modification. Si cette date est la même que la date dans le fichier de finition du navigateur, elle reviendra 304 avec un texte vide (c'est pourquoi il n'a que 223 b). Cela signifie que le navigateur peut utiliser les fichiers qu'il a déjà en toute sécurité. Pas besoin de gaspiller la bande passante et de le télécharger à nouveau.

C'est pourquoi nous voyons un grand nombre de nombres "d'envoi de demande et d'attente" demandant au serveur de confirmer si le fichier CSS est toujours le dernier. C'est pourquoi le "téléchargement de contenu" il y a 0,33 millisecondes - le serveur renvoie "304 non modifié", et le navigateur utilise simplement les fichiers téléchargés précédemment.

Exercice supplémentaire

Dans le projet d'apprentissage, transférez dans le dossier distal / actifs et renommer le fichier CSS

Accédez à la trajectoire du fichier Distal / index.html et mettez à jour le chemin d'accès des fichiers CSS renommés
Refreindre la page ouverte et ouvrir l'onglet "réseau". C'est ce qu'on appelle le navigateur «Cache» -a-forcée pour re-télécharger la ressource qui peut avoir mis en cache.
Refreindre la page à nouveau -Il est revenu à l'état 304 et a réutilisé le fichier de cache.
4. Maintenant, la deuxième question
-Pour pourquoi avez-vous envoyé cette demande?

Ce comportement est contrôlé par le serveur défini sur l'en-tête de contrôle de cache de la réponse. Cliquez sur le fichier CSS dans le panneau "réseau" pour afficher les informations détaillées de la demande / réponse. Trouvez la valeur "Cache-Control" dans le bloc "En-tête de réponse" de l'onglet "En-tête":

Dans cet en-tête, vous pouvez vous séparer avec une virgule avec différentes combinaisons. Dans notre exemple, il y en a deux:

max -age
• avec un nombre - combien de longs contrôle cette réponse spécifique sera stockée (en secondes) doit-revalider
-dans le cas indique que si la réponse a expiré, elle envoie toujours une nouvelle version de la demande au serveur. Si la réponse existe dans le cache plus que la valeur d'âge maximum, la réponse expirera.
• Par conséquent, en gros, l'en-tête indique au navigateur:

Vous pouvez stocker cette réponse dans votre cache, mais vous devez à nouveau vérifier avec moi après un certain temps.

Soit dit en passant, vous pouvez garder le temps du cache exactement
• zéro
seconde. Bonne chance.
• En conséquence, le navigateur
toujours

Vérifiez avec le serveur et n'utilisez jamais le cache immédiatement.

Cependant, nous pouvons facilement modifier cela - Nous devons seulement changer le numéro d'agence maximum à 0 à 31536000 (un an, le nombre maximum de secondes). À cette fin, dans votre projet d'apprentissage, transférez dans le fichier backend / index.ts, trouvez la position de définition de Max-Age = 0 et passez-la en 31536000 (un an). Actualisez la page plusieurs fois, vous devriez voir le contenu suivant du fichier CSS dans l'onglet "réseau":

Veuillez noter que la colonne "Status" est devenue gris maintenant. Le fichier CSS fournit désormais des services à partir du cache du navigateur, et ce sera toujours le cas dans un an. Actualisez la page plusieurs fois pour le voir ne le changera pas.

Maintenant, pour tous les principaux points de traitement de l'en-tête du cache: Mesquons à nouveau les performances de la page. N'oubliez pas de définir les paramètres de fichier de configuration "3G moyens" et de conserver les paramètres "Désactiver le cache".

Le résultat doit être similaire à:

Bien que le retard soit élevé, la section "Envoi de demande et d'attente" est presque réduite à zéro.

Exercice supplémentaire

1. Modifiez la valeur maximale en 10 (10 secondes)
2. Sélectionnez la case "Cache désactivée" et actualisez la page pour supprimer le cache.
3. Annulez la case à cocher Sélection et actualisez à nouveau la page - cette fois, il doit être fourni à partir du cache de mémoire.
4. attendez 10 secondes, puis actualisez à nouveau la page. Parce que Max-Age n'a que 10 secondes, le navigateur vérifiera à nouveau les ressources et le serveur reviendra 304.
5. Rafraîchir immédiatement la page -Il devrait à nouveau fournir des services à partir de la mémoire.

outils de contrôle du cache et d'emballage moderne

Les informations ci-dessus signifient-elles que le cache est nos performances d'un pirate. Certainement pas! En plus de tout le reste, la possibilité de créer une combinaison de "technologie non compétente" et de "besoin d'expliquer comment effacer le cache du navigateur" entraînera les plus grands développeurs de panique.

Il existe des millions de méthodes d'optimisation du cache, des millions d'instructions dans l'en-tête de contrôle du cache et d'autres combinaisons qui peuvent ne pas affecter la durée du cache. Peut-être que seul ce thème lui-même peut écrire quelques livres. Si vous voulez être un maître de cache, commencez par des articles sur https://web.dev/ et MDN Resources, puis opérez en fonction des chapelure.

Malheureusement, personne ne peut vous dire: "Ce sont les cinq meilleures stratégies de cache adaptées à tout le contenu." Au mieux, la réponse peut être: "Si vous avez ce cas d'utilisation, combiné avec ceci, ceci, et ceci, alors cette combinaison de paramètre de cache est un bon choix, mais faites attention à ces problèmes." Tout cela est attribué à la compréhension de vos ressources, de vos systèmes de construction, de la fréquence des changements de ressources, de la sécurité du cache et des conséquences du fonctionnement des erreurs.

mais il y a une exception. Une exception est la «meilleure pratique» claire: fichiers JavaScript et CSS à l'aide d'un site Web construit par des outils modernes. Les outils d'emballage modernes (tels que VITE, Rollup, WebPack, etc.) peuvent créer des fichiers JS et CSS "insensables". Bien sûr, ils ne sont pas vraiment "inchangés". Cependant, ces outils utilisent la chaîne de hachage en fonction du contenu de fichier pour générer des noms de fichiers. Si le contenu du fichier est modifié, le hachage sera modifié et le nom du fichier sera modifié. En conséquence, lorsque le site Web est déployé, quels que soient les paramètres de cache, le navigateur réobjectera une nouvelle copie du fichier. Le cache a "effacé", tout comme lorsque nous avons déjà renommé manuellement le fichier CSS.

Par exemple, consultez le dossier Distal / Assets dans le projet d'apprentissage. Les fichiers JS et CSS ont tous deux des noms de fichiers index- [hash]. N'oubliez pas ces noms et exécutez NPM Run Build plusieurs fois. Le nom reste inchangé car le contenu de ces documents n'a pas changé.

Accédez maintenant au fichier src / app.tsx et ajoutez un contenu similaire à la console.log ('bla') quelque part. Exécutez à nouveau NPM Exécutez la construction et vérifiez les fichiers générés. Vous devriez voir que le nom du fichier CSS reste inchangé, mais le nom du fichier JS a été modifié. Lorsque ce site Web sera déployé et que la prochaine fois que l'utilisateur la visitera, le navigateur demandera un fichier JS complètement différent qui ne sera jamais apparu dans son cache. Le cache a été effacé.

Exercice supplémentaire

Trouvez l'équivalence du dossier de conception du projet et exécutez votre commande de construction.

• quel est le nom du fichier? Semblable au hachage, ou est-il ordinaire index.js, index.css, etc.?
• Lorsque vous exécutez à nouveau la commande, le nom du fichier sera-t-il modifié?
• Si vous apportez des modifications simples dans une certaine position dans le code, combien de noms de fichiers seront modifiés?

Si votre système de construction est configuré, vous avez de la chance. Vous pouvez configurer le serveur en toute sécurité pour définir l'en-tête maximum d'âge maximum pour générer des actifs. Si vous contrôlez également tous les better de l'image, vous pouvez également inclure l'image dans la liste.

Selon le site Web et leurs utilisateurs et leurs comportements, cela peut vous fournir une très bonne amélioration des performances pour le chargement initial.

Mon cas simple a vraiment besoin de savoir tout cela?

Pour le moment, vous pensez peut-être à de telles choses: "Vous êtes fou. J'ai construit un site Web simple avec Next.js le week-end et le déployer sur Vercel / Netlify / HotTestNewProvider en 2 minutes. Bien sûr, ces modernes Les outils géreront tout cela. "C'est juste. Je pense aussi. Mais ensuite je l'ai vérifié, wow, je suis surpris?

Mes deux éléments ont Max-Age = 0 et Must-Revalidate pour les fichiers CSS et JS. Il s'avère que c'est le paramètre par défaut de mon fournisseur CDN ?? Bien sûr, ils ont des raisons

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!