Auditer votre CSS

Auditer votre CSS vous aide à organiser votre code, à le rendre plus lisible, à éliminer les répétitions, mais aussi à améliorer les performances de votre site. Par Susan Robertson.

Par

La perspective de procéder à un audit de CSS ne soulève généralement pas l'enthousiasme, et pourtant c'est devenu un de mes genres de projets préférés. L'audit de CSS est un vrai travail de détective. Vous partez du code d'un site et vous commencez à creuser : combien de feuilles de styles, quel impact sur la performance, comment le CSS lui-même est-il écrit? Votre objectif est d'améliorer l'existant et d'inventer des solutions permettant d'améliorer le code et les performances du site.

Je vais partager avec vous quelques astuces pour mener votre propre audit, quelques outils, et les avantages de procéder à un inventaire complet de votre CSS.

Bénéfices d'un audit

Procéder à un audit vous aide à organiser votre code et à éliminer les répétitions. Vous n'écrivez pas de code pendant un audit, vous établissez un simple état des lieux et vous formulez des recommandations pour votre client ou en vue d'une discussion avec votre équipe. Ces recommandations garantissent que le nouveau code ne répètera pas les erreurs passées. Mais il y a d'autres avantages à procéder à un audit :

  • Réduire la taille des fichiers. Un passage en revue complet du CSS vous permet de refactoriser le code : de le nettoyer et peut-être de réduire le nombre de propriétés. Vous pouvez aussi faire la chasse à toutes les petites bricoles qui traînent ici et là, comme des versions dépassées de préfixes vendeurs. En se débarrassant du code inutile, on allège le poids du fichier que les utilisateurs chargeront en visitant le site.
  • Assurer la cohérence avec des directives. À mesure que vous avancez, créez un document relatifs à vos styles et à leur utilisation dans votre site ou application. Vous pouvez rédiger un guide de style formel ou simplement écrire quelques recommandations pour indiquer la façon dont fonctionnent certaines parties du code. Quelle que soit la forme que prendra cette documentation, elle fera gagner du temps à vos collaborateurs et leur épargnera quelques soucis en leur permettant de se familiariser avec le CSS et l'architecture du site.
  • Standardiser le code. L'organisation du code - qui est évidemment l'objet de débats - est essentielle pour assurer une bonne maintenance de votre code à l'avenir. Si par exemple vous choisissez de classer vos propriétés par ordre alphabétique, vous verrez apparaître immédiatement les doublons parce que tout d'un coup vous aurez deux valeurs différentes pour la même propriété margin... Ou bien vous préférerez regrouper les propriétés par fonction : positionnement, box-model, etc. Quel que soit le système que vous choisirez, il vous aidera à éviter les répétitions.
  • Améliorer les performances. J'ai gardé le meilleur pour la fin. L'audit de code, ajouté au regroupement des feuilles de styles et à leur compression, conduisent à une nette amélioration des performances du site. Harry Roberts, un développeur front-end anglais qui effectue souvent des audits m'a dit à propos d'un site sur lequel il avait travaillé dernièrement :

J'ai réorganisé Fasetto.com en vue d'améliorer ses performances. Pour un site en single-page on est passé de 27 feuilles de styles séparées (essentiellement des outils UI comme Bootstrap, etc.) à une seule feuille de styles, qui est minifiée et en ligne pour éviter une requête HTTP, et tout cela pèse 5,4kB après gzip.

C'est un gain énorme, très appréciable pour les personnes ayant des connections lentes - mais tout le monde y gagne lorsqu'un site se charge rapidement.

Comment auditer : faire l'inventaire

Maintenant que vous êtes convaincus de la nécessité des audits, comment procéder ? Personnellement j'aime commencer avec quelques outils qui me permettent de passer en revue le code actuel du site. Votre approche pourrait être différente, en fonction des problèmes spécifiques du site audité ou de votre façon de concevoir l'écriture du code (par exemple OOCSS ou BEM). Il faut simplement garder à l'esprit ce qui sera le plus utile pour vous et pour le site.

Un fois cette étape passée, j'examine le site ligne à ligne.

Les outils

