Générateur de sites web

IMPORTANT

Ce site web est un prototype en cours de construction, destiné à valider le code source généré par le logiciel Thot (version 0.0.1), projet personnel lui-même en phase de développement. Son contenu ainsi que son graphisme sont donc expérimentaux et n'ont de ce fait aucune valeur commerciale et/ou juridique. Pour obtenir plus d'information sur cet environnement, vous pouvez vous reporter à la page intitulée Questions fréquentes. Une page Facebook consacrée au projet peut par ailleurs être consultée. Un compte Twitter fournit des informations sur l'avancement du projet.

Concevoir un générateur de sites web performant

Par sepecat - publié le

Le générateur, ce mal aimé…

Lorsqu'on évoque l'idée de mettre en place un générateur de sites web, la majorité des interlocuteurs n'y voit aucun intérêt, reprochant à ce type d'outil de se révèler trop rigide, ne fournissant la plupart du temps qu'un code source mal structuré, non conforme et peu voire pas du tout performant.

Force est de constater que ces arguments ne sont pas toujours infondés et qu'il existe bel et bien des générateurs de sites web dont le niveau de qualité laisse à désirer, soit parce qu'ils reposent sur un Wysiwyg (What You See Is What You Get) non maîtrisé, soit parce qu'ils utilisent des gabarits HTML et CSS conçus manuellement par l'utilisateur, ce qui les rend de facto dépendants du niveau de compétence en amont.

Un Wysiwyg mal maîtrisé

Pour séduisant qu'il soit sur le fond, le concept de Wysiwyg s'avère in fine trop souvent en décalage par rapport aux attentes lorsqu'on analyse le code source effectivement produit.

Divers outils, parmi lesquels Dreamweaver® et Blue Griffon®, se positionnent sur ce créneau, mais les pages HTM qu'ils génèrent ne présentent pas, à mon sens, un niveau de qualité / conformité suffisant pour les retenir en l'état. Un examen attentif du code source révèle par exemple bien souvent des balises HTML vides, ou des sélecteurs CSS trop nombreux et redondants.

Certains outils en ligne, tels que Wix®, construisent des sites web intégralement basés sur JavaScript ce qui les rend de facto impropres à s'afficher correctement sur les navigateurs où ce langage de script est, justement, désactivé, sans parler de la lourdeur des pages HTML en matière de chargement.

Vous ne maîtrisez pas, par ailleurs, le niveau intrusif des sites ainsi produits. À titre d'exemple, un site web réalisé via la plateforme Wix à partir d'un modèle standard et mis en ligne en suivant c'est in fine une page HTML partiellement affichée si JavaScript est désactivé mais, surtout, une vingtaine de scripts bloqués si vous avez installé sur votre navigateur l'extension privacy badger protégeant votre vie privée.

Ce mode de génération étant totalement à la main du générateur Wix, vous ne pouvez donc en aucune manière modifier la façon dont vos pages web seront produites et quels principes d'architecture elles respecteront ou non.

S'ils permettent effectivement de générer en ligne et de façon visuelle votre site web, ces outils ont pour eux l'avantage de la facilité et de la simplicité pour qui ne connaît pas l'environnement web et le développement. Par contre, le code source généré n'atteint pas le niveau de qualité que je souhaite obtenir pour un produit apte à être mis en ligne.

Le recours aux gabarits

D'autres types de générateurs de sites web existent, ne reposant pas sur le concept de Wysiwig. Ceux-ci prennent en entrée un certain nombre de fichiers rédigés manuellement et assemblés ensuite pour aboutir à un site web complet pouvant être mis en production.

À la différence des outils de type Wix, le concepteur de site web ne dispose ici d'aucune interface lui permettant d'assembler visuellement les différents blocs constituant une page HTML. Il lui appartient donc de rédiger intégralement le code source (HTML et CSS) devant intervenir dans la structure du site web, ce qui suppose qu'il ait atteint un niveau de compétence suffisant en la matière.

Ces outils facilitent toutefois la tâche dans la mesure où ils mettent en place un processus d'agrégation des fichiers et reposent, le plus souvent, sur un système de gabarits permettant de factoriser les parties communes aux différentes pages (ex. entêtes et pieds de page, menus, etc.).

On trouve dans cette catégorie de générateurs des outils tels que Jekyll, Gatsby et consorts, majoritairement orientés vers la production de sites web statiques. Une autre catégorie dite CMS (Content Management System) permet de recourir à des gabarit tout en générant des sites web dynamiques, via un module de conception offrant au développeur ou à l'utilisateur averti une approche Wysiwyg (ex. module Gutemberg sous WordPress).

