Traduction française de l’article This Page is Designed to Last de Jeff Huang.
La fin de l’année est l’occasion de faire le ménage et de se préparer au nouveau semestre. Je me suis retrouvé à nettoyer d’anciens marque-pages - oui, des marque-pages : cette fonctionnalité des navigateurs autrefois bien-aimée qui semble avoir perdu la bataille contre la complétion automatique de la barre d’adresse. Mais cet acte de rangement nostalgique me désespérait.
Marque-page après marque-page se suivaient les liens morts. Qu’est-ce qui a disparu : des écrits uniques sur kuro5hin sur la culture technologique ; une collection d’énigmes mathématiques et une discussion associée d’universitaires que mon père m’a présentés ; les didacticiels d’ingénierie inverse de Woodman de mes années de lycée, où j’ai goûté pour la première fois le sentiment de contrôle sur les logiciels ; même mon marque-page le plus récent, une série de messages sur Google+ exposant la non-conformité des chargeurs usb-c avec la spécification ; tous ont disparu.
C’est plus qu’une simple usure des liens, c’est la complexité croissante de maintenir en vie le contenu indépendant sur le Web, conduisant à une dépendance aux plateformes et aux formats de publication éprouvés par le temps (blogs, flux, tweets).
Bien sûr, j’ai aussi contribué au problème. Un article que j’ai publié il y a 7 ans contient un résumé qui comprend un lien de démonstration, qui a été repris par une page de spam avec une image de citrouille dessus. Une partie de cette disparition était la paresse pour éviter d’avoir à renouveler et à maintenir une application Web fonctionnelle année après année.
J’ai recommandé à mes étudiants de piblier dess sites Web surs Heroku et des portfolios sur Wix. Pourtant, chaque plate-forme avec un contenu irremplaçable meurt un jour. Geocities, LiveJournal, what.cd, désormais Yahoo Groups. Un jour, Medium, Twitter et même des services d’hébergement comme GitHub Pages seront pillés puis jetés lorsqu’ils ne pourront plus se développer ou ne trouveront pas de modèle commercial fonctionnel.
Le problème est multiple. Premièrement, le contenu demande des efforts pour être maintenu. Le contenu peut nécessiter une mise à jour pour rester pertinent et devra éventuellement être réhébergé. Beaucoup de contenu, ce qui était autrefois la grande majorité du contenu, a été mis en place par des particuliers. Mais les individus (peut-être vous ?) perdent tout intérêt, alors un jour peut-être que vous ne voudrez plus vous occuper de la migration d’un site Web vers un nouveau fournisseur d’hébergement.
Deuxièmement, un ensemble croissant de bibliothèques et de frameworks rend le Web plus sophistiqué mais aussi plus complexe. D’abord jQuery, puis Bootstrap, npm, angular, grunt, webpack, et plus encore. Si vous êtes un développeur Web qui suit les dernières nouveautés, ce n’est pas un problème.
Mais si ce n’est pas le cas, vous êtes peut-être un programmeur de systèmes embarqués, un CTO de startup, un développeur Java d’entreprise ou un doctorant en chimie. Bien sûr, vous pourriez probablement comprendre comment configurer un serveur Web et une chaîne de compilation, mais allez-vous continuer ainsi année après année, décennie après décennie ? Probablement pas, et l’année prochaine, lorsque vous rencontrez un problème de dépendance de paquet ou que vous cherchez comment régénérer vos fichiers html, vous pouvez simplement renoncer et compresser les fichiers pour les traiter plus tard. Même les technologies simples comme les générateurs de sites statiques (par exemple, Jekyll) nécessitent un flux de travail et cesseront de fonctionner à un moment donné. Vous tombez dans l’enfer des dépendances npm et oubliez la commande pour empaqueter une version. Et avoir un site Web avec plusieurs pages html est complexe ; comment sauriez-vous comment chaque page est liée les unes aux autres ? index.html.old, copie de about.html, index.html (1)
Troisièmement, et cela a déjà été vanté par d’autres (et même réfuté), la disparition du Web public au profit des applications mobiles et Web, des jardins clos (pages Facebook), du chargement WebSockets juste à temps et de l’AMP diminue la proportion du web sur le world wide web, qui ressemble désormais plus à un web continental qu’à un « world wide web ».
Alors pour ces problèmes, que pouvons-nous faire à ce sujet? Ce n’est pas un problème si simple qu’il peut être résolu par cet article. La Wayback Machine et archive.org permettent de conserver certains contenus plus longtemps. Et parfois, un individu altruiste réhéberge le contenu ailleurs.
Mais la solution doit avoir plusieurs facettes. Comment prodfuire du contenu web qui peut durer et être maintenu pendant au moins 10 ans ? En tant que personne qui étudie l’interaction homme-machine, je pense naturellement aux parties prenantes que nous ne soutenons pas. À l’heure actuelle, la mise en place de contenu Web est optimisée pour le développeur Web professionnel (qui utilise les derniers frameworks et flux de travail) ou pour l’utilisateur non averti (qui utilise une plate-forme).
Mais je pense que nous devrions considérer à la fois 1) le mainteneur occasionnel du contenu Web, quelqu’un qui ne se tient pas constamment au courant des dernières technologies Web, ce qui signifie que le site Web doit avoir de faibles besoins de maintenance ; 2) et les crawlers qui conservent le contenu et les archiveurs personnels, les « archiveurs », c’est-à-dire que le site web doit être facile à sauvegarder et à interpréter.
Ma proposition consiste donc en sept lignes directrices non conventionnelles sur la façon de traiter les sites Web à caractère informatifs, afin de les rendre faciles à entretenir et à préserver. L’intention directrice est que le mainteneur essaie de maintenir le site Web pendant au moins 10 ans, peut-être même 20 ou 30 ans. Ce ne sont pas nécessairement des points de vue controversés, mais des aspirations qui ne sont pas courantes - un manifeste pour un site Web durable.
1. Revenir au HTML/CSS – Je pense que nous avons atteint le point où html/css est plus puissant et plus agréable à utiliser que jamais. Au lieu de commencer avec un modèle géant rempli d’inclusions .js, il est désormais possible d’écrire à nouveau du code HTML brut à partir de zéro. CSS Flexbox, Grid, canvas, Selectors, box-shadow, video, filtre, etc. éliminent une grande partie du besoin de bibliothèques JavaScript. Nous pouvons éviter jQuery et Bootstrap lorsqu’ils ne sont pas nécessaires. Plus il y a de bibliothèques incorporées dans le site Web, plus il devient fragile. Ignorez les polyfills et les préfixes CSS et respectez les attributs CSS qui fonctionnent sur tous les navigateurs. Et validez fréquemment votre code HTML ; cela pourrait vous éviter des maux de tête à l’avenir lorsque vous rencontrerez un bogue.
2. Ne pas minifier le HTML – minifier (compresser) votre HTML et le CSS/JS associé semble économiser une bande passante précieuse et toutes les grandes entreprises le font. Mais pourquoi pas? Eh bien, vous n’économisez pas beaucoup car vos pages Web doivent être compressées avant d’être envoyées sur le réseau, donc la réduction préventive de votre contenu ne fait probablement pas grand-chose pour économiser de la bande passante, voire rien du tout. Mais même si cela a permis d’économiser quelques octets (c’est juste du texte à la fin), vous devez maintenant avoir un processus de compilation et l’ajouter à votre flux de travail, donc la mise à jour d’un site Web est devenue plus complexe. S’il y a un bogue ou une incompatibilité future dans le code HTML, le formulaire réduit est plus difficile à déboguer. Et ce n’est pas convivial pour vos utilisateurs ; tant de gens ont commencé avec HTML en appuyant sur ce bouton Afficher la source, et la minimisation de votre HTML empêche cet idéal d’apprendre en voyant ce qu’ils ont fait. Minimiser le HTML ne préserve pas sa qualité éducative, et ce qui est archivé n’est que le sous-produit résultant.
3. Préférez une page à plusieurs – plusieurs pages sont difficiles à maintenir. Vous pouvez perdre la trace de quelles pages sont liées à quoi, et cela conduit également à un système de modèles de page pour réduire la redondance. Combien de pages une personne peut-elle vraiment gérer ? Avoir un seul fichier, probablement juste un index.html, est simple et inoubliable. Utilisez ce défilement vertical infini. Vous n’avez jamais besoin de fouiller dans vos fichiers ou grep pour voir où se trouve du contenu. Et comment suivre la version de ce fichier ? Faut-il utiliser git ? Mettez-les dans un dossier old/ ? Eh bien, j’aime l’approche simple qui consiste à nommer les anciens fichiers avec la date à laquelle ils sont retirés, comme index.20191213.html. L’utilisation du format ISO de la date facilite le tri et il n’y a pas de confusion entre les formats de date américains et européens. Si j’ai plusieurs versions en une journée, j’utiliserais un style similaire à celui qui est habituel dans les fichiers journaux, de index.20191213.1.html. Un effet secondaire agréable est que vous pouvez accéder à une ancienne version du fichier si vous vous souvenez de la date, sans vous connecter à l’hébergeur Web.
4. Mettre fin à toute forme de lien direct (hotlinking) - ce mot d’avertissement semble avoir disparu du vocabulaire d’Internet, mais c’est l’une des raisons pour lesquelles j’ai vu un site Web parfaitement bon se dégrader sans raison. Arrêtez d’inclure directement des images d’autres sites Web, arrêtez d’emprunter des feuilles de style en les liant simplement, et surtout arrêtez de créer des liens vers des fichiers JavaScript, même ceux hébergés par les développeurs d’origine. Le hotlinking est généralement considéré comme impoli car vos visiteurs utilisent la bande passante de quelqu’un d’autre, cela ralentit l’expérience utilisateur, vous laissez un autre site Web suivre vos utilisateurs, et pire encore si l’emplacement auquel vous vous connectez change sa structure de dossiers ou est hors ligne, alors le problème se répercute également sur votre site Web. Google Analytics est inutile ; stockez vos propres journaux d’accès au site et configurez GoAccess ou découpez-les comme vous le souhaitez, vous donnant des statistiques plus détaillées. Ne donnez pas vos journaux à Google gratuitement.
5. Conservez les polices par défaut – nous nous concentrons d’abord sur le contenu, donc les polices de caractères décoratives et inhabituelles sont totalement inutiles. Tenez-vous en aux 13 polices sécurisées pour le Web ou à une pile de polices système qui correspond à la police par défaut du système d’exploitation de votre visiteur. L’utilisation de la pile de polices système peut sembler un peu différente d’un système d’exploitation à l’autre, mais votre mise en page ne doit pas être si fragile qu’un retour à la ligne supplémentaire la gâcherait. Ainsi, vous n’avez pas non plus à vous soucier du problème de police qui flashe. Votre objectif doit être de fournir efficacement le contenu à l’utilisateur et de rendre le choix de la police invisible, plutôt que de vous faire remarquer pour caresser votre ego de concepteur.
6. Compressez obsessionnellement vos images – plus rapide pour vos utilisateurs, moins d’espace pour archiver et plus facile à entretenir lorsque vous n’avez pas à sauvegarder un dossier gigantesque. Vos images peuvent garder une qualité élevée identique, mais être plus petites. Réduisez vos SVG, compressez sans perte vos PNG, générez des JPEG adaptés exactement à la largeur de l’image. Cela vaut la peine de passer du temps à trouver le moyen le plus optimal de compresser et de réduire la taille de vos images sans perte de qualité. Et une fois que WebP est supporté par Safari, passez à ce format. Minimisez impitoyablement la taille totale de votre site Web et maintenez-la aussi petite que possible. Chaque Mo peut coûter de l’argent réel à quelqu’un, et en fait, mon opérateur de téléphonie mobile (Google Fi) facture un centime par Mo, donc un site Web de 25 Mo, ce qui est assez courant de nos jours, coûte 25 centimes, à peu près autant qu’un journal quand j’étais enfant.
7. Éliminer le risque d’URL cassée - il existe des services de surveillance qui vous avertiront lorsque votre URL est en panne, vous évitant de réaliser un jour que votre page d’accueil ne se charge pas depuis un mois et que les moteurs de recherche l’ont désindexée. Parce que 10 ans, c’est plus long que la durée de vie de la plupart des disques durs ou des systèmes d’exploitation. Mais pour éliminer le risque de rupture complète d’une URL, configurez un deuxième service de surveillance. Parce que si le premier s’arrête pour une raison quelconque (ils passent à un modèle payant, ils s’arrêtent, vous oubliez de renouveler quelque chose, etc.), vous recevrez toujours une notification lorsque votre URL est en panne, puis réaliserez que l’autre service de surveillance est en panne parce que vous n’avez pas reçu la deuxième notification. N’oubliez pas que nous essayons de maintenir quelque chose pendant plus de 10 ans (idéalement beaucoup plus longtemps, même 30 ans), et de nombreux services fermeront pendant cette période, donc deux services de surveillance sont plus sûrs.
Après avoir fait ces choses, allez-y et mentionnez en pied de page, « La page a été conçue pour durer », un lien vers cette page expliquant ce que cela signifie. Les mots promettent que le mainteneur fera de son mieux pour suivre les idées de ce manifeste.
Avant de protester, ce n’est évidemment pas pour les applications web. Si vous créez une application, créez votre application Web ou mobile avec le flux de travail dont vous avez besoin. Je ne connais pas d’applications Web qui fonctionnent de manière similaire depuis 10 ans, donc cela semble être une cause perdue de toute façon (à l’exception du tutoriel python de Philip Guo, en raison de sa stratégie minimaliste pour le maintenir). Ce n’est pas non plus pour les sites Web gérés par une organisation comme Wikipedia ou Twitter. Les salaires d’une équipe informatique sont probablement suffisants pour maintenir un site Web en vie pendant un certain temps.
En fait, il n’est même pas si important que vous suiviez strictement les 7 règles, car il s’agit plus d’une provocation que de règles strictes.
Mais disons qu’une petite partie du Web commence à concevoir des sites Web durables pour un contenu destiné à durer. Que se passe-t-il alors ? Eh bien, les gens peuvent préférer se tourner vers eux car ils ont la promesse de fonctionner dans l’avenir. Plus généralement, les gens devraient être plus soucieux de rendre leurs pages plus durables. Et les utilisateurs et les archiveurs économisent de la bande passante lorsqu’ils visitent et stockent ces pages.
Les effets sont à long terme, mais les réalisations sont progressives et peuvent être mises en œuvre par les propriétaires de sites Web sans dépendre de personne d’autre ni attendre un effet de réseau. Vous pouvez le faire maintenant pour votre site Web, et ce serait déjà un résultat positif. Comme utiliser un sac à provisions recyclé au lieu d’en prendre un en plastique, c’est une petite action individuelle.
Cet article est destiné à provoquer et à conduire à une action individuelle, et non à proposer une solution complète à la dégradation du Web. C’est un petit pas simple pour un système sociotechnique complexe. J’aimerais donc que cela se produise. J’ai l’intention de garder cette page pendant au moins 10 ans.
Si vous souhaitez recevoir des mises à jour sur irchiver, notre projet d’archive personnelle des pages Web que vous visitez, veuillez vous inscrire ici.
Merci à mes doctorants Shaun Wallace, Nediyana Daskalova, Talie Massachi, Alexandra Papoutsaki ; mes collègues James Tompkin, Stephen Bach ; mon assistante d’enseignement Kathleen Chai et mon assistant de recherche Yusuf Karim pour leurs commentaires sur les brouillons.
Voir les discussions sur Hacker News et reddit /r/programming.