Why Google Fonts affect content readability – and mobile speed.

WordPress Mobile Speed

Updated: May 2019


There are no affiliate links on PagePipe.

When it comes to fonts, there are many web myths and unsaid facts. Especially concerning mobile speed.

The Google Fonts API serves the fonts listed in the Google Fonts directory. You cannot control Googles headers (including expiration headers). According to the Google Fonts FAQs, their font files are cached for a year. If so, why the PageSpeed Insights render blocking error?

 
Google’s CSS files associated with the font are only cached for 24 hours. Speed test expiration information shows this. That is how long browsers store the asset in the browser. Best practice is setting a 1-year expiration. Far futures expiry plugin controls this or you can hand code your .htaccess file on your server. We prefer the plugin.
 
Google calls its CSS files every time. This is for “font freshness” – updated versions. But that’s a Google smokescreen. Google says, “It’s for fast support of font changes.” Every font changes every day?
 
Daily updates? Really? It doesn’t churn that fast.
 
Ironically, Google Fonts fail Google’s own PageSpeed Test. It generates an error: “Eliminate render-blocking JavaScript and CSS in above-the-fold content.”
 
There is a plugin for hosting the fonts on your own web server (local). Not on Google servers (remote). Then you can do “far future expiration.”
 
 
and
 
 
We don’t use either plugin. We remove fonts. Some caching plugins allow “bundling” webfonts as an option, too. We’ve never seen those work yet.
 
Google, claims to encourage PageSpeed. But they don’t even cache their own fonts Why? A nice data collection opportunity for them. Wake up. It’s for their benefit – not you. There’s also a plugin to merge all font files into one – concatenation. This combines many webfonts into one request.
 
 
We’ve messed with this plugin and never can see it working in speed tests. So we’re not believers yet. But 6,000 other suckers believe.
 
It’s theoretical. When millions of websites all link to the same fonts, they are “ideally” cached. After loading the first font, it should appear “instantly” on all other later visited sites. But that isn’t true in all case or even in most cases. Google sees 1 CSS request per font family, per day, per user browser.
 
That request occurs most often on the most critical first impression. Those are visitor landing pages from the SERPS. Secondary pages don’t have the same visitor expectation for speed. So don’t decorate your main top10 pages. Keep those lean.
 
A single font request may take only 50 milliseconds. To put that in perspective, that’s the same speed as GeneratePress (free) theme.
 

“Web fonts are likely to enhance the performance, maintainability, and accessibility of your page” is a quote directly from Google.

 
That isn’t even a partial truth. Another Google deception. They aren’t that stupid to propose fonts improve site performance.
 
When you use a Google Font, you may load the entire set in the font family. Not a single style like “regular.” There may be many weights. This usually adds around 300 milliseconds to a critical first page (guesstimate). Now that doesn’t include delays caused by loading extra languages of the font set.
 
If you use an <i> tag (italic), which is quite common, that loads the italic font variant. Another 100 milliseconds wasted. If you call 10 font variants you produce a 1-second cumulative delay for fonts. That is very possible on branded sites (H1, H@, bold, italic, etc). Half the 2-second performance budget gone.
 

Google downplays the impact of their fonts on page load time. Especially for mobile phone users.

 
Font loading behavior varies depending on browser type. Some browsers only display text after font files load. Others will use the fallback font from the font stack and then refresh the page when the font is available. This behavior is the “flash of unstyled text,” or FOUT.
 
Websites include 3 fonts on average. These fonts are around 100K in size each. Fonts load after the HTML and CSS sources.
 
Staring at invisible text – or at font-swapping shifts – is unacceptable. The best option is giving up on custom fonts and relying on web-safe fonts. That’s our choice and preference.
 
We can’t describe the loss felt the day we threw our print type collection in the trash. It was something we loved. It was part of orchestrating the mood of a well-designed printed page. We let it go for a better mobile user experience. Gone but not forgotten.
 
Major content platforms (such as Wikipedia, Medium, WordPress and Github) use system fonts. They’re available for use on computer operating systems. This is a worthwhile strategy when styling is not a primary concern like small mobile phones. Not referring to tablets! On heavy-traffic mobile sites, traffic is 20-percent tablet visitors. The 80 percent bulk is small phone screens.
 