Le premier outil que j'utilise est l'indispensable Type-o-matic de Nicole Sullivan, une extension de Firebug qui génère un rapport en format JSON de tous les styles de polices utilisés à travers le site. En bonus, Type-o-matic crée un rapport visuel à mesure qu'il avance dans son analyse. En regardant les deux rapports, vous savez d'un simple coup d'oeil quand simplifier les polices de caractères en éliminant celles qui sont trop similaires. Les détails du rapport JSON facilitent la création d'un système de polices plus facile à réutiliser.

En plus de Type-o-matic, j'utilise CSS Lint, un outil très flexible qui vous alerte sur toute une série de bugs potentiels, depuis des couleurs de rechange (fallback) manquantes jusqu'à l'utilisation de propriétés raccourcies, afin d'améliorer les performances. Pour utiliser CSS Lint, cliquez sur la flèche à côté du mot “Lint” et choisissez les options que vous voulez. Je choisis en général les propriétés dupliquées (repeated properties) et les tailles de polices trop nombreuses (too many font sizes), et ainsi j'audite la maintenabilité (Maintainability & Duplication) et la Performance. CSS Lint me renvoie ensuite des modifications recommandés. Certaines sont liées à des problèmes identifiés de compatibilité avec les navigateurs anciens, d'autres sont de l'ordre des bonnes pratiques (telles que l'outil les conçoit). CSS Lint n'est pas parfait. Si vous laissez toutes les option cochées, il y a des chances que vous trouviez dans le rapport final des choses avec lesquelles vous ne serez pas d'accord, par exemple des avertissements relatifs à IE6. Ceci mis à part, c'est une façon pratique de se faire rapidement une idée de l'état de notre CSS.

Ensuite, je passe en revue le CSS pour avoir une idée du nombre de fois qu'apparaissent les mêmes propriétés, comme float ou margin. Si la console n'est pas un rebutoir, tapez grep et quelques instructions, par exemple grep "float" styles/styles.scss pour trouver toutes les instances de "float". Notez les propriétés que vous pourriez supprimer, raccourcir ou regrouper dans un autre module. Réduire le nombre de propriétés est souvent une question d'équilibre : pour avoir moins de propriétés, il vous faudra peut-être ajouter des classes à votre HTML, donc c'est une affaire de jugement.

J'aime effectuer cette étape à la main, car cela m'oblige à lire le CSS, ce qui en retour me permet de mieux comprendre ce qui se passe. Mais si votre temps est limité, ou si vous n'êtes pas à l'aise avec la console, voici quelques outils qui peuvent vous rendre la vie plus facile :

  • CSS Dig est un script automatisé qui passe en revue tout votre code pour vous aider à le visualiser. StyleStats est un outil similaire dans lequel vous entrez une url pour analyser son CSS.
  • CSS Colorguard est un tout nouvel outil basé sur Node qui vous envoie un rapport sur les couleurs utilisées vous indiquant celles qui sont trop proches. Cela vous aide à limiter votre palette et à faciliter la maintenance.
  • Dust-Me Selectors est une extension de Firebug dans Firefox qui repère les sélecteurs inutilisés.

Ligne à ligne

Après avoir lancé l'analyse automatique, prenez un peu de temps pour lire le CSS. C'est important d'avoir une approche sensible de ce qui se passe. Par exemple, les commentaires présents dans le code - et que les outils ne comprennent pas - vous expliqueront peut-être certaines anomalies.

Un point que je vérifie toujours est la profondeur d'applicabilité  (1), autrement dit jusqu'où s'applique un attribut. Votre CSS fait-il appel à la spécifité ? Est-ce que vous voyez des sélecteurs formés de longues chaînes de caractères, soit dans la feuille de style, soit dans le code retourné par un préprocesseur ? Une grande profondeur d'applicabilité aura pour conséquence que votre code s'appuiera sur une structure HTML spécifique pour vos styles. En étant moins spécifique, vous aurez un code plus facilement réutilisable et un site plus rapide.

Révision et recommandation

Voici maintenant la partie la plus intéressante. Une fois que vous avez fait le point, vous pouvez réfléchir à la façon d'améliorer le CSS et vous pouvez faire vos recommandations.

