Même en 2021, les performances web restent un problème. Selon HTTP Archive, une page moyenne nécessite un téléchargement de 2 Mo, effectue plus de 60 requêtes HTTP et peut prendre 18 secondes pour se charger complètement sur un appareil mobile. Les feuilles de style représentent 60 ko répartis sur sept requêtes, elles sont donc rarement une priorité absolue lorsqu’on tente de résoudre les problèmes de performance.

Cependant, les feuilles de style ont un effet, même s’il semble minime. Une fois que vous avez réglé votre problème de JavaScript, apprendre à optimiser correctement les CSS devrait être la prochaine priorité.

Allons-y !

Comment le CSS affecte les performances de page

CSS a l’air innocent mais peut nécessiter un traitement lourd.

CSS bloquant le rendu

Lorsque votre navigateur rencontre une balise <link>, il interrompt les autres téléchargements et traitements du navigateur pendant qu’il récupère et analyse le fichier CSS.

JavaScript peut aussi bloquer le rendu du navigateur, mais le traitement asynchrone est possible avec :

  1. L’attribut async pour télécharger des scripts en parallèle, qui sont exécutés dès qu’ils sont prêts.
  2. L’attribut defer pour télécharger en parallèle, puis exécuter dans l’ordre lorsque le DOM est prêt.
  3. L’attribut type="module" pour charger un module ES (qui se comporte comme defer).

Les ressources telles que les images nécessitent souvent plus de bande passante, mais des formats efficaces sont disponibles, et ils peuvent être chargés de manière différée ( attributloading="lazy" ) sans bloquer le rendu du navigateur.

Rien de tout cela n’est possible avec CSS. Le fichier est mis en cache, donc les chargements de pages suivants devraient être plus rapides, mais le blocage du rendu demeure.

Les gros fichiers CSS prennent du temps à être traités

Plus votre feuille de style est grande, plus il lui faut du temps pour être téléchargée et traitée dans un modèle d’objet CSS (CSSOM), que le navigateur et les API JavaScript peuvent utiliser pour afficher la page. Bien que les feuilles de style CSS soient plus petites que la plupart des autres fichiers de sites web, elles ne sont pas à l’abri de la règle empirique « plus c’est petit, mieux c’est ».

Les fichiers CSS grossissent

Il peut être difficile d’identifier les styles qui ne sont plus utilisés, et supprimer les mauvais peut faire des ravages sur un site. Les développeurs optent généralement pour l’approche la plus sûre « tout conserver ». Les styles de page, les composants et les widgets qui ne sont plus utilisés continuent d’exister dans le CSS. Le résultat ? La taille du fichier, la complexité et l’effort de maintenance augmentent de façon exponentielle, ce qui rend les développeurs de moins en moins enclins à supprimer le code redondant.

Les feuilles de style peuvent référencer d’autres ressources

Le CSS peut référencer d’autres feuilles de style à l’aide des règles @import. Ces importations bloquent le traitement de la feuille de style actuelle et chargent d’autres fichiers CSS en série.

D’autres ressources, comme les polices et les images, peuvent également être référencées. Le navigateur tentera d’optimiser les téléchargements, mais en cas de doute, il les récupérera immédiatement. Les fichiers encodés en base64 subissent encore un traitement supplémentaire.

Rendu des effets CSS

Les navigateurs ont trois phases de rendu:

  1. La phase de mise en page (ou refonte) calcule les dimensions de chaque élément et la façon dont il affecte la taille ou le positionnement des éléments qui l’entourent.
  2. La phase de peinture dessine les parties visuelles de chaque élément sur des couches séparées : texte, couleurs, images, bordures, ombres, etc.
  3. Le composite dessine chaque couche sur la page dans l’ordre correct selon les contextes d’empilage, le positionnement, les z-index, etc.

Si vous ne faîtes pas attention, les changements de propriétés et les animations CSS peuvent entraîner un nouveau rendu des trois phases. Certaines propriétés, comme les ombres et les dégradés, sont également plus coûteuses en termes de calcul que les couleurs de bloc et les marges.

Outils d’analyse des performances CSS

Admettre que vous avez un problème de performances CSS est la première étape sur le chemin de la guérison ! Trouver et réparer les causes est une autre affaire.

Les outils et services suivants (non classés dans un ordre quelconque) peuvent vous aider à identifier les goulots d’étranglement stylistiques dans votre code.

1. Panneau réseau DevTools

Les spécialistes des performances web passent beaucoup de temps dans DevTools et le panneau Réseau en particulier. DevTools est natif de la plupart des navigateurs modernes, mais nous utiliserons Google Chrome dans nos exemples.

DevTools peut être ouvert à partir du menu du navigateur, généralement dans Plus d’outils > Outils de développement, ou via les raccourcis clavier Ctrl | Cmd + Shift + I ou F12.

