Modern browsers are smart enough to only download the required file type, sniffing is unnecessary the vast majority of the time and you save an entire 3rd party connection.
The tool you linked does not solve the same problem, as the problems isn’t file types but URIs. Google is able to provide the tiniest possibly font files by hinting them for the specific browser/platform requesting them. We never consistently or predictably know the resultant URI of a Google Fonts-hosted font file. Here is a Tweet to the same effect from two days ago. Believe me, I’ve researched this :(
The fonts are static, but the CSS (from fonts.googleapis.com), and the font files it references, vary depending on the User-Agent. For instance, with a Chrome UA it will request WOFF files; with a blank UA it may request TTF files.
The idea is that you take all the links to the different font types and put them directly in your local CSS. Your browser knows which formats it supports, if you have TTF and WOFF2 fonts linked, Chrome will only download the WOFF2 version. No need to send an extra 3rd party request just to get a piece of CSS that only links a single file type.
Well yes, of course you can do that. But at that point, why would you reference third-party font URLs, instead of self-hosting them? (The article pretty much begins by stating that this is the fastest option.)
If performance is your utmost priority, forego web fonts entirely. If you value performance but want the benefit of a web font, self-host your CSS and fonts. If the convenience of Google Fonts is appealing, the suggestions here can improve first-paint performance. Different projects will have different trade-offs.
You could use a couple microseconds on the server to inline CSS to match the HTTP U-A; assuming whatever you needed to know is still in there by the grace of Google whenever they slush up the U-A strings.
