Chrome 不显示 webfont，当在缓存的样式表中声明 font-face 时回退到 Times New Roman
rya*_*hea 7 css caching google-chrome webfonts font-awesome
当启用 Chrome 的缓存时，我在 Chrome 中遇到 FontAwesome (v4) webfont 图标呈现问题。间歇性地，在多个用户机器上，一个页面将加载我们的 FontAwesome 图标，如下所示不正确显示。此问题仅偶尔发生，无法可靠地重现或缩小到单个页面。唯一常见的重现步骤是使用 Chrome，并且没有在开发工具或其他地方启用“禁用缓存”。
检查开发工具计算的图标元素样式显示，Chrome 正确地将指定的字体系列检测为“FontAwesome”，但<i>图标的标签以 Times New Roman 呈现，而不是 FontAwesome webfont。“FontAwesome”@font-face 声明和上述分配font-family: FontAwesome给.fa类的规则存在于同一个样式表中site.css，这会导致问题。
检查下面的来源，我们看到site.css在网站的<head>标签中正确指定。它不会被添加到<head>通过 JavaScript 中；它存在于浏览器加载的初始页面中。该href指向正确的样式表，这不加载问题，当在新标签打开。这并不奇怪，因为 中指定的所有样式site.css都正确应用于页面（当然 webfont 除外）。Chrome甚至可以正确读取.fa的font-family规则，如上面屏幕截图中计算出的样式所示。
我怀疑 Chrome 正在以一种奇怪的方式从缓存加载样式表，这种方式允许加载所有样式，但会干扰 FontAwesome webfont 的创建。这方面的潜在证据如下：
以上是开发工具会话中网络选项卡的一部分。没有被过滤掉，但site.css在请求列表中的条目，即使其他缓存样式表都存在，并从样式site.css被应用到该页面。在同一个块中theme.css紧随其后指定了、jQuery、AdminLTE 和其他样式表的条目。它没有被描绘出来，但是在“FontAwesome”的声明中指定的 fontawesome.woff2 webfont 文件也被成功加载。site.css<head>site.css@font-face
刷新页面或导航到另一个页面有时可以解决问题。在禁用缓存的情况下刷新始终可以解决此问题。我们（相当大的）网络应用程序的每个页面都使用相同的<link>标签加载这个样式表，虽然这个问题很少出现，但它在许多页面上都发生过。该site.css样式表显然是受到Chrome的加载，因为它看到了font-family: FontAwesome规则与本网站的风格其余一起。但是在从缓存加载样式表的过程中似乎发生了一些事情，这导致 Chrome 回退到 Times New Roman，尽管 webfont 被声明为 via@font-face并指定为font-family受影响元素的 。
我们没有使用服务工作者或任何服务器端缓存。我们通过 GET 参数执行一些缓存破坏，如上面的屏幕截图所示 (the ?[productName]Version=2.0.13292.0)，该值被烘焙到由 ASP.NET 加载的初始文档中，并且仅在我们的后端服务器的版本更改时才会更改——因此这不应该是原因这里的问题。
有没有人遇到过类似 Chrome webfonts 的情况？
| 归档时间： |
|
| 查看次数： |
1509 次 |
| 最近记录： |