Fixation d'un site lent itérativement

Les performances du site sont potentiellement la métrique la plus importante . Plus les performances sont meilleures, plus les chances que les utilisateurs restent sur une page, lisent du contenu, effectuent des achats ou à peu près tout ce qu'ils doivent faire. Une étude de 2017 par Akamai en dit autant lorsqu'elle a constaté que même un délai de 100 ms dans la charge de page peut réduire les conversions de 7% et perdre 1% de leurs ventes pour chaque 100 ms il faut pour que leur site se charge, ce qui, au moment de l'étude, soit équivalent à 1,6 milliard de dollars si le site a ralenti d'une seconde. Les repères de l'industrie de Google de 2018 fournissent également une rupture frappante de la façon dont chaque seconde de chargement affecte les taux de rebond.

D'un autre côté, Firefox a réalisé ses pages Web 2,2 secondes plus rapidement en moyenne et a conduit 60 millions de téléchargements de Firefox supplémentaires par an. La vitesse est également quelque chose que Google considère lors du classement de votre placement sur le site Web sur mobile. Avoir un site lent peut vous laisser à la page 452 des résultats de recherche, quelle que soit toute autre métrique.

Avec tout cela à l'esprit, je pensais que l'amélioration de la vitesse de ma propre version d'un site lent serait un exercice amusant. Le code du site est disponible sur GitHub pour référence.

Il s'agit d'un site très basique fabriqué avec un HTML, CSS et JavaScript simples. J'ai intentionnellement essayé de garder cela aussi simple que possible, ce qui signifie que la raison pour laquelle il est lent n'a rien à voir avec la complexité du site lui-même, ou à cause de certains cadre qu'il utilise. À propos de la partie la plus complexe, certains boutons de médias sociaux pour que les gens puissent partager la page.

Voici la chose: les performances sont plus qu'une tâche unique. Il est intrinsèquement lié à tout ce que nous construisons et développons. Ainsi, bien qu'il soit tentant de résoudre tout ce dans un seul coup, la meilleure approche pour améliorer les performances pourrait être itérative. Déterminez s'il y a des fruits bas et déterminez ce qui pourrait être des efforts plus importants ou à long terme. En d'autres termes, les améliorations progressives sont un excellent moyen de marquer des victoires en performance. Encore une fois, chaque milliseconde compte.

Dans cet esprit, ce que nous regardons dans cet article se concentre davantage sur les victoires incrémentielles et moins sur la fourniture d'une liste exhaustive ou d'une liste de contrôle des stratégies de performance.

Phare

Nous allons travailler avec Lighthouse. Beaucoup d'entre vous peuvent déjà être très familiers avec cela. Il a même été couvert un bouquet ici sur CSS-Tricks. C'est un service Google qui vérifie les performances, l'accessibilité, le référencement et les meilleures pratiques. Je vais auditer les performances de mon site lent avant et après les choses que nous abordons dans cet article. Les rapports des phares sont accessibles directement dans Devtools de Chrome.

Allez-y, regardez brièvement les choses qui, selon Lighthouse, ne vont pas avec le site Web. Il est bon de savoir ce qui doit être résolu avant de plonger directement.

Nous pouvons totalement résoudre ce problème, alors commençons!

Amélioration n ° 1: Redirection

Avant de faire quoi que ce soit d'autre, voyons ce qui se passe lorsque nous avons frappé le site Web pour la première fois. Il est redirigé. Le site était à une URL et maintenant il vit à un autre. Cela signifie que tout lien qui fait référence à l'ancienne URL va rediriger vers la nouvelle URL.

Les redirectes sont souvent assez légers en termes de latence qu'ils ajoutent à un site Web, mais ils sont une première chose facile à vérifier, et ils peuvent généralement être supprimés avec peu d'efforts.

Nous pouvons essayer de les supprimer en mettant à jour partout où nous utilisons l'URL précédente du site, et le pointer vers l'URL mise à jour afin que les utilisateurs y soient directement en place au lieu d'être redirigés. À l'aide d'un inspecteur de demande de réseau, je vais voir s'il y a quelque chose que nous pouvons supprimer via le panneau réseau dans Devtools. Nous pourrions également utiliser un outil, comme Postman si nous en avons besoin, mais nous limiterons notre travail à Devtools autant que possible pour la simplicité.

Tout d'abord, voyons s'il y a des redirections HTTP ou HTML. J'aime utiliser Fiddler, et lorsque j'inspecte les demandes de réseau, je vois qu'il y a en effet de vieilles URL et des redirections flottantes.

J'ai récemment renommé mon github de Anonrobot à KealanParr , donc tout est le même sauf le nom de domaine.

Il semble que la première demande que nous appuyions soit https://anonrobot.github.io/redirect-to-slow-site/ avant qu'elle ne redirige vers https://anonrobot.github.io/slow-site/. Nous pouvons rembourser toutes nos URL de redirection vers le site vers le site vers l'URL mise à jour. Dans Devtools, l'inspecteur de réseau nous aide à voir ce que fait la première page Web. De mon point de vue dans Fiddler, cela ressemble à ceci:

Cela nous indique que le site utilise une redirection HTML vers le site suivant. Je vais mettre à jour mon URL référencée au nouveau site pour aider à réduire la latence qui ajoute un glisser vers la charge de page initiale.

Amélioration n ° 2: le chemin de rendu critique

Ensuite, je vais profiler le SIT avec le panneau de performances dans Devtools. Je suis surtout intéressé à débloquer le site en rendant le contenu aussi vite que possible. C'est le processus de transformation de HTML, CSS et JavaScript en un site Web interactif entièrement étoffé.

Il commence par la récupération du HTML à partir du serveur et la conversion en le modèle d'objet de document (DOM). Nous exécuterons n'importe quel JavaScript en ligne tel que nous le voyons, ou le téléchargerons s'il s'agit d'un atout externe au fur et à mesure que nous allons en analyse en ligne du HTML. Nous intégrerons également le CSS dans le modèle d'objet CSS (CSSOM). Le CSSOM et le DOM se combinent pour faire l'arbre de rendu. De là, nous exécutons la disposition qui place tout à l'écran au bon endroit avant de finalement exécuter de la peinture.

Ce processus peut être «bloqué» s'il doit attendre que les ressources se chargent avant son exécution. C'est ce que nous appelons le chemin de rendu critique , et les choses qui bloquent le chemin sont des ressources critiques .

Les ressources critiques les plus courantes sont:

• Une balise qui se trouve dans le et ne contient pas d'attribut asynchrone, out out ou module.
• A qui n'a pas l'attribut désactivé pour informer le navigateur de ne pas télécharger le CSS et n'a pas d'attribut multimédia qui correspond à l'appareil de l'utilisateur.

Il existe quelques autres types de ressources qui pourraient bloquer le chemin de rendu critique, comme les polices, mais les deux ci-dessus sont de loin les plus courants. Ces ressources bloquent le rendu parce que le navigateur pense que la page est «inachevée» et n'a aucune idée des ressources dont il a besoin ou a. Pour tout le navigateur, le site pourrait télécharger quelque chose qui s'attend à ce que le navigateur fasse encore plus de travail, comme le style ou les changements de couleur; Par conséquent, le site est incomplet pour le navigateur, il assume donc le pire et le rendu des blocs.

Un exemple de fichier CSS qui ne bloquerait pas le rendu serait:

 <link href="priing.css" rel="Stylesheet" media="print">

L'attribut "Media =" Print "ne télécharge que la feuille de style lorsque l'utilisateur imprime la page Web (car vous voulez peut-être styliser les choses différemment en imprimé), ce qui signifie que le fichier lui-même ne bloque rien du rendu avant.

Comme Chris aime le dire, un développeur frontal est conscient. Et être conscient de ce qu'une page doit télécharger avant le début du rendu est d'une importance vitale pour améliorer les scores d'audit des performances.

Amélioration # 3: déblocage de l'analyse

Le blocage du chemin de rendu est une chose que nous pouvons immédiatement accélérer, et nous pouvons également bloquer l'analyse si nous ne faisons pas attention à notre javascript. L'analyse est ce qui fait des éléments HTML une partie du DOM, et chaque fois que nous rencontrons JavaScript qui doit s'exécuter maintenant, nous bloquons cet analyse HTML de se produire.

Une partie du JavaScript de ma page Web lente n'a pas besoin de bloquer l'analyse. En d'autres termes, nous pouvons télécharger les scripts de manière asynchrone et continuer à analyser le HTML dans le DOM sans délai.

La balise est ce qui permet au navigateur de télécharger l'atout JavaScript de manière asynchrone. La balise exécute le javascript uniquement une fois la construction de la page terminée.

Il y a un compromis ici entre le JavaScript en instruction (donc l'exécution, il ne nécessite pas de demande de réseau) par rapport à le placer dans son propre fichier JavaScript (pour la modularité et le code-réutilisation). N'hésitez pas à faire votre propre jugement ici car le meilleur itinéraire va dépendre de la cas d'utilisation. Les performances réelles de l'application de CSS et JavaScript à une page Web seront les mêmes que ce soit un actif externe ou incliné, une fois qu'il est arrivé. La seule chose que nous supprimons lorsque nous nous sommes en ligne est le temps de demande de réseau pour obtenir les actifs externes (ce qui fait parfois une grande différence).

La principale chose que nous visons est de faire aussi peu que possible. Nous voulons différer des actifs de chargement et rendre ces actifs aussi petits que possible en même temps. Tout cela se traduira par un meilleur résultat de performance.

Mon site lent est à chaîner plusieurs demandes critiques, où le navigateur doit lire la ligne suivante de HTML, attendez, puis lisez le suivant pour vérifier un autre atout, puis attendez. La taille des actifs, lorsqu'ils sont téléchargés, et s'ils bloquent vont tous jouer énormément dans la vitesse à laquelle notre page Web peut se charger.

J'ai approché cela en profilant le site dans le panneau de performance Devtools, qui est simplement enregistré la façon dont le site se charge au fil du temps. J'ai brièvement numérisé mon HTML et ce qu'il a téléchargé, puis ajouté à tout script javascript externe qui bloquait les choses (comme le

Il est intéressant que Chrome ait une limite de navigateur où il ne peut gérer que six connexions HTTP en vol par nom de domaine, et attendra qu'un actif revienne avant d'en demander un autre une fois que ces six seront en vol. Cela rend la demande de multiples actifs critiques encore pire pour l'analyse HTML. Permettre au navigateur de continuer l'analyse accélérera le temps nécessaire pour montrer quelque chose à l'utilisateur et améliorer notre audit de performances.

Amélioration n ° 4: Réduisez la taille de la charge utile

La taille totale d'un site est un énorme facteur de détermination de la vitesse à laquelle il se chargera. Selon web.dev, les sites devraient viser à être inférieur à 1 600 Ko interactifs en moins de 10 secondes. Les grandes charges utiles sont fortement corrélées avec de longs temps à charger. Vous pouvez même considérer une charge utile importante comme une dépense pour l'utilisateur final, car les téléchargements importants peuvent nécessiter des plans de données plus importants qui coûtent plus cher.

À ce moment-là, mon site lent est un énorme 9 701 Ko - plus de six fois la taille idéale. Coupez cela.

Identifier les dépendances inutilisées

Au début de mon développement, j'ai pensé que je pourrais avoir besoin de certains actifs ou cadres. Je les ai téléchargés sur ma page et je ne me souviens pas maintenant de ceux qui sont réellement utilisés. J'ai certainement des actifs qui ne font que perdre du temps et de l'espace.

En utilisant l'inspecteur de réseau dans Devtools (ou un outil avec lequel vous vous sentez à l'aise), nous pouvons voir certaines choses qui peuvent certainement être supprimées du site sans changer son comportement sous-jacent. J'ai trouvé beaucoup de valeur dans le panneau de couverture de Devtools car il montrera à quel point le code est utilisé après le téléchargement de tout.

Comme nous l'avons déjà discuté, il y a toujours un bon équilibre en ce qui concerne le CSS et le JavaScript par rapport à l'utilisation d'un atout externe. Mais, en ce moment même, il semble certainement que le site télécharge beaucoup trop qu'il n'en a vraiment besoin.

Une autre façon rapide de réduire les choses est de découvrir si l'un des actifs sur laquelle le site essaie de charger les 404. Ces demandes peuvent certainement être supprimées sans aucun impact négatif sur le site car ils ne se chargent pas de toute façon. Voici ce que Fiddler me montre:

