Interview with Scott Jehl: responsible responsive design

We catch up with one of the faces behind a landmark project in the evolution of responsive web design to find out how to prioritise performance, and why we need to start being more responsible

The 2011 Boston Globe website project — which saw design and frontend development studio Filament Group team up with Ethan Marcotte — is seen as a watershed moment in the evolution of responsive web design. It was one of the earliest large-scale implementations of responsive design, and served as a refining ground for the approach and the processes that underpin it. One of the key figures on the project was Scott Jehl, a web designer at Filament Group, who has also worked with clients including Lego, Global News and eBay.

This game-changing moment for the web design industry was closely followed by a lifechanging event for Jehl himself. He and his wife hopped on a plane to Southeast Asia, where they spent eight or so months travelling around. “I left after I had finished up the Boston Globe project and, taking off [for Asia], I felt like I was in a good spot. I felt like I had a lot of answers,” he recalls.

On the road, Jehl worked remotely for the Filament Group while his wife volunteered at a hospital. The couple put down roots for a few months, and Jehl found himself needing to access the internet using the local services. This came as something of a shock.

A different reality

“[In the US] we have it pretty cushy,” he says. Wi-Fi, 4G and Apple’s latest gadgets are all taken for granted. By comparison, accessing the web via mobile networks in SE Asia — as many of the locals do — posed more of a challenge. It relied on a combination of basic protocols, luck and the data showing real determination to reach its destination. “I really got to feel what it was like living in someone else’s shoes, ” Jehl adds.

Experiencing this divide between the digital haves and have-nots brought about a new determination in Jehl. Having left the US filled with confidence won from the Boston Globe’s success, Jehl returned humbled and appreciative of a larger truth: design shouldn’t just be responsive, it needs to be responsible too. “I realised that there are a lot of big problems still to be solved, ” he reflects. “The focus for me became performance, particularly on slow and intermittent connections.”

The realisation was so strong it prompted Jehl to pen a book on the topic: Responsible Responsive Design, published in late 2014 by A Book Apart. The title explores ways to develop for a truly global audience — regardless of network capabilities — and it is already making waves in the web community.

Responsible design

Building sites that are crafted to work on slow connections may sound like the morally right thing to do, but there’s also the business side to consider. Why should a US client with a domestic customer base spare their time and money making sure they have a site that will work in the developing world?

“What you have to remember is, even in the US, 3G is still the most common connection speed, ” Jehl replies. “LTE hasn’t dominated – even in cities. I go into Boston and there are blackspots.”

As for the business case, designing sites and applying optimisations that make the web feel quicker is a pretty easy sell: “If a person is browsing with a prepaid SIM card, every byte they download has a real cost. And most sites on the internet are a megabyte-and-a-half or more in size. That’s pretty heavy.”

“3G is still the most common connection speed in the US. LTE hasn’t dominated, even in cities”

So, designing sites with performance in mind helps everyone. However, Jehl admits that technically, it can be a tough proposition. For a site to feel slick it needs to render in one second or less on Wi-Fi, and in around two seconds over 3G. The perceived wisdom about how you maximise performance is constantly evolving. Jehl recalls the early days of responsive, when there was an immediate focus on the size of the site. We were building sites that addressed a lot of different usage scenarios at once and this, inevitably, made those sites heavier.

“Fluidity was a main concern and so was performance, ” he elaborates. “One of the areas people directed their attention to was the raw file size. How big was the site? How many bytes were being downloaded?”

Lately there’s been a shift. The technical focus has moved on to exploring how we can deliver lighter sites, while still maintaining the same rich experience. One technique, Jehl says, is prioritising what arrives first. By managing the order in which content is displayed on screen, we can greatly influence how the performance of the site is perceived. Although, of course, changing the order in which content arrives doesn’t reduce the weight of the site itself.

Performance issues

As we talk, it becomes apparent that Jehl believes performance should be the star that guides a project team. Performance should be considered at every turn, because it has a profound effect on a site’s ability to reach an audience. “If a site is not delivered quickly, you can’t begin to think about usability, ” Jehl says, simply.

