2021-03-06T21:07:51Z
Suite à la découverte du "512KB Club", initiative qui propose de recenser les sites proposant des pages de moins de 512KB, j'ai eu envie de m'amuser à réduire autant que possible la taille de mon site.
À l'heure où j'écris ces lignes, la page d'accueil du site pèse 4,08 Ko tout compris (2,70 Ko transférés si le navigateur supporte gzip, ce qui est très probable).
Remarquez que cette question ne s'applique pas à gemini : une autre bonne raison d'adopter ce protocole :)
Plusieurs raisons évidentes sont à considérer :
Pour connaître le poids de votre site, plusieurs choix sont disponibles:
Je préfère directement utiliser Firefox. Ouvrez la console de développement (F12) puis cliquez sur l'onglet "Réseau". Il ne vous reste plus qu'à vous rendre sur votre site et recharger la page sans le cache (Ctrl-Shift-r). Vous verrez apparaître la quantité transférée (si c'est compressé) et la taille finale:
Mon site était déjà assez maigre, je suis donc allé chercher les petits détails.
Comme à peu près tout le monde, la feuille de style était contenue dans un fichier à part. Dans chaque page, on pouvait trouver :
Toutefois, mon code CSS une fois nettoyé des éléments inutiles et minifié (c'est à dire une fois tous les espaces et sauts de ligne retirés), était presque moins lourd qu'une requête HTTP. Autrement dit, quand le navigateur demandait au serveur "envoie-moi le fichier css", davantage de données étaient transmises que dans le fichier CSS.
Désormais, on peut trouver dans les pages simplement
Cela pose 2 inconvénients:
=> Maintenir un site statique avec un Makefile (http) | Maintenir un site statique avec un Makefile (gemini)
Dans mon cas, ces inconvénients sont négligeables.
J'utilisais 3 liens pour la favicon selon le type d'image à fournir : ico, png ou svg.
Après avoir vérifié la taille de chacune :
$ ls -l favicon.* -rw-r--r-- 1 prx prx 1150 Mar 5 22:21 favicon.ico -rw-r--r-- 1 prx prx 429 Mar 5 22:21 favicon.png -rw-r--r-- 1 prx prx 3835 Mar 5 22:21 favicon.svg
Il n'y a pas photo, la version png est nettement plus petite, et finalement largement suffisante pour mon site.
Les polices personnalisées, c'est chouette, ça donne une identité au site. Cependant, lorsque le fichier de police est plus lourd que le contenu de la page, il faut se poser des questions.
Aussi, au lieu de charger des polices depuis mon serveur, je propose dans le CSS le nom de la police dans laquelle j'aimerais que mon site s'affiche. Si l'utilisateur ne l'a pas, alors il voudra afficher le site avec la police qu'il a configurée dans les paramètres de son navigateur. Il faudra donc veiller à toujours terminer la définition d'une police par "serif, "sans-serif" ou "monospace". Pour l'instant, j'ai ceci :
font-family:"Hack", monospace;
C'est un peu de la triche, mais ça permet de réduire considérablement la quantité de données transférées. Si le navigateur le supporte, alors il demandera du contenu gzippé. J'utilise pour cela sbw avec le serveur httpd d'OpenBSD.
Le principe est tout bête : toutes mes pages html sont gzipppées.
Lorsqu'un visiteur demande "/all/index.hml", alors sbw va regarder si "/all/index.hml.gz" existe et enverra ce fichier si le navigateur supporte la version gzippée.
=> sbw (http) | sbw (gemini)
J'ai pu revenir sur le code de sbw à cette occasion et le rendre un peu plus simple, en corrigeant un petit bug à la lecture d'un fichier.
On va me dire "pourquoi gzip et pas brotli?" (Coucou Stéphane :)). La réponse est bête : j'aime bien gzip car j'en comprends l'algorithme.
=> Voir la version de Stéphane
D'autres serveurs sont capables de faire ça nativement (sans passer par un cgi), ça s'appelle static_gzip :)
On ne le dira jamais assez : optimisez les images.
Il existe pour cela des services en ligne, ainsi que des outils en ligne de commande. J'utilise pour ma part optipng et Graphicsmagick :
$ optipng image.png $ gm convert image.jpg -strip -quality 75 -interlace line image.jpg
Il existe aussi de nouveaux formats comme WEBP et AVIF, mais pas supportées par tous les navigateurs. Les vieux trucs, c'est bien aussi.
Toute ceci ne remplacera pas LA question : avez-vous vraiment besoin d'une image?
Sérieusement, avez-vous vraiment besoin de code JS pour votre site? C'est possible que oui, mais mis à part pour des éléments esthétiques, voire pour intégrer des scripts de profilage (beurk), il est probable que vous puissiez vous en passer (si vous en avez envie :)).
Je vous invite à vérifier si vous ne pouvez pas remplacer le code javascript par du CSS :
=> http://youmightnotneedjs.com/
Enfin, pensez à mettre votre code javascript tout à la fin de vos pages, juste avant ""
=> Optimiser et accélérer les pages web | https://1mb.club/
=> 📧 Envoyez votre commentaire par mail. | 📫 Abonnez-vous pour recevoir les réponses | 📚 Consultez les archives. | 💨 Vous désinscrire This content has been proxied by September (3851b).Proxy Information
text/plain