Optimiser la taille et les performances (partie 3) —

La base de code refactorisée devrait entraîner des performances similaires ou améliorées et une meilleure santé de la base de code. Après tout, si le déploiement de la base de code refactorisée entraîne des problèmes de chargement ou de performances, cela entraînera moins de trafic et de revenus. Heureusement, il existe de nombreuses techniques d'optimisation que nous pouvons appliquer pour résoudre les problèmes potentiels de taille de fichier et de performances.

Dans les articles précédents de cette série, nous avons couvert l'audit de l'état de la base de code CSS et la stratégie de refactorisation CSS incrémentielleles tests et la maintenance. Indépendamment de l'amélioration de la base de code CSS au cours du processus de refactorisation et de sa facilité de maintenance et d'extension, la feuille de style finale doit être optimisée pour les meilleures performances possibles et une taille de fichier minimale.[19659003]Le déploiement de la base de code refactorisée ne devrait pas entraîner une dégradation des performances du site Web et une moins bonne expérience utilisateur. Après tout, les utilisateurs n'attendront pas indéfiniment que le site Web se charge. De plus, la direction sera insatisfaite de la diminution du trafic et des revenus causés par la base de code non optimisée, malgré les améliorations de la qualité du code.

Dans cet article, nous allons couvrir les stratégies d'optimisation CSS qui peuvent optimiser Taille du fichier CSS, temps de chargement et performances de rendu. De cette façon, la base de code CSS refactorisée est non seulement plus maintenable et extensible, mais également performante et coche toutes les cases importantes à la fois pour l'utilisateur final et la direction. caractères inutiles et formatage et optimisation du code CSS pour utiliser différentes syntaxes ou propriétés abrégées afin de réduire le nombre total de caractères dans un fichier. un incontournable de l'optimisation frontend. Des outils comme cssnano et clean-css font partie de mes outils préférés en matière d'optimisation et de minification CSS. Ils offrent une grande variété d'options de personnalisation pour mieux contrôler la façon dont le code est optimisé et quels navigateurs sont pris en charge.

Ces outils fonctionnent de manière similaire. Tout d'abord, le code non optimisé est analysé et transpilé en suivant les règles définies dans le fichier config. Le résultat est le code qui utilise moins de caractères mais conserve toujours la mise en forme (sauts de ligne et espaces).

/* Avant - code original et non optimisé */
.récipient {
  rembourrage : 24px 16px 24px 16px ;
  arrière-plan : #222222 ;
}

/* Après - code optimisé avec formatage */
.récipient {
  rembourrage : 24px 16px ;
  arrière-plan : #222 ;
}

Et enfin, le code optimisé transpilé est minifié en supprimant tout formatage de texte inutile. Selon la base de code et les navigateurs pris en charge définis dans la configuration, le code avec des préfixes de fournisseur obsolètes peut également être supprimé.

/* Avant - code optimisé avec formatage */
.récipient {
  rembourrage : 24px 16px ;
  arrière-plan : #222 ;
}

/* Après - code optimisé et minifié */
.container{padding:24px 16px;background:#222}

Même dans cet exemple de base, nous avons réussi à réduire la taille globale du fichier de 76 octets à 55 octets, soit une réduction de 23 %. En fonction de la base de code et des outils d'optimisation et de la configuration, l'optimisation et la minification CSS peuvent être encore plus efficaces. des ajustements au flux de travail CSS. C'est pourquoi la minification doit être considérée comme l'optimisation des performances au strict minimum et une exigence pour toutes les feuilles de style du projet.

Optimisation des requêtes multimédias

Lorsque nous écrivons des requêtes multimédias en CSS, en particulier lorsque nous utilisons plusieurs fichiers (PostCSS ou Sass), nous n'imbrissons généralement pas le code sous une seule requête multimédia pour un projet entier. Pour une maintenance, une modularité et une structure de code améliorées, nous écrivons généralement les mêmes expressions de requête multimédia pour plusieurs composants CSS.

Considérons l'exemple suivant d'une base de code CSS non optimisée.

.page {
  affichage : grille ;
  espacement de la grille : 16px ;
}

@media (min-width : 768px) {
  .page {
    grid-template-columns : 268px auto ;
    espacement de la grille : 24 px ;
  }
}

/* ... */

.products-grid {
  affichage : grille ;
  grid-template-columns: repeat(2, 1fr);
  espacement de la grille : 16px ;
}

@media (min-width : 768px) {
  .products-grid {
    grid-template-columns: repeat(3, 1fr);
    espacement de la grille : 20 px ;
  }
}

Comme vous pouvez le voir, nous avons un @media (min-width : 768px) répété par composant pour une meilleure lisibilité et une meilleure maintenance. Exécutons l'optimisation et la minification sur cet exemple de code et voyons ce que nous obtenons.

.page{display:grid;grid-gap:16px}@media (min-width: 768px){.page{grid-template-columns :268px auto;grid-gap:24px}}.products-grid{display:grid;grid-template-columns:repeat(2,1fr);grid-gap:16px}@media (min-width: 768px){. products-grid{grid-template-columns:repeat(3,1fr);grid-gap:20px}}

Cela peut être un peu difficile à lire, mais tout ce que nous devons remarquer est la répétition @media (min-width : 768px) requête média. Nous avons déjà conclu que nous voulons réduire le nombre de caractères dans une feuille de style et que nous pouvons imbriquer plusieurs sélecteurs sous une seule requête multimédia, alors pourquoi le minificateur n'a-t-il pas supprimé l'expression dupliquée ? Il y a une raison simple à cela.

L'ordre des règles est important dans CSS, donc pour fusionner les requêtes multimédias dupliquées, les blocs de code doivent être déplacés. Cela entraînera la modification des ordres de règles ce qui peut entraîner des effets secondaires indésirables dans les styles.

Cependant, la combinaison de requêtes multimédias pourrait potentiellement réduire la taille du fichier, en fonction de la base de code et de la structure. Des outils et des packages tels que postcss-sort-media-queries nous permettent de supprimer les requêtes multimédias en double et de réduire davantage la taille du fichier.

Bien sûr, il y a la mise en garde importante d'avoir un bien- structure de base de code CSS structurée qui ne dépend pas de l'ordre des règles. Cette optimisation doit être prise en compte lors de la planification du refactor CSS et de l'établissement des règles de base.

Je recommanderais de vérifier d'abord si les avantages de l'optimisation l'emportent sur les risques potentiels. Cela peut être facilement fait en exécutant un audit CSS et en vérifiant les statistiques des requêtes multimédias. Si c'est le cas, je recommanderais de l'ajouter plus tard et d'exécuter des tests de régression automatisés pour détecter les effets secondaires et les bogues inattendus qui peuvent en résulter.

Suppression des CSS inutilisés

Pendant la refactorisation processus, il est toujours possible que vous vous retrouviez avec des styles hérités inutilisés qui n'ont pas été complètement supprimés ou que vous ayez des styles nouvellement ajoutés qui ne sont pas utilisés. Ces styles s'ajoutent également au nombre total de caractères et à la taille du fichier. Cependant, éliminer ces styles inutilisés à l'aide d'outils automatisés peut être quelque peu risqué, car les outils ne peuvent pas prédire avec précision quels styles sont réellement utilisés.

Des outils tels que purgecss parcourent tous les fichiers du projet et utilisent tous les les classes mentionnées dans les fichiers en tant que sélecteurs, juste pour faire preuve de prudence et ne pas supprimer accidentellement les sélecteurs pour les éléments dynamiques injectés en JavaScript, entre autres cas potentiels. Cependant, purgecss offre des options de configuration flexibles comme solutions de contournement pour ces problèmes et risques potentiels.

Cependant, cette amélioration ne doit être effectuée que lorsque les avantages potentiels l'emportent sur les risques. De plus, cette technique d'optimisation nécessitera un temps considérable pour l'installation, la configuration et le test, et pourrait causer des problèmes inattendus sur toute la ligne, alors procédez avec prudence et assurez-vous que la configuration est à l'épreuve des balles.

Élimination du CSS bloquant le rendu

Par défaut, CSS est une ressource bloquant le renduce qui signifie que le site Web ne sera pas affiché à l'utilisateur tant que toutes les feuilles de style liées et leurs dépendances (polices, par exemple) n'auront pas été téléchargé et analysé par le navigateur.

Si le fichier de feuille de style a une grande taille de fichier ou plusieurs dépendances situées sur des serveurs tiers ou des CDN, le rendu du site Web peut être considérablement retardé en fonction de la vitesse et de la fiabilité du réseau.

Le plus grand. Contentful Paint (LCP) est devenu une mesure importante au cours des derniers mois. Le LCP n'est pas seulement important pour les performances, mais aussi pour le référencement – les sites Web avec de meilleurs scores LCP auront un meilleur classement des résultats de recherche . La suppression des ressources bloquant le rendu comme CSS est un moyen d'améliorer le score LCP.

Cependant, si nous différions le chargement et le traitement de la feuille de style, cela entraînerait Flash Of Unstyled Content (FOUC) — content serait immédiatement affiché à l'utilisateur et les styles seraient chargés et appliqués quelques instants plus tard. Ce changement peut sembler choquant et peut même dérouter certains utilisateurs.

Critical CSS

Avec Critical CSS, nous pouvons nous assurer que le site Web se charge avec le minimum de styles dont l'utilisation est garantie. sur la page lors de son rendu initial. De cette façon, nous pouvons rendre le FOUC beaucoup moins visible ou même l'éliminer dans la plupart des cas. Par exemple, si la page d'accueil comporte un composant d'en-tête avec navigation et un composant héros situé au-dessus du plicela signifie que le CSS critique contiendra tous les styles globaux et composants nécessaires pour ces composants, tandis que les styles pour les autres composants de la page sera différé.

Ce CSS est inséré en HTML sous une balise stylede sorte que les styles sont chargés et analysés avec le fichier HTML. Bien que cela se traduise par une taille de fichier HTML légèrement plus grande (qui devrait également être réduite), tous les autres CSS non critiques seront différés et ne seront pas chargés immédiatement et le site Web sera rendu plus rapidement. Dans l'ensemble, les avantages l'emportent sur l'augmentation de la taille du fichier HTML.

Il existe de nombreux outils et packages NPM automatisés, en fonction de votre configuration, qui peuvent extraire des CSS critiques et générer des feuilles de style différées.

Feuilles de style différées

Comment faisons-nous exactement rendre le CSS non bloquant ? Nous savons qu'il ne doit pas être référencé dans l'élément HTML head lors du premier téléchargement de la page HTML. Demian Renzulli a décrit cette méthode dans son article.

Il n'y a aucune approche HTML native (pour l'instant) pour optimiser ou différer le chargement des ressources bloquant le rendu, nous besoin d'utiliser JavaScript pour insérer la feuille de style non critique dans le balisage HTML après le rendu initial. Nous devons également nous assurer que ces styles sont chargés de manière non optimale (blocage du rendu) si un utilisateur visite la page avec JavaScript non activé dans le navigateur.

