Comme nous l’évoquions déjà dans « Introduction à la performance web » et dans « Les performances web, pour aller plus loin », le travail d’optimisation des performances d’un site passe grandement par l’optimisation de l’affichage côté client.

Quelques grands axes permettent de contribuer fortement à cet effort de performance côté CSS.

Réduire le poids des feuilles de style

Le premier axe d’optimisation est de réduire tout d’abord le poids du fichier CSS. Les conseils que nous avions vus dans « Les principes de base de CSS » et dans « Introduction à la performance web » restent valables :

• toujours aller du plus général au plus spécifique ;
• éviter d’utiliser des styles inutiles (par exemple, mettre un display: block ne sert à rien sur un élément flottant) ;
• utiliser correctement l’héritage ;
• utiliser les notations compactes ;
• factoriser autant que possible les propriétés communes à plusieurs éléments ;
• évitez les unités inutiles, par exemple border: 0 n’a pas besoin d’unité.

En ressort final, quand votre CSS est suffisamment travaillée, pensez encore à la minifier, cela permet d’en réduire drastiquement le poids, car bien entendu, vous avez particulièrement bien commenté votre feuille de styles ? :)

N’oubliez jamais de bien activer la compression GZIP ou DEFLATE pour réduire encore le poids de vos feuilles de styles, même si c’est en théorie plus du ressort du serveur que de l’intégration proprement dite.

Autre point important : arrangez-vous pour que votre CSS soit envoyée et reçue le plus tôt possible. Il est capital de comprendre que votre chemin critique de rendu de page passe très souvent par CSS, parfois c’est même CSS qui est le chemin critique.

Cela revient à combiner autant que possible vos fichiers CSS en un unique fichier, ainsi vous économiserez facilement des requêtes. Idéalement servez-les depuis le même domaine que celui de la page, cela évitera une coûteuse requête DNS. Dans certains cas extrêmes de recherche de performance, il est même conseillé de mettre le CSS directement en embarqué dans la page (ou du moins la partie critique pour accélérer la sensation de vitesse d’affichage de la page), c’est dire à quel point cette partie est critique.

Réduire les requêtes

L’intégration CSS peut également permettre d’économiser des requêtes HTTP, soit en réduisant leur nombre, soit en les supprimant.

Les sprites CSS

Les sprites CSS permettent de regrouper plusieurs images en une seule. Nous avions ici même publié un article expliquant l’idée de la technique : Les sprites CSS.

En général, cette technique est à réserver aux images de même nature et/ou de même fonction (pour d’évidentes raisons de maintenabilité).

Divers outils facilitent leur création et leur maintenance, typiquement les pré-processeurs comme Sass ont des fonctions qui permettent de les générer automatiquement. Cela peut être très pratique si le site doit utiliser de très nombreux sprites.

Encore une fois, une factorisation efficace peut permettre de grandement réduire le poids de la CSS. Par exemple, imaginons que vous ayez 64 images de 16 par 16 pixels qui sont combinées en un sprite CSS, au lieu d’avoir 64 fois ce genre de code :

.icon-16-pdf,
.icon-16-doc,
.icon-16-wav,
/* etc. */
.icon-16-zip {
  display: inline-block;
  width: 16px;
  height: 16px;
  // etc.
}

Il est possible d’effectuer une factorisation bien plus efficace et légère grâce à certains sélecteurs, par exemple :

[class*=icon-16] {
  display: inline-block;
  width: 16px;
  height: 16px;
  // etc.
}

vous permettra d’économiser un grand nombre de déclarations dispensables, ce sélecteur ciblera automatiquement toutes les classes dont l’attribut class contient icon-16.

Au repeat view

Bien entendu, une mise en cache appropriée des éléments statiques (CSS, images, JavaScript étant les principaux) permet d’optimiser les performances d’une intégration lors d’une seconde consultation. Toutefois, ces bonnes pratiques sont plus du ressort de la gestion du cache, et donc une problématique de serveur.

