More than half the top 1 million websites use Google Fonts. This is not the best practice for mobile speed.

The inaccurate Web Font defense:
“Without Google Fonts we’re limited to a handful of system fonts installed on our user’s device.”

So what? Is this a bad problem? Since when? Web safe fonts are not recognizable to the average web visitor. Google web fonts caused internet dilution. That doesn’t mean web fonts are better. Variety reduces imagined stigma from using “ordinary” fonts.

OFFSITE LINK: 33-amazing-web-safe-fonts-why-you-need-them

There is a justifiable condition for using Google Fonts. That’s when there are no other graphics differentiating your page. The font is then the only thing. It’s the bottom-most design consideration for mobile devices. Color combinations are a much more important factor.

Unaware clients talk about their logo size. Then it’s “What font will we use?” Please select one that’s readable and fast on a mobile device.

For speed, GeneratePress theme uses the default mobile system font stack: -apple-system, system-ui, BlinkMacSystemFont, “Segoe UI”, Helvetica, Arial, sans-serif, “Apple Color Emoji”, “Segoe UI Emoji”, “Segoe UI Symbol”.

This method makes practical sense.

System fonts or ‘Web Safe Fonts’ are common and pre-installed across operating systems. For example, Arial and Georgia come with Windows, macOS and Linux distributions. They load fastest.

Default fonts are utilitarian. That’s good for mobile speed. We do not consider decorative body text important for small mobile screens. Readability and legibility are what count.

Web safe fonts are still preferred over requesting cached Google Fonts.

Google Fonts come with a speed cost. Each font carries a weight that the web browser needs to download before display. In worst case conditions, users wait seconds. That should be reason enough not using Google Fonts. Do Google Fonts cause delays or failures every time? No. Only sometimes. Why? Because they’re hosted from remote servers getting millions of simultaneous API hits.

Claiming “Google Fonts Are Already Optimized” doesn’t buy much in our book. Even optimized they’re never as fast as system fonts. Never.

The Google Fonts API does a “smart check of browser type.” That’s to see how it can deliver files in the most optimized and compressed format. For example, detecting the latest Chrome browser may need only one font type. Google then sends only one font variant instead of a whole font family. That is a speed improvement. Yet that still isn’t faster than system fonts. This is a workaround (kludge?) not providing any improvement over web fonts.

“Google Fonts maintains 30+ optimized variants for each font and automatically detects and delivers the optimal variant for each platform and browser.” — Ilya Grigorik, Web Font Optimization

Wow! Big hairy Google deal.

Does that cool technology specification make us feel better? Google has performant font formats for old browsers. It’s not a feature – it’s a bug fix.

“As the Google Fonts API becomes more widely used, it is likely visitors to your site or page will already have any Google fonts used in your design in their browser cache.” — FAQ, Google Fonts

Because half of websites use Google Fonts, it’s often claimed there’s no waiting. What? There’s no waiting for web safe fonts either. In fact, there is no “first-time-view” without cache for websafe fonts. Web safe fonts are always available.

Google Fonts aren’t completely cached for far-future expiration for more than 48 hours. Why? Google says it’s because they may change something and the fonts need “refreshing.” Wait?

Is Google saying there is a benefit to not caching older versions? None whatsoever for you. Only Google benefits gathering data more often. Every single visitor need a new fresh font file within 48 hours? No way.

Each font can add up to 400 kilobytes to your page weight. Multiply that by a few different font families and fonts weigh more than your entire 2- to 3-megabyte page. That is never a problem with websafe system fonts. They have an instantaneous load time. Zero seconds. Zero page weight.

For example, the Google Roboto font family weighs 144 kilobytes. But if you only use the Regular, Regular Italic and Bold variants, that number is 36 kilobytes. That’s good savings. Right? No. It’s still slower than websafe fonts. Get serious.

Web fonts need calls to Google’s servers (example: fonts.googleapis.com), that’s called an HTTP request. The more HTTP requests, the longer it takes your page to load.

You can call more fonts in a single request. There is no limit to how many fonts and variants a single request can hold. There are plugins to do this trick. But we’ve seen no speed benefit over using websafe system fonts. Even if you use a plugin to host Google Fonts locally on your server, they aren’t faster than system fonts. It’s a weak method to try and hang on to the sluggard.

It takes time for the browser to download Google Fonts, but what happens to the text before they are ready? Showing nothing at all is jarring to the user. A better experience is to show a system font as a fallback and then “swap” the fonts once they are ready. This is possible using the CSS font-display property. This is a ridiculous strategy. Why not avoid the hassle and use the system font? That’s right.

Forget Google Fonts.

There’s not enough time to test all new free WordPress themes for speed potential. So we set easy limitations to reduce our workload. We look for signs or clues of author sloppiness and wasteful shortcuts.

The ideal speed theme is a download file of under 1M-compressed. This is our arbitrary threshold and indicator for speed potential. Once decompressed – and with the demo screenshot subtracted – it will total between 1M and 2M. These generally create 500-millisecond to 2-second page loads. And that’s on cheap, shared hosting.

It’s plain many themes above this 1M-download cutoff may be fast. But we don’t want to mess around searching. It’s also rare for a theme to make written guarantees. Nothing about speed, page weight, or even the number of HTTP requests. Many imply they’re fast. But they don’t give specifications.

A 1M cutoff drastically reduces the number of theme candidates. This is a quick-and-dirty filter. It prevents you from wasting time on themes with low-speed potential. The package size is indicative of the theme author “caring” about performance.

Note: A lite theme means it has crippled features or stripped down from the “pro” paid version. Lite doesn’t mean lightweight.

The nine free themes listed below all have commonalities. We won’t put them on any preferred list. Even though some are attractive. We’re using them to prove some font facts. For us, they’re toward the bottom of the speed barrel – but still pass the 1M limit barely. They have 1-to-2 second page-load potential. They aren’t as forgiving as other less “feature-rich” themes.

Why aren’t they so good? They have built-in site drag. They weren’t authored with speed as a priority. That’s indicated by the frivolous, slow “non-features.”

What are non-features? Unnecessary bloated decorations. Expressive aesthetics like animation. They all use cloud-based Google fonts. And they all have Font Awesome icon font onboard. Four use sliders. Sliders activate JavaScript and are heavy and easily abused. (Read our article about sliders and why they are bad for speed.)

But in spite of these infractions, the themes still pass.

The Font Stacks

• Martial-lite theme: Arimo, Roboto
• Period theme: Roboto, Open Sans
• Lontano theme: Raleway, Hind Siliguri
• Weblog theme: Josefin Sans, PT Sans
• Bohaute theme: Merriweather
• University-hub theme: Roboto
• Barletta theme: Glyphicons-haflings
• Benevolent theme: PT Serif,  Raleway
• Snowbird theme: Droid Serif, Anton

We ask ourselves, “How much speed difference does font baggage make?” So we did some testing with the help of free plugins.

Asset Queue Manager
This plugin is almost a secret. Only 900 installs. It’s used for hardcore performance optimization. It allows us to switch off (dequeue) Font Awesome. Of course, it’s used for dequeuing other scripts, too. But we’re just using it for our Font Awesome experiment.

Font Awesome is a font and icon toolkit released in 2012. And quickly became a crutch for theme authors to create “cheap art.” Twenty percent of websites with third-party fonts use Font Awesome. We find it on half of the new theme releases. It ranks second place after Google Fonts. We hate it because the lightest version uses 70 to 80k of page weight globally. And it has no websafe system font fallback like when using a CSS font stack. That means if we disable it, the site may look broken. Not always. Just especially mobile pages.

Frequently, Font Awesome loads on every single page whether there are any icons used or not. That’s bad for mobile bandwidth usage. Font Awesome may be loaded in parallel with other page assets. That makes the drag invisible to users. So why do we even care? Requested font data is still transferred on each page. And that costs someone time and money.

The inclusion of Font Awesome is a solid indicator of a slow theme. Authors who care about speed don’t include it ( Astra, GeneratePress, and Twenty-seventeen default theme are good examples). They let the site owner decide to install it with a plugin if needed. Like Better Font Awesome plugin.

