RE: many instances of FA: yes, that’s a key feature of this plugin, helping to automatically detect and resolve those conflicts. It seems to work most of the time (i.e. for most combinations of theme/plugins with other FA installations), though there are still some corner cases that can’t be automatically resolved.
RE: webfont loading issues. For background, some of those issues are described in this blog post (NOTE: this post refers to our Fort Awesome kits, so that’s a different product–not what’s being loaded by this plugin. But I offer it for some background on the issues involved.)
The upshot: problems with render blocking can be resolved with asynchronous loading, but async loading can introduce other challenges, like the flash of unstyled text (FOUT) or flash of invisible text (FOIT). That blog post describes the tradeoffs and potential issues involved in synchronous vs. asynchronous loading.
This plugin loads webfonts synchronously. So, among the tradeoffs of each approach, this will avoid the FOIT and FOUT side-effects of async loading, but it will have the render blocking property of all synchronous webfont loading. However, because of the long term browser caching involved with loading of the webfont CDN resources, it normally will not have to block on the network events of downloading webfont files. So any render-blocking would normally be negligible.
It also supports using SVG with JavaScript technology instead of webfonts. Because that technology involves different loading and rendering semantics, it may provide an alternative loading experience, which might be preferred, depending on the details of each use case. However, the SVG/JS tech is also loaded synchronously by this plugin. You could add a script_loader_tag WordPress filter to add the defer attribute and make it work async like this, though, if you wanted.
