Menu
I'm having an issue with FontAwesome (v4) webfont icon rendering in Chrome when Chrome's caching is enabled. Intermittently, across multiple user machines, a page will load with our FontAwesome icons displayed incorrectly as below. This issue happens only occasionally and can't be reliably reproduced or narrowed down to a single page. The only common repro steps are using Chrome and not having "disable cache" enabled in dev tools or elsewhere.
Checking dev tools computed styles for the icon elements reveals that Chrome is correctly detecting the specified font-family as "FontAwesome", but the <i> tags for the icons are being rendered in Times New Roman, rather than the FontAwesome webfont. The "FontAwesome" @font-face declaration and the above rule assigning font-family: FontAwesome to the .fa class exist in the same stylesheet, site.css, which is causing the issues.
Checking the source below, we see that site.css is properly specified in the site's <head> tag. It isn't being added to the <head> through JavaScript; it's present in the in the initial page loaded by the browser. The href points to the correct stylesheet, which loads without issue when opened in a new tab. This isn't very surprising, since all of the styles specified in site.css are correctly being applied to the page (except for the webfont, of course). Even the .fa's font-family rule is being read correctly by Chrome, as shown in the computed styles in the screenshot above.
My suspicion is that Chrome is loading the stylesheet from cache in a weird way that's allowing all of the styles to load but is interfering with the creation of the FontAwesome webfont. Potential evidence for this below:
Above is a portion of the network tab from the dev tools session. Nothing has been filtered out, but site.css has no entry in the list of requests, even though other cached stylesheets are present and the styles from site.css are being applied to the page. There are entries for theme.css, jQuery, AdminLTE, and other stylesheets specified just after site.css in the same <head> block. It's not pictured, but the fontawesome.woff2 webfont file, specified in site.css's @font-face declaration for "FontAwesome", is also being successfully loaded.
Refreshing the page or navigating to another one sometimes fixes the issue. Refreshing with cache disabled always fixes the issue. Every page of our (quite large) web app loads this stylesheet using the same <link> tag, and while this issue pops up fairly rarely, it has happened across many of those pages. The site.css stylesheet is clearly being loaded by Chrome, as it sees the font-family: FontAwesome rule along with the rest of our site styles. But something seems to be happening during the loading of the stylesheet from cache that's causing Chrome to fall back to Times New Roman despite the webfont being both declared via @font-face and specified as the font-family for the affected elements.
We aren't using a service worker or any server-side caching. We do some cachebusting via a GET parameter as shown in the screenshots above (the ?[productName]Version=2.0.13292.0), that value is baked into the initial document loaded by ASP.NET and changes only when our backend server's version changes -- so that shouldn't be the cause of the issue here.
Has anyone experienced anything similar with Chrome webfonts?
477
I had the same problem. My compiled CSS file was missing @charset "UTF-8"; and as a result, the cached icons font was broken. Please check if this helps you.
119
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
