You’d think that years and years of 3G networks and the shamelessly slow growth of broadband speeds may have started developers on the right foot: building pages for the neediest user. After all, most of us have had to consider the oft-mentioned but rare rural visitor rolling in with IE8 and below.
Here’s what those users generally need: fast, lean websites that serve up a workable user experience in a few seconds flat, if not less. Not only will developing for these users only better the experience all visitors have on the whole, but it’ll ensure that fewer and fewer users wait seconds for a DOM-dependent script to fire off. I’ve been there, you’ve been there — you’ve definitely seen how frustrating one-bar web browsing on mobile can be. Let’s fix that.
I found that the key towards building towards faster loading without compromising user experience is in lazy loading, enabling gzip compression, and offloading dependency scripts to CDNs that likely have better uptime and speed than your personal server.
I’ll go over each of them briefly.
Lazy loading in web development is the practice of only loading assets when they’re ready to be displayed, and in their place, offering lower-resolution versions until they do. This’ll make it easier for larger, image-heavy sites to load images progressively, making for a better infinite scroll experience.
Here’s a demo of lazysizes in action:
Enabling gzip compression
If you operate your own server, you can easily set gzip compression. When users visit your website, and their client has an
Accept-Encoding header value that includes gzip, you can serve them compressed assets — script files, CSS, typefaces, images — anything, even html files. It’s a step above and beyond just serving minified assets, but there are plenty of tutorials for enabling gzip compression out there, usually by declaring it in a
.htaccess file in your root site directory.
CDN are a viable way of serving script and css files, and most come gzipped and compressed by default. Most CDNs also give you the option of linking to component parts of libraries (for instance, Bootstrap’s grid module) rather than linking to the core. On my own site, I used cdnjs to serve a 128KB minified and gzipped version of three.
<video> tags introduced in HTML5 that serve up multiple mimetypes depending on your user-agent, browsers are adding support for a new HTML tag called
<picture>. The tag allows you to specify a
<source> tag that defines the media type or user-agent to serve an image or svg to, in the
srcset attribute. The element uses a child
<img> tag as a fallback for when all
<source> conditions fail.
So for instance, you might imagine a smaller image being served up to a mobile device, based on smaller width breakpoint:
<picture> <source srcset="example-logo-sm.jpg" media="(max-width: 480px)"> <source srcset="example-logo-md.jpg" media="(max-width: 720px)"> <source srcset="example-logo-lg.jpg" media="(max-width: 1280px)"> <img src="example-logo-fallback.jpg" alt="original image fallback" /> </picture>
Easy, and you don’t have to jerry-rig breakpoint scripts in your JS files anymore.