Article modifié le 2 février 2017 : Dareboost vient de procéder à la mise à jour de son référentiel des bonnes pratiques. Nouveaux contrôles, impacts sur le score des audits : retrouvez le détail de ces nouveautés, décidez des corrections éventuelles à appliquer et gardez un score au top pour votre site web !
Label “Secure” dans la barre d’adresse
Google l’annonce depuis plusieurs mois : à partir de Chrome 56, un site collectant des mots de passe ou informations bancaires doit nécessairement être délivré via le protocole HTTPS, faute de quoi il sera présenté comme “non sécurisé” aux internautes. Voici comment est affiché un tel site délivré via HTTPS, puis via HTTP (non sécurisé) :
Un guide est mis à disposition des développeurs afin d’éviter que votre site se retrouve dans cette situation. Notez que nous appliquons une forte pénalisation pour les pages web ne respectant pas cette bonne pratique.
Dans la même lignée, Google enlève la mention de site “sécurisé” dans le cas de contenus mixtes (le site ne sera cependant pas marqué comme “non sécurisé” ici).
Nous continuons de pénaliser fortement les contenus mixtes “actifs” (ex : scripts, styles), qui sont bloqués par le navigateur. Mais nous pénalisons désormais également, à un degré moindre, les contenus “passifs” (ex : images) qui engendrent eux aussi la perte de l’indicateur “Secure”.
Chargement de ressources provenant de tierces parties
Le chargement synchrone de ressources provenant de tierces parties reste à proscrire au maximum, les SPOF frontend constituant un risque pour votre site. Nous étoffons d’ailleurs la liste des fournisseurs dont les ressources doivent être rapatriées :
| googleapis.com | code.jquery.com | use.typekit.net |
| maxcdn.bootstrapcdn | addthis.com | cdn.jquerytools.org |
| platform.twitter.com | connect.facebook.net | platform.linkedin.com |
| apis.google.com | assets.pinterest.com | chartbeat.com |
| scorecardresearch.com | ad.doubleclick.net | googlecode.com |
| gstatic.com | googleadservices.com | widgets.digg.com |
Toutefois, pour des problématiques de coût, et pour bénéficier des avantages propres aux CDN, vous serez parfois tentés de conserver ces dépendances. Si tel est votre choix, assurez-vous au minimum que les ressources récupérées n’ont pas été altérées. Pour ce faire, vous pouvez utiliser le contrôle d’intégrité SRI. Son fonctionnement est simple : il suffit d’ajouter un attribut “integrity” à vos balises <script> et <link> qui chargent (en synchrone ou non) des ressources provenant de tierces parties. Cet attribut a pour valeur une empreinte, correspondant au SHA du contenu souhaité, encodé en base64. Le navigateur comparera alors ce SHA avec celui du contenu récupéré, pour déterminer si la ressource correspond bien à celle attendue.
Plusieurs outils vous aideront dans la création de ce SHA. En ligne de commande, vous pouvez utiliser openssl. Exemple sur Linux :
$ curl -s
https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js | openssl dgst -sha512 -binary | openssl base64 –A
2e8qq0ETcfWRI4HJBzQiA3UoyFk6tbNyG+qSaIBZLyW9Xf3sWZHN/lxe9fTh1U45DpPf07yj94KsUHHWe4Yk1A==
Des outils en ligne existent par ailleurs, tels que srihash.org ou report-uri.io.
À noter que certains CDN, comme celui de Bootstrap, fournissent déjà le SHA à intégrer.
Tout comme pour la détection de SPOF, la pénalisation au sein de nos audits se limite aux domaines explicités ci-dessus. N’hésitez pas, cependant, à étendre ce principe selon les tierces parties utilisées par votre site !
Public Key Pinning (HPKP)
L’en-tête HTTP Public-Key-Pins permet de se prémunir de certaines attaques de type Man-In-The-Middle, en indiquant lors de la première visite d’un internaute quelles clés publiques cryptographiques sont tolérées par le serveur. Le navigateur web conserve alors la liste des clés. Lors d’une seconde visite de l’internaute, le navigateur sera en mesure de comparer la clé publique utilisée pour la connexion SSL, avec celles stockées via l’en-tête HPKP lors de la première visite. Si la clé publique est inconnue, le navigateur présente un message d’avertissement et bloque l’accès au site.
Si l’apport de cet en-tête est indéniable, il doit être utilisé avec une extrême précaution. En effet, au même titre que l’en-tête Content Security Policy, une mauvaise configuration pourrait mener à rendre votre site inaccessible. C’est pourquoi cette bonne pratique se positionne comme une “amélioration possible” dans nos audits. La pénalité qui y est associée reste très limitée.
Toute page web utilisant le protocole HTTPS est désormais soumise à ce test dans nos audits.
Blocage des document.write sur les faibles débits
Il y a quelques mois, Google annonçait que sous certaines conditions, son navigateur Chrome s’autoriserait à ne pas exécuter des scripts injectés via l’instruction document.write (rappelons que cette syntaxe est à éviter au maximum). Dans ce cadre, nous conservons notre détection de ce type de contenus, et nous accentuons fortement la pénalisation dès lors que l’analyse est lancée avec des conditions réseau de faible qualité (bande passante descendante inférieure à 1 Mo).
Pénalisation des pages non référencées
Notre outil d’audit dispose d’une catégorie entière de bonnes pratiques dédiées à l’optimisation du référencement d’une page web. Jusqu’à présent, aucune pénalité n’était infligée aux pages déclarant une balise <meta> dans l’objectif de ne pas être indexées par les moteurs de recherche. Exemple :
<meta name="robots" content="noindex">
Désormais, ce type de contenu engendrera une forte baisse de votre score, vous permettant de détecter le problème au plus vite. Si vous souhaitez ne pas voir cette pénalisation (sur une phase de recette par exemple), nous vous recommandons de passer par l’utilisation du fichier robots.txt.
Suppression de bonnes pratiques dépréciées
Jusqu’à présent, nos audits intégraient des bonnes pratiques dédiées à la compatibilité Internet Explorer <= 8. Le taux d’utilisation de ces navigateurs dépréciés étant désormais anecdotique, les recommandations suivantes disparaissent :
- Éviter les filtres alpha lors du chargement des images
- Ne pas indiquer le jeu de caractères dans une balise meta
- Ne pas utiliser les expressions CSS
- jQuery : Placer le sélecteur le plus spécifique à droite
Pour rappel, toutes ces modifications seront mises en place le jeudi 2 février 2017. N’hésitez pas à nous contacter par email d’ici là pour tout complément d’information, et encore un grand merci à nos utilisateurs, qui par leurs retours, nous permettent d’améliorer chaque jour un peu plus notre référentiel de bonnes pratiques !