Rapport de performance web

L'optimisation des images est généralement l'un des moyens les plus simples de réduire le poids d'une page et, par conséquent, le temps de chargement de la page.

La compression est donc l’étape essentielle pour optimiser les images. Elle sert à réduire la redondance des données d’une image afin de pouvoir l’emmagasiner en occupant moins de place.

• Il y a la compression avec perte de données, où l’image devient plus floue à mesure qu’elle est compressée ;
• et la compression sans perte, où les traits de l’image restent nets.

Il faut trouver le bon rapport qualité/compression qui satisfasse à vos besoins.

N'utilisez pas Photoshop ou d'autres outils d'édition d'images, car ils ne sont pas très bons pour l'optimisation. Utilisez des outils spécialisés comme Kraken.io ou l'excellent ImageOptim sur Mac. Pour les images SVG, vous pouvez utiliser SVGOMG.

Article sur le sujet : 

• https://www.artwai.com/optimiser-les-images/

Idéalement, votre page ne doit jamais diffuser d'images plus grandes que la version affichée sur l'écran de l'utilisateur. La règle de base est de dimensionner l’image à sa taille réelle d’affichage. Vous pouvez très bien avoir une image de 1000 px x 1000 px affichée en 100 px x 100 px. Du coup, en exagérant, votre image est 10 fois plus lourde que nécessaire. 

Ainsi, tout ce qui est plus grand que cela entraîne simplement des octets gaspillés et ralentit le temps de chargement de la page. 

La principale stratégie pour diffuser des images de taille appropriée est appelée "images responsives". Avec les images responsives, vous générez plusieurs versions de chaque image, puis spécifiez la version à utiliser dans votre code HTML ou CSS à l'aide des requêtes multimédia, des dimensions de la fenêtre d'affichage. 

De plus, il se peut que l'attribut "sizes"  liés aux "srcset" d'une image responsive soit incorrect. Cela peut entrainer un mauvais choix d'image chargée, donc potentiellement plus de poids ou une dégradation de l'image affichée.  Pour contrôler cet aspect vous pouvez utilisez  dans Chrome, l'extension Responsive Image Linter qui vérifie chaque image de la page.

Article sur le sujet : 

• https://www.artwai.com/optimiser-les-images/

Les ressources textuelles type CSS ou JS doivent être servies avec compression pour minimiser le nombre total d'octets réseau, c'est-à-dire limiter limiter l’utilisation de la bande passante et améliorer les temps de chargement.  Selon le test, certains fichiers pourraient ne pas être compressés du tout ou être déjà compressés avec Gzip, mais deviendraient encore plus légers avec Brotli.

Tous les principaux systèmes de serveurs sont désormais compatibles avec Brotli.

Consultez la liste des types MIME concernés.

NB : la compression de petits fichiers (< 1 Ko) est discutable et que certains éléments tels que les images ou les polices au format WOFF2 ne doivent pas être compressés, car ils sont déjà inclus dans leur format. 

Lorsqu'une ressource est demandée à un serveur, celui commence par répondre avec un code de statut HTTP. Ces codes sont envoyés par le serveur HTTP au navigateur afin de permettre à ce dernier de déterminer automatiquement si une requête a réussi, et sinon, de connaître le type d'erreur. Ces codes sont spécifiés dans le document RFC 7231 par l'IETF (Internet Engineering Task Force). 

Une erreur 404 est un code d’erreur HTTP transmis par un serveur web quand une ressource demandée est indisponible ou que le serveur n’arrive pas à la trouver. Les erreurs 404 ne sont jamais mises en cache, donc chaque fois qu'une URL se termine en 404, elle arrive sur le serveur même si elle se trouve derrière un CDN ou un cache de proxy inverse.

Une erreur 404 occupe inutilement le navigateur et le serveur qui doit lui répondre et chercher une ressource qui n'existe pas ou qui n'existe plus.

NB : Cette bonne pratique est recommandée par l'analyste GreenIT Analysis, mais n'a pas son équivalent dans le référentiel du CNumR.

Envisagez de charger paresseusement (en lazyload) les images sous la ligne de flottaison du viewport , une fois que toutes les ressources critiques ont fini de se charger pour réduire le temps d'interaction. Il s'agit de différer le chargement des images non visibles à l’écran jusqu'au moment où l’utilisateur est susceptible de les voir.  C'est un excellent moyen d'accélérer le temps de chargement initial d'une page tout en économisant de la bande passante.

Nous recommandons d'utiliser le lazyloading natif des image qui fonctionne désormais pour les principaux navigateurs du marché. Ce simple attribut se révèle très efficace. Attention, toutes les images ne doivent pas être lazyloadée avec l'attribut loading="lazy". Pour les images constitutive du LCP ou situées au dessus de la ligne de flottaison, préférez loading="eager" qui priorisera leurs chargements. 

Articles sur le sujet : 

• https://www.artwai.com/attribut-loading-lazy-or-not-lazy/
• https://www.artwai.com/hybrid-lazy-loading-la-fausse-bonne-idee/

Il se peut que, pour une raison historique, votre serveur soit configuré pour fermer les connexions rapidement, voire immédiatement. En faisant de la sorte, vous privez l'utilisateur des avantages d'une connexion persistante.

Les connexions persistantes réduisent le temps nécessaire pour établir de nouvelles connexions, notamment dans le cadre d'une négociation SSL. Sans cela, la requête suivante est ralentie, car le navigateur doit ouvrir une nouvelle connexion au serveur, ce qui signifie un aller-retour supplémentaire.

Corrigez le problème en définissant un en-tête Keep-Alive sur le serveur coupable. Lorsque Keep-Alive est activé, le client et le serveur conviennent de maintenir la connexion ouverte pour les demandes ou réponses ultérieures. Keep-Alive est généralement activé par défaut sur votre serveur d'origine.

En termes d'écoconception, l'utilisation de connexions persistantes profitera au serveur. En effet, avec moins de requêtes HTTP générées, cela réduit l'utilisation du processeur et de la mémoire du serveur, et donc la consommation d'énergie.

Un nombre élevé d'éléments DOM signifie beaucoup de travail pour le navigateur pour rendre la page. Cela peut ralentir les performances de votre page de plusieurs manières :

• Efficacité du réseau et performances de charge
  Une grande arborescence DOM comprend souvent de nombreux nœuds qui ne sont pas visibles lorsque l'utilisateur charge la page pour la première fois, ce qui augmente inutilement les coûts de données pour vos utilisateurs et ralentit le temps de chargement.

• Performances d'exécution
  Au fur et à mesure que les utilisateurs et les scripts interagissent avec votre page, le navigateur doit constamment recalculer la position et le style des nœuds. Une grande arborescence DOM associée à des règles de style compliquées peut ralentir considérablement le rendu.

• Performances de la mémoire
  Si votre JavaScript utilise des sélecteurs de requête généraux tels que document.querySelectorAll('li'), vous stockez peut-être sans le savoir des références à un très grand nombre de nœuds, ce qui peut surcharger les capacités de mémoire des appareils de vos utilisateurs.

La taille du DOM est souvent liée à des problématiques d'affichage.  Nous observons que cela vient d'une utilisation restreinte de la sémantique HTML qui conduit à un abus de <div> et d'une méconnaissance des nouvelles propriétés CSS qui permettent de simplifier grandement l'arbre DOM tout en étant compatible avec la plupart des navigateurs.

Le DOM est aussi le critère le plus important qui détermine la notation Ecoindex, car il a une influence directe sur la durée de vie des terminaux.

Analyser votre code HTML et CSS pour réduire ce DOM, le cas échéant demandez l'avis des experts d'Artwaï.

Un DOM profond rend difficile la correspondance CSS avec les éléments DOM.

Cela ralentit également les modifications JavaScript apportées au DOM car la modification des dimensions d'un élément oblige le navigateur à recalculer les dimensions de ses parents. Même principe pour les événements JavaScript, qui remontent à la racine du document.

La complexité d'imbrication du DOM est souvent liée à des problématiques d'affichage.  Nous observons que cela vient d'une utilisation restreinte de la sémantique HTML qui conduit à un abus de <div> et d'une méconnaissance des nouvelles propriétés CSS qui permettent de simplifier grandement l'arbre DOM tout en étant compatible avec la plupart des navigateurs.

Analyser votre code HTML et CSS pour réduire ce DOM, le cas échéant demandez l'avis des experts d'Artwaï.

L'attribut id définit un identifiant qui doit être unique pour l'ensemble du document. Le but de cet attribut est de pouvoir identifier un élément lorsqu'on crée un lien, qu'on souhaite le manipuler avec un script ou qu'on le met en forme avec CSS.

Comme les navigateurs sont très indulgents en matière de rendu HTML, ils autorisent les ID en double. Cela devrait être à proscrire dans la mesure du possible et strictement proscrit lors de l'accès aux éléments par ID en JavaScript.

En effet, que doit renvoyer la méthode getElementById lorsque plusieurs éléments correspondants sont trouvés ? Devrait-il renvoyer une erreur, le 1er élément correspondant, un ensemble d'éléments, etc. ?

C'est d'autant plus important en termes d'accessibilité. S'assurer que les ids sont uniques permet d'éviter les erreurs clés qui sont connues pour causer des problèmes aux technologies d'assistance lorsqu'elles essaient d'analyser le contenu qui a le même attribut id sur différents éléments.

Même si la plupart du temps, les erreurs relevés par le W3C n'ont que peu d'impact sur le fonctionnement d'une page ; certaines erreurs sont rédhibitoires.

En effet, tout code HTML mal formé peut provoquer des bugs graphiques et dans certains cas empêcher la bonne indexation des pages dans les moteurs de recherche. 

Nous avons identifié les erreurs graves suivantes comme des erreurs devant être corrigées : 

• Elément mal placé : par exemple un élément meta dans le body ne sera pas interprété.
• Pas d'espace entre 2 attributs.
• Ouverture d'un élément non fermé par la suite.
• Fermeture d'un élément non ouvert au préalable.
• Erreur fatale qui empêche le validateur de parcourir le code dans son intégralité. 

Article sur le sujet : 

• https://www.artwai.com/valider-le-code-de-son-site-internet/

La modification du DOM, par l'ajout et la suppression d'éléments, la modification d'attributs, de classes ou d'animations, obligera le navigateur à recalculer les styles d'éléments et, dans de nombreux cas, à mettre en page (ou redistribuer) la page ou des parties de celle-ci. 

Plus votre code JavaScript accède au DOM, plus la page se chargera et interagira lentement. En analysant le nombre de fois que le JavaScript lit, modifie ou lie le DOM, nous pouvons déterminer un indicateur qui permet d'évaluer la charge côté navigateur.

Et n'oubliez pas que plus le nombre d'éléments DOM est grand, plus les accès DOM sont lents car il y a plus d'éléments à parcourir.

Ce nombre d'accès DOM doit être le plus petit possible. Essayez, dans la mesure du possible, d'avoir une page HTML entièrement générée par le serveur au lieu de faire des modifications avec JS. Essayez également de réduire le nombre de requêtes en refactorisant votre code JavaScript. Lier trop d'événements JS a également un coût.

Les appels en JS de "document.write" ralentissent la construction de la page, surtout s'ils sont utilisés pour insérer des scripts dans la page.

En effet, si le script injecte dynamiquement un autre script, l'analyseur est obligé d'attendre encore plus longtemps le téléchargement de la ressource, ce qui peut entraîner un ou plusieurs allers-retours réseau et retarder le premier rendu de la page.

D'un point de vue performance, document.write()  n'est pas un  mal en soi. En fait, tout ce qu'il fait, c'est mettre en évidence les comportements potentiels déjà présents dans n'importe quel script synchrone - la seule différence principale est que le document.write() garantit que ces comportements négatifs se manifesteront, alors que d'autres scripts synchrones peuvent utiliser des optimisations alternatives pour les contourner. Même la doc de MDN les déconseille !

