If your website is ‘international’, you’ve probably already run into this. If you’ve ever worked for cooperate America, you’ve seen this happen. If you’re on an out of date browser, you’ve definitely seen it.

It’s that horrible day when your site looks like absolute crap because something critical to your site isn’t loading because it cannot be accessed from where you are.

Let’s step back.

A wall of fire from a fireball

Using Google’s Open Sans doesn’t work in China because Google is, generally speaking, blocked in China. What does this mean for people there? Well their WordPress dashboard is going to load slowly, in fact for many it’s so slow as to be unusable. This is because WP 3.8 uses Google fonts on the back-end. Now, you can disable it with the Disable Google Fonts plugin, but many people feel that’s a poor user experience.

I want to take a moment to note that while I, personally, dislike using Google for required fonts on WordPress, there was a discussion on bundling vs linking that took place in November 2013. At that time, everyone agreed bundling (that is including the fonts with WP) would be best, however how to do that was more complicated. In order to provide a good experience for all users and all languages, it got messy and large really fast. You can read up on the history on make/core: Open Sans, bundling vs. linking.

That being said, by remotely calling Google, there are two main issues: privacy (which I’m not getting into) and accessibility (that’s what I want to poke at).

We know that calling Google remotely, for everyone in a country with good internet speeds, is great as it speeds up your site! That’s the premise behind Use Google Libraries after all. If someone’s already downloaded the files in their cache for JS (or fonts), then the next site they visit will load faster if it uses the same ones! It’s a sound, and accurate, theory.

But are you making your site inaccessible with your need for speed?

What happens when someone can’t load Google? In the case of the Use Google Libraries plugin, it falls back to using WP’s standard, which is good, but that initially connection has to fail first! The same happens for WordPress’s back end, which means the time it takes to load your site is longer for those users.

I tell this to people a lot, and generally they reply “Well I don’t have users in China.” or “This doesn’t affect my visitors.” Really? REALLY? Sorry, but that is one of the most shortsighted views I’ve ever heard in the history of ever, and one I tell people “Yeah, that’s an incorrect and rather arrogant conceit.”

Mt. Fuji

Let me tell you a story. I went to Japan for 12 days to hike O’Henro with my Buddhist brother and our agnostic father. We made the “A Jew, a Buddhist, and an Agnostic walk into a temple…” jokes. While there, I checked in on my websites and on my regular sites I visited, only to find out that some were blocked because we were using a net connection that went through a country those sites blocked. Why? Because “no one” who would ever visit their site was from there.

I no longer use those services, I no longer support those sites. My father goes to China regularly (he does risk assessment on the disused weapons caches in China). I turn off Google Fonts on his website in order that he, and his customers, can see the site as intended. You can tell me all you want that ‘no one’ visits from those places, and you’re just wrong, and arrogant, and yes, I strongly disagree with WordPress having made Open Sans via Google a requirement like that.

My personal dislike of Google aside, it’s a reality I look at more than I wish I had to that people and places block third parties. This is why I get on the case of plugin developers who use third-party services when they don’t have to. They’ve created an unnecessary dependency on this other service, which will crazy to debug when someone says their code doesn’t work.

Your code should be as self-sufficient as humanly possible. Offloading for ‘speed’ doesn’t work for all situations, and instead can make things slower by causing more external resources to load. Have you ever looked at those scan reports where they say your site calls too many sites for JS or CSS? This is what you’re doing. Even though it increases the odds that people who can get to these sources will already have the files cached, people who can never access them have a worse time. And then loading them locally will make your site heavier and load slower, unless you use proxy-caching (like Pagespeed or Varnish).

It’s not a perfect solution for everyone. This is why websites are hard.

Reader Interactions


  1. Kirsten says:

    Hi, Mika!
    Interesting thoughts. One of my clients can’t see Google fonts because of the firewall in his office. The office is not in China but in Germany. Took me some time to figure out why he was complaining about the strange typography…
    So, what’s the solution? To host all the fonts on the website’s server? That’ s what I did in the case of my firewalled client.
    But is it a good way to go?

    Cheers, Kirsten

    • @Kirsten: Germany has some pretty firm laws (yes, law) about tracking, and embedding remote fonts actually fall under that, so they’re often blocked. I include the needed fonts on the webserver, myself, in that situation.

  2. I was also against that move too. My concerns were mostly related to privacy though. To my mind, WordPress should keep data private by default.

    I hadn’t realised that browsers could lock up like that just due to a font not existing though. I assumed they just served the wrong font.

    • @Ryan Hellyer: Depends on how they’re blocked. China does a weird thing where it either redirects you to wherever they track evil google users OR it kicks you right to ‘not accessible.’ If it’s just not accessible, it fails after whatever the timeout is, but either way it has to timeout to fail. That’s where the hanging comes in.

  3. To all those users who are suffering because of Google Fonts why not block it on your own device!! Edit your hosts file and place the following line in it. fonts.googleapis.com

    Windows users can find this file at C:\Windows\System32\drivers\etc\hosts

    Linux – /etc/hosts

%d bloggers like this: