En tant qu'ingénieur de développement front-end, vous devez prêter attention à trois indicateurs de performance :

En tant qu'ingénieur de développement front-end qualifié, connaissez-vous plusieurs indicateurs de performance auxquels vous devez prêter attention ? Aujourd'hui je vais vous faire une bonne introduction aux trois indicateurs auxquels vous devez prêter attention en tant qu'ingénieur front-end

1. Concernant le temps de réponse des pages, il existe un fameux "principe 2-5-8" . Lorsqu'un utilisateur visite une page :

obtient une réponse dans les 2 secondes, le système répond rapidement ; lorsque

obtient une réponse entre 2 et 5 secondes, le système répond rapidement

Lorsque la réponse est reçue dans les 5 à 8 secondes, la vitesse de réponse du système semble très lente, mais elle est acceptable

Lorsque l'utilisateur ne peut toujours pas obtenir la réponse après plus de 8 secondes, l'utilisateur Vous sentirez que le système est terrible et choisirez de quitter le site ou de lancer une deuxième demande.

Si un site Web espère attirer des utilisateurs, la vitesse et la stabilité du site Web sont la première priorité.

À partir de diverses plateformes de surveillance frontale, vous pouvez obtenir de nombreux indicateurs de performance de la page. Cet article présentera plusieurs indicateurs clés et donnera des idées d'optimisation correspondantes.

2. Démarrage du temps de rendu

Ce point temporel indique que le navigateur commence à dessiner la page. Avant cela, la page est un écran blanc, elle est donc également appelée temps d'écran blanc.

Ce point temporel peut être représenté par la formule Time To Start Render = TTFB (Time To First Byte) + TTDD (Time To

Document Download) + TTHE (Time To Head End). TTFB représente le temps entre le moment où le navigateur lance une requête et le moment où le serveur renvoie le premier octet, TTDD représente le moment où le document HTML est chargé depuis le serveur, et TTHE représente le temps nécessaire pour terminer l'analyse de l'en-tête du document. Il existe un attribut correspondant dans les navigateurs avancés pour obtenir le point temporel. Chrome peut être obtenu via chrome.loadTimes().firstPaintTime et IE9+ peut être obtenu via performance.timing.msFirstPaint Dans les navigateurs non pris en charge, la valeur approximative peut être simulée en obtenant le moment où la ressource d'en-tête est chargée selon la formule ci-dessus. . Plus le temps de démarrage du rendu est rapide, plus les utilisateurs peuvent voir la page rapidement.

Les optimisations à ce stade incluent :

1) Optimiser le temps de réponse du serveur, sortie du serveur le plus tôt possible

2) Réduire la taille du fichier HTML

3) Réduisez les ressources d'en-tête et placez le script dans le corps autant que possible

DOM Ready

Ce moment indique que l'analyse DOM est terminée et que les ressources ont n'a pas été chargé. A ce moment, la relation entre l'utilisateur et la page Interaction est déjà disponible. Il peut être exprimé par la formule TimeTo Dom Ready = TTSR (Time To Start Render) + TTDC (Time To Dom Created) + TTST (Time To Script). TTSR a été introduit ci-dessus et TTDC représente le temps nécessaire pour créer l'arborescence DOM. TTST représente le temps de chargement et d'exécution de tous les scripts

statiques dans BODY. Il existe un événement DOMContentLoaded qui lui correspond dans les navigateurs avancés. Le document sur MDN décrivant l'événement DOMContentLoaded est le suivant,

L'événement DOMContentLoaded est déclenché lorsque le document a été complètement chargé et analysé. , sans attendre la fin du chargement des feuilles de style, des images et des sous-cadres (l'événement load peut être utilisé pour détecter une page entièrement chargée).

Pour les spécifications détaillées, veuillez consulter la spécification HTML5 du W3C. Il ressort du document MDN que cet événement fait principalement référence à l'achèvement du chargement et de l'analyse du document DOM. Cela semble très simple, mais le déclenchement de l'événement DOMContentLoaded est étroitement lié aux CSS et js. terme Critical Rendering Path (chemin de rendu critique) pour le décrire. L'impact du chemin de rendu critique sur DOMContentLoaded est présenté en détail dans l'article [Critical Rendering Path].

Dans les navigateurs qui ne prennent pas en charge l'événement DOMContentLoaded, la valeur approximative peut être obtenue par simulation. Les principales méthodes de simulation sont :

1) Les navigateurs du noyau du kit Web version basse peuvent interroger. le document.readState à implémenter

2) Dans IE, la méthode doScroll de documentElement peut être appelée en continu via setTimeout jusqu'à ce qu'elle puisse être utilisée pour implémenter

Pour les méthodes d'implémentation spécifiques, veuillez vous référer à. la mise en œuvre de frameworks grand public (jquery, etc.). Le point temporel DOM Ready signifie que l'utilisateur peut interagir avec la page, donc le plus tôt sera le mieux. Les optimisations pour ce point temporel sont :

1) Réduire la complexité de la structure DOM, avec le moins de nœuds possible. et l'imbrication N'allez pas trop loin

2) Optimisez le chemin de présentation critique

3 Temps du premier écran

Ce point temporel représente le moment où l'utilisateur. voit le premier écran de la page, ce Le point temporel est important mais difficile à obtenir Généralement, une heure approximative ne peut être obtenue que par simulation. Les méthodes générales de simulation sont :

1) Obtenir en continu des captures d'écran Lorsque les captures d'écran ne changent plus, cela peut être considéré comme le premier temps d'écran. Vous pouvez vous référer à l'algorithme Speed ​​​​Index de webPagetest ;

2) Généralement, le principal facteur affectant le premier écran est le chargement de l'

image Une fois la page chargée, déterminez. si l'image se trouve dans le premier écran et découvrez le chargement. Le plus lent peut être considéré comme le temps du premier écran. Bien sûr, d'autres détails doivent être pris en compte. Pour plus de détails, veuillez vous référer à [Créer un système de surveillance des performances front-end en 7 jours]

Les optimisations pour ce point temporel sont :

1. ) Essayez de ne pas vous fier à l'affichage du premier écran de la page js, js doit être exécuté ou chargé autant que possible après domReady

.

2) Chargement retardé des images en dehors du premier écran

3) Gardez la structure du premier écran aussi simple que possible, et les CSS en dehors du premier écran peuvent être retardés chargés

onload

à ce moment-là, c'est le moment où l'événement window.onload est déclenché, indiquant que le document original et tout le contenu référencé ont été chargés. Le sentiment le plus évident pour l'utilisateur est que l'état de chargement sur le navigateur. l'onglet est terminé.

Les méthodes d'optimisation à ce stade sont :

1) Réduire le nombre de demandes de ressources et la taille des fichiers

2) Placer le script de non-initialisation après onLoad et exécutez-le

3) Chargement asynchrone des scripts sans synchronisation

Afin d'optimiser les performances de l'ensemble du site, vous pouvez envisager de faire un peu de préchargement lors du onload de la page, et de précharger les ressources que les autres les pages doivent être utilisées.

J'espère que la lecture de l'article ci-dessus vous sera utile dans votre parcours de développement front-end.

Lecture connexe :

Questions d'entretien JS front-end

Introduction aux frameworks JS et UI front-end Web pratiques

Résumé du système de connaissances Web front-end

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!