Nous avions écrit sur le sujet lors de précédents articles, donc nous ne reviendrons pas dessus, vous pouvez relire « Les performances web, pour aller plus loin ».

Embarquer du contenu dans la CSS

L’autre solution pour améliorer les performances est de limiter les requêtes HTTP. En effet, une requête HTTP peut avoir un coût bien supérieur en performances que du contenu directement embarqué dans une feuille de style, surtout en situation de mobilité où la latence ou tout simplement une mauvaise connectivité peuvent fortement ralentir le téléchargement d’une ressource.

Nous avions déjà évoqué la possibilité des Data-URI dans « Les performances web, pour aller plus loin ». C’est particulièrement bien adapté pour les images de petite taille. En général, le code produit est un petit peu plus lourd que l’image originale sous forme de fichier, mais l’économie d’une requête HTTP reste préférable en général.

Il est également possible d’embarquer d’autres types de contenus directement dans les feuilles de styles, des web fonts ou du SVG par exemple. Là c’est vraiment selon le cas d’utilisation que la décision se prendra. Par exemple, une web font embarquée dans la CSS va alourdir de manière conséquente cette dernière. Une question à sous-peser en somme ! :)

Autres astuces

Accélération matérielle

L’affichage et le calcul de propriétés CSS est en général très peu consommateur de ressources côté processeur, toutefois, le calcul d’animations ou de transitions CSS peut être plus compliqué pour certains périphériques peu puissants, et des saccades et autres ralentissements peuvent survenir. Toutefois, il est possible de déléguer certains de ces calculs à des processeurs graphiques qui eux sont spécialisés dans ce genre de calculs. On appelle cela « l’accélération matérielle », et cela peut se déclencher en utilisant certaines propriétés comme :

transform: translateZ(0);
/* avec tous les préfixes nécessaires ! */

Le gain en fluidité sera parfois visible immédiatement. D’autres avantages sont également possibles, comme le lissage des polices, l’accélération des filtres CSS, etc.

Pour en savoir plus sur ce sujet, vous pouvez lire l’article suivant : L’accélération matérielle au service de vos animations CSS.

Pur CSS ?

Parfois, les solutions les plus simples sont les meilleures : si le design souhaité peut être créé intégralement avec CSS (ou quasi-majoritairement), n’hésitez pas une seconde et franchissez le pas ! Non seulement se passer d’images vous fera gagner de précieuses requêtes, mais en plus les propriétés CSS ne « pèsent pas lourd » : quelques lignes de propriétés CSS seront toujours plus rapides et plus souples à l’utilisation que des images, aussi bien conçues soient-elles.

De là à dire que c’est une raison de plus de faire intervenir le développeur front-end très tôt dans les processus de création des sites, il n’y a qu’un pas… que je franchis allègrement ! C’est une économie substantielle en temps d’export des images pour le graphiste et une immense souplesse offerte au développeur front-end (particulièrement sur les sites en responsive), dont il serait bien dommage de se priver.

Autre point : l’approche d’intégration choisie par le développeur front-end peut également influer sur les performances : typiquement, si ce dernier choisit une intégration mobile-first, le rendu sera sûrement plus rapide sur les petits écrans, et le surplus de styles pour les écrans plus larges sera absorbé par les navigateurs plus puissants des ordinateurs dits « classiques ».

Quid des sélecteurs efficaces ?

Nous le mentionnions ici nous aussi dans « Introduction à la performance web » : avoir des sélecteurs courts et qualifiants est également une source d’optimisation. De nombreux articles comme « Writing efficient selectors » nous indiquaient de faire très attention à nos sélecteurs.

Premier rappel : un sélecteur efficace peut se définir comme un sélecteur évitant au moteur du navigateur trop d’analyse pour appliquer les styles.

Exemple : #header ul li a.header-link est un sélecteur trop long : cela ne sert à rien de sur-spécifier les styles là où .header-link suffirait à cibler les liens en question. Ajoutons à cela que la surcharge dans une media-query sera d’autant plus courte selon le sélecteur à surcharger.