Bien qu'ils commencent à gagner en notoriété et trouvent un public de plus en plus large ces générateurs statiques ont, à mon avis, pour principal inconvénient de reposer sur des fichiers requérant de la part des concepteurs web de maîtriser la façon de les concevoir et de les intégrer. Les CMS gomment une partie de ce besoin, mais nécessitent souvent, à un moment ou à un autre, de mettre les mains dans le cambouis et de se plonger dans le langage HTML / CSS, avec en plus une maîtrise du langage PHP qui n'est pas intuitive. Il est donc indispensable de savoir sélectionner et mettre en place une balise ou un attribut HTML, rédiger des règles CSS et les lier aux pages, installer éventuellement des scripts ou intégrer des bibliothèques existantes. Bien qu'il soit plus permissif que la norme XHTML, le langage HTML5 requiert tout de même de la part du développeur un niveau de connaissance non négligeable.

Tout ceci nécessite donc d'avoir, par soi même ou dans son équipe, des compétences éprouvées en langage HTML ou autres, ce qui induit une dépendance forte envers ceux qui ont conçu les sites web en question puisque tout départ d'un intervenant au fait du projet est susceptible d'entraîner une perte de savoir faire. Les plus optimistes se rassureront en disant qu'il restera la documentation technique établie par les partants… mais nous savons tous ce qu'il en est de la documentation au sein des équipes. Ceci dit on peut toujours y croire.

Un autre problème bien connu des développeurs web réside dans la différence de traitement d'un même code source existant entre les différents navigateurs web présents sur le marché, due à l'incompatibilité de certains d'entre eux (Internet Explorer notamment) par rapport aux spécifications établies par le W3C (World Wide Web Consortium). Connaître les contournements permettant de faire fonctionner une page HTML de façon identique sur des environnement hétérogènes requiert, là aussi, un niveau de compétence qui ne s'improvise pas. Tout départ d'un développeur maîtrisant cet aspect du développement web est donc susceptible de fragiliser un existant, les gabarits étant élaborés manuellement. Même s'il est d'usage de pratiquer par copier / coller pour tout nouveau projet… on atteint vite les limites de l'exercice.

Un outil taillé sur mesure

Si les générateurs existants, qu'ils soient Wysiwyg ou non, ne conviennent pas à mes besoins en matière de code HTML, comment dès lors produire des sites web dont la structure réponde au niveau de qualité requis en matière de sécurité, conformité et performance ?

Tout simplement en adoptant une approche proactive… c'est à dire en analysant et en développant soi-même un générateur apte à couvrir les besoins en question tout en satisfaisant par ailleurs les critères d'optimisation pour les moteurs de recherche (SEO - Search Engine Optimization) dont les pages de résultats sont omniprésentes sur le web d'aujoutd'hui.

Qu'il s'agisse d'optimiser une URL (Uniform Resource Locator), ne commettre aucune erreur de langages ou d'attributs, le développement de documents et fichiers HTML ne s'improvise plus et il est nécessaire d'acquérir puis maintenir à jour une somme importante de connaissances qui, prises individuellement ne se révèlent pas toujours complexes mais doivent cohabiter en respectant des règles de plus en plus strictes (ex. Content Security Policy).

Concernant la mise en forme des pages HTML, celle-ci doit tenir de plus en plus compte de la diversité des périphériques sur lesquels ces pages sont susceptibles de s'afficher. Il n'est ainsi plus envisageable à ce jour pour un développeur de faire l'impasse sur la réalisation de sites web dits « responsive » c'est à dire aptes à s'afficher de façon correcte sur des terminaux toujours plus différents tout en reposant sur un code HTML / CSS unique parfaitement reconnu par un navigateur web.

Un fichier HTML, une feuille de style CSS ou un script se doivent donc d'être étudiés dans leurs moindres détails avec un niveau de qualité constant, c'est à dire concerner la totalité des pages composant un site web. Pour des sites ne comportant qu'un nombre limité de ressources, cette tâche reste abordable manuellement mais, dès que la taille dudit site augmente, l'interdépendance entre ces différentes ressources devient de plus en plus difficile à gérer.

Les composants à la rescousse

Un document HTML n'étant, stricto sensu, qu'un assemblage de blocs devant être analysés puis affichés par un navigateur web, la notion de composants dédiés au traitement de chacun de ces blocs s'impose d'elle même.

Par ailleurs, l'un des objectifs fixés pour ce nouveau générateur consistait à n'avoir à aucun moment besoin de saisir du code HTML ou CSS. Toutes les règles applicables aux balises et attributs HTML ainsi qu'aux sélecteurs CSS doivent avoir été analysées puis intégrées dans le générateur, la tâche du développeur du site web consitant dès lors à assembler les briques logiques que représentent les composants.

