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

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 (MIT¹), 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 gras², 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 Explorer³ ; 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é⁴.

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 part⁵. 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.