Embedded Font Causing Rendering Delay on Lonestarball.com

I am a Texas Rangers fan. I grew up in the Metroplex and suffered through season after season as a young boy with a terrible franchise. In recent years I have become an even bigger fan because my dad works at the ballpark. This is not to put my support of the Cardinals on the backseat, but there is a very personal connection to the Rangers in recent years. If you are a fan of sports team, university or TV show you have probably spent time on fan web sites. Lonestartball.com is one of those sites for me. Tuesday night I visited before the game because Joey Gallo was making his major league debut. Something that had been bothering me for at least a few weeks was a very slow loading process. So, you guessed it, I decided to investigate.

Lone Star Ball Home Page

When I loaded the site, there is at least a 5-10 second delay before any content is rendered. When it renders it renders fast. This tells me there is a classic blocking resource problem. So I run the Lone Star Ball home page through WebPageTest to start investigating. For the record I probably run 2-3 different sites a day through WebPageTest I find are struggling because I want to know why, so I do not make the same mistake. For Lone Star Ball the problem was very obvious, the site is suffering from a large CSS file. The file contains a base64 encoded font, which might sound like a good idea, but it is killing the site. A page like the LoneStarBall home page should start rendering in under 1000ms, over broadband I would expect an average of 300ms to start rendering.

Understanding Page Installation and Rendering Cycle

Web developers and designers should understand how a web page loads, but the reality is most do not. The first concept you need to understand is every time someone loads a URL or web page they are installing the page. They must download the markup, which initiates requests for CSS, scripts, fonts, images and other assets that compose the final user experience. Sadly the average home page is now over 2MB, which means this process take time and over cellular networks (GPRS) cost money.

The best practice is to reduce the page weight or how big all the page assets are, but also to add proper caching headers. These tell the browser to hang onto the downloaded file for possible future references. Unfortunately less than half the web does this. However this should not be assumed. Browsers purge cache all the time. Mobile browsers purge more aggressively. So never assume your files are cached, always assume they must be downloaded every time the page or application is requested. This is why I love WebPageTest, it runs an unprimed test and a primed cached run. This allows you to compare what the load experience is like for a brand new visitor and one that returns with all cached assets locally available.

Once files are loaded the page must be rendered. The browser runs a cycle known as the critical rendering cycle. Here the browser composes the markup, combines with with CSS and then applies any JavaScript to the rendering process. You want the browser to run through the cycle once and avoid starting it over again. Browsers will pause the rendering cycle for external scripts and any CSS to be loaded and processed. In the case of Lone Star Ball it loads many external script and CSS files, which cause varying degrees of rendering blocking.

Identifying the Problem

Once WebPageTest runs I typically look at the waterfall. This is where you see details of each asset request, in the order the requests were made. It is called a waterfall because it is very vertical and resembles the water going over the side of a cliff. A good waterfall is not very tall and wide. Unfortunately most waterfalls are tall and wide, indicating too many requests and a long load time.

Lone Star Ball Home Page Rendering Stats

Another feature the WebPageTest waterfall shows is when the browser began rendering content. This time should be as close to initial request as possible. For example this Blog takes about 300ms on average to start rendering. For Lone Star Ball the start render time is roughly 4.5 seconds, 15 times slower than Love2Dev.

By following the green vertical line indicating the start render time down the waterfall you can clearly see rendering is handcuffed by a call to https://fonts.voxmedia.com/196299/17D999CF5D88F3310.css. The CSS file is nearly 700kb in size and takes over a second to download. The file is not requested till after 3 seconds, already a long delay.

Problematic CSS file Load Details

Detailing the Problem

Now that I have found the culprit what is wrong with the CSS file? Obviously it is too large. No site should have that much CSS in play. A typical site should use between 20-60kb of CSS. Even the average site, according to HTTP Archive, contains 62kb of CSS. Clearly this file is too large. In fact Lone Star Ball loads over 827kb of CSS, over a quarter of the entire page weight. While there are many places Lone Star Ball could loose weight, lets focus on this CSS file since it is clearly a render blocker.

Investigating the contents of the file reveal a base64 encoded font embeded in the file. Custom font files have become very popular in recent years because designers can tightly control the typography or how the text is rendered in the page. This can be a nice feature, but it comes at a performance cost and is known for causing a flash on the page when the font is loaded. The flash is caused by the browser rendering the content again to implement the font. This is known is Flash of Unstyled Text or FOUT or FOIT (Flash of Invisible Text). Font files tend to be on the large side as well. So you should always ask yourself if a custom font is a good idea or not.

For Lone Star Ball this font is a font called "Ziggurat A", which is hosted by their design company, VOX Media. In fact the file is referenced via a 301 redirect from http://cloud.typography.com/706184/636620/css/fonts.css. A 301 redirect is another bad practice. Instead they should reference the file directly, but lets focus on the font issue.

@font-face{ font-family: "Ziggurat A"; src: url(data:application/x-font-...

A quick search of the site's source code reveals the font is referenced in a few places in the actual CSS, sbnmodulesc.v35af2c6d8cdec29d.css for example. I also did some basic investigation throughout the site to see where Ziggurat A is applied and I found nothing. The primary fonts on the site seem to be a Sentinal and Mercury font. If I had more time I might run something like UNCSS over the pages to get the used CSS and then reevaluate it, and I recommend you do this before you go to production, it is part of my work flow now.

Comparing Lone Star Ball with MLBTradeRumors and Love2Dev

Just for fun I used a WebPageTest feature that allows you to compare test run film strips against each other. The film strip view is great because it shows what the page looked like over time, as it renders. When you compare Lone Star Ball's rendering experience to another baseball fan site I visit, MLBTraderumors.com and this Blog, you get a visual sense of how bad the experience is.

WebPageTest Filmstrip Comparision

Better Custom Font Loading

When using custom fonts you should use them responsibly. I like to use glyph fonts, but I try to isolate the characters used through a service like Fontello.com. Here you can select the icons characters you want and create a much smaller custom font.

The Filament Group has also done some research on responsibly loading custom fonts and font events. Vox Media should invest some time in these articles and change the way they are loading fonts.

Summary

There are many little things that can drag your page load and render times down. It is not hard to create a fast loading experience, but you need to have knowledge of how the browser works. Unfortunately the average web developer and designer has never considered things like the critical rendering path or network latency. They tend to copy and paste code, which ultimately leads to a poor user experience.

Custom fonts are a good idea when used properly. When used poorly or loaded and not used at all you are killing your user experience. Poor user experience because of poor load and render times are one of the leading reasons people do not visit your site. You have 1 second to make a positive first impression, use it wisely. Lazy load custom fonts or do not use them at all. If you page is loading poorly then use tools like WebPageTest to find and correct your bottlenecks.

Share This Article With Your Friends!

Googles Ads Facebook Pixel Bing Pixel LinkedIn Pixel