Category Archives: Web Fonts

Cursory Perf Audit:

Posted in Front End Engineering, Web Fonts, Web Performance, WebPageTest on by Rick Viscomi.

I’m a huge fan of Quentin Tarantino and so I was excited to find out earlier today that the locations of the large format showings of his new film, The Hateful Eight, were just released. Luckily, the theater a few miles away will be showing it in GLORIOUS 70MM. However, I was intrigued by their promotional website, I wondered about the performance of this site and if there were any interesting take-aways. So I spun up the WebPageTest site and here’s what I learned.

What it’s made of

The Hateful Eight website screenshot.

The home page is 7,079 KB fully loaded, so it’s a heavy page especially considering that the average page size is about 2,200 KB. The page is adorned with a very seasonally appropriate falling snow effect. I can feel the chills running down my spine — not from the freezing weather but from the JavaScript that must be crippling the CPU.

Behind the festive snow, the hero graphic (pun intended) scrolls with a parallax effect. When done right, this actually looks nice considering the depth of the images. Unfortunately, you probably won’t have requisite CPU remaining to get the full smooth scrolling effect. When you do manage to scroll down, you’ll find some lovely portraits of the main characters (which have a tilt effect on scroll) and press clippings. The trouble here, in addition to the Web 2.0 effects, is mostly the images. Because of the parallax effect, the landing graphic is actually composed of three images: the background image of the cabin and woods, the midground image of the characters wading through the snow, and the foreground image of the gunslinging hero. In total, these images are 1,904 KB. Those images alone are almost as big as the average web page!

It’s also worth mentioning that none of the text above the fold is actually text but rather static images. Not only is having to load extra images bad for performance, but it’s also terrible for accessibility as visually impaired users will be unable to have the images’ content read back to them via assistive technology. Speaking of the text, or lack thereof, two custom web fonts are included on the page: Rockwell W01 and Rockwell W01 Bold.

Load time

The WebPageTest results speak for themselves. The most horrifying statistic is the fully loaded time of about 16 seconds; because the content above the fold is entirely composed of images and the onload event waits for all images before firing. As the filmstrip shows, the page doesn’t appear usable until at least 15 seconds, after the images have loaded and their slide transition completes.

How to do better

15 seconds is an order of magnitude slower than what I would be willing to tolerate for a static page like this. There are many performance optimizations that could significantly help this site. Being a cursory perf audit, here are just a few that stand out:

1. Enable Keep-Alive

Seriously. It’s almost 2016 and people still haven’t heard about persisting connections. It’s one of the easiest optimizations out there and it takes less than a minute to implement. Do it.

2. Prioritize the first byte

The WPT “First Byte Time” grade is an F, and rightfully so. It takes almost 2,400 ms just to get a single byte of the HTML response. A page in decent shape would have already rendered by now. There are some nasty server-side issues going on here that WPT doesn’t have the insights to show us. In addition to the previous connection issue, these need to be fixed before all other optimizations because this directly impacts the lower limit of how fast this page can be. Even with a perfectly optimized client-side page, it will still be no faster than 2,400 ms and that’s a big problem.

3. Delay loading content below the fold

Fully loaded, the site has 47 requests, which isn’t too bad. But considering that there are 15 requests made before the first paint and 45 before the DOM Content Loaded event (more than 10 seconds later!) there are some serious prioritization issues. The content above the fold, groovy snow/parallax effects aside, is really just a group of images. Get these images onto the screen as soon as possible by avoiding contention with content below the fold. Don’t even load the subsequent images until the user starts to scroll them into view. Don’t even load the web fonts if there isn’t even any text above the fold!

Remember to prioritize the critical path, which is the series of network requests that must be made in order to complete the page above the fold. In this case, anything that is not the hero image or masthead graphic should be deferred until visible.

4. Optimize the content above the fold

Getting the secondary content out of the way of the primary content is just the first step. The site will seem faster because the important stuff will load sooner, but as a whole you’ve just rearranged the slow parts to load later. This is the step where you actually make things faster. This is kind of easy because we’re only dealing with images.

Most importantly, use the right image format. I’m going to go out on a limb and guess that the photographic images wouldn’t be nearly 2 MB if they weren’t PNG format. JPEG images are much better suited for photographic images and I bet that their size would be greatly reduced if properly formatted. Fewer bytes to download directly correlates with faster download times. One caveat is the use of transparency due to the layering of the images needed for the parallax effect. In that case, I would definitely use WebP as the image format to achieve transparency along with photographic quality.

Also, use appropriately sized images. The images are 1800 by 1700 pixels. My retina Macbook Pro browser window is about 1400 pixels wide, so this isn’t terribly inappropriate. However, the same images are used when the browser window is only 800 pixels wide! This is incredibly wasteful to load an image and hide most of it. It’s only exacerbated by the fact that all three background/midground/foreground images do the same thing.


I don’t care how slow The Hateful Eight website is because I love the director and I’m going to see his film regardless. This was just an exercise in using WebPageTest to analyze a page and demonstrating what can go wrong with web performance. But to the movie studios, remember that users hate slow websites and the abandonment rate increases with slowness. Some users might leave the site out of frustration for how slow it loads or how janky it is to use due to the excessive effects. The studios might as well consider these users as being dollars never spent on tickets for their film. Optimizing web performance is more than just a fun exercise; it’s a powerful tool that ensures that everyone who wants to visit a site can do it without having to wait, which can mean better conversion and better marketing reach.

Oh, and don’t get me started on its mobile web performance.

You can find out more about how to use WebPageTest to analyze the performance of websites in my new book, Using WebPageTest.

Agile Auburn Weasels and the Power of Web Fonts

Posted in Front End Engineering, Web Fonts and tagged , , , on by Rick Viscomi.

Quick brown fox jumping over a lazy dog.

It was the Spring of 2010. I was poised to graduate from college, but one thing stood in my way: Creative Writing 250. You see, even though I was on track to get a Bachelor of Science, I still had to complete several “general education” courses to round me out as an academic.

Your jokes and quips are words unzipped.
The knives you use to axe my heart in two.
The lavender-scented love from mom to you.
You guessed, it’s the alphabet you lipped.

I was proud of that poem, because I used a clever little trick; more than just a play on words, a play on letters. What does my poem have to do with fonts?

Dwarf mobs quiz lynx.jpg, kvetch!

Go on, take a closer look. Continue reading

Extreme Flash of Unstyled Text

Posted in Web Fonts, Web Performance and tagged , , , , on by Rick Viscomi.

Extreme Flash of Unstyled Text

A flash of unstyled text, commonly referred to as FOUT, is the undesirable phenomenon during custom web font loading when text in the default font is abruptly restyled to use the custom font.

While researching the effects of asynchronous web font loading techniques, I found an interesting variation on the problem; Chrome and Firefox momentarily hide the text before the custom font is applied. This is what I’m referring to as an extreme flash of unstyled text, or XFOUT, because everyone loves acronyms. Continue reading