En examinant à nouveau le rapport de couverture, nous savons qu'il y a des choses qui sont téléchargées mais qui ont une quantité importante de code inutilisé qui se rendent toujours à la page. En d'autres termes, ces actifs font quelque chose, mais sont également prêts à faire des choses dont nous n'avons même pas besoin pour faire. Cela inclut React, JQuery et Vue, de sorte que ceux-ci peuvent être supprimés de mon site lent sans impact réel.

Pourquoi tant de bibliothèques JavaScript? Eh bien, nous savons qu'il existe des scénarios réels où nous atteignons quelque chose parce qu'il répond à nos exigences; Mais alors ces exigences changent et nous devons atteindre autre chose. Encore une fois, nous devons être conscients en tant que développeurs frontaux, et en continuant à garder un œil sur les ressources pertinentes pour le site fait partie de cette conscience globale.

Comprimer, minimiser et mettre en cache des actifs

Ce n'est pas parce que nous devons servir un actif que nous devons le servir de taille réelle, ou même reserser cet actif la prochaine fois que l'utilisateur visitera le site. Nous pouvons compresser nos actifs, minimer nos styles et scripts et mettre en cache les choses de manière responsable, nous servons donc ce dont l'utilisateur a besoin de la manière la plus efficace possible.

• La compression signifie que nous optimisons un fichier, tel qu'une image, à sa plus petite taille sans impact sur sa qualité visuelle. Par exemple, GZIP est un algorithme de compression commun qui rend les actifs plus petits.
• La minification améliore la taille des actifs textuels, comme les fichiers de script externes, en supprimant Cruft du code, comme les commentaires et les espaces blancs, dans le but d'envoyer moins d'octets sur le fil.
• La mise en cache nous permet de stocker un actif dans la mémoire du navigateur pendant un temps afin qu'il soit immédiatement disponible pour les utilisateurs des charges de page suivantes. Alors, chargez-le une fois, profitez-en plusieurs fois.

Regardons trois types différents d'actifs et comment les croquer avec ces tactiques.

Actifs textuels

Ceux-ci incluent des fichiers texte, comme HTML, CSS et JavaScript. Nous voulons faire tout ce qui est en notre pouvoir pour les rendre aussi légers que possible, donc nous les comprimons, les minifaces et les mettons en cache lorsque cela est possible.

À un niveau très élevé, GZIP fonctionne en trouvant des pièces courantes et répétées dans le contenu, stocke ces séquences une fois, puis les supprime du texte source. Il garde une recherche de dictionnaire afin qu'il puisse rapidement référencer les pièces enregistrées et les remettre en place où elles appartiennent, dans un processus appelé Gunzipping. Consultez ces exemples gziés un fichier contenant de la poésie.

Nous faisons cela pour rendre les téléchargements de texte aussi petits que possible. Nous utilisons déjà GZIP. J'ai vérifié à l'aide de cet outil par GidNetwork. Il montre que le contenu du site lent est compressé à 59,9%. Cela signifie probablement qu'il y a plus d'occasions de rendre les choses encore plus petites.

J'ai décidé de consolider les multiples fichiers CSS en un seul fichier appelé styles.css. De cette façon, nous limitons le nombre de demandes de réseau nécessaires. En outre, si nous ouvrons les trois fichiers, chacun contenait une si petite quantité de CSS que les trois demandes de réseau ne sont tout simplement pas justifiées.

Et, ce faisant, cela m'a donné l'occasion de supprimer les sélecteurs CSS inutiles qui n'étaient pas appliqués dans le DOM n'importe où, réduisant à nouveau le nombre d'octets envoyés à l'utilisateur.

Ilya Grigorik a écrit un excellent article avec des stratégies de compression des actifs basés sur le texte.

Images

Nous sommes également en mesure d'optimiser les images sur le site lent. Comme les rapports le montrent systématiquement, les images sont la demande d'actifs la plus courante. En fait, le transfert médian de données pour les images est de 948,1 Ko pour les ordinateurs de bureau et de 902 Ko pour les appareils mobiles de 2016 à 2021. Cela déjà plus de la moitié de la taille idéale de 1 600 Ko pour une charge de page entière.

Mon site lent ne sert pas autant d'images, mais les images qu'il sert peut être plus petite. J'ai dirigé les images via un outil en ligne appelé Squoosh et réalisé une économie de 40% (18,6 Ko à 11,2 Ko). C'est une victoire! Bien sûr, c'est quelque chose que vous pouvez faire avant de télécharger à l'aide d'une application de bureau, comme ImageOptim, soit même dans votre processus de construction.

