Unused CSS et outils pour supprimer feuilles de style inutilisées

Nouveau WRInaute
Bonjour à tous !
J'aurais aimé avoir vos avis sur les outils qui permettent de compresser ou de supprimer les CSS inutilisés d'un site pour améliorer son référencement.
Avez-vous déjà utilisé Unused CSS, Purify CSS, ou d'autres solutions comme les plug-ins pour Wordpress et quel outil préférez vous ? Sinon avez vous trouvé une alternative ?
Merci d'avance !
 
WRInaute accro
Améliorer la vitesse de chargement améliore toujours le référencement. Quand tu vois ce que certains thèmes peuvent arriver à charger....
 
WRInaute passionné
Il faut être sûr de ne pas avoir des classes dans du code, par exemple :

?>
<div class="<?= if ($a) echo 'a'; ?>">
<?php

sinon ces outils ne verront pas que la classe 'a' est utilisée et la supprimeront.
 
WRInaute discret
Le truc qu'il faudrait faire pour détecter des CSS inutilisés ce serait de faire quelque chose dans ce genre là :

Exemple de CSS:
.style1 { ... }
.style2 { ... }
.style3 { ... }

Exemple de la page index.html:
<span class="style1"></span>

Exemple de la page2.html:
<span class="style3"></span>

Il faudrait parcourir toutes les pages du site, et si style1 est trouvé alors il indique quelque part que c'est ok et il le met de côté !
Si style3 est trouvé, il indique que c'est "ok" et il le met de côté.
Et ensuite si style2 n'est pas trouvé, il reste toujours inactif dans le fichier css.
Et du coup il faut prendre tous les CSS qui sont de côtés et créer un nouveau fichier css ou remplacer l'ancien par le nouveau avec tous ceux qui sont ok

Mais je ne connais aucun script opensource qui fait ça, c'est assez relou de s'en faire un soi-même.


Une autre solution encore plus pro ce serait de faire un robot à la NodeJS et ce robot on lui donne un fichier css et il récupére tous les noms avant "{" et ils sont stockés quelque part.
Ensuite ce bot il crawl toutes les pages d'un site et il récupérè la totalité des noms stockés pour les comparer avec ceux qui sont dans chaque et chaque fois qu'un nom de class est introuvable il l'indique quelque part et c'est ensuite à nous de faire le ménage sur le site en recherchant la class inutilisée pour l'enlever
 
WRInaute impliqué
Sinon avez vous trouvé une alternative ?

Les outils de dev de Chromium / Chrome permettent d'enregistrer la couverture du CSS, ce qui donne un aperçu intéressant de ce qui est utilisé ou non.

Par contre, et pour rejoindre ce que disais @rick38, il faut tout de même se méfier du style qui n'est employé que dans une fenêtre modale qui n'est utilisée que sur une page obscure aux tréfonds du site, parce qu'on peut un peu trop vite exclure un style qui a pourtant son utilité.

Et du coup il faut prendre tous les CSS qui sont de côtés et créer un nouveau fichier css ou remplacer l'ancien par le nouveau avec tous ceux qui sont ok

Dans le prolongement de l'outil de Chromium / Chrome, on peut faire un export JSON de ce qui est utilisé et le transformer en un CSS avec https://nachovz.github.io/devtools-coverage-css-generator/

Je l'utilise parfois lorsque le CSS est trop lourd pour en extraire ce qui est juste appelé sur la landing page et intégrer ce CSS "essentiel" dans le <head> : ainsi les styles nécessaires à l'affichage de la landing page se chargent immédiatement, et le temps que l'utilisateur fasse les premières actions les fichiers CSS avec l'ensemble des règles pour tout le site aura pu être téléchargé et mis en cache.

compresser le CSS améliore le référencement ?

La vitesse de chargement d'un site et l'immédiateté de son affichage font partie des critères retenus par Google au titre des "core web vitals". Comme toujours, assez peu d'information de la firme sur l'influence réelle de ces critères sur le classement ; il est annoncé qu'il s'agit de critères secondaires.

Il y a probablement deux écueils : négliger la performance d'un site et s'y consacrer exclusivement. Un site performant ne sera jamais bien référencé si son contenu est mauvais.

S'agissant des CSS, ce sont des fichiers qui bénéficient très largement de la compression lorsqu'elle est activée sur le serveur ; par exemple un fichier CSS (non minifié) de 1,5 Mo pourra n'en faire plus que 127 ko une fois compressé. Certains considèrent que la minifaction n'apporte finalement qu'un gain presque négligeable ; le fichier CSS en exemple fait 1,4 Mo minifié et 121 ko minifié et zippé (gain de 6 % sur la minifaction contre 91 % sur la compression).

Surtout, on arrive dans une échelle où le temps de chargement est presque autant dû à l'accès au fichier qu'au transfert du fichier à proprement parler. Avec les multiplication des plugins on a tôt fait de se retrouver avec une multiplicité de fichiers CSS de petite taille, les regrouper dans un seul fichier peut être une solution pertinente.
 
