2,360 reads

Don’t Brake for Fonts: 3 web performance techniques to show content quickly

by FirasJune 9th, 2016

Too Long; Didn't Read

<em>If you can see a site’s layout, you should see its text at the same time. If you don’t, send them this article.</em>

Companies Mentioned

Coin Mentioned

featured image - Don’t Brake for Fonts: 3 web performance techniques to show content quickly

Load the base of your content first (Wikipedia)

If you can see a site’s layout, you should see its text at the same time. If you don’t, send them this article.

Stop me if you’ve seen this before: you click on an article, and it seems to have loaded, including layout and colors, but you can’t see the text you wanted to read. Turns out, you’re waiting for fonts to load. Good news: I’ll explain how publishers can avoid building sites that act like this unless they want visitors to give up, close the page, and go back to Facebook.

Fast websites win: they’re good for user experience, and good for business goals, including search ranking. The techniques I suggest may make webpages appear in stages instead of waiting until the complete design downloads, but that’s the nature of the medium: live websites are not like paper brochures.

Learning to reduce network requests

Recently, I worked on improving web performance at Smart Blogger. Using webpagetest.org among other tools, Tim Gary and I began reducing the time taken to start page rendering. In this context, once you’re under 5 seconds, every tenth of a second (0.1s) reduced counts as progress.

In the process of trying various optimizations, I learned something new: the number of HTTP resources counts, not just their file sizes. In other words, page speed is dependent on network congestion, not just bandwidth. This remains true even given HTTP/2 and keep-alive connections.

For example, articles on Smart Blogger host comments with profile pictures known as Gravatars. We observed using developer tools that opening an article started a flood of network requests for Gravatars, which slowed down the fetching of render-blocking resources, such as stylesheets in the document head. This made no sense: low-priority images that are only visible after several screens of scrolling shouldn’t delay the article headline from displaying.

Given this experience, my focus in this article is on speeding up content by reducing initial network requests. Web performance is a vast field that covers all areas of web development including the server, the network, and the browser, but I believe these techniques will be measurably effective in combination with any other efforts to improve page speed.

1. Lazy Loading

Fonts

Thanks to web fonts, online typography in this decade has expanded well beyond Georgia and Verdana. Today, The New Yorker’s site almost looks like a magazine. However, this progress has come at a cost that is hotly debated: the bad experience of a ‘flash of invisible text’ while fonts load.

This conflict is unnecessary. We can achieve both, good typography and fast pages, through asynchronous font loading: new visitors get fallback fonts until web fonts load, and returning visitors get web fonts immediately from the browser cache.

Async loading codes are available from popular web font providers.

TypeKit’s embed codes
Google Fonts use the Web Font Loader.
Font Awesome, the popular icon font, provides async codes.

The Web Font Loader can be used for fonts hosted at various locations: ‘Loading Web Fonts with the Web Font Loader’. Another option is to use the Font Face Observer library, as described in ‘Font Loading Revisited with Font Events’.

More information: ‘Analyzing Web Font Performance’.

Images

The concept behind most image lazy loading techniques is to create a placeholder image in the markup that gets replaced with the intended image when that part of the page is scrolled into the viewport. The placeholder has a temporary src attribute that is later overwritten with the URL of the intended image, which prompts the browser to fetch the new image at that point.

The code to use depends on your specific setup, but there are a variety of examples available online. For WordPress, we used the a3 Lazy Load plugin.

Note: Since lazy loading is dependent on JavaScript, use noscript tags to provide image tags with the intended URL for non-JavaScript clients like search engine robots. The a3 Lazy Load plugin handled that in our case.

2. Combine multiple CSS and JavaScript files

Send them together (wikimedia)

A simple way to reduce the number of HTTP requests is to combine multiple files of the same type into a single file. On complex sites this is often managed automatically by bundlers and other workflow tools, but on simpler sites it may be an occasional optimization to handle manually.

We used the Autoptimize plugin for WordPress. It has many features; we only used it to combine CSS files.

Note: Be careful when combining files to make sure you don’t introduce bugs. For example, both the CSS cascade and JavaScript programs can depend on code being in a specific order. Also, if the CSS or JS is different on various pages on your site, you may prefer to keep some files separate so they can be cached for repeat visitors, instead of creating a variety of combinations.

3. CloudFlare Rocket Loader

While most web performance techniques are like a scalpel, intricately adjusting your code and resources, Rocket Loader is a hammer. It pretty much stops all JavaScript until after initial page load. If your page includes external widgets like analytics, social sharing buttons, and signup forms, Rocket Loader is likely to be very effective and cut down several seconds of time to first rendering.

Rocket Loader can be instructed to ignore specific scripts, which we had to specify for font-loading scripts among other code.

You would have to setup your website to use CloudFlare, which is a decision with both strategic and technical aspects.

Note: You probably don’t want to use Rocket Loader on webpages that only render client-side markup, such as Single-Page Apps powered by JavaScript frameworks like React, Angular or Ember.

Potential Concerns

Reflow

When you can’t use a website because the layout reflows (Jamiroquai — Virtual Insanity)

A major issue with lazy loading is that it can cause the page layout to reflow. If you insert an element into a page and the layout changes to accommodate it, any content around the new element will suddenly shift around, which is especially aggravating for people using the site on a mobile phone. Take care to have placeholder elements with appropriate dimensions to minimize this kind of layout adjustment.

This issue is covered in detail in the article: ‘Our best practices are killing mobile web performance.’

Browsers should support native lazy loading

Current techniques for lazy loading use JavaScript workarounds. This adds complexity because it is there is no standard code or method, and if you want lazy-loaded elements to also exist in the unscripted HTML document you need to provide alternate markup in noscript tags.

I would recommend that browser vendors support an attribute like lazyload on elements like img, script, and link to only fetch resources specified with this attribute after the initial document loads. (The script element has defer and async attributes, but they don’t actually delay the HTTP request to fetch the script.)

Summary

Web performance is an intricate topic but well worth the effort. Cutting down initial network requests through progressive enhancement and lazy loading is useful to make initial rendering as fast as possible. Showing basic content first, and then loading enhancements like fonts, media, and scripts later, brings the user experience in harmony with aesthetic designs and business goals.