Blogs claim, “Great typography is crucial on the web” for readability, legibility and “well-crafted typographic design.”

 
Is well-crafted a must for brand recognition and the success of your message? We say credibility and readability trump branding. Frivolous branding requires special fonts. They’d do better paying attention to other readability details. Like not using small, squinty fonts or low-contrast gray colors.
 
Fast-loading mobile (modern?) font stacks look something like this in CSS:
 
body {
font-family: -apple-system,
BlinkMacSystemFont,
“Segoe UI”,
Roboto,
Oxygen-Sans,
Ubuntu,
Cantarell,
“Helvetica Neue”,
sans-serif;
}

Google says one thing. We say the opposite. What’s the truth?

 
We strip fonts unless a site already achieves under target speed goals. Then they’re ignored. But generally, we disable them. Site users are oblivious to the differences.
 
Trends in mobile include new speed themes like GeneratePress and Tiny Hestia. And the new Twenty-nineteen default theme. Out of the box they enable mobile font stacks defined in the style.css file. They don’t use Google Fonts. Fonts have a stigma for mobile. They consume unnecessary bandwidth and data limits.
 
Single-column, 350-pixel wide images or resized images are what’s served up. All that matters is legibility and readability. Creating any mood is from color choices. Color combinations recall memories. Memories have feelings associated with them. It’s a subconscious influence.
 
How much “mood or emotion” can you muster in a small 5.5-inch screen space? Be honest. Small blocks of color whizzing by with the flick of a thumb. That’s mobile user experience? More like roulette.
 
Stripped-down “speed themes” often don’t enable jQuery by default either. If you resist the temptation to install a slider, top-of-page button, or some other jQuery intensive plugin, you avoid the extra load. Themes did this in the past (like Susty, Frank and Sobe themes) but were seen as esoteric or fanatic and not well received. Now it’s a mainstream trend. The Herd wants extreme modifications because they suppose speed will save their site. Speed never compensates for poor content. Ever.
 
Discarding font baggage and jQuery are nuances for speed. They make for fast themes. But you can destroy that with a few popular plugins. Then the gain is minuscule by comparison. Dwarfed by thoughtless plugin abuse.
 

Fussing about choosing Google Fonts is wasteful.

 
Theme authors retrofitted speed change based on requests from users. The demand was high enough and thus offered the chance to sweeten the deal.
 
This means using Google Font usage is now seen as painful to speed and UX. And thus SEO. Big deal.
 
You don’t have to install a plugin to remove Google Fonts on these speed themes. The theme loads are transparent: meaning less than 50 millisecond load times. But if you buy the premium version, they’re no longer the fastest kid on the block. They don’t tell you that fact. The themes then are more average than special.

Human eyes have limitations. There’s a theme trend to use light-gray type on web pages. This is not good UX. But designers, who should know better, are setting bad examples. Black on white was the standard for many years. That color combination is fatiguing when reading a large block of text onscreen.

The recommendation is #333 dark-gray on white to reduce harsh contrast. But going lower contrast than #333 makes viewers squint to attempt reading text – even when the font size is 18px. We recommend using browser tools for checking font specifications including color and size. We use FontFinder for Firefox. There are equivalent tools for Google Chrome.

FontFinder type specification tool using Google Chrome.

 

“An article about how the web is becoming unreadable has been making the rounds. I feel like most designers already know that light gray text on a white background is a bad idea. The article focuses on text color but I think a more relevant issue is font weight – I’m seeing so many sites these days set body text in 100 and 200 weights which were not designed for body text use.” — Jeremiah Shoaf of TypeWolf

How the Web Became Unreadable
I thought my eyesight was beginning to go. It turns out, I’m suffering from design. by Kevin Marks

Look at these websites. They look fabulous indeed but how good is that if people can’t read them?

Light-gray text is fake minimalism.

“Minimalism in web design started as a backlash against decades of interfaces that increased the prominence of so many elements at once that they all clamored for attention and became visually overwhelming.

What’s great about minimalism is the principle of stripping out non-essential elements. In most cases, this is a best practice to follow.

When it becomes an issue is when there is lots of essential content on a page. Having a lot of content doesn’t suit the minimalist approach to design. So the designer’s compromise has become reducing the contrast of those elements so that, at a glance, the page still ‘looks’ minimal.