Le document de recommandations n'a pas besoin d'un design ni d'un format recherché, mais il devrait être facile à lire. Une bonne idée est de le présenter en deux parties : la première présente le travail de révision et ce que vous avez trouvé. Si vous vous référez aux résultats de CSS Lint ou de Type-o-matic, n'oubliez pas d'inclure quelques copies d'écran ou le rapport JSON lui-même en pièce jointe. La deuxième contient vos recommandations d'actions pour améliorer le code. Cela peut être aussi simple qu'une liste, avec des indications comme “Regrouper et simplifier les styles de polices de caractères proches et créer des mixins pour une utilisation sur l'ensemble du site”.

Lorsque vous analysez toutes les informations que vous avez réunies, cherchez tous les endroits où vous pouvez :

  • Resserrer le code. Est-ce que vous avez trouvé 4 différents styles pour une boîte, plusieurs styles de liens similaires, trop d'exceptions à votre grille standard ? Ce sont des candidats idéals aux styles modulaires répétables. Pour faciliter la consolidation, vous pouvez utiliser un préprocesseur comme Sass pour en faire des mixins ou des extend, ( NdT : voir à ce sujet Tout sur @extend et Mixin ou Placeholder?) qui vous permettent d'appliquer des styles en les appelant au moyen d'une classe.
  • Conserver la cohérence du code. Un bon audit s'assure que le code reste fidèle à sa propre philosophie. Si votre CSS est écrit selon une approche particulière, par exemple BEM ou OOCSS, est-il cohérent ? Ou bien les styles dévient-ils de temps à autres dans une mesure acceptable ? Assurez-vous que ces déviations sont clairement indiquées dans votre document, afin d'attirer l'attention de votre équipe sur elles.

Si vous travaillez avec un client, il est également important de lui expliquer les approches que vous préconisez, de lui faire comprendre vos raisons et ce que vous considérez problématique dans le code. Par exemple je préfère OOCSS, donc j'ai tendance à pousser vers plus de modularité et de réutilisabilité. Quelques classes de plus (si vous n'utilisez pas de préprocesseur) ne me gênent pas. Il est crucial de vous assurer que le client comprend le contexte de votre travail lorsque vous ne faites pas partie de l'équipe responsable de l'implémentation.

Remettre le document au client

Vous l'avez fait ! Maintenant que vous avez écrit vos recommandations et que vous avez pris un peu de temps pour les réexaminer et vérifier qu'elles sont bien solides, vous pouvez les remettre à votre client. Soyez prêt à répondre à toutes les questions. Si c'est un document pour votre équipe, félicitations, sortez le champagne !

Mais attendez - un audit vous apporte d'autres récompenses. Maintenant que vous avez cette documentation, passez à l'étape suivante : elle peut désormais vous servir à parler de la façon de maintenir le CSS à l'avenir. Si les mêmes problèmes se reproduisaient dans le code, mettez par écrit la façon dont vous les avez résolus, de sorte que chacun sache comment faire lorsque de nouvelles fonctionnalités ou de nouvelles sections seront créées. Vous pourriez même transformer ce document en guide de style. Autre chose à prendre en considération, la fréquence des révisions futures, pour vous assurer que le code reste propre. Cette fréquence peut varier selon les équipes et les projets, mais déterminez un planning réaliste et régulier, c'est une part essentielle du processus de révision.

Mener un audit est une première étape vitale pour maintenir votre CSS épuré et concis. Cela vous aide également à garder à jour votre documentation, ce qui donne à votre équipe des bases solides pour le développement de nouvelles fonctionnalités. Quand votre code est bien structuré, il est plus performant, au bénéfice de tous. Alors, trouvez un peu de temps, mettez votre chapeau de Sherlock Holmes, et au boulot !


Ressources Supplémentaires.

Voici quelques ressources qui vous permettront de maintenir votre architecture CSS.

Organiser votre CSS

  • Harry Roberts a écrit CSS Guidelines, un formidable document de recommandations pour vous aider à mieux penser la façon d'écrire de larges systèmes CSS.
  • Si vous voulez savoir comment intégrer plus facilement un guide de style dans votre audit, ce repo Github liste toute une série d'informations sur divers générateurs.

