Journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node)

Posté par  . Licence CC By‑SA.
Étiquettes :
18
17
juil.
2026

Cher journal, chères moules,

Votre site pèse trois tonnes, vos polices tirent des mégaoctets et vos SVG partent sur le web sans même être décortiqués ? J'ai deux petites soluces. Libres (MIT1), en Go, et qui ne réclament ni Node ni Python pour tourner. Transparence d'abord : je les ai extraites d'un service que je bricole (patu.dev, hop, le lien est passé ; et comme il est court, vous allez vous en souvenir longtemps, trop tard pour le « -1 pub », pire qu'un rickroll). Mais le code est à vous, et c'est lui le sujet.

woffify : décortiquer vos polices jusqu'au WOFF2

L'encodeur WOFF2 de référence, c'est google/woff2 (woff2_compress). Sauf qu'il ne mange que du TTF/OTF et ne fait pas de subsetting. Or un TTF brut sur le web, c'est deux tiers de gras2, et le subsetting (ne garder que les glyphes utiles) est le plus gros levier.

woffify enrobe le même encodeur et ajoute les deux trucs qui manquaient :

  • Entrée WOFF 1.0, décodée en SFNT en Go pur, pour recompresser vos vieux .woff sans perte.
  • Subsetting via HarfBuzz (hb-subset) : un sous-ensemble latin fait couramment 80 à 95 % de moins.

Détail pour les maniaques (bonjour) : sur du TTF/OTF sans subsetting, la sortie est octet pour octet identique à woff2_compress (même encodeur, Brotli qualité 11). Pas « presque pareil », pareil.

Formats avalés : .woff, .ttf, .otf, .ttc, .eot. Oui, EOT, pour exhumer vos assets Internet Explorer3 ; seul l'EOT non compressé est lu, la compression MicroType Express est refusée avec un message clair plutôt qu'un segfault poli.

Le tout tient dans un seul binaire statique (image ~6 Mo), zéro Node, zéro Python, pensé pour la CI et les clusters.

woffify -subset-text "Salut les moules" Brand.ttf

silk : dégraisser vos SVG sans invoquer Node

Pour les SVG, la référence c'est svgo. C'est du Node. Tirer 300 Mo de node_modules pour raboter une icône de 2 Ko dans un service Go, non merci.

silk réimplémente en Go pur (pas de cgo, pas de runtime externe) les passes de svgo qui pèsent vraiment : convertPathData, mergePaths, et une poignée de passes structurelles sûres. Et surtout, il a une religion : la sortie doit rendre pixel pour pixel comme l'entrée. Toute construction dont l'optimisation ne peut pas être prouvée sûre est réémise telle quelle, octet pour octet. Pas de « ça a marché sur mes trois icônes ».

Le seul vrai risque de fidélité, c'est l'arrondi des coordonnées : il est donc opt-in et borné (-precision). Les translations de transformations ne sont arrondies que si vous le demandez, parce qu'arrondir la translation d'un groupe décale des sous-arbres entiers et transforme un joli motif régulier en moiré4.

out, err := silk.Optimize(svg, silk.DefaultOptions())

Licence, et non ce n'est pas du Rust

Les deux sont en MIT. Je vous laisse lancer le débat permissif contre copyleft en commentaire, c'est vendredi quelque part5. Et non, ce n'est pas réécrit en Rust ; je sais, je sais, on me l'a déjà dit.

  • silk : github.com/Gheop/silk
  • woffify : github.com/Gheop/woffify

Les deux tournent en prod pour de vrai (oui, derrière le service du début, je ne le redis pas, vous l'avez déjà en tête). Mais l'idée du journal, c'est surtout que si vous devez alléger fonts ou SVG dans un pipeline sans Node ni Python, ces deux-là vous éviteront de réinventer le bouchot. Patchs, issues et remarques acides bienvenus.

Voilà, votre bouchot est délesté. Vous pouvez retourner aux moules-frites.

  1. Oui, MIT. Rangez les fourches. ↩

  2. Chiffre non contractuel, mais franchement pas loin. ↩

  3. Paix à son âme. ↩

  4. Demandez à quiconque a déjà arrondi un SVG un peu vite : le moiré, c'est le diable. ↩

  5. Statistiquement, il est vendredi quelque part sur Terre. CQFD. ↩

  • # Dredi

    Posté par  (Mastodon) . Évalué à 9 (+6/-0).

    Statistiquement, il est vendredi quelque part sur Terre.

    Ouais enfin ça dépend quand.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Dredi

      Posté par  . Évalué à 2 (+0/-0).

      Statistiquement, il est vendredi quelque part sur Terre.

      c'est pas une chanson de l'anarchiste du Sud Ouest ? (ah non, en fait, c'est Samedi soir sur la terre)

      "Si tous les cons volaient, il ferait nuit" F. Dard

    • [^] # Re: Dredi

      Posté par  . Évalué à 3 (+4/-1).

      Bien vu. En moyenne sur la semaine, « il est vendredi quelque part » n'est vrai qu'environ 50h sur 168 : les fuseaux extrêmes (UTC-12 et UTC+14) sont à 26h d'écart, donc un jour donné existe 24+26 = 50h. Soit ~30% du temps, tu as raison.
      Sauf que là je poste un vendredi en début d'après-midi heure de Paris (UTC+2 en été), soit ~13h UTC : à cet instant c'est vendredi de UTC-12 à UTC+10, environ 85% des fuseaux. Mon CQFD est donc sauf… jusqu'à ce que quelqu'un relise ce journal un mardi. Merci pour le rapport de bug, je passe la note en 0.8-stable !

      • [^] # Re: Dredi

        Posté par  (site web personnel) . Évalué à 9 (+6/-0).

        Il semble essentiel de prendre en compte les personnes n'étant pas sur Terre (ni en orbite directe autour de la Terre disons)). Parce que sur la Lune ou sur Mars, on ne sait pas si c'est soirée disco chez Boris, déjà qu'on ne sait pas si c'est les vendredis.

      • [^] # Re: Dredi

        Posté par  (Mastodon) . Évalué à 6 (+3/-0).

        Soit ~30% du temps

        Ça par contre c'est marrant à quel point c'est contre intuitif, merci pour les calculs !

        Du coup j'ai un peu regardé cette histoire du UTC-12 et UTC+14, ce sont des îles du pacifique bien évidemment, qui ont décidé de leur jour de semaine (par exemple pour s'aligner avec des partenaires commerciaux de l'autre côté du changement de date mais très proches géographiquement).

        Ça veut donc dire que chaque jour il y a 2h où il existe 3 dates différentes qquepart.

        Par exemple un lundi matin à midi à Paris (UTC+2 été), on est encore dimanche en UTC-12, et déjà mardi en UTC+14.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Dredi

      Posté par  (site web personnel) . Évalué à 10 (+10/-0).

      Vous vous demandez légitimement « Vendredi quelque part sur Terre, mais où ? ». Voici donc l'information que vous attendiez : « sur une île inhabitée à l'embouchure de l'Orénoque, près des côtes vénézuéliennes » (source)
      https://www.openstreetmap.org/relation/1083284#map=12/8.6206/-60.6965

      • [^] # Re: Dredi

        Posté par  . Évalué à 3 (+4/-1).

        Wouah, fallait la trouver celle là !!

        • [^] # Re: Dredi

          Posté par  . Évalué à 1 (+1/-0).

          Ah oui, respect comme disent les d'jeunes !

    • [^] # Re: Dredi

      Posté par  (Mastodon) . Évalué à 3 (+0/-0).

      En fait ça n'a absolument rien à voir avec les statistiques.

  • # Encore un journal généré par un LLM...

    Posté par  (site web personnel) . Évalué à 6 (+6/-3).

    Tu hallucines : les bons bouchots légers utilisent les polices du système !

    Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board

    • [^] # Re: Encore un journal généré par un LLM...

      Posté par  . Évalué à 1 (+5/-4).

      C'est pas moi qui hallucine, c'est toi qui as croqué dans la pomme qui t'est tombée sur la tête ;)
      On peut avoir envie d'un peu plus de fun que les polices du système … qui ne sont pas les mêmes suivants les systèmes/distros voire même desktop !
      Mais la police du LLM … faudrait demander à Linus ce qu'il en pense : pcinpact.com/247523/linus-torvalds-sagace-une-nouvelle-fois-sur-lia-cette-fois-pour-la-defendre/

  • # Efficacité, gains réels

    Posté par  . Évalué à 4 (+2/-0).

    J'aurais aimé voir des résultats avec les gains de poids obtenus et une comparaison avec des outils directement disponibles dans la plupart des distributions comme woff2_compress, ou même des outils en ligne du type https://fontcompressor.com/

    • [^] # Re: Efficacité, gains réels

      Posté par  . Évalué à 2 (+3/-1).

      Ça tombe bien, on a mesuré sur 40 polices réelles (des TTF Google Fonts) et publié les chiffres : https://patu.dev/fr/blog/fonts-woff2-and-subsetting

      En deux temps :
      - WOFF2 seul : −64 % médian (22 Mo → 7 Mo sur les 40)
      - WOFF2 + subsetting latin : 22 Mo → ~1 Mo, soit 95 %

      Et c'est là la nuance avec woff2_compress : il fait le premier temps (la conversion WOFF2, le −64 %), mais pas le subsetting. Le gros de la surprise est dans le second (7 Mo → 1 Mo) : une police Google traîne du cyrillique, du grec, du vietnamien, des symboles qu'un site latin ne rend jamais. woffify enchaîne les deux dans un seul binaire (subsetting via hb-subset de HarfBuzz). Sur la conversion WOFF2 pure, il ne fait pas mieux que woff2_compress, c'est le même conteneur Brotli.

      fontcompressor.com fait aussi compress + subset, mais en ligne et à la main (upload, interface). woffify, c'est un binaire local qu'on glisse dans un build ou une CI, et rien ne quitte ta machine.

      woffify subsette selon ce que tu lui donnes, soit des plages Unicode (-subset-unicodes), soit directement le texte utilisé (-subset-text, il garde les glyphes qui le couvrent). Il ne crawle pas le site lui-même : tu lui passes le texte réellement rendu (un -subset-text "$(cat contenu.txt)" dans le build suffit), et il ne reste que tes caractères. Pour un site multilingue, tu élargis les plages ou tu sers plusieurs subsets via unicode-range dans @font-face. Je te laisse imaginer ce que tu peux gagner sur tes fonts avec ça ;)

      • [^] # Re: Efficacité, gains réels

        Posté par  . Évalué à 3 (+2/-1).

        Il est très simple d'obtenir des polices de caractères ne comportant que le jeu de caractères désiré (latin par exemple). Au pire il y a des tas d'outils classiques (fonttools) pour extraire celui voulu.
        C'est normalement ce que l'on commence par vérifier lorsque l'on veut une police spécifique pour un site web.

        Le taux de compression obtenu est alors identique puisque le même algorithme (brotli) est utilisé.

        Désolée mais je ne vois pas la valeur ajouté de ce logiciel vibe-codé par rapport aux solutions éprouvées.

        • [^] # Re: Efficacité, gains réels

          Posté par  . Évalué à 2 (+5/-3).

          Oui, bien sur, les briques existent, mais chacune traîne son runtime. fonttools (pyftsubset) subsette très bien, mais c'est du Python à installer. woff2_compress compresse, mais ne subsette pas et ne lit que le TTF/OTF. Et pour extraire le sous-ensemble depuis tes fichiers, on ajoute souvent glyphhanger, en Node. Il n'y avait pas de binaire unique, sans dépendance,sans runtime, pour toute la chaîne. Et c'est l'utilité de woffify.

          Convertir, subsetter, et même scanner tes CSS/textes pour ne garder que les glyphes utilisés (-subset-scan), le tout dans un binaire statique unique, sans Python ni Node, pensé pour un CI léger (build de ton site) ou un conteneur. Un ordre de grandeur, sur ma Fedora, le binaire woffify fait 6 Mo. dnf install python3-fonttools réclame 19Mo une fois installé. Et il faut ajouter l'installation de Python. Plus d'autres outils pour faire le reste…

          Sur les octets tu as raison,sur du TTF/OTF sans subsetting, la sortie est byte-for-byte identique à woff2_compress (même encodeur, Brotli 11), et le subset passe par le même HarfBuzz(hb-subset). Je ne prétends pas faire plus petit. woffify ajoute juste la couverture d'entrée dans ce même binaire : le WOFF 1.0, et l'EOT non compressé (le vieux format IE, un besoin que nous avions) que ni woff2_compress ni fonttools n'ouvrent.

          Si ce besoin « un binaire, zéro dépendance, tous formats, dans un CI/docker » n'est pas le tien, fonttools reste parfait, garde-le. Si tu n'y vois pas de valeur, c'est sans doute que tu n'es pas la cible ;-)

          • [^] # Re: Efficacité, gains réels

            Posté par  . Évalué à 2 (+0/-0). Dernière modification le 22 juillet 2026 à 09:59.

            Oui, bien sur, les briques existent, mais chacune traîne son runtime. fonttools (pyftsubset) subsette très bien, mais c'est du Python à installer. woff2_compress compresse, mais ne subsette pas et ne lit que le TTF/OTF.

            fontools c'est juste un paquet à installer et cela fait tout ce que propose ton outil : extraction de caractères, enregistrement et compression en wooff2, etc. et plus : autres formats en entrée, fusion, etc. (cf. https://fonttools.readthedocs.io/en/latest/index.html)

            J'ai quand même un peu l'impression que tu as réinventé la roue…

            • [^] # Re: Efficacité, gains réels

              Posté par  (site web personnel) . Évalué à 2 (+2/-0).

              Dans notre chaîne (k3s), l'image passe de 84 Mo (python:3-alpine + fonttools + brotli, 163Mo avec python:3-slim !) à 6,6 Mo (binaire statique, image scratch), sans Python à installer ni à épingler. Ça se paie à chaque noeud qui tire l'image, à chaque cold start au scale-out, et à chaque run de CI qui réinstalle la stack. Sans compter la surface à suivre … une image Python, ce sont des CVE à suivre/patcher. Ou faire confiance à latest.
              C'est un problème d'ops, pas de fonctionnalité. Ce ne sont pas les mêmes usages.

              Et on avait de toute façon besoin de traiter de l'EOT en masse, ce que fontTools n'ouvre pas (il ouvre bien tous les WOFF1.0, tu m'as fait douter, j'ai vérifié) …

              • [^] # Re: Efficacité, gains réels

                Posté par  . Évalué à 2 (+0/-0). Dernière modification le 23 juillet 2026 à 10:43.

                Merci, c'est un retour intéressant qui cependant m'interroge sur l’adaptation d'une architecture à l'outil plutôt qu'à l'usage.

                Quel est le coût le plus élevé : balancer des dizaines de polices de caractères dans le flux de dév/production et avoir une architecture complexe qui les optimise à la volée ou envoyer directement les polices optimisées correspondant aux besoins ?

                P.S. : qui utilise encore le format propriétaire et obsolète EOT en 2026 ?

  • # quel algo jpeg ?

    Posté par  . Évalué à 4 (+2/-0).

    Bravo pour l'écriture, j'avais besoin de rigoler!

    Par curiosité, sur patu.dev, tu utilises quel outil pour les jpeg ? J'ai l'habitude de Mozjpeg et du nouvel algo cjpeg de Google (qui est lent).

    • [^] # Re: quel algo jpeg ?

      Posté par  . Évalué à 3 (+4/-1).

      Et bien, nous utilisons jpegli, tiré de libjxl, justement ! le machin lent de Google.

      Chez nous il tourne côté serveur, au moment de l'optimisation, pas à la livraison : on encode une fois et on met en cache. Le visiteur récupère ensuite le fichier déjà encodé depuis le CDN, il n'attend jamais l'encodeur. Et comme on vise une qualité perçue mesurée à la ssimulacra2 (pas un -q à l'aveugle), on fait une petite recherche de qualité par-dessus, ce qui rajoute encore du CPU en amont.

      En mode « stored », c'est encore plus net : le POST renvoie tout de suite un 202 avec l'URL finale, un worker encode derrière, et l'URL sert l'original en repli tant que la version optimisée n'est pas prête.

      Sur nos mesures, jpegli sort 16 à 32 % plus petit que libjpeg-turbo (mozjpeg) à score ssimulacra2 égal, parce que son modèle psychovisuel place les bits là où l'œil est moins sensible au lieu des tables de quantification fixes. mozjpeg (quantif trellis) joue dans la même cour, un cran au-dessus de la baseline, mais on a tranché pour jpegli. En repli, si cjpegli tombe, on repasse sur libjpeg-turbo via libvips.

      Cela dit, pour beaucoup d'images on ne sort même pas de JPEG : AVIF ou WebP quand le navigateur suit, JPEG en filet de sécurité. Les chiffres à qualité perçue égale sont là si ça t'intéresse : https://patu.dev/blog/avif-vs-webp-vs-jpeg (la baseline JPEG y est en libjpeg-turbo).

  • # Commentaire supprimé

    Posté par  . Évalué à 2 (+0/-0). Dernière modification le 18 juillet 2026 à 10:37.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Rangez les fourches ?

    Posté par  (site web personnel) . Évalué à 2 (+0/-0).

    J'attends la version AGPL en Rust auto-hébergeable.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.