Code Coverage teste chaque sélecteur de chaque feuille de style lisible par rapport à la page en direct, afin que vous puissiez voir quelles règles CSS ne correspondent actuellement à rien, combien d'octets chaque fichier gaspille et quels scripts retardent la première peinture.
Les feuilles de style ne font que croître. Un thème arrive avec des règles pour les pages que vous n'avez pas, un framework fournit des composants que vous n'utilisez jamais, et trois refontes plus tard, personne ne sait vraiment quelle moitié du fichier est porteuse. Le résultat est un CSS qui coûte de la bande passante à chaque visiteur et du temps de rendu pour fournir des règles que la page ne peut pas utiliser.
La couverture du code mesure cela directement. Il parcourt chaque règle de chaque feuille de style que le navigateur lui permet de lire – y compris les règles imbriquées dans les requêtes multimédias, les blocs @supports et @layer – et teste chaque sélecteur par rapport au DOM en direct. Une règle qui ne correspond à rien pour le moment est signalée comme inutilisée, par fichier, avec un pourcentage, les octets gaspillés et la liste complète des sélecteurs que vous pouvez développer et copier.
Il fait attention aux pièges évidents. Les pseudo-éléments et les pseudo-classes d'état sont supprimés avant la correspondance, donc une règle :hover ou ::before est jugée en fonction de l'existence de son sélecteur de base plutôt que d'être radiée à tort. Les feuilles de style diffusées d'origine croisée sans en-têtes CORS ne peuvent être lues par aucun script, elles sont donc signalées comme illisibles au lieu d'être considérées silencieusement comme parfaites. Et comme l’analyse reflète la page telle qu’elle est à ce moment-là, les règles des menus, onglets et modaux qui ne sont pas encore ouverts sembleront inutilisées – alors ouvrez-les et appuyez sur Re-scan avant de supprimer quoi que ce soit.
L'onglet JavaScript répond à une question différente : poids et blocage. Il inventorie chaque script chargé par la page avec sa taille de transfert, son temps de téléchargement et s'il est asynchrone, différé, un module, chargé dynamiquement ou retenant le premier paint, puis totalise le nombre d'octets bloquants. Il n'est délibérément pas vendu comme couverture d'exécution : savoir quelles lignes JavaScript ont été exécutées nécessite l'API du débogueur de Chrome, ce que DevSuite Pro ne demande pas, donc rien ici ne prétend être un rapport au niveau de la ligne.
Chaque règle de chaque feuille de style lisible est testée par rapport au DOM en direct, y compris les règles contenues dans les requêtes multimédias, les blocs @supports et @layer – sans estimation à partir des noms ou des tailles de fichiers.
Chaque feuille de style obtient un pourcentage inutilisé, un nombre de règles utilisées par rapport à celles inutilisées et le nombre d'octets gaspillés, triés de manière à ce que le pire contrevenant soit en haut.
Développez n'importe quel fichier pour lire les sélecteurs qui ne correspondent à rien, puis copiez-les sous forme de bloc CSS pour les travailler dans votre éditeur ou les remettre à un coéquipier.
Les pseudo-éléments et les pseudo-classes d'état telles que :hover et :focus-within sont supprimés avant la correspondance, de sorte que les règles interactives sont jugées équitablement au lieu d'être radiées.
Chaque script répertorié avec sa taille, son temps de téléchargement et s'il est asynchrone, différé, un module, chargé dynamiquement ou bloquant le premier paint, ainsi que le nombre total d'octets bloquants.
Les feuilles de style d'origine croisée illisibles sont signalées plutôt que notées, et l'onglet JS indique clairement qu'il mesure le poids, et non les lignes exécutées. Pas de chiffres inventés.
Un thème acheté fournit du CSS pour des dizaines de mises en page de démonstration. Voyez quelle quantité votre site n’utilise jamais et réduisez le fichier avec des preuves plutôt que des conjectures.
Vérifiez dans quelle mesure un framework CSS survit sur un modèle réel et si votre configuration de purge ou d'arborescence fait ce que vous pensez.
Répertoriez les scripts qui retardent le rendu, avec leur taille, et décidez quoi différer, diviser ou supprimer pour afficher le contenu à l'écran plus tôt.
Entrez avec des chiffres : quels fichiers gaspillent le plus d'octets, combien de JavaScript bloque et où la première heure de travail rapporte le plus.
En reprenant un site que vous n'avez pas construit, découvrez rapidement dans quelle mesure ses CSS et JavaScript gagnent encore sa place.
Cliquez sur l'icône Couverture du code dans le dock DevSuite Pro. L'analyse s'exécute immédiatement et indique le nombre de règles vérifiées et la part d'entre elles qui est inutilisée.
La rangée du haut vous indique le nombre de feuilles de style, le total des règles, le pourcentage inutilisé et les octets gaspillés. Les fichiers ci-dessous sont classés en fonction de leur quantité gaspillée.
Cliquez sur Afficher les sélecteurs inutilisés sur n'importe quel fichier pour lire exactement quelles règles ne correspondent à rien sur cette page.
Ouvrez les menus, les onglets, les accordéons et les modaux, puis appuyez sur Re-scan. Les règles dont les éléments n’existent que dans ces états passeront de inutilisées à utilisées – faites-le toujours avant de les supprimer.
Copier les sélecteurs inutilisés vous donne un bloc CSS sur lequel travailler ; Export JSON copie le rapport complet, y compris l'inventaire JavaScript, pour un ticket ou un document d'audit.
Installez DevSuite Pro gratuitement et débloquez plus de 71 outils de développement pour votre navigateur.