Passez à l’onglet Réseau et assurez-vous que la case Désactiver le cache est cochée pour éviter que les fichiers mis en cache n’affectent le rapport. Vous pouvez aussi modifier l’option d’étranglement pour simuler des réseaux mobiles plus lents.

Rafraîchissez la page pour afficher le graphique de la cascade de téléchargement et de traitement :

Panneau Réseau de DevTools.
Panneau Réseau de DevTools.

Toute barre longue est source d’inquiétude, mais vous devez vous méfier tout particulièrement des barres longues bloquées/stagnées (indiquées en blanc). Dans cet exemple, la ligne en surbrillance et toutes les lignes suivantes n’ont pas pu commencer à se télécharger tant que les fichiers CSS et JavaScript bloquant le rendu n’ont pas été traités en haut de la page HTML.

La case Filtre vous permet d’afficher ou de masquer des resssources spécifiques :

  • lager-than:<S>: Limite aux fichiers plus grands que <S>, exprimés en octets (10 000), kilo-octets (1 000 Ko) ou méga-octets (1 Mo)
  • -larger-than:<S>: Limite les fichiers plus petits que <S>
  • -domain:*<.yourdomain.com>: Affiche les requêtes tierces qui ne sont pas chargées depuis votre domaine principal. Celles-ci contribuent grandement à la lenteur des sites.

Une page très performante avec un CSS optimisé a généralement moins de ressources chargées en parallèle avec de courtes barres bloquées/stockées.

2. WebPageTest

WebPageTest fournit une vue similaire de la cascade de réseaux, ainsi que de nombreux autres graphiques de performance :

Cascade de ressources de WebPageTest.org
Cascade de ressources de WebPageTest.org

Le service utilise des appareils basés dans divers endroits du monde pour que vous puissiez évaluer les performances réelles et les optimisations CSS.

3. Panneau Chrome DevTools Lighthouse

Le panneau DevTools Lighthouse est fourni dans les navigateurs basés sur Chromium tels que Chrome, Edge, Brave, Opera et Vivaldi. Vous pouvez générer des rapports sur les performances, les Progressive Web App, les meilleures pratiques, l’accessibilité et l’optimisation des moteurs de recherche pour les appareils mobiles et de bureau.

Panneau DevTools Lighthouse.
Panneau DevTools Lighthouse.

L’outil fait des suggestions d’amélioration, notamment des moyens d’optimiser les CSS. Toutes ne sont pas forcément pratiques ou possibles, mais les gains rapides les plus bénéfiques sont mis en évidence.

4. Google PageSpeed Insights

PageSpeed Insights est la version en ligne de Lighthouse. Elle a moins de fonctionnalités mais peut être utilisée dans n’importe quel navigateur et fournit d’autres aperçus.

Par exemple, un treemap montre les ressources JavaScript les plus importants avec une mesure de couverture, qui indique quelle proportion de code est utilisée et non utilisée :

Treemap de Google PageSpeed Insights.
Treemap de Google PageSpeed Insights.

Les CSS ne sont pas affichés, mais la quantité de JavaScript aura une incidence sur l’efficacité des styles.

Parmi les outils similaires de test de la vitesse des sites web figurent Pingdom Website Speed Test et GTmetrix.

5. Panneau DevTools Couverture de Chrome

Le panneau DevTools Couverture des navigateurs basés sur Chromium aide à localiser le code CSS (et JavaScript) inutilisé. Sélectionnez Couverture dans le sous-menu DevTools Plus d’outils, puis rafraîchissez votre page et parcourez votre site/application :

Panneau DevTools Couverture.
Panneau DevTools Couverture.

Les ressources CSS et JavaScript sont affichées dans le panneau Couverture , avec la proportion de code inutilisé en rouge. Cliquez sur n’importe quel fichier pour afficher sa source, le code inutilisé étant mis en évidence en rouge dans la gouttière du numéro de ligne.

Quelques éléments à prendre en compte :

  • Les mesures de couverture se réinitialisent si vous actualisez ou naviguez vers une nouvelle page, ce qui est typique d’un site WordPress. La mesure du code inutilisé ne diminuera que si vous naviguez sur une application mono-page qui charge le contenu sans rafraîchissement de la page.
  • L’outil ne peut rendre compte que du CSS utilisé jusqu’à un moment donné. Il ne peut pas déterminer si un widget n’a pas été consulté ou s’il a plusieurs états liés à JavaScript.

6. Moniteur de performance en temps réel de Chrome DevTools

Les navigateurs basés sur Chromium disposent d’un moniteur de performance en temps réel. Là encore, il est disponible dans le menu DevTools Plus d’outils. Les graphiques se mettent à jour lorsque vous naviguez dans les pages, que vous faîtes défiler les pages et que vous déclenchez des animations :

Moniteur de performance en temps réel de Chrome DevTools
Moniteur de performance en temps réel de Chrome DevTools

