Andy Davies

"I'm not sure I agree that "it only takes *a* site to take one for the team" as there's no guarantee that once a font is downloaded how long it will stay in the cache - we're building sites that consume more and more cache, and using many different fonts from many different foundries. Not sure I follow the bigger question of when browsers are going to become more responsible - originally browsers didn't block waiting for the font and display the page anyway until we (devs and designers) complained we didn't like the experience it gave our visitors, so instead they started waiting for font. Ilya's got an interesting proposal to allow us to have greater level of control, but we'll still have a challenge when we choose to use a font - https://github.com/igrigorik/c..." - Andy Davies

"Even with a cache lifetime of a year there's no guarantee that the font file will stay in cache, as depending on how frequently it's uses a browser is likely to eject it so it can cache other content" - Andy Davies

"Key thing to remember with webfonts is they block rendering in Safari, Chrome, Opera and Firefox - the last three wait 3 seconds before timing out and falling back to a default font, Safari waits longer. But… The browser doesn't know which fonts it needs until the render tree is being built i.e. until the CSS styles are matched against the DOM, and only then does it request them - it's one of the reasons fonts can be such a painful user experience on slow networks. We then get into the tradeoff of base64 encoding fonts which of course results in larger CSS, so longer download and later construction of the render tree, which is why people go down the route of storing them in localStorage. Ilya Grigorik put together a great idea for controlling font-blocking behaviour in more detail - https://github.com/igrigorik/c..." - Andy Davies