Conclusion : retirez-les dès que possible !

Si vous ne pouvez pas les supprimer car ils proviennent d'un script tiers (tel que des publicités), consultez PostScribe .

AJAX (Asynchronous JavaScript + XML) désigne une approche utilisant l'ensemble de technologies Web existantes et surtout l'objet XMLHttpRequest. En utilisant des requêtes AJAX, les applications web sont capables de réaliser des mises à jour rapides de l'interface utilisateur sans devoir recharger la page entière dans le navigateur. Les pages sont censés fonctionner plus rapidement et être plus réactives aux actions de l'utilisateur.

Mais, encore faut-il faire attention aux détails : le paramètre async de la requête XMLHttpRequest doit être défini à true et non pas à false. Sinon le thread principal du navigateur doit tout arrêter jusqu'à ce que la réponse soit reçue...

Ce n'est pas la technologie qui est mise en cause mais le caractère synchrone et donc bloquant de son usage avec l'option async défini à false.

jQuery est une bibliothèque JavaScript libre et multiplateforme créée pour faciliter l'écriture de scripts. Le but de la bibliothèque étant le parcours et la modification du DOM, elle contient de nombreuses fonctionnalités ; notamment des animations, la manipulation des feuilles de style en cascade, la gestion des évènements, etc. Et l'utilisation d'Ajax est facilitée et de nombreux plugins sont présents.

Depuis sa création en 2006 et notamment à cause de la complexification croissante des interfaces Web, jQuery a connu un large succès auprès des développeurs Web. Il est à l'heure actuelle en 2022, la bibliothèque front-end la plus utilisée au monde.

Chaque nouvelle version de jQuery optimise les performances. Ne conservez pas une ancienne version de jQuery. La mise à jour peut parfois casser certaines choses, mais il est généralement assez facile de les réparer. Alors n'hésitez pas. La dernière version en juillet 2023 est la version 3.7.0.

