因此，我被迫在我正在开发的网站上使用@font-face，不得不说，与谷歌字体相比，跨浏览器的渲染质量给我留下了深刻的印象，但它似乎确实对与 Cufon 相比，http 请求，因为每个字体需要四个变体用于正文复制，有时需要几个变体用于标题。
我通常使用 cufon，因为我发现它灵活、可靠的跨浏览器和移动设备，尽管有时会出现一些奇怪的空白问题，但易于使用。由于渲染在某些浏览器中很糟糕，我没有对 Google 字体做太多事情。
显然，技术已经发展！这三者有何不同，三者中的任何一个是否存在严重的陷阱？
我认为在@font-face、浏览器默认值和cufon 之间进行选择有两个考虑因素。
1. 使用 CSS 维护网站的外观对您来说是多么容易
在为网站的任何部分使用 javascript 解决方案时，重要的是（至少对我而言）网站在使用或不使用 javascript 时看起来都不错。这意味着如果用户在页面完成加载之前单击“停止”，则该类型仍将位于设计中的位置。这意味着使用默认字体进行后备。我发现这在过去确实存在问题，因为 cufon 字体的行高可能与常规字体的行高有很大不同，因此有必要编写多余的 css 来控制这些情况以及跨浏览器的不规则性——简而言之，一个屁股痛。
使用@font-face，特别是使用谷歌字体或typekit，字体质量挑选和显示可预测和consitently好（关于布局和行高）跨浏览器。例如，您可以从 proxima-nova 切换回默认的 arial，而不会影响布局——我发现这对 cufon 来说是一个挑战。
2. 用户需要如何与网站交互
当我将鼠标悬停在文本上时，我希望能够突出显示文本、搜索文本以及查看文本光标。你不能用cufon做到这一点。如果您的网站包含更多信息，那么 cufon 不是一个好的选择。
我想说，对于美学与内容同等重要的小型网站，Cufon 是一个不错的选择（因为如果没有用户需要通过 CMS 维护的引人注目的排版，内容根本不会产生相同的效果...... www.macretailsolutions.com 是我与 Cufon 合作的一个网站，我认为它属于这一类）。否则，我的观点是，从维护/开发的角度和可用性的角度来看，它很糟糕。
Cufon 确实会在 IE 中渲染得更漂亮，但事实是，如果人们一开始就使用 IE，他们一开始并不太关心美学。
结论：不要使用Cufon。