Second rappel : un sélecteur qualifiant est quand à lui un sélecteur qui permet au navigateur de cibler très efficacement les éléments auxquels s’appliquent les styles. Cette « erreur » est souvent commise par simple ignorance de la manière dont les navigateurs évaluent les styles.

Par exemple : .header a semble être un bon sélecteur : court et précis. Le développeur va se dire en l’écrivant : le navigateur va aller prendre tous les a dans .header. Or, cela ne se passe pas du tout comme cela pour le navigateur !

Ce dernier va évaluer cette règle CSS de droite à gauche, autrement dit, il va cibler tous les liens a de la page, et regarder ensuite ceux qui se situent dans .header. Si l’on imagine qu’il y ait beaucoup de liens dans la page, ce sélecteur devient donc peu qualifiant : le navigateur teste beaucoup d’éléments pour peu d’élus. Un ciblage direct par .header-link aurait évité des efforts au navigateur.

Pour prendre une analogie, c’est un peu comme faire un SELECT * dans une requête SQL : c’est à éviter, autant ne sélectionner que les champs dont on a besoin. Si vous n’êtes pas familier du back-end, voici une analogie humoristique : cela revient à prendre tous les produits d’un supermarché dans son caddie et à ne mettre sur le tapis de la caisse que ceux que vous voulez acheter. Pas très efficace ! :)

Toutefois, ces articles ont été écrits il y a plusieurs années, et ces propos sont à modérer : sur des navigateurs modernes et sur des machines décentes, l’efficience des sélecteurs serait à relativiser, comme l’indiquent plusieurs articles [1]. En quelque sorte, nous serions de l’ordre de la micro-optimisation. D’autres articles indiquent de quand même faire attention à certains sélecteurs trop peu efficaces et nous conseillent de les simplifier [2], comme le sélecteur universel. Bref, la question n’est pas totalement tranchée.

Qu’à cela ne tienne, je prends le parti d’affirmer qu’avoir des sélecteurs efficaces et qualifiants fait également partie du travail qualitatif qui doit être fait sur CSS, et ce pour plusieurs raisons :

• ce travail est induit par d’autres facteurs comme le fait que la CSS ne doit pas trop être liée à la structure HTML, que nous avons abordé dans l’article « Les principes de base en CSS » ;
• les sélecteurs efficaces sont plus facilement surchargeables, les CSS de sites en responsive n’en seront que plus légères ;
• des sélecteurs précis auront moins de risques d’être trop larges ou trop précis : les effets de bord sur des CSS très complexes seront limités ;
• même si c’est de l’ordre de la micro-optimisation pour les navigateurs modernes, pourquoi s’en priver ? Déjà les navigateurs plus anciens ou sur des périphériques plus modestes apprécieront, et cela ne coûte rien de plus de le faire.

Conclusion

Assurément, cette question des performances n’est pas triviale. Comme le précisaient déjà les articles d’OpenWeb sur la performance Web, ce sont surtout de bonnes pratiques et de bonnes habitudes à prendre très tôt et tout au long de la conception des sites Web.

Le développeur front-end est particulièrement sollicité sur cette problématique, et même si l’optimisation de ce dernier déborde souvent de son propre cadre en sollicitant le back-end, il a assurément une place de choix dans le travail sur les performances Web quand il produit des CSS.

Références, compléments

• Introduction à la performance web
• Les performances web, pour aller plus loin
• Les sprites CSS
• L’accélération matérielle au service de vos animations CSS
• Checklist Opquast performances Web : 41 bonnes pratiques Webperf
• Page Speed best practices: Optimize browser rendering
• Efficiently rendering CSS
• CSS and the critical path
• Writing efficient CSS
• Performance impact of CSS Selectors
• Simplifying CSS selectors
• Front-end performance for web designers and front-end developers

Note

Cet article fait partie de la série « Grands principes de construction moderne de CSS ».