Un coup de main des task runners

Vous aimez les exécuteurs de tâches comme Grunt ou Gulp ? Le tutoriel d'Addy Osmani passe en revue plusieurs task runners qui vous aideront à trouver des sélecteurs CSS inutilisés : Spring Cleaning Unused CSS Selectors (un nettoyage de printemps pour vos sélecteurs CSS).

Accessibilité

Vous êtes intéressé par un audit de votre accessibilité ? (j'espère que oui !) Il existe des outils à cet effet. Cet article vous aidera à auditer l'accessibilité de votre site, c'est un bon exposé de tout ce qu'il convient de faire.

Performance

  • Sitepoint s'est intéressé à la cure d'amaigrissement de votre site, ce qui devrait optimiser ses performances.
  • Le dev tool de Google Chrome comporte un outil d'audit qui vous suggère quelques façons d'améliorer la performance de votre site. Un excellent article de HTML5 Rocks passe en revue cet outil en profondeur.

Grâce à ces outils, vous aurez ce qu'il vous faut pour nettoyer votre CSS, optimiser votre site, et améliorer l'expérience utilisateur. Lorsqu'on parle d'audit de code, beaucoup de gens se concentrent sur la performance, qui est évidemment essentielle, mais n'oubliez pas que la maintenabilité et l'amélioration de la productivité des développeurs vont également de pair avec un site plus rapide.


NdT:

(1) Susan Robertson se réfère au livre de Jonathan Snook, Scalable and Modular Architecture for CSS (SMACSS), dont je traduis ci-dessous un extrait synthétisé pour illustrer la notion de profondeur d'applicabilité :

Prenons un bloc de CSS typique :

//CSS
#sidebar div {
    border: 1px solid #333;
}

#sidebar div h3 { 
    margin-top: 5px;
}

#sidebar div ul {
    margin-bottom: 5px; 
} 

En regardant ce code, vous imaginez facilement ce à quoi ressemblera le HTML : certainement une ou plusieurs sections dans un encadré (sidebar) comportant un titre et une liste non ordonnée à la suite. Pour un site simple, pas de problème, mais si votre site est plus complexe et évolue souvent, vous allez au devant de problèmes. Il vous faudra ajouter de nouvelles règles, avec des sélecteurs de plus en plus complexes et la maintenance peut virer au cauchemar.

Où est l'erreur ?

  1. Je m'appuie trop sur la structure HTML
  2. La profondeur du HTML à laquelle le sélecteur s'applique est trop grande.

HTML est une structure en arbre, comprenant des parents et des enfants. La profondeur d'applicabilité est le nombre de générations affectées par une règle donnée. Par exemple body.article > #main > #content > #intro > p > b a une profondeur d'applicabilité de 6 générations. Si le sélecteur était .article #intro b la profondeur resterait la même : 6 générations.

Revenons à notre exemple de sidebar, si nous voulons recréer ce module ailleurs, par exemple dans un footer, nous devons dupliquer les règles. Le noeud qui se trouve à la racine de ces règles est div, c'est de là que nous devons créer notre style :

//CSS
.pod {
    border: 1px solid #333;
}

.pod > h3 { 
    margin-top: 5px;
}

.pod > ul {
    margin-bottom: 5px; 
} 

La contrepartie est que nous devons répéter cette classe à chaque fois dans notre HTML, mais la profondeur est moins importante, le code est plus lisible, la maintenance est plus facile, les performances sont meilleures.
(Jonathan Snook, Scalable and Modular Architecture for CSS)    ↩︎


original paru le dans A List Apart.

Sur l'auteur : est tombée amoureuse du code en 2005 et a écrit avec bonheur en HTML et en CSS depuis lors. À l'aise avec des équipes de toutes tailles, elle aime travailler avec des designers et des développeurs qui codent des applications ambitieuses, belles et accessibles. Elle a récemment travaillé avec l'équipe d'Editorially et est actuellement freelance. On peut la suivre sur Twitter et sur son site.

Traduit avec la permission de A List Apart et de l'auteur.