Avec link rel="preload" as="style" s'assure que le fichier de feuille de style est demandé de manière asynchrone, tandis que onload le gestionnaire JavaScript s'assure que le fichier est chargé et traité par le navigateur une fois le chargement du document HTML terminé. Un certain nettoyage est nécessaire, nous devons donc définir le onload sur null pour éviter que cette fonction ne s'exécute plusieurs fois et ne provoque des rendus inutiles.

C'est exactement comment Smashing Magazine gère ses feuilles de style. Chaque modèle (page d'accueil, catégories d'articles, pages d'articles, etc.) a un CSS critique spécifique au modèle inséré dans la balise HTML style dans l'élément headet une deferred main.css stylesheet qui contient tous les styles non critiques.

Cependant, au lieu de basculer le paramètre relnous pouvons voir ici le média requête étant basculée du support de faible priorité print automatiquement différé à l'attribut de priorité élevée all lorsque la page a fini de se charger. Il s'agit d'une approche alternative, tout aussi viable, pour différer le chargement des feuilles de style non critiques.

Fractionnement et chargement conditionnel de feuilles de style avec des requêtes multimédias

Pour les cas où le fichier de feuille de style final a une grande taille de fichier même après l'application des optimisations susmentionnées, vous pouvez fractionner les feuilles de style en plusieurs fichiers basé sur les requêtes média et utiliser la propriété média sur les feuilles de style référencées dans l'élément HTML link pour les charger conditionnellement.

De cette façon, si une approche axée sur le mobile est utilisée, les styles pour les écrans plus grands ne seront pas téléchargés ou analysés sur les appareils mobiles qui pourraient fonctionner sur des réseaux plus lents ou peu fiables.

Je répète, cette méthode doit être utilisée si le résultat des méthodes d'optimisation mentionnées précédemment donne une feuille de style avec une taille de fichier sous-optimale. Pour les cas courants, cette méthode d'optimisation ne sera pas aussi efficace ou percutante, selon la taille de la feuille de style individuelle.

Deferring Font Files And Stylesheets