Our other beef with Font Awesome is that only three icons are traditionally used. These are:

• the magnify glass for search fields
• the mobile navigational “hamburger”
• the up-arrow on top-of-page links

(Also social icons. But that story we’ll save for another day.)

You could make 70 PNG image icons with the same total weight – or less – than Font Awesome. It’s equal to a hero header image. We’d rather not see any icons – either font or image. Overused and boring.

It’s possible for a theme to load Font Awesome – and then a plugin may load it again, too. This duplicates the global load. Doubling the additional page weight by around 150k. Wow. That sucks.

Is it worth removing or dequeuing Font Awesome? Nope. You might save 50 to 100 milliseconds. But, it usually will break something somewhere. Not always. Some theme authors don’t use Font Awesome for the hamburger and magnifying glass. They are merciful. Those authors deserve a medal for going the extra mile.

Is it worth finding a theme that doesn’t use Font Awesome? Yes. We think so. We hunt for those jewels. Remember half of new themes don’t use this iconic boat anchor. (The same statistic goes for unneeded sliders. Half do. Half don’t.) But leaving out Font Awesome is usually futile. It won’t make any noteworthy perceived speed difference in tests. It makes a difference in how much data goes back and forth from server to browser. And if you think that browser caching might help, sorry. Font Awesome comes in many oft-changing versions and flavors. That means browsers probably aren’t storing the right one for your users.

Font Awesome sometimes does weird fluctuations and delays loading by an extra second. Why? Voodoo! Why even take this speed risk?

So does removing Google Fonts make a difference in speed?

External font scripts like Typekit or Google Fonts slow down your site. Typekit is the worst for speed. Websafe fonts are guaranteed to be faster. According to HTTP Archive, as of October 2016, web fonts are just over 3 percent of an average page’s overall weight.

Disabling with Remove Google Fonts References plugin makes an average difference of only 53 milliseconds in our tests. But in the extreme, one theme (Martial-Lite) had a 300-millisecond gain in speed. In some cases, there was no change in speed at all.

The difference in weight is anywhere from 60k to 300k. Again, it’s wasted mobile bandwidth.

Would we delete Google fonts and go with default browser fonts just to save 300 milliseconds? You bet. When we’re working on getting under 2 seconds or even 1 second, that can make a big difference.

Again, there are times requesting Google Fonts will throw a 1-second delay. Just like Font Awesome. Why? We don’t know. Go ask Google. And, of course, the more fonts you call the slower things get. There’s a plugin that combines the Google font requests. Google WebFont Optimizer finds every Google Font request. It bulks them all together. Then your website only asks Google once for the fonts, instead of multiple times.

Finally, there are a bunch of elements that have become something of a standard with a modern website design that, while not offensively intrusive, are often unnecessary. I appreciate great typography, but web fonts still load pretty slowly and cause the text to reflow midway through reading the first paragraph. REFERENCE

So our speed recommendations are:

• Find a 1M or less compressed theme.
• If it doesn’t have Font Awesome, it’s best.
• If you can bear turning off Google Fonts, that’s even better.
• Avoid sliders.

Only about 20 percent of new themes meet these criteria. No surprise.

Another plugin alternative for speed: Google Fonts cause slow external requests to Google’s servers. You can host the fonts locally on your server instead. Hosting fonts locally won’t always make your site load faster. If the font is popular (like Lato or Roboto font) and already cached in a visitor’s browser, those fonts load pretty fast. But a plugin exists to help optimize local Google font hosting. It’s CAOS for Webfonts (11.5k zip download). The plugin decreases page load times, leverages browser cache, and minimizes DNS requests.

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.

https://wordpress.org/plugins/selfhost-google-fonts/

https://wordpress.org/plugins/host-webfonts-local/

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.

Remove Google Fonts References plugin

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.

https://wordpress.org/plugins/google-webfont-optimizer/

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, H2, 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:

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 Astra. And the 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.

“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). [/pullquote]

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

---

OFFSITE FONT TEST LINK:
https://fontsplugin.com/google-fonts-checker/