Les mesures suivantes sont particulièrement intéressantes pour optimiser les performances de CSS (plus elles sont faibles, mieux c’est) :

  • Utilisation du processeur : Utilisation du processeur de 0% à 100%.
  • Mises en page/sec : La vitesse à laquelle le navigateur doit remettre la page en page.
  • Recalculs de style/sec : La vitesse à laquelle le navigateur doit recalculer les styles.

Les autres mesures peuvent aussi être utiles si CSS a des difficultés en raison de facteurs externes (là encore, des valeurs plus faibles indiquent de meilleures performances) :

  • Taille du tas JS : La mémoire totale utilisée par les objets JavaScript.
  • Nœuds DOM : Le nombre d’éléments dans le document HTML.
  • Écouteurs d’événements JS : Le nombre d’auditeurs d’événements JavaScript enregistrés.
  • Documents : Le nombre de ressources, y compris la page, les fichiers CSS, les modules JavaScript, etc.
  • Cadres du document : Le nombre de frames, d’iframes et de scripts de travail JavaScript.

7. Rapport de performance DevTools

Le panneau Performance de DevTools vous permet d’enregistrer les activités de la page pour une analyse plus approfondie et pour vous aider à identifier les problèmes de performance. Les rapports générés sont complexes, et de nombreux développeurs les évitent, mais ils fournissent des informations précieuses.

L’icône des réglages du panneau Performance vous permet de définir diverses options, comme le ralentissement du réseau et du processeur. Vous pouvez aussi désactiver les échantillons JavaScript pour que les piles d’appels détaillées ne soient pas enregistrées.

Pour commencer, cliquez sur l’icône circulaire Enregistrer, chargez et/ou utilisez votre page, puis cliquez sur le bouton Arrêter pour afficher le rapport :

Rapport de performance DevTools.
Rapport de performance DevTools.

Presque toutes ces mesures seront utiles aux développeurs JavaScript, mais les problèmes d’optimisation CSS peuvent être particulièrement évidents à partir de :

  • Barre rouge supérieure : Cela indique que le taux de frame a considérablement baissé, ce qui peut causer des problèmes de performance. Cela est normal au début du chargement d’une page, mais des animations CSS excessives peuvent aussi être un problème.
  • Tableau récapitulatif : Des mesures élevées de chargement, de rendu et de peinture peuvent indiquer des problèmes de CSS.

Corrections indirectes des performances CSS

Les corrections suivantes ne résoudront pas directement les problèmes CSS, mais elles peuvent vous aider à résoudre certains problèmes de performance avec relativement peu d’efforts.

Utilisez un bon hébergeur

L’utilisation d’un bon hébergeur avec des serveurs physiquement plus proches de vos utilisateurs apportera des avantages immédiats en termes de performances. Les plans d’hébergement varient, mais il existe trois types principaux :

  1. Hébergement partagé : Votre site web est hébergé sur un serveur physique, peut-être aux côtés de centaines d’autres sites. L’espace disque, la RAM, le temps CPU et la bande passante sont partagés. Les plans sont souvent bon marché, mais les performances et la disponibilité sont affectées par les autres sites. Une mise à niveau est possible, mais votre site restera généralement sur la même infrastructure.
  2. Hébergement dédié : Votre site est hébergé sur un ou plusieurs serveurs physiques qui  vous appartiennent. Le matériel peut être configuré et mis à niveau en fonction des besoins. Les plans sont souvent chers, et les pannes de matériel restent problématiques.
  3. Hébergement cloud : L’hébergement cloud abstrait l’infrastructure matérielle en un ensemble de services auxquels on peut accéder à la demande. Votre site pourrait être provisionné sur toute une gamme d’appareils pour faciliter les mises à niveau.

Les plans d’hébergement cloud et les prix varient énormément. Vous pouvez envisager :

  1. Options de plateforme en tant que service (PaaS), comme les serveurs web et les bases de données virtuelles, ou
  2. Les options Software as a Service (SaaS), qui offrent des applications entièrement infogérées comme WordPress.

Changer d’hébergeur peut améliorer les performances. Il est peu probable que cela résolve tous vos problèmes, mais c’est une solution rentable aux problèmes de backend et de bande passante.

Vous pouvez aussi envisager d’utiliser un réseau de diffusion de contenu (CDN) ou un CDN spécialisé dans les images et les vidéos qui peut répartir la charge sur plusieurs sites géographiquement plus proches des utilisateurs.

Exploitez les fonctions d’efficacité des navigateurs et des serveurs

Environ 10 % des sites n’activent pas la compression gzip (ou mieux), qui est généralement l’option par défaut du serveur. Cela réduit la taille des CSS de 60 % ou plus en compressant les fichiers avant leur transmission. Cela ne réparera pas les CSS inefficaces, mais le code arrivera plus vite !