Le report des feuilles de style de police (fichiers Google Font, par exemple) pourrait également être bénéfique pour performances de rendu initiales. Nous avons conclu que les feuilles de style bloquent le rendu, tout comme les fichiers de polices référencés dans la feuille de style. Les fichiers de polices ajoutent également un peu de surcharge aux performances de rendu initiales.

Le chargement de feuilles de style de polices et de fichiers de polices est un sujet complexe et il faudrait un tout nouvel article pour expliquer toutes les approches viables. . Heureusement, Zach Leatherman a décrit de nombreuses stratégies viables dans cet impressionnant guide complet et a résumé les avantages et les inconvénients de chaque approche. Si vous utilisez Google Fonts, Harry Roberts a décrit une stratégie pour le chargement le plus rapide de Google Fonts.

Si vous décidez de différer les feuilles de style de police, vous vous retrouverez avec Flash of Unstyled Text (FOUT) . La page sera initialement rendue avec la police de secours jusqu'à ce que les fichiers de polices et les feuilles de style différés aient été téléchargés et analysés, après quoi les nouveaux styles seront appliqués. Ce changement peut être très perceptible et peut provoquer des changements de mise en page et dérouter les utilisateurs, selon le cas individuel.

Barry Pollard a décrit certaines stratégies qui peuvent nous aider à faire face à FOUT et a parlé de la prochaine fonctionnalité CSS d'ajustement de la taille qui fournira un moyen plus simple et plus natif de traiter FOUT. comme HTML, les fichiers CSS, les fichiers JavaScript, etc. Les algorithmes de compression HTTP comme Gzip et Brotli peuvent être utilisés pour réduire en plus la taille du fichier téléchargé.

La compression HTTP doit être configurée sur le serveur qui dépend de la pile technique et la configuration. Cependant, les avantages en termes de performances peuvent varier et peuvent ne pas avoir autant d'impact que la minimisation et l'optimisation des feuilles de style standard, car les navigateurs décompresseront toujours les fichiers compressés et devront les analyser.

Caching Stylesheets

Caching static files est une stratégie d'optimisation utile. Les navigateurs devront toujours télécharger les fichiers statiques du serveur lors du premier chargement, mais une fois mis en cache, ils seront chargés directement à partir de celui-ci lors des requêtes suivantes, accélérant ainsi le processus de chargement.

La mise en cache peut être contrôlée via . ]Cache-Control Entête HTTP au niveau du serveur (par exemple, en utilisant le fichier .htaccess sur un serveur Apache).

Avec max-age on peut indiquer combien de temps le fichier doit rester en cache (en secondes) dans le navigateur et avec publicnous indiquons que le fichier peut être mis en cache par le navigateur et tout autre cache.

 Cache-Control : public, max-age=604800

Une stratégie de cache plus agressive et efficace pour les actifs statiques peut être obtenue avec la configuration immutable. Cela indique au navigateur que ce fichier particulier ne changera jamais et que toute nouvelle mise à jour entraînera la suppression de ce fichier et un nouveau fichier avec un nom de fichier différent prendra sa place. Ceci est connu sous le nom de cache-busting.

Cache-Control: public, max-age=604800, immutable

Sans une stratégie de cache-busting appropriéeil existe une risque de perdre le contrôle des fichiers mis en cache sur le navigateur de l'utilisateur. Cela signifie que si le fichier devait changer, le navigateur ne pourra pas savoir qu'il doit télécharger le fichier mis à jour et ne pas utiliser le fichier mis en cache obsolète. Et à partir de ce moment-là, nous ne pouvons pratiquement rien faire pour résoudre ce problème et l'utilisateur sera bloqué avec le fichier obsolète jusqu'à son expiration.

Pour les feuilles de style, cela pourrait signifier que si nous devions mettre à jour les fichiers HTML avec un nouveau contenu. et les composants qui nécessitent un nouveau style, ces styles ne s'afficheront pas car la feuille de style obsolète est mise en cache sans stratégie de contournement du cache et le navigateur ne saura pas qu'il doit télécharger le nouveau fichier.

Avant d'utiliser une stratégie de mise en cache pour feuilles de style ou tout autre fichier statique, des mécanismes efficaces de contournement du cache doivent être mis en œuvre pour empêcher les fichiers statiques obsolètes de rester bloqués dans le cache de l'utilisateur. Vous pouvez utiliser l'un des mécanismes de gestion des versions suivants pour le contournement du cache :

• Ajout d'une chaîne de requête au nom de fichier.
  Par exemple styles.css?v=1.0.1. Cependant, certains CDN peuvent complètement ignorer ou supprimer la chaîne de requête du nom de fichier et entraîner le blocage du fichier dans le cache de l'utilisateur et ne jamais se mettre à jour.
• Modifier le nom du fichier ou ajouter un hachage.
  Par exemple styles.a1bc2.css ou styles.v1.0.1.css. C'est plus fiable et efficace que d'ajouter une chaîne de requête au nom du fichier. livraison d'actifs statiques tels que des images, des vidéos, des fichiers HTML, des fichiers CSS, des fichiers JavaScript, etc.

  Bien que les CDN puissent sembler être une excellente alternative aux actifs statiques auto-hébergés, Harry Roberts a effectué des recherches approfondies sur le sujet et a conclu que les ressources d'auto-hébergement sont plus bénéfiques pour les performances.

  « Il y a vraiment très peu de raisons de laisser vos ressources statiques sur l'infrastructure de quelqu'un d'autre. Les avantages perçus sont souvent un mythe, et même s'ils ne l'étaient pas, les compromis n'en valent tout simplement pas la peine. Le chargement d'actifs d'origines multiples est manifestement plus lent. »

  Cela étant dit, je recommanderais d'auto-héberger les feuilles de style (feuilles de style de police incluses, si possible) par défaut et de passer au CDN uniquement s'il existe des raisons ou d'autres avantages à le faire.

  Auditing CSS File Size and Performance

  WebPageTest et d'autres outils d'audit de performance similaires peuvent être utilisés pour obtenir un aperçu détaillé du processus de chargement du site Web, de la taille des fichiers, ressources bloquant le rendu, etc. Ces outils peuvent vous donner un aperçu de la façon dont votre site Web se charge sur une large gamme d'appareils – d'un ordinateur de bureau fonctionnant sur un réseau haut débit aux smartphones bas de gamme fonctionnant sur des réseaux lents et peu fiables.

  Faisons un audit de performance sur un site Web mentionné dans le premier article de cette série – celui avec les 2 Mo de CSS minifié.

  Tout d'abord, nous allons jeter un œil au répartition du contenu pour déterminer qui Les ressources h occupent le plus de bande passante. À partir des graphiques suivants, nous pouvons voir que les images prennent la plupart des demandes, ce qui signifie qu'elles doivent être chargées paresseux. À partir du deuxième graphique, nous pouvons voir que les feuilles de style et les fichiers JavaScript sont les plus volumineux en termes de taille de fichier. C'est une bonne indication que ces fichiers doivent être soit minimisés et optimisés, refactorisés, soit divisés en plusieurs fichiers et chargés de manière asynchrone.

  

  Nous pouvons tirer encore plus de conclusions des graphiques Web Vitals. En examinant le tableau Largest Contentful Paint (LCP), nous pouvons obtenir un aperçu détaillé des ressources bloquant le rendu et dans quelle mesure elles affectent le rendu initial.

  Nous pourrions déjà conclure que le site Web La feuille de style aura le plus d'impact sur le LCP et les statistiques de chargement. Cependant, nous pouvons voir des feuilles de style de police, des fichiers JavaScript et des images référencées dans les feuilles de style qui bloquent également le rendu. Sachant que nous pouvons appliquer les méthodes d'optimisation susmentionnées pour réduire le temps LCP en éliminant les ressources bloquant le rendu. Remarquez l'ampoule orange sur la chronologie dans la liste des ressources – ces ressources bloquent le rendu. ( Grand aperçu)
  

  Conclusion

  Le processus de refactorisation n'est pas terminé lorsque la santé et la qualité du code ont été améliorées et lorsque les faiblesses et les problèmes de la base de code ont été corrigés. La base de code refactorisée devrait entraîner des performances identiques ou améliorées par rapport à la base de code héritée.

  Les utilisateurs finaux ne devraient pas rencontrer de problèmes de performances ou de longs temps de chargement à partir de la base de code refactorisée. Heureusement, il existe de nombreuses méthodes pour s'assurer que les bases de code sont à la fois robustes et performantes – des méthodes simples de minification et d'optimisation aux méthodes plus complexes comme l'élimination des ressources bloquant le rendu et le fractionnement de code.[19659003]Nous pouvons utiliser divers outils d'audit des performances comme WebPageTest pour obtenir un aperçu détaillé des temps de chargement, des performances, des ressources de blocage du rendu et d'autres facteurs afin que nous puissions résoudre ces problèmes rapidement et efficacement.

  Références

  (vf, yk, il)