Audit qualité web : nouveaux contrôles sur Dareboost

Mise à jour : les bonnes pratiques évoquées au sein de cet article sont désormais en place sur dareboost.com !

Notez-le bien sur vos agendas : de nouvelles vérifications automatisées seront déployées ce jeudi 24 mars. Cet article a pour vocation de vous présenter en amont les nouveautés apportées, et vous permettre de corriger les éventuels problèmes avant la moindre baisse du score DareBoost de vos pages web !

Au programme : qualité du CSS, sécurité, mais aussi accessibilité !

Bonnes pratiques de qualité du code CSS

Jusqu’à présent, DareBoost remontait les résultats de la validation W3C pour vos feuilles de style. Vous pouvez  maintenant détecter rapidement les principales améliorations de qualité à mettre en place sur vos CSS.

Notez que notre analyse CSS porte uniquement sur les fichiers hébergés sur le domaine de la page analysée (nous évitons ainsi de vous suggérer des optimisations sur des contenus qui ne sont pas de votre responsabilité).

  • Sélecteurs CSS dupliqués : au cours du développement d’un site, il peut arriver de définir par mégarde une règle CSS déjà définie précédemment. Pour vous aider à améliorer la maintenabilité de votre code, nous vous signalons ce type d’étourderies :
.maClasse { ... }
...
.maClasse{ ... } // déjà définie au dessus !

 

  • Propriétés CSS dupliquées : de la même sorte, il peut arriver de réécrire la même propriété au sein d’une règle. Là encore, vous êtes avertis :
.maClasse {
  margin-left: 10px;
  margin-left: 10px; // déjà défini juste au dessus !
}

 

  • Attention aux effets de bord : le CSS comporte parfois quelques pièges (article en anglais). Par soucis de simplification, nous avons accès à des propriétés « raccourcies ». Par exemple, « border » s’applique sur toutes les bordures d’un élément, et revient à redéfinir « border-top », « border-right », « border-left » et « border-bottom ». DareBoost vous aide à identifier les propriétés surchargées par une propriété raccourcie au sein d’une même règle CSS. Exemple :
.maClasse {
  border-color:red;
  border:5px; // border reprend la couleur par défaut
}

 

  • Sélecteurs CSS trop complexes : une page bien structurée permet l’écriture de règles CSS simples, rapidement lisibles et performantes. Au delà de 7 sélecteurs, nous vous avertissons car il y a peu de doute sur la possibilité d’une simplification !
body div .maClasse1 table ul li .maClasse2 p {} 
// la règle peut être largement simplifiée

 

  • Le mot clé !important : ce mot clé s’approche d’un hack permettant d’éviter toute surcharge ultérieure de la propriété définie (on perd la notion de cascade propre aux CSS !). Si parfois il peut s’avérer utile, il ne faut pas en abuser ! Si nous détections plus de 10 fois ce mot clef, nous vous avertissons !

Veuillez noter que ces vérifications sont essentiellement présentes pour vous faciliter la tâche et n’impactent votre score que de manière limitée !

 

D’autres indicateurs sont par ailleurs remontés à titre informatif (conseils avec pastille bleue sur nos rapports), sans impacter du tout la note du rapport.

  • Nous remontons le nombre de couleurs utilisées sur la page, ainsi que la proportion de couleurs utilisées 1 seule fois. Sans doute l’occasion pour vous d’identifier quelques harmonisations possibles au sein de votre charte graphique.
  • Parfois, les règles CSS s’appuient des sélecteurs superflus. Des sélecteurs « body », « ul » suivis de « li », ou encore « table » suivis de « tr » : nous listons chaque sélecteur superflu, toujours dans l’objectif de faciliter la lisibilité de vos styles.

 

Des Cookies toujours plus sécurisés

Cela ne vous aura pas échappé si vous lisez ce blog : passer au HTTPs est nécessaire. Nous délivrons plusieurs bonnes pratiques de sécurité en lien avec le HTTPS : détection de contenus mixtes, de l’en-tête HSTS (HTTP Strict Transport Security), ou encore de la redirection de vos pages HTTP vers leur version HTTPs. Nouveau conseil : préciser l’instruction secure lors d’un Set-Cookie. Cela vous assurera que vos visiteurs peuvent transmettre leurs cookies vers votre serveur uniquement via une requête HTTPs (on élimine ainsi le risque de voir un cookie sensible transité sans être crypté).

En complément, même si aucune pénalité n’est appliquée, nous vous informons qu’il est préférable d’utiliser également l’instruction http-only, qui interdit au navigateur de manipuler le cookie (en JavaScript par exemple). Le cookie ne peut que transiter sur le réseau et est utilisé uniquement par le serveur.

Je vous recommande la lecture de cet article (EN) pour en savoir plus sur ces sujets.

 

Faille de sécurité lors d’un target=_blank

Edit : nous avons publié un article dédié à ce sujet : sécurité et performance de vos liens target=_blank avec rel=noopener.

L’utilisation de liens avec l’attribut target=_blank est rarement pertinente. Cependant, si vous tombez sur l’une des exceptions impliquant son usage, veuillez noter qu’il existe une faille à ce sujet qui pourrait causer du tort à vos visiteurs si votre site comporte des contenus contributifs.
Elle permet à la page cible d’un tel lien de manipuler la propriété window.opener.location, et ainsi d’effectuer une redirection au niveau de l’onglet parent. Lorsque l’utilisateur revient sur son premier onglet, il se peut alors qu’il ait été redirigé vers un site malicieux (phishing, etc).

Nous vous recommandons donc d’ajouter l’attribut rel=noreferrer lors de l’utilisation d’un target=_blank vers un site externe afin de bloquer l’accès à la propriété.

 

Bonnes pratiques d’accessibilité

Vous serez désormais avertis dès lors qu’un <label> ne dispose pas d’un attribut for, qui permet d’identifier l’élément décrit par le label. Nous vérifions par ailleurs si cet attribut n’est pas vide et correspond à un élément de la page.

L’outil s’assure par ailleurs qu’aucun élément <button> ou <li> n’est vide.

 

C’est tout pour aujourd’hui ! N’attendez plus pour découvrir vos résultats vis-à-vis de ces nouvelles vérifications avec notre outil d’audit de site web.

Nous espérons que vous appréciez cette mise à jour. Vous avez une question sur l’un de ces points ? Une idée à nous suggérer ? Nous répondrons avec plaisir à toutes vos interrogations !

4 réflexions au sujet de « Audit qualité web : nouveaux contrôles sur Dareboost »

  1. C’est une information importante et on vous remercie de nous l’avoir partagé. Ce genre de vérification est toujours nécessaire pour améliorer la qualité des prestations qu’on propose à nos clients.

  2. Bonjour,

    Concernant les CSS, est-ce que votre outil d’audit SEO prend en compte les frameworks genre Saas, Less ou Bootstrap ?

    Merci pour la faille target_blank, j’avais l’habitude de contrer certains effets de bord avec du Javascript (prevent…) mais là c’est plus simple et plus compatible.

    Bonne continuation !

    1. Bonjour Marc,

      Pour l’analyse du CSS nous prenons en compte toutes les ressources de la page ayant le Content-Type « text/css ».

      Ces bonnes pratiques portant sur l’analyse de la qualité du code, nous avons exclu les principaux frameworks sur lesquels vous n’avez pas la main, type Bootstrap, etc.

      Merci pour ces retours !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*