Vous devriez aussi activer HTTP/2 (ou mieux), qui envoie les données dans un format binaire plus petit, compresse les en-têtes et peut envoyer plus d’un fichier sur la même connexion TCP.

Enfin, assurez-vous que le navigateur peut mettre en cache les CSS et autres fichiers de manière efficace. Il s’agit généralement de définir les Expires, Last-Modified et/ou ETag hashes dans l’en-tête HTTP.

Optimisez votre CMS

Les systèmes de gestion de contenu tels que WordPress peuvent être étendus avec des thèmes et des extensions qui servent leurs propres CSS. Dans la mesure du possible, vous devriez accélérer votre CMS pour :

  1. Supprimer les extensions inutilisées.
  2. Utiliser des thèmes plus légers
  3. Activer la mise en cache pour éviter la régénération excessive des pages.

Optimisez vos images

Les images n’ont pas la même surcharge de traitement et de rendu que le HTML, le CSS et le JavaScript, mais elles représentent une grande partie du poids des pages et de la bande passante utilisable. Prennez en compte :

  1. Supprimer les images inutiles.
  2. Redimensionner les grandes images – peut-être à 150% maximum de la taille maximale qu’elles peuvent afficher à l’écran.
  3. Utiliser un format d’image approprié – idéalement une option hautement compressée comme WebP ou AVIF, mais éventuellement SVG pour les logos et les graphiques.
  4. Remplacer les images par des dégradés CSS ou d’autres effets.
  5. Ajouter des attributs de largeur et de hauteur aux balises HTML <img> ou utiliser la nouvelle propriété CSS aspect-ratio pour s’assurer qu’un espace approprié est réservé sur la page avant le téléchargement de l’image.

Un CDN spécialisé dans les images peut gérer une partie de ce travail pour vous. Pour plus de conseils, consultez notre guide sur la façon d’optimiser les images pour le web.

Supprimez les CSS inutilisés

Les styles les plus rapides sont ceux que vous n’avez jamais besoin de charger ou de rendre ! Essayez de supprimer/modifier tout code CSS dont vous n’avez plus besoin, comme celui des anciennes pages, des widgets ou des frameworks. Cela peut être difficile sur des sites plus grands, et il n’est pas toujours évident de savoir si un ensemble de styles particulier est essentiel ou non.

Les outils suivants analysent l’utilisation de HTML et CSS au moment de la construction ou en parcourant les URL pour identifier le code redondant. Cela n’est pas toujours suffisant, c’est pourquoi des configurations supplémentaires peuvent être définies pour s’assurer que les styles déclenchés par JavaScript et les interactions des utilisateurs sont autorisés à être listés :

Il existe une meilleure option : Divisez le CSS en fichiers séparés avec des niveaux de responsabilité clairs et documentez en conséquence. La suppression des styles inutiles devient alors considérablement plus facile.

Optimiser les performances de chargement du CSS

Les CSS ne sont pas tous chargés de la même façon. L’humble balise <link> possède un certain nombre d’options et de bizarreries qui ne sont pas toujours logiques.

Optimisez l’utilisation des polices web

Google Fonts et d’autres polices similaires ont révolutionné les polices web, mais quelques lignes de code de police peuvent entraîner des centaines de kilo-octets de bande passante.

Voici nos suggestions d’optimisation :

  1. Ne chargez que les polices dont vous avez besoin : Supprimez les polices que vous n’utilisez pas et vérifiez si de nouvelles polices sont nécessaires.
  2. Ne chargez que les poids et les styles dont vous avez besoin : La plupart des polices peuvent limiter le téléchargement à certains jeux de caractères (comme le latin uniquement), poids (épaisseurs) et italiques (inclinaisons). Les navigateurs peuvent rendre automatiquement les styles manquants, mais les résultats peuvent être médiocres.
  3. Limitez les caractères nécessaires : Les polices peu utilisées peuvent être limitées à des caractères spécifiques. Par exemple, le titre « Tutoriel CSS » en Open Sans peut être défini en ajoutant un paramètre &text= à la chaîne de requête de Google fonts : fonts.googleapis.com/css?family=Open+Sans&text=CStuorial
  4. Considérez les polices variables : Les polices variables définissent une grande variété de styles, de poids et d’italiques en utilisant l’interpolation vectorielle. Le fichier de police est un peu plus gros, mais vous n’en avez besoin que d’un seul au lieu de plusieurs. La police récursive démontre la flexibilité des polices variables.
  5. Chargez les polices à partir de votre serveur local : L’auto-hébergement des polices est plus efficace que l’utilisation d’une fonderie. Moins de consultations DNS sont nécessaires et vous pouvez limiter le téléchargement à WOFF2, que tous les navigateurs modernes prennent en charge. Les navigateurs plus anciens (je te regarde, IE) peuvent se rabattre sur une police OS.
  6. Considérez les polices OS : Cette police web de 500 Ko est peut-être superbe, mais quelqu’un le remarquerait-il si vous passiez aux polices courantes Helvetica, Arial, Georgia ou Verdana ? Les polices OS ou web-safe sont un moyen facile d’améliorer les performances.

Utilisez une option de chargement de police appropriée

Les polices web peuvent prendre quelques secondes à télécharger et à traiter. Le navigateur va soit :

  1. Montrer un flash de texte non stylisé (FOUT) : La première police de secours disponible est utilisée initialement mais est remplacée dès que la police web est prête.
  2. Afficher un flash de texte invisible (FOIT) : Aucun texte n’est affiché jusqu’à ce que la police web soit prête. C’est le processus par défaut des navigateurs modernes, qui attendent généralement trois secondes avant de revenir à une police de secours.

Aucun des deux n’est idéal. La propriété CSS font-display et le paramètre Google Font & display = peuvent sélectionner une autre option :

  • auto : Le comportement par défaut du navigateur (généralement FOIT).
  • block : Effectivement FOIT. Le texte est invisible pendant trois secondes au maximum. Il n’y a pas de changement de police, mais le texte peut mettre du temps à apparaître.
  • swap : Effectivement FOUT. La première solution de repli est utilisée jusqu’à ce que la police web soit disponible. Le texte est immédiatement lisible, mais l’effet de changement de police peut être gênant. Font Style Matcher peut être utilisé pour définir un fallback de taille similaire.
  • fallback : Un compromis entre FOIT et FOUT. Le texte est invisible pendant une courte période (généralement 100 ms), puis la première solution de repli est utilisée jusqu’à ce que la police web soit disponible.
  • facultatif : Similaire à fallback, sauf qu’il n’y a pas de permutation de police. La police web ne sera utilisée que si elle est disponible pendant la période initiale. La première page affichera probablement une police de secours, les pages suivantes utilisant la police web téléchargée et mise en cache.

L’utilisation de swap, fallback ou optional peut offrir un gain de performance perçu.

Évitez @import CSS

L’at-rule @import permet aux fichiers CSS d’être inclus dans d’autres :

/* main.css */
@import url("reset.css") ;
@import url("grid.css") ;
@import url("widget.css") ;

Cela semble être un moyen efficace de charger des composants et des polices plus petits. Malheureusement, chaque @import bloque le rendu, et chaque fichier doit être chargé et analysé en série.

Les multiples balises <link> au sein du HTML sont plus efficaces et chargent les fichiers CSS en parallèle :

<link rel="stylesheet" href="reset.css">
<link rel="stylesheet" href="grid.css">
<link rel="stylesheet" href="widget.css">

Cela dit, il est préférable de…

Concaténer et minimiser les CSS

Les outils de construction modernes, les préprocesseurs CSS tels que Sass et les extensions WordPress peuvent combiner tous les partiels en un seul grand fichier CSS. Les espaces blancs, commentaires et caractères inutiles sont ensuite supprimés pour réduire la taille du fichier au minimum.

Les fichiers multiples sont moins un problème de performance avec HTTP/2 et plus, mais un fichier unique ne nécessite qu’un seul en-tête et peut être gzippé et mis en cache plus efficacement.

Les fichiers CSS séparés ne sont pratiques que si vous avez une ou plusieurs feuilles de style qui sont modifiées fréquemment – peut-être plusieurs fois par semaine. Même dans ce cas, le code CSS principalement statique peut être combiné dans un seul fichier.

Les clients de Kinsta peuvent accéder à la fonction de modification du code dans leur tableau de bord MyKinsta pour les y aider. Cette fonction permet aux clients d’activer la minification automatique de CSS et JavaScript d’un simple clic. Cela permet d’accélérer un site sans aucun effort manuel.

Évitez l’encodage en base64

Les outils peuvent encoder les images en chaînes base64, que vous pouvez utiliser comme URI de données dans les balises HTML <img> et les arrière-plans CSS :

.background {
  background-image : url('data:image/jpg;base64,ABC123...') ;
}

Cela réduit le nombre de requêtes HTTP, mais cela nuit aux performances de CSS :

  • les chaînes base64 peuvent être 30 % plus grandes que leur équivalent binaire.
  • les navigateurs doivent décoder la chaîne avant qu’une image puisse être utilisée, et
  • la modification d’un pixel d’image invalide l’ensemble du fichier CSS.

N’envisagez l’encodage base64 que si vous utilisez de très petites images qui changent peu souvent et pour lesquelles la chaîne résultante n’est pas beaucoup plus longue qu’une URL.

Cela dit, vous pouvez encoder en UTF8 les icônes SVG réutilisables, par exemple.

.svgbackground {
  background-image : url('data:image/svg+xml;utf8,') ;
}

Supprimez les hacks CSS et les Fallbacks d’IE

À moins que vous n’ayez la malchance d’avoir une forte proportion d’utilisateurs d’Internet Explorer, les feuilles de style conditionnelles et les hacks d’IE peuvent être supprimés de votre CSS. Dans la plupart des cas, les utilisateurs d’IE verront quand même quelque chose, surtout si vous utilisez un design mobile-first qui affiche une vue linéaire plus simple par défaut. Le résultat ne sera peut-être pas joli, et il ne sera pas parfait au pixel près, mais votre budget de développement est mieux dépensé en tenant compte de l’accessibilité pour tous les utilisateurs.

Préchargez les fichiers CSS

La balise <link>fournit un attribut de préchargement facultatif qui peut démarrer un téléchargement immédiatement plutôt que d’attendre la référence réelle dans le HTML :

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>My page</title>
  <!-- preload styles -->
  <link rel="preload" href="/css/main.css" as="style" />
  <!-- lots more code -->
  <!-- load preloaded styles -->
  <link rel="stylesheet" href="/css/main.css" />

Cela est particulièrement bénéfique dans WordPress et d’autres CMS’ où une extension qui pourrait ajouter une feuille de style plus bas dans la page.

Utilisez le CSS en ligne critique

Les outils d’analyse peuvent vous suggérer « d’utiliser les CSS critiques en ligne » ou de « réduire les feuilles de style qui bloquent le rendu» Cela améliore les performances en :

  1. Identifiant les styles essentiels utilisés par les éléments au-dessus du pli (ceux qui sont visibles lorsque la page se charge)
  2. Insérant ce CSS essentiel dans une balise <style> dans votre <head>
  3. Chargeant le reste du CSS de manière asynchrone pour éviter le blocage du rendu. Pour cela, chargez la feuille de style dans un style « print » auquel le navigateur accorde une priorité moindre. JavaScript la fait ensuite passer à un style de média « all » une fois que la page est chargée (une <noscript> garantit que le CSS fonctionne si JavaScript n’est pas disponible) :