Je n'ai pas pu voir de différences visuelles entre les images d'origine et les versions optimisées (ce qui est génial!) Et j'ai même pu réduire davantage la taille en redimentant le fichier réel, en réduisant la qualité de l'image et même en modifiant la palette de couleurs. Mais ce sont des choses que j'ai faites dans les logiciels d'édition d'images. Idéalement, c'est quelque chose que vous ou un designer ferais lorsqu'il ferait initialement les actifs.

Mise en cache

Nous avons abordé la minification et la compression et ce que nous pouvons faire pour essayer de les utiliser à notre avantage. La dernière chose que nous pouvons vérifier est la mise en cache.

J'ai demandé le site lent encore et encore et, jusqu'à présent, je peux voir qu'il semble toujours être demandé à chaque fois sans aucune mise en cache. J'ai regardé à travers le HTML et j'ai vu que la mise en cache était désactivée ici:

 <meta http-equiv="cache-control" contenu="non-cache, sans magasin, doit-revalider">

J'ai supprimé cette ligne, donc la mise en cache du navigateur devrait maintenant pouvoir avoir lieu, aidant à servir le contenu encore plus rapidement.

Amélioration # 5: Utilisez un CDN

Une autre grande amélioration que nous pouvons apporter sur n'importe quel site Web consiste à servir autant que possible à partir d'un réseau de livraison de contenu (CDN). David Attard a une pièce super complète sur la façon d'ajouter et de tirer parti d'un CDN. Le chemin traditionnel de la livraison du contenu consiste à appuyer sur le serveur, à demander des données et à attendre qu'il revienne. Mais si l'utilisateur demande des données de l'autre côté du monde, d'où vos données sont servies, eh bien, cela ajoute du temps. Faire un voyage d'octets plus loin dans la réponse du serveur peut ajouter de grandes pertes de vitesse, même si tout le reste est rapide.

Un CDN est un ensemble de serveurs distribués à travers le monde qui sont capables de fournir intelligemment du contenu plus près de l'utilisateur, car il dispose de plusieurs emplacements à partir duquel il a choisi de le servir.

Nous avons discuté plus tôt de la façon dont je faisais à l'utilisateur JQuery lorsqu'il n'utilise pas réellement le code téléchargé, et nous l'avons supprimé. Une correction facile ici, si j'avais réellement besoin de jQuery, est de demander l'actif à un CDN. Pourquoi?

• Un utilisateur a peut-être déjà téléchargé l'actif en visitant un autre site, afin que nous puissions servir une réponse en cache pour le CDN. 75,49% des meilleurs sites utilisent encore jQuery, après tout. En 2020, les navigateurs (Safari, Chrome) ont commencé à faire du «partitionnement du cache», ce qui signifie que les actifs ne sont pas mis en cache entre différents sites, donc ce bénéfice potentiel est supprimé. Le fichier se cachera toujours par website.
• Il n'a pas à voyager aussi loin de l'utilisateur qui demande les données.

Nous pouvons faire quelque chose d'aussi simple que de saisir jQuery de Google's CDN, qu'ils mettent à disposition pour que quiconque référenne sur ses propres sites:

 <adal>
  <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js"> </ script>
</ head></script></adal>

Cela sert JQuery beaucoup plus rapidement qu'une demande standard de mon serveur, c'est sûr.

Les choses sont-elles meilleures?

Si vous avez mis en œuvre avec moi jusqu'à présent, ou si vous lisez simplement, il est temps de re-profiler et de voir si des améliorations ont été apportées sur ce que nous avons fait jusqu'à présent.

Rappelez-vous où nous avons commencé:

Après nos modifications:

J'espère que cela a été utile et vous encourage à rechercher des victoires en performances supplémentaires sur votre propre site. En demandant de manière optimale des actifs, en reportant certains actifs du chargement et en réduisant la taille globale de la taille du site obtiendra un site fonctionnel et entièrement interactif devant l'utilisateur le plus rapidement possible.

Vous voulez continuer la conversation? Je partage mon écriture sur Twitter si vous voulez en voir plus ou vous connecter.

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!