Like many, Chrome is my browser of choice, but the past couple of updates have resulted in some problems specifically with Google web font rendering (as well as some other web font rendering).
I had considered linking to a number of different issues that I had seen in bug trackers, but you can see just how popular this particular issue has gotten by performing a quick Google search.
To be honest, I’m not sure if this is relegated only to Chrome or to all WebKit-based browsers.
Anyway, since Chrome normally does silent version updates in the background, this should be fixed in an upcoming version – last I checked, it was resolved in the latest build of Chromium – but until then, I thought it may be worth sharing one way to fix the issue.
Google Web Font Rendering (A Temporary Fix)
Normally, I wouldn’t dedicate an entire blog post to something like this; however, it hits close to home namely because this site has been impacted by the bug.
There have been a number of fixes that I’ve tried – many of which are CSS based – but there’s only one that I’ve used that has resulted in a consistent fix of the problem and it’s a JavaScript fix:
For those who are familiar with JavaScript and/or jQuery, then you’re already aware of what’s happening, but if you’re not, the above code waits for the page to load, then applies a display:none; to the entire body element, then removes the property right after it has been set ultimately forcing the browser to repaint the page.
I know – it’s a hack, it’s ugly, it may cause flickering depending on how fast your connection is, and it’s basically anything but elegant.
But it gets the job done, it does so consistently, it’s temporary, and it’s the only resolution that I’ve found that works 100% of the time, so when weighed against all other options, this is the lesser of all evils, so to speak.
Of course, if there are other fixes, I am all ears, but until then, feel free to borrow this gist and use it in any of the projects that you have being affected by this bug.
Wow, that is a sledge hammer. But I guess there aren’t really any great alternatives at the moment.
It’s surprising that Chrome of all browsers messed this up so badly. Given their Blink fork, I don’t think we can blame Webkit for this one.
Yes it is – and hopefully it’s clear that I’m not exactly a fan of doing this, but it’s the only thing I’ve found that has resulted in a consistent fix across browsers, mobile devices, and so on.
Agreed. Perhaps what’s weirder is that the problem still exists. Normally, they have things patched up pretty quickly.
This bug is much more annoying on the mobile version of Chrome, since I can’t resize the page as a quick fix if the developer hasn’t implemented something like above.
Yeah – this is where the majority of tweets and emails that I received came from (that is, Android users with Chrome).
Fitvids.js causes the text to not render in chrome. Removing the script would likely help fix up issues on your site.
Interesting. That’s the first I’ve heard of this.
Either way, I’m not so much for removing that particular script right now mainly because I need it for the responsive nature of the site ;).
Yes, after a ton of testing I came to find out that fitvids.js will actually prevent @font-face from rendering on first page load (in Chrome only). There are some much better CSS alternatives to fitvids (both direct code and plugins).
In addition to this little hack, there was another one that I found somewhere on google support forums, made a simple wp plugin (search for ‘chrome font fix’) out of it which loads local fonts until web fonts load. Obviously you know better but thought to share it though. :)
Prerak.
Sure thing, Prerak — thanks for sharing the info!