Web Performance Today

WEB DESIGNERS have cared about web performance since the profession’s earliest days. When I started, we saved user bandwidth by employing GIF images that had the fewest possible colors—with no dithering, when possible, and by using actual web text instead of pictures of web text. (Kids, ask your parents about life before CSS enabled, type designers created formats for, browsers finally supported, and Typekit quickly popularized web fonts.)

Later, we learned to optimize JPEGs and blur their backgrounds: the blurrier large swathes of a JPEG image can be, the lower the bandwidth requirements for the image. We found the optimally performant size for repeating background tiles (32 x 32 and 64 x 64 were pretty good) and abandoned experiments like single-pixel-wide backgrounds, which seemed like a good idea but slowed browsers, servers, and computers to a crawl.

We developed other tricks, too. Like, when we discovered that GIF images optimized better if they possessed repeating patterns of diagonal lines, we worked diagonal background images into a design trend. It was the trend that preceded drop shadows, the wicked worn look, and skeuomorpic facades, which were themselves a retro recurrence of one of the earliest styles of commercial web design; that trend, which was always on the heavy side, performance-wise, eventually gave way to a far more performant grid-driven minimalism, which hearkened back to classic 1940s Swiss graphic design, but which our industry (sometimes with little knowledge of design history) called “flat design” and justified as being “born digital” despite its true origins going back to pixels, protractors, and a love of Greek mathematics.

All of this nostalgia is prelude to making the obvious comment that web design today is far more complex than it was in those golden years of experimentation; and because it is so much more complex, front-end performance is also far more complicated. You didn’t need an engineering degree to run DeBabelizer and remove needless elements from your markup, but, boy, does front-end design today feel more and more like serious coding.

All of which is to say, if you’re a front-end designer/developer, you should probably read and bookmark Nate Berkopec’s “Ludicrously Fast Page Loads – A Guide for Full-Stack Devs.” While you’re at it, save it to Pocket, and as a PDF you can read on your tablet.

I cannot verify every detail Nate provides, but it is all in line with recommendations I’ve heard over and over at top conferences, and read in articles and books by such performance mavens as Jake Archibald, Lara Hogan, Scott Jehl, and Yesenia Perez-Cruz.

You should also pick up these great books on performance:

(It’s not why I wrote this post, but if you order Scott’s book today, you can save 10% when you enter discount code ABAHARVEST at checkout.)

Even the most complex site should work in any device that reads HTML. It should work if stylesheets fail to load or the device doesn’t recognize CSS. It should work if JavaScript fails to load or the device doesn’t recognize JavaScript. The principles of standards-based design will never change, no matter how complex our web becomes. And as it becomes more complex (and, arguably, much richer), it behooves us to squeeze every byte of performance we can.

Websites can never be too rich or too thin.