title: Chrome not displaying webfont, falling back to Times New Roman when font-face declared in cached stylesheet
body: <p>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 <em>not</em> having "disable cache" enabled in dev tools or elsewhere.</p>
  
  <p><a href="https://i.stack.imgur.com/oi3xz.png" rel="noreferrer"><img src="https://i.stack.imgur.com/oi3xz.png" alt="Improperly rendered icons"></a></p>
  
  <p>Checking dev tools computed styles for the icon elements reveals that Chrome is correctly detecting the specified font-family as "FontAwesome", but the <code>&lt;i&gt;</code> tags for the icons are being rendered in Times New Roman, rather than the FontAwesome webfont. The "FontAwesome" @font-face declaration <em>and</em> the above rule assigning <code>font-family: FontAwesome</code> to the <code>.fa</code> class exist in the same stylesheet, <code>site.css</code>, which is causing the issues.</p>
  
  <p><a href="https://i.stack.imgur.com/ibS1v.png" rel="noreferrer"><img src="https://i.stack.imgur.com/ibS1v.png" alt="Font styles"></a></p>
  
  <p>Checking the source below, we see that <code>site.css</code> is properly specified in the site's <code>&lt;head&gt;</code> tag. It isn't being added to the <code>&lt;head&gt;</code> through JavaScript; it's present in the  in the initial page loaded by the browser. The <code>href</code> 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 <code>site.css</code> are correctly being applied to the page (except for the webfont, of course). Even the <code>.fa</code>'s <code>font-family</code> rule is being read correctly by Chrome, as shown in the computed styles in the screenshot above.</p>
  
  <p><a href="https://i.stack.imgur.com/Jty9w.png" rel="noreferrer"><img src="https://i.stack.imgur.com/Jty9w.png" alt="site.css present in &lt;head&gt; tag"></a></p>
  
  <p>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:</p>
  
  <p><a href="https://i.stack.imgur.com/hZpSc.png" rel="noreferrer"><img src="https://i.stack.imgur.com/hZpSc.png" alt="site.css skipped in Network tab"></a></p>
  
  <p>Above is a portion of the network tab from the dev tools session. Nothing has been filtered out, but <code>site.css</code> has no entry in the list of requests, even though other cached stylesheets are present <em>and</em> the styles from <code>site.css</code> are being applied to the page. There are entries for <code>theme.css</code>, jQuery, AdminLTE, and other stylesheets specified just after <code>site.css</code> in the same <code>&lt;head&gt;</code> block. It's not pictured, but the fontawesome.woff2 webfont file, specified in <code>site.css</code>'s <code>@font-face</code> declaration for "FontAwesome", is also being successfully loaded.</p>
  
  <p>Refreshing the page or navigating to another one sometimes fixes the issue. Refreshing with cache disabled <em>always</em> fixes the issue. Every page of our (quite large) web app loads this stylesheet using the same <code>&lt;link&gt;</code> tag, and while this issue pops up fairly rarely, it has happened across many of those pages. The <code>site.css</code> stylesheet is clearly being loaded by Chrome, as it sees the <code>font-family: FontAwesome</code> 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 <code>@font-face</code> and specified as the <code>font-family</code> for the affected elements.</p>
  
  <p>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 <code>?[productName]Version=2.0.13292.0</code>), 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.</p>
  
  <p>Has anyone experienced anything similar with Chrome webfonts?</p>