WRInaute accro
Avec les multiplication des plugins on a tôt fait de se retrouver avec une multiplicité de fichiers CSS de petite taille, les regrouper dans un seul fichier peut être une solution pertinente.

Oui c'est surtout cela le problème. Beaucoup de plugins enregistrent leurs css et leurs js sans conditions pour tester s'il est nécessaire, c'est gonflant :)
 
WRInaute discret
Dans le prolongement de l'outil de Chromium / Chrome, on peut faire un export JSON de ce qui est utilisé et le transformer en un CSS avec https://nachovz.github.io/devtools-coverage-css-generator/

Je viens de regarder, je ne connaissais pas ce système de coverage sur Chrome, c'est trop bien !

Il faudrait le même sur Firefox car c'est celui-ci que j'utilise toujours.

Je viens de mettre un tout petit site à jour avec un seul fichier css simple contenant très peu de ligne, j'ai viré tous les css inactifs (eniron 15), faudra voir ce que ça donne sur Google pour voir s'il peut mieux classer le site :eek:
 
WRInaute impliqué
S'agissant des CSS, ce sont des fichiers qui bénéficient très largement de la compression lorsqu'elle est activée sur le serveur ; par exemple un fichier CSS (non minifié) de 1,5 Mo pourra n'en faire plus que 127 ko une fois compressé. Certains considèrent que la minifaction n'apporte finalement qu'un gain presque négligeable ; le fichier CSS en exemple fait 1,4 Mo minifié et 121 ko minifié et zippé (gain de 6 % sur la minifaction contre 91 % sur la compression).
Mieux que le Zip, il y a Brotli qui permet des gains d'environ 17% supplémentaires pour les CSS : https://caniuse.com/brotli
Il est aussi possible de précompresser les fichiers. On peut ainsi utiliser le taux de compression le plus élevé (et le plus lent, et c'est VRAIMENT trop lent pour être fait à la volée) en n'ayant que les avantages : https://css-tricks.com/brotli-static-compression/

Surtout, on arrive dans une échelle où le temps de chargement est presque autant dû à l'accès au fichier qu'au transfert du fichier à proprement parler. Avec les multiplication des plugins on a tôt fait de se retrouver avec une multiplicité de fichiers CSS de petite taille, les regrouper dans un seul fichier peut être une solution pertinente.
En général, non : les temps d'accès sont minimes. Les ressources communes comme les CSS étant souvent utilisées, elles restent dans le cache du serveur (par contre, si on utilise Apache, il faut désactiver les .htaccess sinon Apache vérifie la présence de tels fichiers dans le dossier courant et les parents à chaque requête, ce qui est effectivement pénalisant).
La question, c'est surtout de savoir si on a intérêt à regrouper les fichiers avec HTTP2. C'est un coup à télécharger plein de règles inutiles si c'est fait de façon pas très subtile (ce que j'ai souvent vu). Mais aussi, si une ligne d'une CSS change, le plus gros fichier qui regroupe les petits fichiers doit être intégralement téléchargé à nouveau. Si on a beaucoup de visites récurrentes et des mises à jour fréquentes, ça devient une mauvaise pratique.
 
WRInaute impliqué
En général, non : les temps d'accès sont minimes.

Je m'exprime mal ; je ne veux pas tant parler du temps d'accès au fichier par le serveur (qui reste en effet globalement négligeable), mais du temps pris par toutes les opérations en amont du téléchargement (Résolution DNS, connexion avec le serveur, établissement liaison TLS, et temps d'attente avant de démarrer la réception du fichier).
 
WRInaute impliqué
Je m'exprime mal ; je ne veux pas tant parler du temps d'accès au fichier par le serveur (qui reste en effet globalement négligeable), mais du temps pris par toutes les opérations en amont du téléchargement (Résolution DNS, connexion avec le serveur, établissement liaison TLS, et temps d'attente avant de démarrer la réception du fichier).
Si tes CSS sont sur un seul nom de domaine, tout ceci n'est fait qu'une fois — et si elles sont sur le même domaine que la page, il n'y en a aucune faire spécifiquement pour les CSS.

Du temps d'HTTP/1.1, chaque fichier utilisait une connexion, et il ne pouvait y en avoir qu'un certain nombre simultané, donc oui, c'était problématique et il fallait essayer de limiter le nombre de ressources bloquantes, mais ça n'est plus comme ça que ça fonctionne : avec HTTP/2, tout passe par une seule connexion. Que tu aies 1 gros ou 10 petits fichiers, la différence n'est plus significative.
Démo visuelle avec 100 fichiers : http://www.http2demo.io
Waterfalls des chargements d'une même page en HTTP/1.1 et HTTP/2 : http://techslides.com/page-performance-in-http1-vs-http2 (il n'y a plus moyen d'afficher les tests complets, mais on voit quand même les multiples connexions en HTTP/1.1).
 
Discussions similaires
Haut