Yes, low contrast text does ‘look’ minimal, the same way a blurred photo on Instagram can ‘look’ retro. But you wouldn’t blur your website even if it were fashionable. Don’t lower your contrast, either.”Nielsen Norman Group

Easy reading helps learning and enjoyment, so what we write should be easy to understand. Readability is about ease of reader understanding. Text should be inviting. Text depends on content (vocabulary) and typography (font size, line height, and line length).

Readability Plugins for WordPress
An interesting article about web readability mentions several WordPress plugins that help assess the readability of body text. The one plugin we feel is most appropriate (because it’s lightweight) is: FD Word Statistics Plugin. It shows word and sentence counts at the bottom of the WordPress editor. Plus a readability analysis of the page or post currently being edited is shown using three different readability measurements. Those are the Gunning-Fog and the Flesch-Kincaid indexes. (Plus one labeled Flesch that we don’t care about).

Various factors to measure readability have been used, such as speed of perception, perceptibility at a distance, perceptibility in peripheral vision,  visibility, the reflex blink technique, rate of work (e.g., speed of reading), eye movements, and fatigue in reading.

Readability and legibility aren’t the same. Legibility is a measure of how easily individual letters or characters can be distinguished from each other.

The average adult reads at the 9th-grade level. It also shows that, for recreation, people read texts that are two grades below their actual reading level.

Four variables give the most reliable measure of web reading ease:

  • Words per sentence.
  • Average grade level of words.
  • Characters per word.
  • Sentences per paragraph.

Readability should be your number one goal. Someone in your company or organization should especially check graphics to ensure they’re readable. This means:

  • No “reverse” (white body text on a colored background, which is hard to read).
  • As few italics as possible (they’re hard to read).
  • Not too much boldface (ditto).
  • Not too much super-wide full-width copy (ditto).
  • No type above headlines (confusing).
  • No hard-to-read colors like light grays. There should be a 30% grayscale differential between text color and background color. We search for edges of letters for character recognition.

 


Measure onscreen font sizes in pixels using the Firefox browser tool: Font Finder or the Google Chrome browser tool: WhatFont.

6pt, 8px, 0.5em, 50% Sample text

7pt, 9px, 0.55em, 55% Sample text

7.5pt, 10px, 0.625em, 62.5%, x-small Sample text

8pt, 11px, 0.7em, 70% Sample text

9pt, 12px, 0.75em, 75% Sample text

10pt, 13px, 0.8em, 80%, small Sample text

10.5pt, 14px, 0.875em, 87.5% Sample text

11pt, 15px, 0.95em, 95% Sample text

12pt, 16px, 1em, 100%, medium Sample text

13pt, 17px, 1.05em, 105%, Sample text

13.5pt, 18px, 1.125em, 112.5%, large Sample text

14pt, 19px, 1.2em, 120% Sample text

14.5 pt, 20px, 1.25em, 125% Sample text

15pt, 21px, 1.3em, 130% Sample text

16pt, 22px, 1.4em, 140% Sample text

17pt, 23px, 1.45em, 145% Sample text

18pt, 24px, 1.5em, 150%, x-large Sample text

20pt, 26px, 1.6em, 160% Sample text

22pt, 29px, 1.8em, 180% Sample text

24pt, 32px, 2em, 200%, xx-large Sample text

26pt, 35px, 2.2em, 220% Sample text

27pt, 36px, 2.25em, 225% Sample text

28pt, 37px, 2.3em, 230% Sample text

29pt, 38px, 2.35em, 235% Sample text

30pt, 40px, 2.45em, 245% Sample text

32pt, 42px, 2.55em, 255% Sample text

34pt, 45px, 2.75em, 275% Sample text

36pt, 48px, 3em, 300% Sample text


Godspeed—

Steve Teare
performance engineer

Mobile WordPress Speed – without coding!

Coming Soon to PagePipe readers.

Other Related Resources

If you’re new here, start with our best primer speed articles.

If you’re ready to give your WordPress site wings, here are powerful tools to speed up your site.

Learn how the most popular plugins and ideas waste your time – and hurt web speed. Includes important tips for mobile speed without coding.

Build with Empathy
GIVE SPEED