“Our client interactions always start by getting everybody on the same page, ” he continues, explaining how to get a project off on the right foot. “Performance becomes baked into everything we produce throughout the course of the project.” Again, Jehl makes the point that convincing clients of the need to focus on performance is never a difficult proposition. A highly performant site will naturally present low access barriers, which means more paying customers will be able to access it.

We move on to discuss performance budgets. Jehl explains there are, in his experience, two common approaches. There’s the overall budget of how much code you want to deliver, and there’s the budget of how much time you can afford to spend rendering this code on various connection speeds. Neither metric is perfect.

At Filament Group the focus usually rests on time-based metrics. The team’s budgets are incorporated into their build tools so, when they make changes to a codebase, the code is optimised and then tested in a browser. This testing reveals whether the changes to the code have made any performance regressions against the budget — is it still loading within one second on Wi-Fi, and under two-and-a-half seconds on 3G?

“If we regress, ” Jehl says, “we have to go back and figure out what happened. We tend to approach the budget that way, but I’ve seen other companies have very successful budgets that are based on file sizes. At Etsy — I don’t know if it’s an unwritten policy — but when somebody adds something heavy to a page, they have to remove something of the same weight. That works too.”

Exploring inlining

Finally we move on to exploring how a team can boost performance after they’ve finished developing and editing their code. “There are lots of automated processes we can use,” Jehl reveals. “We can let our tools combine files so we make fewer requests over the network. And we can start to deploy inlining.” Inlining involves serving up some of the CSS needed for a page in the same file as the markup. With the HTML and CSS combined, the number of server requests needed to build a page are reduced.

Inlining is, in Jehl’s opinion, simply incredible. So incredible, Google commonly deploys the technique, which is one reason why its sites are so highly performant.

“Inlining’s a comparatively new thing that’s come along in the last year or so, and it’s really taken off, ” Jehl enthuses. “It’s great because it offers such a dramatic improvement. It can, in some circumstances, cut load times in half. That’s because a site can take two, three or more round trips to a server before it can start to render something usable.”

“Inlining offers such a dramatic improvement. It can, in some cases, cut load times in half”

You shouldn’t, of course, develop code with CSS and HTML combined. It’s simply too messy, and, as Jehl points out, blending your concerns is bad practice. “On the flip-side, ” he counters, “if you’re making the simplest one-page website, it’s common — and actually smart — to put a style element in the head of a document, and add your CSS there.”

It’s smart because when the browser encounters externally linked CSS it will effectively stop everything it’s doing. It will then request, download and parse the CSS. When all that’s done, it’ll get back to the business of rendering your page.

“So, yes, develop your code in silos,” Jehl sums up, “but when it comes to optimising your code, it’s a very different concern. Inlining is something we want to have our tools automate after we’ve finished developing. It’s a production step.”

Tomorrow’s techniques

Jehl’s relentless quest for better performance doesn’t end with inlining — he’s currently eyeing up the possibilities of HTTP/2. The problem with HTTP/1.1 is that, because it only allows one request per TCP connection, loading multiple assets efficiently is difficult. To get round this limitation, browsers can run multiple TCP requests in parallel. However, this is a limited fix, because too many TCP requests can lead to network congestion and resource conflicts. Multiple requests also produce a lot of data duplication which, again, harms performance.

What’s attractive about HTTP/2, Jehl says, is that it makes a lot of today’s performance hacks unnecessary. Certain browsers (Chrome and Firefox, for example) now support HTTP/2, but it’s still not widely accessible. “The problem is, servers need to be converted so they can communicate in this language, ” Jehl explains. “So it’s not something that’s going to happen overnight.”

HTTP/2 also offers new features. The server can, for example, push assets to the browser in the same round trip that another request is made. “The browser can say ‘please send me this HTML document’ and the server will think: ‘I know, in addition to that HTML document, you’re going to need this CSS file’, ” explains Jehl, excitedly. “The server will send both back to the browser in one request. So HTTP/2 mimics that same inlining workaround we’re using.”

With that, Jehl draws our chat to a close. Rattling though his complicated schedule, he explains that he’s off to Australia in a few days. It comes as no surprise to find he’ll be talking about performance.

Words by Martin Cooper. Photography by Chandler Williams.


This article originally appeared in issue 267 of net magazine.