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.
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.
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.
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’.
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.
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.
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.
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.’
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.)
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.
If you found this article valuable, Paypal tips are appreciated.
If your website or organization needs web performance improvements, get in touch (firasd at gmail) — my colleagues and I can help out.
Questions or feedback? Let me know in the comments.
Was the article helpful? Paypal tips are appreciated.
I’m also looking for web development projects, preferably related to WordPress or React; some information about my background on LinkedIn.
Other things I wrote you might like: