Re:Saving the Internet 2000TB a Day: Fixing Font Awesome’s F...
by csswizardry on Friday December 09, 2016 @03:32PM
(#13141583)
Hah, this is getting interesting. Would be more fun doing this over a beer, but…
> Let's assume a reasonable 8mbit connection and 50ms RTT.
This is a huge assumption; you’ll be neglecting almost all of your mobile users there. But! Optimise for your use-case, of course.
If you’re self hosting your fonts I would leave them external, `preload` them, and use the preferred `font-display` mechanism to deal with (or elimiante) FOUT and/or FOIT. That’s your extra connections taken care of, and we’ve moved fonts back off of the critical path :)
I think what we’ve both hit upon here is the fact that browsers need to decide on a standard way of handling FOUT/FOIT. Leaving pages blank for up to 3s (or in Safari’s case, indefinitely) would completely eliminate the need to try and circumvent it by base64 inlining :(
> Let's assume a reasonable 8mbit connection and 50ms RTT.
This is a huge assumption; you’ll be neglecting almost all of your mobile users there. But! Optimise for your use-case, of course.
If you’re self hosting your fonts I would leave them external, `preload` them, and use the preferred `font-display` mechanism to deal with (or elimiante) FOUT and/or FOIT. That’s your extra connections taken care of, and we’ve moved fonts back off of the critical path :)
I think what we’ve both hit upon here is the fact that browsers need to decide on a standard way of handling FOUT/FOIT. Leaving pages blank for up to 3s (or in Safari’s case, indefinitely) would completely eliminate the need to try and circumvent it by base64 inlining :(