This switches the fontkit from our current one which loads every single icon in the brands and duotone fonts for a manually sub-setted one . Currently we only use 4 of the 60,000 odd icons available in those two sets so there's quite a lot of unused assets between the two which we can bring in as and when we need it.
Local .com
before
css - 908kB
fonts - 392kB
after
css - 392kB
fonts - 273kB
Local BusinessEvents
before
css - 4.4mB
fonts - 726mB
lighthouse - ~40
after
css - 1.4mB
fonts - 160kB
lighthouse - ~60
The numbers will be less drastic on servers that actually use gzip but hopefully it'll still be a significant move in the right direction.
I've updated the confluence page on working with icons to account for the new process. Generally, it just means that if we want to use a new icon we have to update the font files in the component library in the way we already did if we added a new custom icon, even if that new icon we're using it from the base fontawesome set.
This switches the fontkit from our current one which loads every single icon in the brands and duotone fonts for a manually sub-setted one . Currently we only use 4 of the 60,000 odd icons available in those two sets so there's quite a lot of unused assets between the two which we can bring in as and when we need it.
Local .com
before css - 908kB fonts - 392kB
after css - 392kB fonts - 273kB
Local BusinessEvents
before css - 4.4mB fonts - 726mB lighthouse - ~40
after css - 1.4mB fonts - 160kB lighthouse - ~60
The numbers will be less drastic on servers that actually use gzip but hopefully it'll still be a significant move in the right direction.
I've updated the confluence page on working with icons to account for the new process. Generally, it just means that if we want to use a new icon we have to update the font files in the component library in the way we already did if we added a new custom icon, even if that new icon we're using it from the base fontawesome set.