A List Apart Event: Designing for Performance

Some notes from A List Apart’s online panel Designing for Performance:
Can We Have it All?
featuring Lara Hogan, Scott Jehl, Yesenia Perez-Cruz, and Mat Marquis:

  • Optimizing images (or reducing their number outright) are an area where designers and developers can get big wins quickly.
  • Examine the critical path for page rendering—what is synchronous, and what can be deferred?
  • Look at whether you have render-blocking JS/CSS referenced in the
  • Inline critical CSS. Lots of debate on whether this is gross or yucky. Scott Jehl spent the following morning on Twitter clarifying that this is an automated post-production step, not something you do by hand.
  • Style guides can help, by establishing performant chunks that can be copy/pasted.
  • element and srcset. srcset lets the browser choose the best image to display.
  • Use webpagetest to check for the timing on when your page can be used. Balance overall page weight against how soon the page is usable.

My chief takeaways from the panel were to think about how images are used, and how to optimize them. I’m interested in optimizing the critical path, and it seems like Scott Jehl and the Filament Group have been doing a lot of work in that area. It does seem like certain things (like CSS inlining) are going to require integrating a dev tool like Grunt into the mix, which I’ve been hesitant to do so far.

The big area that I am personally curious about is how to achieve performance within the context of open-source CMS platforms like Drupal and WordPress. All of this performance tuning is fine and good if you have complete control over your output, how does it change given the constraints on those platforms?

Dev Discomfort

Frank Chimero recently wrote a post, “Two Sentences About Getting Older and Working on the Web”, which is short enough that I’ll just quote it here in full:

It is time to come clean: Github is confusing, Git is confusinger, pretty much everything in a modern web stack no longer makes sense to me, and no one explains it well, because they assume I know some fundamental piece of information that everyone takes for granted and no one documented, almost as if it were a secret that spread around to most everyone some time in 2012, yet I some how missed, because—you know—life was happening to me, so I’ve given up on trying to understand, even the parts where I try to comprehend what everyone else is working on that warrants that kind of complexity, and now I fear that this makes me irrelevant, so I nestle close to my story that my value is my “ideas” and capability to “make sense of things,” even though I can’t make sense of any of the above—but really, maybe I’m doing okay, since it’s all too much to know. Let the kids have it.

…which reminded me of a recent A List Apart blog post by Susan Robertson, “Overwhelmed by Code”, where she writes:

There is a constant pressure to learn new things and keep up with all the latest ideas: new frameworks, new platforms, new ideas of how to write code, they just keep coming out. In addition, the ebb and flow of what is desired from a front-end developer keeps changing. It used to be that knowing CSS and HTML was enough, then jQuery came along, then responsive techniques, then Node.js and then Angular, Ember, etc., etc., etc. That list, right there, it tires me out.

I’ve been thinking a lot about those two posts, because they echo my ambient, long-running fear about being left behind by my industry. Things move extremely fast in web design and development, and sometimes (okay, many times) I feel like my relationship with my tools has gotten flipped—instead of them existing to serve my needs, I feel like I have to improve myself to be able to use them. And don’t get me started on how tightly-coupled some of these tools have become. You find something that sounds cool, until you realize that this other thing is a dependency which requires this other doohickey, and suddenly you have to understand five different parts in the chain when you really just wanted the first thing. The prerequisites have gotten so large that it feels like I can’t even get good at something before the whole rickety system has been replaced by something new. Not necessarily better in ways that matter to me, mind you. Just new.

It takes time for these things to soak in, and time is something we are extremely miserly about. I’ve been using Drupal for a number of years, and it’s probably only in the last year or so where I’ve finally developed a good mental model for how it’s designed to work. That’s three or four years of muddling around with the framework before reaching a state of relative clarity. No wonder most people balk at the learning curve.

I don’t think I understood Git until I had to teach my students how to use it. And even then I didn’t really understand its distributed nature until I set up a repo to push to multiple remotes. Brains are maddeningly slow like that.

What helps, then? I like Susan’s suggestion to stop and think about what you enjoy:

So lately I’ve had to do some evaluating. What do I want to focus on, what do I love about the web? What do I actually want to learn, versus what I think I should learn.

Having a colleague or a mentor who can reduce the complexity is good, too. I find it helps to have someone who can look at the problem in front of you and sift the signal from the noise: Oh, you want to do x? Don’t worry about all this other stuff. Start here.

That’s probably where I feel the strongest pull on my own personal focus. Frank mentioned in his post how it feels like we lack the people willing to slow down and take the time to share knowledge. And the thing is, anyone can do this. There’s always something you know that could help somebody else. Many times when I find myself saying, I wish someone had told me this a year ago, I also think: I can be that person for someone else.

Earlier today I sat with two of Bluecadet’s developer apprentices during their three-month checkin. I told them that it’s ok to feel overwhelmed, because everyone feels that way to some degree. I want them to feel like they can explore things at their pace, that they can play on the edges of their understanding without feeling defeated. I want them to grow comfortable with being uncomfortable, if that makes any sense.

I essentially told them the things I have to remind myself: it’s okay to take time. Rushing doesn’t improve things, it might even slow you down. Focusing on a few things and doing them well is worthwhile. Sharing what you learn—even while you’re still figuring things out—is even better.

On Web Typography

Perhaps the highest compliment I can pay Jason Santa Maria is that his book On Web Typography is changing my handwriting.

Every morning I read, pray, and journal for a few minutes—and I recently noticed that I’ve been tweaking my script. I’ve adjusted my margins, fiddled with the space between lines, and tweaked the size of my letters. I’ve tested different pens with varying stroke widths.1 It’s as if reading the book opened up a subchannel in my brain where I examine the form of my handwritten words in the light of ideas pulled from Jason’s book.

To say that I eagerly anticipated this book would be an understatement—as far back as early 2013, I had it as a bullet point in my Wish List note in nvALT. I had to wait a bit longer than expected, but it proved to be very well worth the extra time. I’ve read the book about three times: first on my phone, then the paperback, and now I’m revisiting it on my Kindle.2 Compare that to my copy of Bringhurst’s Elements of Typographic Style, which I have yet to finish despite many attempts.

I’m no stranger to typography, but it still often feels like a second language to me. As a developer I have a pretty good grasp of the technical aspects of CSS and its properties with respect to setting type, but I’ve always lacked a method for the step that comes before that: choosing and pairing type. I’ve relied on intuition and gut feeling, going with what looked right. That’s a process that can sometimes produce good results, but mostly I just end up burning up time. What I like about the book is that it welcomes people like me into the fold, peeling back how Jason approaches type. His “type for a moment, type to live with” distinction is so simple, but it clarified something I’ve struggled with for years.

There’s an easygoing generosity to the book, and as I re-read it I’m struck with how little Jason holds back: it’s like being invited to hover over his shoulder as he explains how he goes about his work. That’s no small thing, and it’s difficult to pull off in a way that feels authoritative, natural, and humble.3 There is nothing I find more inspiring than talented people simply opening a door into the things that they love. You feel that joy in this book, and it’s infectious.

I still find choosing and pairing type challenging, but at least Jason has answered the basic question—What am I hoping to communicate?—and explained his approach to evaluating and selecting type. The properties of type aren’t treated in abstract, but are approached in the context of the typeface’s potential purpose. For me this helped transform typography from an arcane pursuit into something more approachable, now marked with handy guide posts to anchor my own explorations.

Above all, Jason reminded me that typography is there to serve a purpose. Writing about type to live with, he says:

You want that clear goblet. Help people forget that they’re staring at a screen and instead immerse them in the words and the story you’re telling. The type you use should be smooth, removing as much friction as possible between the reader and the text.

In a way that passage sums up this book for me: it lessened the friction introduced by technical components like x-heights and stroke contrast, and situated those components in a story about type. I can’t help but hope for a follow-up volume.


  1. Uniball Signo DX (.38) vs Pilot Hi-Tec C (.3), lately. 
  2. Ironically, that experience underscores how terribly the Kindle executes basic typography. 
  3. I should pause here and thank editor Tina Lee for this.