Possible font subsetting optimization
Munter opened this issue · comments
The docs are using fontawesome for icons. But only a 2 of 705 icons are actually used of the 95-72kb font download (.woff and .woff2).
Creating an optimal subset of the font, to include only the exact icons that are in use, would cut the download down to ~680 bytes (.woff2), which is in the realm of inlineability.
I've been working with @papandreou to attempt a 100% automation of creating such subsets based on static analysis of the page. The tool is called subfont and the jekyll based static generation approach that the docs are taking should fit well with the static analysis approach.
Would you be interested in a PR that adds subfont to your tool chain? It would be a bit more work than just plugging it at the end because of the multiple file references in _headers, sw.js, appcache and so on, but I think it should be doable.
Some highlights from our initial experiments:
lodash.com without scripts
lodash/index.html: 1 font (1 variant) in use, 77.2 kB total. Created subsets: 680 B total
FontAwesome:
400 : 3/705 codepoints used, 77.2 kB (woff2) => 680 B (woff2)
Total savings: 76.5 kB
We are hanging out in https://gitter.im/assetgraph/assetgraph if you are interested to have a chat about it
Would you be interested in a PR that adds subfont to your tool chain?
Yes, please!
I'll see if I can set that up. No promises on a deadline, since I don't have a complete overview of the complexities yet :)
Hi @Munter, just checking in.
I've been tinkering a bit with the docs page for a few hours to see if I can make things work. There is a bit of a catch 22 in the setup.
In order to automate font subsetting and the other optimizations that go with it, I need the full static page generated in order to analyse it. But a part of the page generation also puts references to the original css and font files in _headers, sw.js, manifest.appcache, boot.js and the html files. This means of I make any modifications with new additions of files, name changes or new preload additions, all of those original references are still there. Of course loading the same thing as before, plus an extra bit more, doesn't really yield any performance benefits.
The whole thing is also slightly more complicated because if the setup in config.yml where the vendor assets are remote, but sometimes pulled in as part of the scripting.
I think the only way I can get a piece of automation in there is if either a lot less references to the original vendor files are put all over the place, or if it is possible to create a two-step build where the font automation can be slotted into the middle. But it's probably not worth the effort.
A thing I would recommend though, is just dropping the concept of fonts from external vendors and pulling it in with scripts. Just self-host those google fonts and the fontawesome thing. It would simplify the setup quite a bit.
I can offer to to a hand-rolled optimization of the fontawesome fonts based on the current usage of fonts, but that comes with a tradeoff of losing flexibility of just using the other available icons at will.