En dessous de la version 3, jQuery embarque du code de rétrocompatibilité avec de très anciens navigateurs. Ces versions sont très lourdes et lentes. Elles sont à proscrire si vous cherchez la performance. ( artwaï a également un avis négatif sur l'usage de la librairie associée jQuery UI qui est encore plus lourde toutes versions confondues ).

La plupart des fonctionnalités de jQuery sont désormais réalisables avec les API DOM natives et peuvent être inutiles dans les pages Web d'aujourd'hui. artwaï recommande de ne pas l'utiliser du tout : R.I.P jQuery.

Avoir un grand nombre de règles CSS nuit aux performances.

Lors du rendu initial de la page, le CSS est appliqué à une page et une structure similaire au DOM connue sous le nom de CSS Object Model (CSSOM) est créée. Ce rendu des styles nécessite que le navigateur vérifie au moins une fois si chaque élément correspond à chaque sélecteur CSS déclaré. Pour faire simple, vous multipliez le nombre d'éléments par le nombre de sélecteurs !

Si le nombre de règles CSS est supérieur au nombre d'éléments DOM, il y a clairement un problème.

Les feuilles de style volumineuses se produisent généralement lorsque les différentes pages d'un site Web chargent tous les CSS, concaténés dans une seule feuille de style, même si une grande partie des règles sont inutiles à la page en cours. Dans ce cas-là, une solution consiste à créer un fichier CSS principal avec des règles globales et un fichier personnalisé par page.

Sinon il faut repenser la conception de vos CSS, voir même revoir la cohérence graphique du site, pour factoriser vos sélecteurs. La mise en place d'un design system peut grandement être utile dans cette mise en œuvre. Le cas échéant demandez l'avis des experts d'artwaï.

Les sélecteurs complexes sont des sélecteurs CSS avec 6 éléments ou plus comme "#header ul li .foo". 
Les combinatoires "espace", ">", "+", ":not()", etc, comptent pour un élément. Notre exemple "#header ul li .foo" compte donc 7 éléments : un id (#header), un espace, une balise (ul), un espace, une balise (li), un espace, une class (.foo).
Contrairement à ce que l'on pourrait penser, trop de précisions dans les sélecteurs CSS deviennent contreproductives pour la performance.

Pour le rendu initial des styles, le navigateur vérifie au moins une fois si chaque élément du DOM correspond à chaque sélecteur CSS déclaré (cf BP#26). Chaque sélecteur est parcouru de droite à gauche pour vérifier si l'élément correspond au sélecteur. Le navigateur filtre les éléments du DOM en fonction de l'élément du sélecteur le plus à droite et parcourent ses éléments parents pour déterminer les correspondances. Plus la longueur de la chaîne du sélecteur est longue, plus le navigateur doit parcourir d'éléments parents pour déterminer si l'élément de droite correspond au sélecteur. 

Dès lors, en précisant plus d'un sélecteur, vous complexifiez le travail du navigateur.

Cela peut se produire si les feuilles de styles sont développées en SCSS. Les développeurs front-end ont tendance à trop indenter et donc surspécifier les sélecteurs CSS. La compilation avec Gulp ou Grunt, ne peut pas régler ce problème de manière automatique.

NB : Vous pouvez visualiser la complexité et la spécificité de vos sélecteurs avec un outil comme Specificity Visualizer.

La simplification des sélecteurs passe par l'œil aguerri d'un intégrateur front-end.  Et pourquoi pas un intégrateur de chez artwaï ? 

Soyons clair : le nombre de couleurs définies dans vos CSS n'a aucun impact sur le temps de chargement de vos pages. Même le codage de celles-ci, que cela soit en hexa, RGB ou HSL, cela n'a aucune différence notable d'un point de la rapidité de leur interprétation.

Toutefois, c'est un révélateur de la qualité de votre code. En effet, si le nombre de couleurs est très important, il y a fort à parier que la cohérence du code CSS sur l'ensemble des autres caractéristiques soit équivalente. Ce qui signifie un code non factorisé avec tous les inconvénients que cela implique.

Dans l'idéal une palette de couleur est déterminée en amont, le cas échéant avec des variables CSS ou SCSS. Et chaque composant utilise ces couleurs ainsi référencées.

Au-delà de la performance, c'est la maintenabilité de votre code CSS qui est ici en jeu. Votre CSS sera plus facile à maintenir si vous conservez un petit jeu de couleurs.

Pour résoudre cette bonne pratique la première étape est d'identifier les couleurs similaires et de les rationaliser. Pour cela référez vous à la BP#29.

Soyons clair : le nombre de couleurs définies dans vos CSS n'a aucun impact sur le temps de chargement de vos pages. Même le codage de celles-ci, que cela soit en hexa, RGB ou HSL, cela n'a aucune différence notable d'un point de la rapidité de leur interprétation.

Au-delà du nombre de couleurs qui peut être justifié, c'est la similarité de certaines couleurs entre elles qui est à remettre en cause. Leur proximité peut rendre impossible leur identification distincte par l'utilisateur. Dès lors, quel est l'intérêt de conserver deux couleurs similaires si une seule peut faire le job.

Cela est d'autant plus vrai, car il est illusoire de croire que vous maîtrisez le rendu final de ces couleurs. Si une couleur reste toujours la même d'un point vu de son code, la réalisation physique d'une couleur dépend de l'écran utilisé, des matériaux utilisés pour l'affichage, des paramètres d'affichage (notamment le taux de contraste), de l'éclairage de la pièce et d'un éventail presque infini de situations.

Au-delà de la performance, c'est la maintenabilité de votre code CSS qui est ici en jeu. Réduire ce nombre en rapprochant les couleurs similaires est une partie de la solution pour réduire le nombre de couleurs (cf BP#28).

Le nombre indiqué dans la métrique mesurée est la liste des couleurs trouvées dans les feuilles de style, qui sont très proches les unes des autres. L'œil peut à peine voir la différence. Utilisez cette liste pour réduire le nombre de couleurs dans votre palette, vos CSS seront plus faciles à maintenir.

Les breakpoints CSS sont des points où le contenu du site Web réagit en fonction de la largeur de l'appareil, vous permettant de montrer la meilleure mise en page possible à l'utilisateur. Ce sont généralement des paliers dont la valeur est incrémentée au fur et à mesure des résolutions cibles.

Pour définir ces paliers, on utilise les médiaqueries avec des instructions de taille portant généralement sur la largeur. Notez que la métrique ici mesurée est basée uniquement sur les médiaqueries min-width , max-width , min-device-width et max-device-width .

D'un point de fonctionnement, le moteur de rendu d'un navigateur sérialise et supprime les médiaqueries en double, de sorte qu'ils n'ont besoin d'évaluer chaque médiaquerie qu'une seule fois. Ils mettent également en cache les requêtes pour les réutiliser ultérieurement. Ainsi, même s'il y a une différence de performance, elle est minime au regard d'un chargement initial. Toutefois, si vous redimensionnez la fenêtre du navigateur, cela peut entraîner une charge massive du processeur et de la mémoire qui peut même planter votre navigateur. Il ne s'agit certes pas d'un usage courant (aucun utilisateur ne redimensionne constamment son navigateur) mais cela traduit quand même la complexité du code.

Votre CSS sera plus facile à maintenir si vous conservez un nombre raisonnable de breakpoints. Essayez de faire une conception fluide - en utilisant des pourcentages - pour éviter la création de nombreux breakpoints.

Pour réduire ce nombre, définissez bien vos cibles en fonction de vos statistiques de fréquentation ou inspirez vous des breakpoints des frameworks CSS populaires comme Bootstrap qui dans sa version 5.3 définit 6 breakpoints. Le cas échéant demandez l'avis des intégrateurs front-end d'artwaï.

On considère comme mobile-first l'ensemble des pratiques qui donne la priorité aux besoins des utilisateurs mobiles pour optimiser leur expérience. En termes de code CSS, cela consiste à écrire du CSS de manière à ce que les petits appareils, les smartphones, puissent accéder à leurs styles sans avoir à parcourir les styles écrits pour les ordinateurs de bureau.

Généralement on définit les éléments communs à tous les appareils. Puis  on définit les éléments spécifiques à chaque résolution par palier à l'aide des mediaqueries en passant par l'instruction min-width. L'usage de max-width n'est pas à proscrire, mais vous devez garder deux principes en tête : 

• Ne définissez les styles que lorsque cela est nécessaire. 
• Ne pas les définir dans l'espoir de les écraser plus tard, encore et encore. 

Dans l'idéal, fractionnez vos CSS en plusieurs fichiers et distribuez-les via l'élément link dans le head en précisant la mediaquerie directement avec l'attribut media. Vous profiterez de la priorisation du navigateur qui chargera en premier les fichiers qui correspondent à sa résolution. Si vous travaillez en SCSS, l'usage d'un compilateur comme GULP devrait automatisé cette tâche.

Le respect de cette pratique peut contribuer à la résolution des problèmes de FOUC (Flash Of Unstyled Content) où l'utilisateur peut voir votre page se charger sans style pendant quelques instants avant de se corriger.

Une erreur de syntaxe CSS peut avoir des effets non-négligeables sur l'affichage de vos pages web. Et là il ne s'agit pas que de performance, mais cela peut avoir des effets non-désirés sur le fonctionnel lui-même. Un bouton qui devient non cliquable, des éléments se chevauchant, ou alors une page affichée sans aucun style du tout.

Pour éviter, ce genre d'erreur vous pouvez valider votre code manuellement avec un validateur en ligne comme celui du W3C ou CSSLint, ou dans votre chaine de déploiement vérifier automatiquement le code CSS avec un compilateur comme GULP ou Grunt.

Attention, nous ne mesurons pas ici les syntaxes qui ne seraient pas prises en compte par une version de navigateur X ou Y. Pour cela, référez-vous à au site caniuse.com.

Article sur le sujet :

• https://www.artwai.com/caniuse-sur-mon-site/

La plupart des fichiers CSS sont des ressources bloquant le rendu, ce qui signifie que le navigateur doit les télécharger avant de pouvoir afficher le contenu à l'utilisateur.

La règle CSS @import est un des moyens disponibles pour charger des feuilles de style supplémentaires au sein d'une instruction CSS. Et lorsque plusieurs feuilles de style sont ajoutées avec @import, le navigateur doit télécharger séquentiellement ces fichiers. Il peut même y avoir une cascade de requêtes, un fichier CSS en appelant un autre qui en appelle un autre et ainsi de suite... Par conséquent, la page Web se charge plus lentement.

Cela se produit souvent lors de l'importation de Google Fonts dans un fichier CSS : le CSS des polices Google ne commence à se charger qu'après le téléchargement du fichier initial. 

A l'inverse, plusieurs balises link au sein du HTML sont plus efficaces et chargent les fichiers CSS en parallèle. Il y a donc une solution efficace : vous devez utiliser <link rel='stylesheet' href='a.css'> à la place.

S'il y a deux sélecteurs CSS ou plus qui pointent vers le même élément, le sélecteur avec la valeur de spécificité la plus élevée "gagnera" et sa déclaration de style sera appliquée à cet élément HTML. Considérez la spécificité comme un score/rang qui détermine quelle déclaration de style est finalement appliquée à un élément. Vous pouvez voir comment est déterminé le score de spécificité sur la page What is Specificity ? du W3School.

Cela demande donc un certain temps de calcul pour déterminer qui a la priorité; d'autant plus si les sélecteurs sont strictement identiques. Les sélecteurs en double sont très rarement intentionnels. Dans le cas d'un sélecteur basé sur un id, il s'agit certainement d'une erreur. En plus du travail supplémentaire requis par le navigateur, cela est souvent source de conflit et n'aide pas la maintenance.

Une seule issue : lorsque deux ou plusieurs sélecteurs sont strictement identiques au sein d'une même media query, ils doivent être fusionnés.

Dans le cas d'une chaîne de production automatisée avec GULP ou Grunt, il est aisé de regrouper ces sélecteurs dupliqués en un seul. Mais gare aux propriétés dupliquées ! (cf BP#35)

CSS autorise les propriétés en double même au sein d'un même sélecteur. Mais seule la dernière instance de la propriété détermine la valeur réelle qui sera attribuée à l'élément cible. Par conséquent, la modification des valeurs des occurrences précédentes d'une propriété dupliquée n'aura aucun effet et pire, cela peut entraîner des conflits et des bogues d'affichage.

Ainsi, seule la dernière occurrence de la propriété est utile. Du coup, on embarque du code en plus qui nécessite plus de temps à être téléchargé. 

La duplication de propriété est donc autant un problème de maintenabilité que de performance.

La meilleure solution reste d'utiliser un parseur CSS qui au sein d'une chaîne de production automatisée, avec GULP ou Grunt par exemple, va automatiquement supprimer les occurrences de propriétés inutiles.

Le rendu initial des styles nécessite que le navigateur vérifie au moins une fois si chaque élément correspond à chaque sélecteur CSS déclaré, même si celui-ci ne contient aucune propriété, bref même si il est vide.

Pourquoi surcharger le travail du navigateur avec un parcours du CSS Object Model (CSSOM) inutile ?
La solution est donc simple : supprimez toutes les règles vides.

Dans le cas d'une chaîne de production automatisée avec GULP ou Grunt, il est aisé de supprimer ces sélecteurs vides.

Une déclaration !important permet de donner à une valeur CSS plus de poids qu'elle n'en a naturellement.

La balise !important semble être la solution la plus simple pour forcer des styles qui ne fonctionnent pas comme prévu. Cette situation se produit lorsque vous essayez de remplacer des styles qui sont déclarés ailleurs dans votre CSS. Généralement, le sélecteur que vous utilisez n'a pas la priorité par rapport à un autre. Vous pouvez voir comment est déterminé le score de priorité sur la page What is Specificity ? du W3School.

Les déclarations !important ne doivent pas être utilisées à moins qu'elles ne soient absolument nécessaires après que toutes les autres voies ont été épuisées. C'est une mauvaise pratique car elle remplace la logique de cascade CSS normale : plus vous utilisez !important, plus vous en avez à nouveau besoin pour la remplacer. Cela conduit à une mauvaise maintenabilité du code CSS.

Pour résoudre ce problème, il vous faudra généralement revoir la spécificité des sélecteurs utilisant la mention !important de façon à ce qu'ils reprennent la priorité.

Il s'agit là de supprimer du code inutile. En effet, les habitudes ont la vie dure et il n'est pas rare de trouver au sein du code CSS, des propriétés, des sélecteurs voire des hacks qui se référent à des très anciens navigateurs.

Internet Explorer est de ceux-ci. Depuis 2019, Microsoft recommande de ne plus l'utiliser. Et en juin 2022, Microsoft a mis fin définitivement au développement et au support d’Internet Explorer, après vingt-sept années de service. 

Même avec cette popularité passée, rien ne justifie aujourd'hui de cibler spécifiquement Internet Explorer qui représente en juillet 2023 moins de 0,5% de part de marché... 

Il convient donc de supprimer toutes les anciennes façons d'adresser du CSS pour ce navigateur.

Les préfixes de fournisseur CSS ou préfixes de navigateur CSS, sont un moyen pour les fabricants de navigateurs d'ajouter la prise en charge de nouvelles fonctionnalités CSS avant que ces fonctionnalités ne soient entièrement prises en charge dans tous les navigateurs. Cela peut être fait pendant une période d'expérimentation où le fabricant du navigateur détermine exactement comment ces nouvelles fonctionnalités CSS seront implémentées. Ces préfixes sont devenus très populaires avec l'essor de CSS3 il y a quelques années. 

Une fois, la période d'expérimentation terminée, ces préfixes deviennent inutiles.

Ainsi de nombreux préfixes de propriété tels que -moz- ou -webkit- ne sont plus nécessaires, ou pour très peu de navigateurs. Parfois, ils n'ont même jamais existé et sont intégrés par méconnaissance de l'intégrateur. Vous pouvez les supprimer ou les remplacer par la version sans préfixe pour réduire cette portion de code inutile. Cela aidera à réduire le poids de vos feuilles de style.

NB : la base de données des préfixes provient de Can I Use.

Au-delà des sélecteurs complexes (cf BP#27), il est souvent inutile de surspécifier un sélecteur. Ce qui signifie qu'un tag HTML peut être redondant voir parfaitement inutile.

C'est le cas du tag body, puisque tout élément que l'on souhaite styliser se trouve nécessairement à l'intérieur du body. N'oubliez pas que chaque sélecteur est parcouru de droite à gauche pour vérifier si l'élément correspond au sélecteur. Dès lors, en précisant un parent body à vos sélecteur, vous complexifiez le travail du navigateur inutilement.

Vous devez donc supprimer les tags body redondant, ce qui est une manière de réduire la complexité de vos règles CSS.

NB : le tag body peut lui même être stylisé. Dans ce cas là, il ne s'agit pas de redondance.

Au-delà des sélecteurs complexes (cf BP#27), il est souvent inutile de surspécifier un sélecteur. Ce qui signifie qu'un tag HTML peut être redondant voir parfaitement inutile.

C'est le cas de certaines balises incluses dans d'autres balises. Par exemple, lorsque "ul li" est spécifié dans une règle, "ul" peut être supprimé car la balise "li" est presque toujours à l'intérieur d'un conteneur "ul" (le conteneur "ol" est assez rare). Même chose pour "tr td", "select option", ...

N'oubliez pas que chaque sélecteur est parcouru de droite à gauche pour vérifier si l'élément correspond au sélecteur. Dès lors, en précisant un tag évident de par sa hiérarchie à vos sélecteurs, vous complexifier le travail du navigateur inutilement.

Vous devez donc supprimer les tags redondants, ce qui est une manière de réduire la complexité de vos règles CSS.