Chaque balise HTML possède ses propres contraintes et spécificités. Par exemple, la balise <article> provoque un avertissement lors de sa soumission au valideur W3C dès lors que son contenu n'affiche aucun titre de niveau H1 à H6. Le composant prenant en charge la sérialisation d'un article sur une page HTML va donc vérifier la structure de cet article et remplacer la balise <article> par <div> si aucun titre n'a été détecté. Ultérieurement le contenu peut changer lors d'une révision de l'article et la structure de la page HTML sera adaptée en conséquence.

Lors de la sérialisation, ces composants vont effectuer un certain nombre de contrôles et s'assurer que le code source ainsi produit, la mise en page et d'autres contraintes correspondent effectivement au niveau de qualité souhaité. L'interdépendance entre les différentes ressources (documents HTML, feuilles de style CSS, images, polices de caractères, etc.) va par ailleurs être analysée et validée. Toute anomalie constatée durant ce processus de sérialisation aura pour effet de l'interrompre purement et simplement, garantissant ainsi qu'un site web mis en ligne sera pleinement conforme.

Cachez ce JavaScript que je ne saurais voir

Le deuxième objectif assigné au générateur de sites web Thot consiste à limiter au minimum, voire réduire à néant, l'utilisation de JavaScript pour l'affichage des blocs sur une page HTML.

Dans la quasi totalité des cas de figure, ce langage de script n'est absolument pas indispensable à la construction et la mise en forme d'une page HTML, même si certains concepteurs se lâchent complètement et nous pondent des sites web dont le moindre bloc se met à gigoter à l'écran avant de se positionner. Faire reposer l'affichage d'une page web sur la présence de JavaScript est un anachronisme et non une nécessité.

Rien n'est plus décrédibilisant que de voir une page blanche s'afficher lorsqu'on visite un site web, simplement parce que l'exécution de JavaScript a été désactivée sur son navigateur…

Cette question est récurrente sur les forums et il est fréquent de croiser des intervenants déclarant de façon péremptoire qu'un utilisateur ayant désactivé JavaScript sur son navigateur est a minima un fossile n'ayant rien compris au web d'aujourd'hui.

Désolé de casser l'ambiance mais je considère a contrario que le fait de désactiver le langage de script en question est un gage de santé mentale. On l'oublie trop souvent en effet mais une page HTML comportant des scripts verra ces derniers s'exécuter dès le chargement, sans aucune action de la part de l'utilisateur. La plupart du temps cette exécution n'aura aucune conséquence fâcheuse pour notre pauvre utilisateur, mais qu'en est-il si un script se met à crypter de la monnaie en tâche de fond, ou s'il lui prend l'envie de se connecter à un site web externe peu recommandable ? Il y a fort à parier que lorsque les effets indésirables seront perçus par l'utilisateur ce sera un tantinet trop tard.

On rappellera par ailleurs pour mémoire que tous les outils de traçage sans exception sur le web reposent sur des scripts mis en place au niveau de chaque page HTML. Les Google Analytics, Facebook et consorts voient leur action fortement limitée si JavaScript est désactivé, même s'ils peuvent utiliser d'autres techniques basées sur la présence de cookies (que l'on peut là aussi désactiver).

Sur ces bases, chaque composant développé dans le cadre du générateur de sites web Thot l'est en minimisant au maximum le recours au langage de script et en privilégiant les solutions simples sans effet de bord préjudiciable pour le visiteur d'une page HTML appartenant au site web.

Et maintenant ?

Débutée il y a plus d'un an, la phase de développement du générateur de sites web Thot se poursuit. D'ores et déjà plusieurs des objectifs assignés lors de son lancement sont atteints, même s'il reste toujours des fonctionnalités perfectibles.

L'un des points les plus satisfaisants concerne la sécurité puisque le site WEB prototype que vous êtes en train de visiter, entièrement généré via Thot (version 1.0) obtient systématiquement la note maximale A+ sur les sites de test en ligne tels que Mozilla Observatory, Security Headers et WebPage Test.

Le second objectif assigné au projet était de produire des sites web totalement conformes aux spécifications du W3C en ce qui concerne HTML et CSS. C'est aujourd'hui le cas et l'ensemble des pages ou feuilles de styles produites ne générent aucune erreur ou avertissement lors de leur soumission aux outils de validation.

Enfin, le troisième objectif assigné au générateur concerne la performance et l'utilisation a minima de la bande passante. Il est lui aussi pleinement atteint, comme le confirment les tests effectués via Page Speed Insights de Google, WebPage Test ou encore GTMetrix.

La phase de développement n'en est pas pour autant terminée et il reste encore des fonctionnalités à mettre en place ou améliorer, notamment en matière d'optimisation pour les moteurs de recherche et l'apparition dans les pages de résultats.

Ce travail d'analyse et développement se poursuit donc…

Image bouton cliquable permettant le retour en haut de page