<style>
/* critical styles */
body { font-family: sans-serif; color: #111; }
</style>
<!-- load remaining styles -->
<link rel="stylesheet" 
     href="/css/main.css"
    media="print" 
   onload="this.media='all'">
<noscript>
  <link rel="stylesheet" href="/css/main.css">
</noscript>

Des outils tels que critical et criticalCSS peuvent aider à extraire les styles des éléments en vue.

Cette technique permet d’améliorer sensiblement les performances et d’augmenter les résultats des audits. Les sites ou les applications dotés d’interfaces cohérentes devraient être plus simples à mettre en œuvre, mais cela peut être plus difficile ailleurs :

  • Un outil de construction est essentiel pour tous les sites, sauf les plus simples.
  • Le « pli » est différent sur chaque appareil.
  • Les sites peuvent avoir une variété de mises en page nécessitant différentes CSS critiques.
  • Les outils CSS critiques peuvent avoir des difficultés avec des frameworks spécifiques, le HTML généré côté client et le contenu dynamique.
  • La technique profite surtout au chargement de la première page. Les feuilles de style CSS sont mises en cache pour les pages suivantes, de sorte que l’ajout de styles en ligne augmente le poids de la page.

Utilisez le rendu Media Query

Une seule concaténation et minification profitera à la plupart des sites, mais les sites qui nécessitent une quantité importante de styles pour grand écran pourraient diviser les fichiers CSS et les charger à l’aide d’une media query :

<!-- core styles loaded on all devices -->
<link rel="stylesheet" href="core.css">
<!-- served to screens at least 40em wide -->
<link rel="stylesheet" media="(min-width: 40em)" href="40em.css">
<!-- served to screens at least 80em wide -->
<link rel="stylesheet" media="(min-width: 80em)" href="80em.css">

Cet exemple suppose une méthodologie mobile-first. Les appareils mobiles chargent core.css mais n’ont peut-être pas besoin de télécharger ou d’analyser les autres feuilles de style.

Utilisez le rendu progressif

Le rendu progressif est une technique qui définit des feuilles de style individuelles pour des pages ou des composants distincts. Elle peut profiter à de très grands sites où les pages individuelles sont construites à partir d’un large éventail de composants.

Chaque fichier CSS est chargé immédiatement avant qu’un composant soit référencé dans le HTML :

<head>
  <!-- core styles -->
  <link rel="stylesheet" href="core.css" />
</head>
<body>
  <!-- header -->
  <link rel="stylesheet" href="header.css" />
  <header>...</header>
  <!-- primary content -->
  <link rel="stylesheet" href="main.css" />
  <main>
    <!-- widget styling -->
    <link rel="stylesheet" href="widget.css" />
    <div class="mywidget>...</div>
  </main>
  <!-- footer -->
  <link rel="stylesheet" href="footer.css" />
  <footer>...</footer>
</body>

Cela fonctionne bien dans la plupart des navigateurs. (Safari affiche une page blanche jusqu’à ce que tout le CSS soit chargé, mais cela ne devrait pas être sensiblement pire qu’une seule grande feuille de style)

L’adoption des composants web encourage également l’utilisation de styles scopés qui sont chargés lorsque l’élément personnalisé est rendu.

Optimiser les performances CSS

Les techniques et propriétés CSS exercent différentes pressions sur le navigateur, le processeur, la mémoire, la bande passante et d’autres ressources. Les conseils suivants peuvent vous aider à éviter les traitements inutiles et les performances léthargiques.

Adoptez des techniques de mise en page modernes (Grid et Flexbox)

Les mises en page basées sur « float » sont difficiles à créer, utilisent de nombreuses propriétés, nécessitent des ajustements continuels de la marge et de la marge intérieure, doivent être gérées à l’aide de media queries et entraînent un traitement considérable du navigateur. Elles ont été la seule méthode de mise en page viable pendant de nombreuses années, mais ne sont plus nécessaires. Utilisez l’une ou l’autre :

  • CSS Flexbox pour les mises en page unidimensionnelles qui pourraient s’enrouler sur la ligne suivante. C’est idéal pour les menus, les galeries d’images, les cartes, etc.
  • CSS Grid pour les mises en page bidimensionnelles avec des lignes et des colonnes explicites. C’est idéal pour les mises en page.

Les deux sont plus simples à développer, utilisent moins de code, offrent un rendu plus rapide et s’adaptent à toutes les tailles d’écran sans media queries.

Les très vieux navigateurs ne reconnaîtront pas les propriétés modernes de flexbox et de grille, donc chaque élément devient un bloc. Affichez-les dans une mise en page linéaire simple de type mobile : il n’est pas nécessaire d’émuler le design avec des fallbacks basés sur float.

Remplacez les images par des dégradés et des effets CSS

Dans la mesure du possible, optez pour le code CSS plutôt que pour les images. Expérimentez les dégradés, les bordures, les rayons, les ombres, les filtres, les modes de fusion, les masques, le détourage et les effets de pseudo-éléments pour réutiliser ou remplacer les images existantes.

Les effets CSS utilisent beaucoup moins de bande passante, sont plus faciles à modifier et peuvent généralement être animés.

Évitez de trop utiliser les propriétés coûteuses

Vous avez peut-être un code déclaratif laconique, mais certaines CSS nécessitent plus de traitement que d’autres. Les propriétés suivantes déclenchent des calculs de peinture qui peuvent être coûteux lorsqu’ils sont utilisés en excès :

  • position : fixed
  • border-radius
  • box-shadow
  • text-shadow
  • opacity
  • transform
  • filter
  • backdrop-filter
  • background-blend-mode

Utilisez les transitions et les animations CSS lorsque c’est possible

Les transitions et animations CSS seront toujours plus fluides que les effets alimentés par JavaScript, qui modifient des propriétés similaires. Elles ne seront pas traitées dans les très vieux navigateurs mais, comme ceux-ci sont susceptibles de fonctionner sur des appareils moins performants, c’est mieux ainsi.

Cependant, évitez les animations excessives. Les effets doivent améliorer l’expérience utilisateur sans nuire aux performances ou provoquer le mal de mer. Vérifiez la media query prefers-reduced-motion et désactivez les animations si nécessaire.

Évitez d’animer les propriétés qui déclenchent une remise en page

Modifier les dimensions d’un élément (largeur, hauteur, marge intérieure, bordure) ou sa position (haut, bas, gauche, droite, marge) peut entraîner une nouvelle mise en page de toute la page à chaque trame d’animation. Les propriétés les plus efficaces à animer sont :

  • opacity
  • filter: Flou, contraste, ombre et autres effets
  • transform: Pour traduire (déplacer), mettre à l’échelle ou faire pivoter un élément

Les navigateurs peuvent utiliser le GPU à accélération matérielle pour rendre ces effets dans leur propre couche, de sorte que seule l’étape de composition est affectée.

Si vous devez animer d’autres propriétés, vous pouvez améliorer les performances en retirant l’élément du flux de la page avec position : absolute.

Attention aux sélecteurs complexes

Les navigateurs analyseront rapidement les sélecteurs CSS les plus complexes, mais les simplifier réduit la taille des fichiers et améliore les performances. Les sélecteurs complexes sont souvent générés lorsque vous créez des structures profondément imbriquées dans des préprocesseurs CSS comme Sass.

Indiquez quels éléments vont changer

La propriété CSS will-change vous permet d’avertir de la façon dont un élément sera modifié ou animé afin que le navigateur puisse effectuer des optimisations à l’avance :

.myelement {
  will-change : transform, opacity ;
}

Il est possible de définir un nombre quelconque de valeurs séparées par des virgules, mais la propriété ne doit être utilisée qu’en dernier recours pour résoudre des problèmes de performance connus. vous ne devez pas l’appliquer à un trop grand nombre d’éléments et veillez à lui donner suffisamment de temps pour s’initialiser.

Considérez le confinement CSS

Le confinement (ou containment) est une nouvelle fonctionnalité CSS qui peut améliorer les performances en vous permettant d’identifier les sous-arbres isolés d’une page. Le navigateur peut optimiser le traitement en rendant – ou en ne rendant pas – un bloc de contenu DOM spécifique.

La propriété contain accepte une ou plusieurs des valeurs suivantes dans une liste séparée par des espaces :

  • none: Le confinement n’est pas appliqué
  • layout: La mise en page de l’élément est isolée du reste de la page – son contenu n’affectera pas les autres éléments
  • paint: Les enfants de l’élément ne sont pas affichés en dehors de sa limite
  • size: La taille de l’élément peut être déterminée sans vérifier les éléments enfants – les dimensions sont indépendantes du contenu

Deux valeurs spéciales sont également disponibles :

  • strict: Toutes les règles de confinement (sauf aucune) sont appliquées
  • content: Applique la mise en page et la peinture

Le confinement CSS est pris en charge par la plupart des navigateurs modernes. Il n’y a pas de prise en charge dans Safari ou les applications plus anciennes, mais le confinement peut être utilisé en toute sécurité dans celles-ci car le navigateur ignorera simplement la propriété.

Réagissez à l’en-tête Save-Data

Save-Data est un en-tête de requête HTTP indiquant que l’utilisateur a demandé des données réduites. Il peut être étiqueté mode « Lite » ou « Turbo » dans certains navigateurs.

Lorsqu’il est activé, un en-tête Save-Data est envoyé avec chaque requête du navigateur :

GET /main.css HTTP/1.0
Host : site.com
Save-Data : on

Le serveur peut répondre en conséquence lorsque Save-Data est détecté. Dans le cas de CSS, il peut envoyer une mise en page linéaire plus simple de type mobile, utiliser une police OS, passer à des couleurs de bloc ou charger des arrière-plans d’image à faible résolution.

Remarque : le serveur doit renvoyer l’en-tête suivant sur les requêtes modifiées pour s’assurer que le contenu minimal n’est pas mis en cache et réutilisé lorsque l’utilisateur désactive le mode Lite/Turbo :

Vary : Accept-Encoding, Save-Data

L’en-tête peut aussi être détecté par JavaScript côté client. Le code suivant ajoute une classe bestUX à l’élément <html>lorsque l’option Save-Data n’ est pas activée :

if ('connection' in navigator && !navigator.connection.saveData) {
  document.documentElement.classList.add('bestUX') ;
}

Les feuilles de style peuvent alors réagir en conséquence sans aucune manipulation du serveur :

/* no hero image by default */
header {
  background-color: #abc;
  background-image: none;
}
/* hero image when no Save-Data */
.bestUX header {
  background-image: url("hero.jpg");
}

La media query prefers-reduced-data offre une option CSS uniquement comme alternative, bien que cela ne soit pris en charge par aucun navigateur au moment de la rédaction :

/* no hero image by default */
header {
  background-color: #abc;
  background-image: none;
}
/* hero image when no Save-Data */
@media (prefers-reduced-data: no-preference) {
  header {
    background-image: url("hero.jpg");
  }
}

Résumé

Il existe de nombreuses options pour optimiser les performances CSS, mais pour les nouveaux projets, considérez les pratiques suivantes :

  1. Utilisez une approche mobile-first: Commencez par coder la mise en page mobile la plus simple, puis ajoutez des améliorations à mesure que l’espace de l’écran et les fonctionnalités du navigateur augmentent.
  2. Divisez le CSS en fichiers séparés avec des responsabilités identifiables : Un préprocesseur CSS ou une extension CMS peut combiner les partiels CSS en un seul fichier.
  3. Ajoutez une étape de construction : Il existe des outils qui peuvent automatiquement linter le code, identifier les problèmes, concaténer, minifier, réduire la taille des images, et plus encore. L’automatisation facilite la vie, et vous avez moins de chances d’oublier une étape d’optimisation.
  4. Documentez vos feuilles de style : Un guide de style avec des exemples documentés rendra votre code plus facile à prendre en main et à entretenir. Vous serez capable d’identifier et de supprimer les vieux CSS sans transpirer.

Enfin, apprennez le CSS ! Plus vous en saurez, moins vous devrez écrire de code et plus votre application web sera rapide. Cela fera de vous un meilleur développeur, quelles que soient les plateformes et les frameworks que vous utilisez.

Quels autres conseils avez-vous pour optimiser les performances de CSS ? Partagez-les dans la section des commentaires !

 

Craig Buckler

Freelance UK web developer, writer, and speaker. Has been around a long time and rants about standards and performance.