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 ;-)
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 ;)
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).
Oui, tu peux forcer ton firefox chéri (parce que l'autre, il va juste te tracer) à utiliser les fonts que tu veux à la place des choix des webmasters ! Tu es libre !
Mais tu peux toujours compresser tes fonts favoris avec woffify :-) C'est magique ! le choix ET la légèreté.
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/
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: Efficacité, gains réels
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). É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: Rangez les fourches ?
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). Évalué à 4 (+5/-1).
Tout est faisable et … facturable, très cher mécène ;-)
[^] # Re: Efficacité, gains réels
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). É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: quel algo jpeg ?
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). É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).
[^] # Re: Encore un journal généré par un LLM...
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). Évalué à 2 (+5/-3).
Oui, tu peux forcer ton firefox chéri (parce que l'autre, il va juste te tracer) à utiliser les fonts que tu veux à la place des choix des webmasters ! Tu es libre !
Mais tu peux toujours compresser tes fonts favoris avec woffify :-) C'est magique ! le choix ET la légèreté.
[^] # Re: Encore un journal généré par un LLM...
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). É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/
[^] # Re: Dredi
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). Évalué à 3 (+4/-1).
Wouah, fallait la trouver celle là !!
[^] # Re: Dredi
Posté par Patu . En réponse au journal Chères moules, votre bouchot est trop lourd ? J'ai la soluce (libre, en Go, sans Node). É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 !