Il y a un audit technique pour vérifier la vitesse du site et identifier les causes des retards. Il est recommandé de le réaliser même si le système semble fonctionner correctement et qu'il n'y a pas de problèmes de performances. Le fait est qu'il peut encore être amélioré: l'optimisation de l'infrastructure accélérera la livraison du code et la refactorisation de la base de code aidera à réduire les coûts de maintenance.
Dans cet article, nous montrerons comment un audit technique d'un site Web passe par l'exemple d'une ressource d'actualité populaire, visitée par des dizaines de milliers d'utilisateurs par heure. Considérons les étapes indépendantes de vérification et d'analyse, à la suite desquelles nous montrerons clairement comment vous pouvez améliorer le projet et éliminer les goulots d'étranglement qui ralentissent le chargement de la page.
Collecte de métriques et analyse des ressources statiques du site
Assurez-vous de collecter des métriques et de mesurer tout ce que vous pouvez à l'aide d'outils prêts à l'emploi tels que Google Page Speed, Lighthouse et Web.dev. C'est le moyen le plus rapide d'obtenir des métriques qui serviront de point de départ à votre recherche. Avec leur aide, vous comprendrez ce à quoi il faut prêter attention en premier lieu, ce qui peut être optimisé.
Nous vous conseillons d'exécuter l'analyse avec le bloqueur de publicités activé et désactivé. En conséquence, vous découvrirez à quelle vitesse le premier rendu du contenu a lieu et combien de scripts tiers sont connectés sur le site.
À ce stade, vous verrez également combien d'opérations de base se produisent lors du rendu du site:
Les métriques collectées sont susceptibles d'indiquer un espace pour améliorer les actifs statiques du site: images, vidéos, scripts, styles et polices. Analysez ces données et assurez-vous de suivre les pratiques générales en matière de ressources statiques. Cependant, rappelez-vous qu'il ne s'agit que de directives et non d'exigences strictes.
Dans notre exemple, toutes les images sont stockées au format jpg. Si vous utilisez webp, que les navigateurs supportent parfaitement, la taille du fichier sera réduite de 20% en moyenne. Vous pouvez configurer la compression Webp automatique pour les images haute résolution uniquement. Il est recommandé de convertir les vidéos haute résolution en webm pour les navigateurs prenant en charge ce format. Pour réduire la charge sur le réseau, il est conseillé de désactiver la lecture automatique des vidéos qui ne sont pas visibles. Cela peut être fait à l'aide de l'API Intersection Observer.
Assurez-vous que votre site a des téléchargements progressifs et ajoutez une compression partout si possible. Assurez-vous d'utiliser des techniques de compression de script modernes telles que brotli, gzip et deflate.
Ne chargez pas ce qui n'est pas utilisé. Cela peut s'appliquer au code, aux styles, aux symboles, aux images. Si, par exemple, un site Web a un bouton qui apparaît dans l'un des mille cas, le script qui le traite ne doit être connecté qu'à la demande.
Dans l'exemple ci-dessus, vous pouvez voir que ~ 93% du code total n'est pas utilisé (~ 340 ko). Un bundle avec un code est considéré comme idéal si sa couverture est de 100% lorsqu'il couvre tous les cas sans recharger la page. Cela peut se produire si le code n'est pas du tout utilisé ou si le fractionnement du code est mal configuré, ou s'il est utilisé, mais sur d'autres pages, ou lorsqu'un certain scénario est atteint.
La solution à ce problème consiste à déplacer les composants réutilisables dans des fichiers séparés (morceaux), qui sont ensuite connectés uniquement aux endroits où ils sont nécessaires.
Comme nous l'avons dit, ces exigences sont facultatives, mais l'optimisation des ressources statiques est importante, car l'utilisateur les remarque en premier.
Prenons les polices comme exemple - sur ce projet, elles ont pris trop de temps à charger. Puisque nous ne voulons pas que l'utilisateur voie les polices standard, nous les chargeons au tout début, dans la section critique-css. Comment résoudre ce problème? Vous pouvez optimiser les polices au niveau du code, modifier l'ordre de connexion, remplacer ttf par woff2.
Vous pouvez également essayer de réduire le nombre de polices utilisées, ce qui implique une refonte du design, mais ce n'est pas toujours justifié. Si le site utilise la bibliothèque Google Fonts, puis supprimez les caractères inutilisés des fichiers, cela n'est pas interdit par le droit d'auteur.
Mais parfois, il est plus facile de laisser les choses telles qu'elles sont et de se concentrer sur d'autres possibilités.
Examen des requêtes HTTP
A ce stade, nous vérifions si le frontend interagit correctement avec le backend, à savoir:
- compression configurée pour les demandes d'API;
- il n'y a pas de requêtes parasites qui chargent la connexion, dont les résultats ne sont utilisés nulle part;
- aucune demande n'est renvoyée avec une erreur sans que l'utilisateur ne remplisse une analyse de rentabilisation spécifique;
- lors du chargement initial de la page, le navigateur n'envoie pas de requêtes à l'API (si le site utilise le rendu côté serveur, comme dans notre exemple);
- il n'y a pas de demandes en double. Si une demande est faite lors de l'accès à une page, il est préférable de l'envoyer une fois et d'enregistrer les données pour une réutilisation;
- pending , . , , , . , — , .
Les demandes bloquées sont surlignées en rouge, mais le site continue de fonctionner.
De plus, lors de l'analyse des demandes, vous pouvez trouver des bogues. C'est ainsi que nous avons rencontré le mauvais fonctionnement de l'application frontale, qui pouvait envoyer plus de 100 requêtes par seconde, ce qui chargeait considérablement le serveur. L'écran clignotait, le chargeur tournait sans cesse, etc. La raison était cachée dans un parchemin mal implémenté. Le navigateur a conservé sa position en bas de page lorsque de nouveaux éléments sont apparus. Autrement dit, lors du défilement de la page, un chargeur a été lancé, en raison duquel la page a été déplacée vers le bas. Le gestionnaire Javascript a renvoyé la demande, qui à son tour a déclenché à nouveau l'animation du chargeur, en raison de laquelle la taille de la page a changé, et ainsi de suite à l'infini.
En raison d'un fonctionnement incorrect du chargeur, le nombre de requêtes augmente à l'infini
Analyse des scripts et ressources externes
À ce stade, vous devez déterminer les ressources de sites tiers qui prennent le plus de temps à se charger.
Le Web moderne vous permet de hiérarchiser les téléchargements. Souvent, les statistiques et les annonces sont chargées avant l'affichage de la page, ce qui en soi n'a aucun sens, car l'utilisateur ne pourra toujours pas voir l'annonce, mais le site prendra plus de temps à se charger. Nous vous recommandons d'afficher des publicités immédiatement après le rendu du site, ce qui n'affectera en aucun cas les statistiques - sinon l'utilisateur verra un écran blanc pendant un certain temps.
Profilage des pages
Utilisez les outils de développement de chrome pour profiler les pages de votre site afin de suivre les demandes longues et l'utilisation accrue du processeur. En conséquence, vous verrez ce qui charge clairement le site.
La capture d'écran montre qu'il faut 19 millisecondes pour charger Jquery, ce qui n'est pas nécessaire pour le moment. Mieux vaut charger jquery après les ressources principales, de préférence après un événement de chargement réussi (par exemple, onload, domcontentloaded.)
Analyse du nombre et de la durée des demandes
À ce stade, nous explorerons comment le frontend interagit avec le backend. Pour ce faire, vous devez analyser le nombre et la durée de toutes les demandes. Pour obtenir une image plus complète, vous devez mesurer le temps de réponse moyen pour une demande et pour les demandes parallèles.
Pour plus de clarté, combinez les données obtenues dans un graphique récapitulatif. De cette façon, vous pouvez identifier rapidement les requêtes qui prennent beaucoup plus de temps que les autres.
Si le site est installé sur un serveur puissant, le temps d'exécution de 100 requêtes parallèles ne doit pas dépasser largement le temps d'exécution d'une requête. Dans l'exemple, nous voyons une différence de 30 fois. Les requêtes les plus anciennes doivent être examinées en premier.
Dans ce projet, pour certaines demandes, un délai d'expiration de la passerelle s'est produit, c'est-à-dire que la réponse du serveur n'est pas du tout venue.
Les frais généraux dans les projets à forte charge sont normaux. Cependant, si possible, vous devriez essayer de décomposer les demandes en leurs composants dans les cas où une demande est responsable de plusieurs actions. Exécutez ces pièces dans des filetages parallèles.
Que peut-on faire pour améliorer le serveur? Connectez la bibliothèque pour surveiller le serveur et redémarrez l'application (dans le cas de node.js, il s'agit de pm2). Il est également recommandé de connecter un outil de surveillance des erreurs tel que Sentry. Configurez la sortie d'erreur et la journalisation des incidents. De cette façon, vous pouvez suivre les temps d'arrêt de votre application.
Idéalement, configurez un enregistreur asynchrone pour surveiller toute activité sur le site (requêtes d'API, requêtes à la base de données, API externes, au système de fichiers ou aux services pour travailler avec le système de fichiers), qui les connectera dans une base de données distincte.
Analyse statique du code source
Cette analyse est effectuée par des utilitaires qui signalent le mauvais code et aident à se débarrasser du «code mort». Il est à noter que ces outils doivent être utilisés automatiquement pendant le développement, mais vous ne devez pas toujours vous fier à l'intégrité des développeurs, il est donc préférable de ne pas sauter cette vérification.
Pour effectuer une analyse statique, vous devez utiliser des linters eslint et d'autres utilitaires de formatage de code tels que Joli et sonar qui suivent les violations de code.
En conséquence, sur la base des violations identifiées, vous pouvez rédiger un document:
Habituellement, ces violations n'affectent pas les performances du site, mais compliquent la lecture et l'écriture de code, ce qui signifie qu'il sera plus coûteux à maintenir. Par exemple, sur ce projet, nous avons trouvé une fonction dans laquelle il y avait trois arguments, dont l'un n'a pas été utilisé - de telles bagatelles ensemble augmentent la dette technique du projet.
Analyse sémantique du code source
À ce stade, le programmeur devra examiner manuellement les fichiers du projet. Il est à noter qu'il ne sera possible d'évaluer que les erreurs évidentes dans le comportement du code source; pour une analyse plus approfondie, vous devez bien connaître la logique du projet. À ce stade, vous pouvez trouver du code répétitif qui peut être mis en un seul endroit (classe, fonction ou constante) pour réduire le nombre de lignes et réduisez la possibilité de bugs.
Parfois, cette analyse aidera à déterminer si l'équipe de développement rencontre des problèmes. À partir des lignes de code de Git, vous pouvez déterminer qui est l'auteur et déterminer les performances de chaque employé. Vous constaterez peut-être que plus de la moitié des commentaires font référence à un développeur.
Par exemple, nous avons identifié ici dix opérations asynchrones qui mettent à jour la base de données, mais elles ont été effectuées une par une, sans être connectées les unes aux autres. Cela signifie que leurs performances peuvent être doublées en les exécutant en parallèle. Utilisez le parallélisme autant que possible, car même dans les versions actuelles de PHP, vous pouvez régler le parallélisme artificiel pour améliorer les performances du système.
Résultat
Le développement de logiciels comporte de nombreux risques et, en réalité, vous devez souvent faire des compromis pour qu'un projet soit opérationnel à temps. Par conséquent, la documentation est généralement préparée rétroactivement et l'optimisation du site est reportée au tout dernier moment.
Mais il n’est jamais trop tard pour améliorer les performances. Accélérer votre site Web améliorera l'expérience utilisateur et donnera une réponse positive au public. À l'aide d'un audit technique, vous pouvez déterminer ce qui cause des retards dans le travail du site - une application frontale ou principale. Nous avons rassemblé ici des recommandations sur la façon de mener un audit frontal. Ils sont de nature générale et conviennent pour tester n'importe quel site.
Nous vous dirons bientôt comment réaliser un audit technique du backend dans notre prochaine publication.