Thinking of switching to a system font stack? Wise choice!
Speed tests revealed that hosting Google fonts locally was faster than calling them from Google's server.
But speed tests aren't everything. To the human eye, there was no perceivable difference.
In the same way that sleight of hand deceives the eye, even a 500ms difference in font loading speed is imperceptible to you and I.
But switching to a system font stack is the single biggest factor responsible for my site now loading almost instantly!
System fonts require no download time by the browser.
Why Do Google Fonts Slow Down Websites?
It doesn't matter whether Google web fonts are called from your own server or Google's, each font face has a different load time.
Key CDN did an interesting case study to establish which are the fastest loading Google fonts.
Additionally, each font style being called adds to the page load time. Google's servers are erratic and I've seen load time fluctuations from 120ms to 642ms per font style, within the space of a minute.
I was using 2 font families on this site. A serif font (regular, italic and bold) for content and a sans-serif font for navigation, buttons and pagination.
GTMetrix tests reflected acceptable contentful paint times of anywhere between 400ms to 600ms. Yet to my eye, the site wasn't performing. And it wasn't a browser issue.
I was overwrought seeing some sites loading really fast while mine felt like it was lagging.
Being the tenacious person that I am, I wouldn't succumb to a slow WordPress site.
I'd previously tested my site out with the Georgia font and its use had made a very noticeable difference to loading speed. It works on Windows and MacOS but not Unix+X. That being the case I reverted to my Google webfonts.
With persistence, I discovered how to properly use a system font stack. This allows one to specify the most apt system fonts for each operating system. Knowing that the site would look good across the board, I switched to system fonts.
We'll get to how to do this shortly.
In the meantime, let's look at why Google fonts are slow to load?
Besides the number of fonts and styles playing a role, let's look at some other factors giving rise to weak performance.
- Server Speed.
- Google fonts are render blocking.
- The SSL handshake.
As you probably already know, web hosting is the #1 factor affecting site speed.
Google fonts are compressed and their servers (plus CDN) are highly optimized for speed.
Irrespective, considering the number of requests from the millions of sites using their fonts, it's inevitable that the servers come under pressure. As mentioned already, I had fluctuations of up to 642ms per font style and that just destroys perceived load time.
I did find that hosting Google fonts on my own server had a very positive impact on speed. But then I host this site on a Linode server with Cloudways so it's incredibly fast.
Cloudways offers the best value for money cloud (VPS) hosting in the marketplace.
Plans start at $10 per month and work on a Pay As You Go pricing model. There are NO CONTRACTS!
I switched from Siteground because they're too expensive and I had some real bad experiences with them.
Compared with Siteground's cloud hosting at $80 per month, the same resources (bandwidth RAM and web space) with Cloudways cost $42 per month!
Use PROMO CODE: WPMM25OFF to get 25% off your first two months if you decide to host with Cloudways.
Even if you switch to system fonts, I’d recommend you give Cloudways strong consideration.
Google Fonts Are Render Blocking
Before a web page can be painted by the browser, the page's HTML must be completely parsed.
But stylesheets block the HTML parser until they themselves have been parsed. This happens because the CSS is required by the browser in order to format the page and display fonts.
Because Google fonts are called from CSS, their downloading delays paint times (rendering).
By comparison, system fonts (hopefully called from an appropriate system font stack) require no download time by the browser because they're built into the user's operating system.
The SSL Handshake Affects Speed
When fetching a site over a secure connection (HTTPS), an additional layer of encryption is added to the HTTP protocol.
The handshaking process over HTTPS requires and additional 2 round trips for the connection to be established when compared with HTTP.
Fonts called from Google servers are made over HTTPS. Moreover, with Google giving preference to SSL sites in SERP and considering that over 84% of pages viewed in Chrome are over HTTPS, chances are high that your font loading speed is being affected by SSL handshaking.
System Fonts Eliminate FOIT And FOUT (FOUC)
Slow loading fonts and/or a slow internet connection can both give rise to FOIT and FOUT.
I've already written about FOIT and FOUT in the following two posts:
While it's debatable which is the lesser of the two evils, it's better to eliminate both. Neither are good for user experience.
font-display: auto | block | swap | fallback | optional property was recently devised as a mechanism to override default browser behavior in order to keep text visible during page loading, thereby eliminating FOIT. It’s successfully achieved, however, this at the expense of FOUC.
Reverting to system fonts using a befitting system font stack is the only surefire way to eliminate both evils while improving page load times in the process.
For a site like this one, where content takes precedence over design, this has proven to be an ideal solution.
What Is A Font Stack?
A font stack is a collection of fonts specified in a site’s stylesheet, in preferential order, for use on an “if not this, then that” basis.
It is deployed as a means to display, either temporarily or permanently, one or more fallback (system) fonts in the event that a webfont is unable to be presented due to lengthy download time.
This is what my font stack looked like before switching to a system font stack:
font-family: 'Cormorant Garamond', serif;
As simple as it is, it’s effective. It allows the user agent to select a serif fallback based on available system fonts for the operating system in use.
However, it doesn’t address the possibility of a user having installed another font on the system. In such a case, the fallback font displayed may not be a default system font and the site may be rendered as intended. [NOTE: I have purposely elaborated on this so as to give you a broader background understanding into the workings of a system font stack].
Nevertheless, I’ve seen more elaborate fonts stacks, for example:
font-family: 'Roboto', 'Helvetica', 'Arial', sans-serif;
If Roboto cannot be displayed the browser will fall back to Helvetica and if that cannot be displayed it falls back to Arial and eventually to the closest sans-serif font that can be displayed.
A system font stack works in a similar way but but is more complex in that fonts are specified in a particular order so as to correctly display the most apt system fonts for each operating system.
How To Implement A System Font Stack
If you switch to system fonts please make certain to disable all calls for Google or other web fonts.
How you do this will depend on your theme and the way that web fonts are called. For example, you may need to remove @import from a stylesheet, a script from your HTML document or dequeue a style.
For me it was as simple as commenting out this line in the functions.php file.
But then that’s the beauty of a StudioPress theme running on the Genesis framework.
For testing purposes only, I applied the following font stack to each and every element in my stylesheets:
font-family: 'Arial', 'Helvetica', sans-serif;
I suppose you could call this a system font stack, just that it’s not a very good one. It’s more of a way to specify websafe fonts with fallbacks.
A true system font stack is more comprehensive in the way it caters for different operating systems and user agents (browsers).
|Font||Device And OS Targeted|
|-apple-system (San Francisco |
in Safari; Helvetica Neue
and Lucida Grande on older versions)
|iOS Safari, macOS Safari, macOS Firefox|
|BlinkMacSystemFont (San Francisco)||macOS Chrome|
|Segoe UI||Windows (Vista onwards)|
|Roboto||Android, Chrome OS|
|Oxygen / Oxygen-Sans||KDE|
|Fira Sans||Firefox OS|
|Droid Sans||Android pre-Ice Cream Sandwich|
|Helvetica Neue||macOS versions|
It's important to construct the order of the system font stack in such a way as to ensure that the first font will actually be the user's system font.
If the order is incorrect, a cached (or other installed) font may be displayed instead.
I'll illustrate by way of an example pertaining to a Windows based system:
Segoe UI is a Windows specific font. If Roboto were to be specified before Segoe UI in the font stack and assuming it were cached in the user's browser or installed on the system, it would be [incorrectly] displayed, thereby negating the intended use of a system font stack.
[NOTE: Android developers on Windows with Roboto installed: List Segoe UI before Roboto in order to use it instead of Roboto].
Here are some well known sites that use system fonts together with the exact system font stack used.
-apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif;
BlinkMacSystemFont, -apple-system, Segoe UI, Roboto, Helvetica, Arial, sans-serif;
-apple-system, BlinkMacSystemFont, San Francisco, Helvetica Neue, Helvetica, Ubuntu, Roboto, Noto, Segoe UI, Arial, sans-serif;
-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Fira Sans", "Droid Sans", "Helvetica Neue", Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
Inter, -apple-system, BlinkMacSystemFont, Segoe UI, Helvetica, Arial, sans-serif, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol;
-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
Wpmediamastery.com (This site)
-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
The font stack is applied to the font-family declaration.
Go through your stylesheets and replace all elements containing webfonts with your system font stack as seen above, e.g. headings, tables, navigation etc.
This is where well coded themes are desirable, such as StudioPress which runs on the Genesis Framework. They’re lightweight, optimally coded, blazing fast and SEO optimized.
With StudioPress (Genesis) themes, there are 2 stylesheets that you need to concentrate on when applying a system font stack.
- style.css – the main stylesheet that contains all of the typographical elements where you’ll need to add the system font stack.
- style-front.css – applies to the widgetized home page (not applicable to a static front page) where you’ll also find font-family declarations.
Why not grab yourself a super hot deal on a StudioPress theme. With a single lifetime theme you get . . .
- UNLIMITED use on unlimited domains.
- Lifetime support.
- Lifetime Updates.
- No annual recurring fees.
Seriously, the best way to test the difference in speed is to judge the way your site loads before and after using system fonts.
For me, switching to system fonts made a marked difference to the speed of my site.
Always remember that speed tests are not always the best judge. A busy speed test server can easily provide skewed results.
Nevertheless, I ran a GTMetrix test because it's the only way to illustrate the speed of my site.
And then a Pingdom test.
The site loads so fast that Pingdom can't even capture a screenshot!
The most time consuming thing for me was doing the research and finding out how to use a system font stack to properly display system fonts on all operating systems.
And if I say so myself, I think my site looks pretty darn good.
Switching from web fonts to system fonts shouldn't take much longer that 10 minutes but you'll be richly rewarded.
Just copy my system font stack above and replace the relevant elements in your stylesheet/s.
Now that I've made it easy for you, are you going to give it a try?
Let me know in the comments.