Je suis tombé récemment sur le projet github nommé front-end checklist créé par David Dias. Ce projet récapitule tout ce qu’on trouve en terme de bonnes pratiques lors d’une mise en production. Je me suis donc dit que ca pourrait être pas mal d’en faire une version française. La checklist front-end française est donc désormais disponible ici.
Si vous respectez tout ça, et que vous intégrez aussi les bonnes pratiques de développement PSR-2, alors félicitations, vous êtes un as du développement 🙂
Pour vous donner un aperçu de cette liste, et aussi profiter un peu du contenu pour le SEO de mon site personnel, la voilà:
Table des matières
Comment l’utiliser ?
Tous les élements de la Front-End Checklist sont requis dans la majorité de vos projets, mais certains peuvent être omis ou ne sont pas essentiels (par exemple, dans le cas d’une application d’administration , vous n’avez pas besoin de flux RSS). Nous avons choisi d’utiliser 3 niveaux de flexibilité:
- signifie que l’élement est recommandé mais peut être omis dans certaines situations.
- signifie que l’élement est hautement recommandé et peut éventuellement être omis dans certains cas particuliers . Certains élements s’ils sont omis peuvent avoir des mauvais effets secondaires en terme de performance ou de référencement (SEO).
- signifie que l’élement est indispensable. Vous pouvez provoquer des dysfonctionnements dans votre page, ou avoir des problèmes d’accessibilité, voir de SEO. La priorité des tests doit d’abord s’assurer de ces éléments en premier.
Plusieurs resources possèdent un emoticon pour vous aider à comprendre quel type de contenu il s’agit :
- : documentation ou article
- : outil online / outil de test
- : media ou contenu vidéo
Head
Notes: Vous pouvez trouver une liste de toute les balises qui peuvent être trouvées dans la section
<head>
d’un document HTML.
Meta tag
<!-- Doctype HTML5 -->
<!doctype html>
Les prochains 3 meta tags (Charset, X-UA Compatible and Viewport) doivent venir en premier dans le head.
<!-- Set character encoding for the document -->
<meta charset="utf-8">
<!-- Instruct Internet Explorer to use its latest rendering engine -->
<meta http-equiv="x-ua-compatible" content="ie=edge">
<!-- Viewport for responsive web design -->
<meta name="viewport" content="width=device-width, initial-scale=1">
- Title: Un titre est utilisé sur chaque page (SEO: Google calcule la largeur des pixels de chaque caractères utilisés dans le titre, et coupe entre 472 et 482 pixels. La limite moyenne de caractères se situe autour des 55).
<!-- Document Title -->
<title>Page Title less than 55 characters</title>
- Description: Une meta description est fournie, elle est unique et ne contient pas plus de 150 caractères.
<!-- Meta Description -->
<meta name="description" content="Description of the page less than 150 characters">
- Favicons: Chaque favicon a été créé et s’affiche correctement. Si vous avez un
favicon.ico
, posez le à la racine de votre site. Normalement vous n’avez pas besoin d’utiliser de balise. Cependant, cela reste une bonne pratique de le relier comme dans l’exemple ci-dessous. Aujourd’hui, Le PNG est recommandé en remplacement du format.ico
(dimensions: 32x32px).
<!-- Standard favicon -->
<link rel="icon" type="image/x-icon" href="https://example.com/favicon.ico">
<!-- Recommended favicon format -->
<link rel="icon" type="image/png" href="https://example.com/favicon.png">
- Apple Touch Icon: Les favicons Apple touch apple-mobile-web-app-capable sont présents. (Créer vos icones Apple avec au pire des dimensions de 200x200px pour supporter toutes les dimensions dont vous aurez besoin)
<!-- Apple Touch Icon -->
<link rel="apple-touch-icon" href="/custom-icon.png">
<!-- Microsoft Tiles -->
<meta name="msapplication-config" content="browserconfig.xml" />
Le balisage xml minimum requis pour le balisage du fichier browserconfig.xml doit être:
<?xml version="1.0" encoding="utf-8"?>
<browserconfig>
<msapplication>
<tile>
<square70x70logo src="small.png"/>
<square150x150logo src="medium.png"/>
<wide310x150logo src="wide.png"/>
<square310x310logo src="large.png"/>
</tile>
</msapplication>
</browserconfig>
<!-- Helps prevent duplicate content issues -->
<link rel="canonical" href="http://example.com/2017/09/a-new-article-to-red.html">
HTML tags
- Language attribute: L’attribut
lang
de votre site est spécifié et indique le langage de la page courante.
<html lang="en">
- L’attribut direction : Le sens de lecture est specifié dans le tag html (Il peut être indiqué dans un autre tag HTML).
<html dir="rtl">
- Alternate language: Le tag language de votre site est specifié et est en relation avec le language de la page courante.
<link rel="alternate" href="https://es.example.com/" hreflang="es">
- Flux RSS: Si votre projet est un blog ou possède des articles, un flux RSS est fourni.
- Inline critical CSS: Les CSS des contenus qui doivent être immédiatement visibles pendant le chargement (« au dessus de la ligne de flottaison ») sont appelés « CSS critiques ». Ils sont inclus avant le CSS principal et entre les balises
<style></style>
dans une seule ligne (en étant minifié).
- Critical by Addy Osmani on GitHub automatise cela
- Ordre des CSS : Tous les fichiers CSS sont chargés avant n’importe quel fichier JavaScript dans la section
<head>
. (Parfois certains fichiers JS sont chargés en asynchrone en haut de page, et font donc exception à la règle).
Social meta
Facebook OG et Twitter Cards sont pour tous les sites, hautement recommandés. Les autres tags de média sociaux peuvent être utiles si vous ciblez une audience particulère et que vous voulez vous assurer un affichage particulier.
- Facebook Open Graph: Tous les Open Graph Facebook (OG) sont testés et aucun ne manque ou contient de fausses informations. Les images doivent être au minimum de 600 x 315 pixels, mais 1200 x 630 pixels est recommandé.
Notes: L’utilisation des balises
og:image:width
etog:image:height
qui spécifient les dimensions des images au crawler permettent le rendu des images immédiatement sans avoir besoin de les redimensionner avec un système asynchrone.
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/page.html">
<meta property="og:title" content="Content Title">
<meta property="og:image" content="https://example.com/image.jpg">
<meta property="og:description" content="Description Here">
<meta property="og:site_name" content="Site Name">
<meta property="og:locale" content="en_US">
<!-- Next tags are optional but recommended -->
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
- Guide du partage pour les Webmasters
- Bonnes pratiques du partage
- Tester votre page avec Facebook OG testing
<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@site_account">
<meta name="twitter:creator" content="@individual_account">
<meta name="twitter:url" content="https://example.com/page.html">
<meta name="twitter:title" content="Content Title">
<meta name="twitter:description" content="Content description less than 200 characters">
<meta name="twitter:image" content="https://example.com/image.jpg">
- Débutez avec les cartes — Twitter Developers
- Tester votre page avec Twitter card validator
HTML
Bonnes pratiques
- HTML5 Semantic Elements: Les élements sémantiques HTML5 ont une utilisation spécifique (header, section, footer, main…).
- Error pages: Les pages d’erreurs 404 et 5xx existent. Rappelez vous que les pages d’erreurs 5xx ont besoin de CSS intégrés (pas d’appel externe au serveur courant).
- Noopener: Dans le cas ou vous utilisez des liens externes avec
target="_blank"
, votre lien devrait avoir l’attributrel="noopener"
pour prévenir du tab nabbing (piratage par onglet). Si vous devez supporter les anciennes versions de Firefox, utiliser alorsrel="noopener noreferrer"
.
HTML testing
- W3C compliant: Toutes les pages doivent avoir passé la validation W3C pour identifier de possibles problèmes dans le code HTML.
- HTML Lint: Utiliser ces outils pour vous aider à analyser des problèmes que vous auriez dans votre code HTML.
- Adblockers test: Votre site doit affiché un contenu correct malgré la présence d’adblocker (Vous pouvez fournir un message pour encourager les gens à les désactiver).
Webfonts
Notes: Utiliser les webfonts peut causer des problèmes de textes invisibles avec Flash – envisager d’avoir des polices de secours et / ou d’utiliser des chargeurs webfont pour contrôler le comportement.
- Webfont size: La taille des Webfonts ne doit pas excéder 2 MB (toutes les variantes incluses).
- Webfont loader: Controler le comportement du chargement avec un loader de webfont.
CSS
Notes: Regardez les guidelines CSS et les Guidelines Sass fournis par de nombreux développeurs Front-End. Si vous avez des doutes sur des propriétés CSS, vous pouvez visiter la Reference CSS. Il y a aussi ce court Guide pour la cohérence.
- Responsive Web Design: Le site utilise un design responsive.
- CSS Print: Une feuille d’impression CSS est incluse et permet une impression correcte sur chacune des pages.
- Preprocessors: L’utilisation d’un preprocessor CSS (Sass est conseillée).
- Unique ID: Si des IDs sont utilisés, ils sont uniques sur chaque page.
- Reset CSS: Un CSS reset (reset, normalize ou reboot) est utilisé et mis à jour. (Si vous utiliser un Framework CSS comme Bootstrap ou Foundation, une feuille Normalize est déjà incluse.)
- JS prefix: Toutes les classes (ou les id- utilisés dans les fichiers JavaScript) commencent par js- et ne sont pas stylés dans les fichiers CSS.
<div id="js-slider" class="my-slider">
<!-- Or -->
<div id="id-used-by-cms" class="js-slider my-slider">
- Embedded ou inline CSS: Tous les CSS embarqués dans des balises
<style>
ou utilisant le CSS en style: le sont uniquement pour de bonnes raisons (e.g. background-image pour des sliders, ou des CSS critiques). - Vendor prefixes: les préfixes des CSS sont utilisés en prenant soin de la compatibilité des navigateurs.
Performance
- Concatenation: Les fichiers CSS sont concatenés dans un fichier unique. (Pas besoin pour HTTP/2)
- Minification: Les fichiers CSS sont minifiés.
- Non-blocking: Les fichiers CSS ne doivent pas être bloquants pour que le DOM puisse se charger rapidement.
CSS testing
- Responsive web design: Toutes les pages ont étés testées sur les résolutions suivantes: 320px, 768px, 1024px (peut être plus / en fonction de votre analyse).
- CSS Validator: Le CSS a été testé et il n’y a aucune erreur.
- Desktop Browsers: Toutes les pages ont étés testées sur différents navigateurs (Safari, Firefox, Chrome, Internet Explorer, EDGE…).
- Mobile Browsers: Toutes les pages ont étés testées sur différents navigateurs mobiles (Native browser, Chrome, Safari…).
- OS: Toutes les pages ont étés testées sur différents OS (Windows, Android, iOS, Mac…).
- Pixel perfect: Les pages collent parfaitement au pixel près aux maquettes. Cela dépend de la qualité qu’on vous a fourni. Vous ne pourrez pas forcément avoir 100% en précision, mais cela doit ressembler le plus possible.
- Reading direction: Les pages ont étés testées dans les 2 sens de lecture si les 2 sont supportés (gauche à droite et droite à gauche).
Images
Notes: Pour une complète compréhension de l’optimisation des images, lisez ce livre gratuit Essential Image Optimization d’Addy Osmani.
Bonnes practiques
- Optimisation: Toutes les images sont optimisées pour un rendu sur navigateur. Le format WebP peut être utilisé pour des pages critiques (comme la page d’accueil).
- Imagemin
- Utiliser ImageOptim pour optimiser gratuitement vos images.
- Utiliser Kraken.io une alternativeincroyable pour des optimisations sur des png et des jpg . Jusqu’à 1 Mb en version gratuite.
- Picture/Srcset: Vous pouvez utiliser des images/srcset pour fournir l’image la plus appropriée à la résolution de l’utilisateur.
- Retina: Vous fournissez des layout d’images 2x or 3x, pour l’affichage sur un support retina.
- Sprite: Les petites images sont dans un seul fichier sprite (dans le cas d’icones, elles peuvent être dans un sprite d’image SVG).
- Width and Height: Ajouter les attributs
width
etheight
sur la balise<img>
dans le rendu final si la taille est connue (le css de dimensionnement peut alors être omis). - Text alternatif: Toute les balises
<img>
ont un texte alternatif qui décrit l’image visuellement.
- Lazy loading: Les images sont chargées au fur et à mesure (Un noscript fallback est toujours fourni).
JavaScript
Bonnes pratiques
- JavaScript Inline: Vous n’avez aucun code javascript inline (contenu dans votre code HTML).
- Concatenation: Les fichiers JavaScript sont concatenés.
- Minification: Les fichiers JavaScript sont minifiés (vous pouvez ajouiter le suffixe
.min
).
- Securité JavaScript:
- Non-blocking: Les fichiers JavaScript sont chargés en asynchrone avec
async
ou avec l’utilisation de l’attributdefer
.
- Modernizr: Si vous avez besoin de fonctionnalités spécifiques, vous pouvez utiliser un Modernizr personnalisé pour ajouter les classes au tag
<html>
.
Tester le JavaScript
- ESLint: Pas d’erreurs détéctés par ESLint (basé sur votre configuration ou sur les règles standards).
Securité
Scan et vérification de votre site web
Bonnes pratiques
- Cross Site Request Forgery (CSRF): Vous êtes sure que vos requêtes faites coté serveur sont légitimes et proviennent de votre site / app pour éviter les attaques CSRF.
- Content Type Options Empêcher Google Chrome et Internet Explorer d’essayer de mime-sniff le type de contenu d’une réponse différente de celle déclarée par le serveur.
- Content Security Policy Definir comment le contenu est chargé sur votre site et d’ou il est autorisé à être chargé. Cela peut aussi vous permettre de vous protéger des attaques par clickjacking.
Performance
Bonnes pratiques
- Lazy loading: Images, scripts et CSS doivent être chargé en lazy loading pour améliorer le temps de réponse (Voir les details dans une autre section).
- Cookie size: Si vous utilisez des cookies, assurez vous qu’ils n’excèdent pas 4096 bytes et qu’il n’y en ai pas plus de 20 pour votre nom de domaine.
- Composants tiers: Les éléments tiers comme les iframes ou les composants basés sur des JS externes (comme les boutons de partage) sont remplacés par des composants statiques quand c’est possible, pour limiter les appels aux APIs externes et préservez l’activité de vos visiteurs confidentielle.
Préparer les requêtes à venir
- DNS resolution: DNS est un service tiers qui peut résoudre en avance les prochaines requêtes grâce à l’utilisation de
dns-prefetch
.
<link rel="dns-prefetch" href="https://example.com">
- Preconnection: DNS lookup, TCP handshake et la neéociation TLS avec services permettent de gagner du temps en utilisant
preconnect
.
<link rel="preconnect" href="https://example.com">
- Prefetching: Resources that will be needed soon (e.g. lazy loaded images) are requested in advance during idle time using
prefetch
.
<link rel="prefetch" href="image.png">
- Preloading: Les resources nécessaires à la page courante (ex: scripts placés en bas du tag
<body>
) sont chargés en avance avecpreload
.
<link rel="preload" href="app.js">
Tester la Performance
- Google PageSpeed: Toutes vos pages ont étés testées (pas seulement la page d’accueil) et ont un score au pire de 90/100.
Accessibilité
Notes: Vous pouvez regader la playlist A11ycasts with Rob Dodson
Bonnes pratiques
- Progressive enhancement: Les fonctionnalités importantes comme la navigation et la recherche doivent pouvoir fonctionner avec le JavaScript désactivé.
Headings
- H1: Toutes les pages ont un H1 qui n’est pas le titre du site.
- Headings: Les balises Hn doivent être correctement utilisées et dans le bon ordre (H1 à H6).
Repères
- Role banner:
<header>
a lerole="banner"
. - Role navigation:
<nav>
a lerole="navigation"
. - Role main:
<main>
a lerole="main"
.
Sémantique
- Specific HTML5 input types are used: C’est assez important pour les périphériques mobiles de personnaliser les keypads et autres widgets pour améliorer l’ergonomie.
Formulaire
- Label: Un label est associé avec chaque élement de formulaire. Dans le cas ou un label ne peut être affiché, utiliser
aria-label
à la place.
Tester l’accessibilité
- Test des standards d’accessibilité: Utiliser l’outil WAVE tool pour vous assurer de respecter les standards d’accessibilité.
- Navigation par clavier: Tester votre site en utilisant uniquement votre clavier dans un ordre prévisible. Tous les élements doivent être accessibles et utilisables.
- Screen-reader: Toutes les pages ont étés testées dans un outil de lecture d’écran (VoiceOver, ChromeVox, NVDA or Lynx).
- Focus style: Si le focus est désactivé, il est remplacé par un état visible en CSS.
SEO
- Google Analytics: Google Analytics est installé et correctement configuré.
- Headings logic: Le texte d’entête aide à comprendre le contenu de la page courante.
- sitemap.xml: Un sitemap.xml existe et a été envoyé à Google Search Console (historiquement Google Webmaster Tools).
- robots.txt: Le robots.txt ne bloque pas l’indexation des pages.
- Tester votre robots.txt avec Google Robots Testing Tool
- Structured Data: Les pages utilisant une structure de données ont étés testés et n’ont pas d’erreurs. Les données structurées aide les crawlers à comprendre le contenu de votre page.
- Introduction aux données structurées – Search – Google Developers
- Tester votre page avec Structured Data Testing Tool
- Liste complete du vocabulaire utilisé dans les données structurées. Schema.org Full Heirarchy
- Sitemap HTML: Un sitemap HTML est fourni et accessible via un lien dans le pied de pagede votre site.
Et maintenant il est possible d’utiliser la NOUVELLE application Front-End Checklist
! C’est dynamique et peut générer manuellement des rapports de tests! ➜ http://frontendchecklist.com
Salut David.
Merci c’est cool 🙂
Sinon, je t’ai fais la modif sur ton nom dans l’article. J’ai essayé de te répondre par mail au commentaire de Korben, mais je me suis pris 3 retours. J’avais pas vu qu’il s’agissait d’un no reply.
Qq petites questions en compléments, si tu veux bien.
Tu es francais ? Tu habites pas vers Nantes à tout hasard ? 🙂
Et sinon, as tu touché aux servicesworkers ? Je commence tout juste, et je me dis que comme ca peut gérer un mode déconnecté (si perte de connexion), il pourrait être assez intéressant d’en mettre sur tous les sites et donc au final d’intégrer ça à la checklist. Enfin, quand tous les navigateurs l’auront intégrés…
Cela fait à présent quelques semaines que j’utilise un nouvel outil, et il marche parfaitement ! En plus, j’adore le design simple et épuré. Du coup je me suis dit, pourquoi pas le partager avec vous également.
Voici l’outil en question : https://www.websiteplanet.com/fr/webtools/robots-txt/
Je suis sûre que vos utilisateurs apprécieront cet outil autant que moi, si vous décidiez de le partager avec eux : )
En espérant avoir été pertinente,
Bien cordialement,
Anna.