with Jeff Lembeck of Filament Group

This week, Katie and Tim talk to Jeff Lembeck of the Filament Group about how they conduct performance analysis, how they sell performance, why everyone needs a “Jank Tank”, and the importance of perceived performance.

Sponsors:

SpeedCurve—Get continuous feedback on how your front-end code affects a user’s web experience. Built on top of the amazing WebPageTest, SpeedCurve makes it easy to set up performance budgets, Slack alerts, competitive benchmarking, deployment testing and much more.

Transcript:

Katie Kovalcin:

Welcome! You’re listening to episode three of the Path to Performance, a podcast for everyone dedicated to making websites faster. I’m your host, Katie Kovalcin.

Tim Kadlec:

And I am your other host, Tim Kadlec. Today’s episode is sponsored by SpeedCurve, which I’m really excited about. SpeedCurve is a performance monitoring tool that is built on top of WebPageTest, and it is one of my personal favorite options for keeping tabs on performance.

For one, it’s beautifully designed, which is admittedly a bit of a rare thing in performance monitoring tools. Mark, who created SpeedCurve, has a really strong background in design, and that definitely comes through. There’s a lot of really great visualizations that help you to quickly make sense of the performance metrics being reported.

There’s also a ton of features baked in. You can monitor performant sites to let you see how you stack up against them. They’ve got a great dashboard for continuous deployment through their API. You can define performance budgets, which is something that both Katie and I are big fans of. They have detailed responsive analysis, Slack integrations, and a really nice visualization for third-party components. It’s just a really nice option for helping to keep tabs on performance throughout development and long after launch. You can check out the features, as well as a demo, at SpeedCurve.com.

You know what else has me super excited? Not just SpeedCurve, Katie.

Katie:

What is that, Tim?

Tim:

It is that we finally got a chance to meet in person!

Katie:

We did! Hopefully it hasn’t come through thus far, but in all of our previous episodes, they were recorded with Tim and I never actually having met in person.

Tim:

That’s right.

Katie:

And last week that changed, and we had some podcast team bonding. Tim came to where I work and he gave a really awesome workshop on performance budgets, and we got to play volley pong together… Tim sang some karaoke.

Tim:

[Laughs] No. No, I did not sing karaoke, despite what you might have heard on Twitter from apparently many people. Thank you for that, Katie. Thank you so much. No, but I hear you’re a mean karaoke person; quite good.

Katie:

Uh, I mean, I’m extremely tone deaf, but I can choose some crowd-pleasing songs and scream really horribly, and I guess people think it’s entertaining in some way. But I wouldn’t say “good.” “Good” is a stretch.

Tim:

[Laughs] It depends on how you’re going to use the term. I’ve heard there’s video footage somewhere out there

Katie:

There’s actually a lot.

Tim:

And what is your song of choice again? Remind me.

Katie:

“Work it” by Missy Elliott.

Tim:

Yeah…

Katie:

Because in middle school, I sat at my computer and made myself memorize every word by looking at the lyrics and listening to it on repeat. So, that’s one of the few songs that I know all the words to offhand.

Tim:

That’s cool.

Katie:

[Laughs]

Tim:

If I did the karaoke thing, my go-to would probably be something by Neil Diamond or something like that, ’cause I got those lyrics down.

Katie:

I don’t know if I know any Neil Diamond songs.

Tim:

That’s sad. You’ve got to know “Sweet Caroline,” right?

Katie:

Uhh…

Tim:

No?

Katie:

I don’t know. Tim also got really mad at me because I’ve never seen Indiana Jones.

Tim:

[Laughs] Look, that’s just inexcusable in today’s day and age. It’s so good. It’s so good. And there’s never been a better action movie.

Katie:

I also learned that Tim used to exclusively dress like Indiana Jones.

Tim:

[Laughs] It wasn’t obvious to me at the time, but yeah, in retrospect my high school “style,” if you’d call it that, was the khakis and the button-down thing, and the little leather jacket.

Katie:

The chain wallet.

Tim:

Yeah—well, I don’t know about that. I think the chain wallet was more your thing. [Laughs] I didn’t have the fedora—and I can’t believe I’m going to admit this on something people are going to listen to—but I was really into those bucket hats, you know, like you see the retired people wearing?

Katie:

[Laughs] Do you still have them? Bucket hats have made a really big comeback this year.

We also came up with a pretty exciting new side project that I think we are about to take on. We are hopefully getting Jennifer Lawrence and Will Smith in on it, but we have this really good idea for the next blockbuster hit.

One of the other things that I learned about Tim is that he has a long history of being a basketball star, and we were just talking about sports, and I was talking about my basketball career in middle school, which I played for two seasons for the free recreational team—not the school one—I couldn’t make tryouts.

But I got one basket in the last game of both seasons that I played, and I was like crying from happiness that I finally got one, and it was really sad. But that wasn’t just for basketball, that was for every sport that I’ve ever tried, which has been pretty much all of them, except for soccer.

Then relaying this to Tim, he was like, “Aw man, what if soccer is your sport?” and then we were just kind of workshopping that I have the potential to be an amazing soccer player and I just don’t know it, and I could be like an Olympic athlete.

So, that sounds like a pretty good movie right there. Picture this: Jennifer Lawrence down on her luck—obviously for Hollywood, we have to ham up what making websites is, so she’s in a dingy basement doing server maintenance or something, and she’s just like, “Oh, grumpy corporate office… Blegh.” And then Will Smith is her coach and advisor, and comes in and encourages her to try soccer.

Tim:

After they launch a wildly successful podcast.

Katie:

Yeah, the podcast definitely has to be in there. And the tagline will be like, “Based on a true story…” because it’s worded in a kernel of truth.

Tim:

Totally inspired by a true story.

Katie:

But I think it’ll be good. We’re hoping to get a Kickstarter here soon. Thanks to my coworker Ethan, he said, “Oh, you guys have to have the ’net’ in the title somewhere.” So, we’re spitballing maybe like, Get the Net or something like that—internet and soccer. I think it’ll be really good. Straight to VHS.

Tim:

I will personally be really surprised if we don’t get somebody like Disney to agree to this. It’s perfect for them.

Katie:

Oh, absolutely. I can also picture “From the people who brought you Air Bud… Presenting Get the Net.”

Tim:

[Laughs] Look, they did the whole movie with Mark Wahlberg, where he was a garbageman and became a football player.

Katie:

What?

Tim:

Oh yeah, this was a thing. I think it was Mark Wahlberg, I’ll have to look it up after. But yeah, he was like this garbage man and there was a strike in football, and then he joined the team, and made the team and did good and stuff, and like won football games or something… I don’t know, I don’t remember exactly what he did.

But yeah, this is totally right up their alley. This is perfect. It’s got all the right things.

Katie:

You heard it here first. It’s going to happen. Tim was like, “Oh, Channing Tatum could play me,” but everyone kind of shot down that idea. [Laughs]

Tim:

I think it was just that the resemblance was too uncanny. It was too close between me and Channing, so that was the problem.

Katie:

But performance.

Tim:

Yeah, we could talk about that, I guess.

Katie:

Yeah, I don’t know. This could just be the podcast where we give great movie ideas to the world.

Tim:

Which I think has benefits for everybody listening as well.

Katie:

Yeah, because we could all just work together to make it happen.

Tim:

For sure. Anyway, we could tie that back to culture somehow.

But yeah, performance! There was some cool stuff since the last episode that we could talk about, right?

Katie:

Yeah, there’s been a lot of cool things out there. We kind of keep track of things that pop up on our radar and that we find interesting and cool. I think one of the most exciting things that I’ve seen recently has been Udacity.

Tim:

I liked the pronunciation you used before recording the podcast, which was “you-da-city.” So, we should just go with that. There’s a “you-da-city” course…

Katie:

[Laughs] Yeah, so Udacity, there’s now a browser rendering optimization course by Paul Lewis and Cameron Pittman. It looks pretty awesome. I haven’t done it myself because I think a lot of it would be probably over my head, but I think that it’s exciting to see this offered and out there and getting people talking about it, and it seems like a really good place to start on your path to performance.

Tim:

Yeah, there are few people more qualified to talk about that then Paul Lewis. This is his thing. And it’s free, which is awesome.

Katie:

Yeah, I’ve definitely sent it to a bunch of developers, like, “Hey, you should try this.”

The Web Performance Today site is just a great one to follow. There’s always a lot of great business metrics and case studies and things coming out of there. It’s a good one to pay attention to.

But since 2010 they’ve been looking at the top 100 e-commerce sites in terms of performance, and so they do this little state of the union report and give some ideas about how we’re doing in the e-commerce sector in terms of page performance. Which, you know, the results are a little slower than I think I would like to see. I think 5.2 seconds was the median time to interact on retail sites. We can bring that down. They talk in it about how there are studies that say 67% of consumers abandoned that takes longer than 3 seconds to load, and here we’re seeing that the average is 5.2, so that’s not great.

Katie:

That also leads nicely into the topic of perceived performance and that one Filament Group post, which is really great timing, because we’re going to talk to Jeff Lembeck here in a little bit, who works at Filament Group.

Yeah. They just talk a lot about some ways to improve perceived performance and how fast the content is getting to the users, even if the whole page isn’t necessarily loaded yet, and just some ways that you can think about and improve that, and not just focus so much on the page weight itself.

It’s nice to get more into those abstract concepts and moving away from that number, which I know we just talked about in the last episode, about the performance budget. So, this is a way to start thinking about some of those other metrics.

Tim:

It’s awesome, because it’s written by Scott Jehl, and he goes through, step by step—like, he took the WIRED site and, without changing the weight—like you said, it ends up being pretty much the exact same weight—but they get it to be 8.5 seconds faster in terms of when you start seeing content, which is crazy. They go through all the steps that they did to make that happen. So, it’s not just a theory about perceived performance, it’s actually the sorts of things that they were able to do to improve that. The improvement is just crazy.

So, should we talk to Jeff now?

Katie:

Yeah, that’s a nice way to segue from talking about Filament to talking to Filament Group. So, we will be right back.

Tim:

This week we’re going to be talking to Jeff Lembeck from Filament Group. Hey Jeff.

Jeff Lembeck:

Hey.

Tim:

How are you doing?

Jeff:

I’m doing alright. How are you?

Tim:

Good, good. Jeff, could you tell us a little bit about Filament Group and your role there?

Jeff:

So, Filament Group is a design and development consultancy out of Boston. There are a grand total of seven of us, and I am one of the developers. We have a range of positions, and mostly I do front-end development and also build a lot of tools, including some performance-based tools and CI-related tools.

Tim:

I know Filament is actually very prolific in that area. You guys produce a ton of different tools and utilities that you guys are using on your own work and then releasing for everybody else to have access to.

Jeff:

It’s kind of a cool trip of a thing, because every time I meet anybody who’s in public who’s like, “Oh, you work for Filament Group?” I’m like, “Yeah,” and they’re like, “What’s it like working there?” and it’ll come up that there’s seven of us, and they’re just like, “What? There’s only seven of you? You have like 200 open source libraries.” And it’s like, “Yeah, no, that’s just what we do. That’s how we do things.”

Tim:

Not a lot of sleep there?

Jeff:

We, as a company, are super, super reasonable about it, but the big deal is that we have a mentality in-house that if we can produce something and abstract it well that we can use for a client, then we’ll just put it out. So, we roll out a ton of stuff, including some stuff that just ends up sucking every once in a while, and we’re like, “Well, retire that.”

But most of the time you end up with something that somebody else out there is like, “Hey, this is good,” or “Hey, this is good except maybe it needs this,” and we’re like, “Oh, it does need that,” and thus the wonders of open source culture can start kicking in, which is nice.

It’s important also to set up your Gmail filters so you aren’t just getting bombarded at 1:30 in the morning with, “Hey man, I was wondering if you could add this feature to Grunticon.” [Laughs]

Katie:

This is totally not necessarily on the topic of performance, but how do you get that to the point where you want to release? I’ve worked at several places that were like, “We have this really cool thing we built, but there’s a lot of things we need to do to make that ready for public consumption,” and then time is just not in our favor, and then, “Oh well, we’ll just use it internally,” or maintaining it and all of that.

Jeff:

I might be the worst offender/best person for this kind of a problem. I’m a “screw it, release it,” and if it’s broken, then just don’t publicize that you released it. Open it, then continue to use it, and continue to fix it in public. Then once you get to a point where you’re using this tool and you’ve been putting fixes in it in public—part of this is that Filament Group is pretty high profile, there’s a lot of people who will just start following or starring a Github project if we put it up.

So, as long as the documentation is there, most of the time it’s like, “Put it out.” Also, I’m a huge, huge fan of “Put it and make it 1.0,” and that just starts putting a pressure on you, and if anybody is looking at it, they’ll be like, “Oh, I guess I’ll file an issue,” which really, really helps with being able to get things out and being able to understand where priorities. Because that seems to be a big issue, at least for me and a lot of other people, is when you’re developing something, it’s never going to be just the way you want it, so you might as well just put it out there and see where the priorities are for other people who might use it.

That’s how we end up doing that, is just like, “Alright, let’s put it out there. Put it out there, and if we start using it a lot and if it starts getting some interest, we’ll write about it and we’ll show people how we use it.”

Tim:

And a lot of these tools that you guys are putting out there are very tightly related to performance. You guys do a ton of performance work and seem to be really well-known for that. Would you say that being so open with the process and the tooling is a big part of why that’s the case?

Jeff:

Yeah, that’s a huge part. There’s a part of it that’s also that we have a reputation with that, and our reputation, and the culture of the company in and of itself, tends to be, “We build things for the web and websites that work everywhere for everybody as much as possible,” and performance is such a huge part of that responsibility.

You can have a site that fully works on a screen reader, but if it doesn’t load in 60 seconds then, well, it’s not useable. So, accessibility isn’t just the part that people think about. It’s also speed and performance. So, that reputation that we’ve kind of built for ourselves embeds itself in the culture of the company, which makes it so we focus a lot on making sure that we have good tooling for performance-related things.

Katie:

Which came first? Was it just, “We need to focus on accessibility” and then performance just naturally emerged from that? I’m curious as to how you guys got to be so awesome at having performance super integrated into everything you do.

Jeff:

I’ve been at Filament for three years. Long before I came along, they wrote Designing with Progressive Enhancement, which is a big deal of a book for setting things up with progressive enhancement, and it had a long stretch of focus on writing things with accessibility. So, I think the performance thing kind of just came from having an inherent culture of accessibility and progressive enhancement. Next up came, “Hey, we can build all this stuff faster. We’re building things responsively. We can build things fast, and responsive, and accessible.

Katie:

It sounds like there was a pretty cool book about that, about making responsible responsive design…

Jeff:

[Laughs] Yeah, my coworker Scott, who is like… I mean, Scott’s a super genius, and it’s really cool to work with a super genius because ideas are just always flowing out of him and he’s really good at putting them somewhere. So yeah, his book, Responsible Responsive Design, was just so good.

During the process of him making that book, we had a lot of moments in-house where we were able to test new ideas and write down a lot of things we were thinking of, and try a ton of things out to see, “Hey, does this work? Does this work? Oh, this is great.” We’ll break down something and put it into a bunch of different tests and find out, “Oh, well using this way to load fonts sped up the usability of the site by a full second,” or sometimes two, or 30. But yeah, that book and the creation of it have been really, really great in-house for us and for how it’s really taken into our process and our system.

Tim:

Are these experiments happening on client sites or are you doing the experiments on things internally as sort of independent research?

Jeff:

There’s actually a few different ways we handle this kind of thing.

Let’s say we do something for a client. A lot of the time we’re contacted by a client, we do performance-related analysis. So, somebody will reach out to us and say, “Hey, our site is just not moving as fast as we’d like it to,” and we’ll take a look at it and we’ll go through WebPageTest and we’ll analyze what they’re doing, and we’ll talk to them about performance, and we’ll talk to them about page weight, and we’ll go through a system where we put together a big, thick analysis of what they’ve been doing right and what they’ve been doing wrong.

During that time, while we’re analyzing their things, a lot of our internal techniques that we’ve developed will come through. Like, “Oh, Zach wrote something about font events recently. Hey, now that we have something that’s live, that’s out there, and that we have to play with, let’s check out what happens if we add font events and then run it through WebPageTest. Oh, that sped up the usability of the site by this much.”

So, we’re always focused on that kind of thing when analyzing. Scott wrote a blog post that came out this last week, where he was testing some of our techniques and just grabbed WIRED’s new site. He wanted an example of a new, big responsive site and what certain techniques would do for it, and he was able to fine-tune some of the analysis tools that we have.

Tim:

Yeah, we actually talked about that earlier in the show. It was a fantastic post. Is it fair to say that that’s sort of a casual, high-level glimpse into your auditing analysis process? Does it line up pretty well with the sorts of things you’d be reporting, say, if WIRED had come to you and said, “How do we make things faster?”

Jeff:

Yeah, that was pretty casual. The analysis gets pretty deep, and the process to it gets pretty heavy. I’ve definitely seen multiple-hundred slide decks come out of the analysis a few times.

We’ll start breaking down everything from page weight to how to speed up time to first byte, to how to speed up your rendering, to how to handle the difference between first and repeat views, what to do to reduce your number of requests, the total loading time for everything.

The first thing that’s most important is always the fastest way to get a site that’s useable, which is kind of what we talk about when we talk about a lot of our high-level stuff. We’ll break down a bunch of other things, too. That’s what we do.

Katie:

Do you do that auditing even on clients who don’t come to you necessarily for that? Is that just a place that you start?

Jeff:

That’s totally the place where we start when building somebody’s site. We’ll talk about performance budget pretty early on, and what we’ll do is we’ll see what they’ve got now, and we’ll look at a list of their competitors and run them all through WebPageTest, like two or three major pages on their site.

Let’s say their site is a site where you would go shopping for something, so the search page is going to be a big deal, and a direct listing page is going to be a really big deal, and then the homepage. So, we’ll run WebPageTest for a ton of runs on shaped connections—different kinds of connections from different places for WebPageTest to access, and we’ll be able to set up, “You’re here at eight seconds for your page to be usable on new Google Nexus device. Your competitor does four and a half seconds.”

We’ve seen a measurable difference, and there are some stats out there, that people will be more likely to flip over to a competitor if their site is more than 250 milliseconds faster to be usable. They can feel the difference and they like that. So, our goal is always the maximum time that this site should be able to be useable from this device from this point forward is 250 milliseconds less than your fastest competitor, and that’s kind of how we start to frame how we’re going to build something out.

Tim:

Which metrics do you zero in on that budget when you’re identifying that up front? Or does that change from project to project?

Jeff:

It changes a little bit. The Start Render time on WebPageTest was always my favorite. But at the same time, it doesn’t give you the full story.

What we end up doing is going through film strips a lot of the time. We’ll knock it down to a tenth of a second pieces of the film strip and we’ll say, “Okay, when is this page usable on this film strip?” and that’s our general metric. That seems kind of arbitrary, but really usability of a page is slightly arbitrary. We’ll look at it and go, “Okay, at this point in time, everything is readable,” which is a big deal—I mean, clearly. “I can read all the text on this page. That’s enough for this type of page to exist and for it to work. I can read all the text on it and I can probably start scrolling.” So, that tends to be our general “here’s the part where we’re focused on.”

Katie:

Do you ever have to sell this to clients? Do clients only come to you knowing who you are and what you care about, and they’re like, “Yes, we want a fast site. We go to Filament”? Or do people approach you and are resistant to it, and you have to convince them?

Jeff:

The sell isn’t very hard a lot of the time for us. The big deal for this conversation is you start pointing out things like, “Do you want more people to be able to access your site?” “Well, yes…” “Do you know that if you have an extra 200-millisecond delay, your revenue might drop a high percentage?”

I listened to the first podcast of this series and Lara Hogan was talking about how they added 500 milliseconds worth of time—it was a bunch of empty images and it increased the bounce rate by 12%. We have stats like that for days from Amazon, from Facebook, from eBay, from a bunch of companies out there that are like, “Yeah, when things slowed down, we lost money.” So, that conversation tends to go pretty quickly.

If you build a site that is fast, the likelihood that you will have people bouncing because it’s slow will drop dramatically, and people will bounce because your site is slow. That’s just the way things are. People are pretty dang impatient, and if you make them wait for more than three seconds, they’re out a lot of the time. So, the sale tends to be pretty simple. That, and yeah, a lot of people do come to Filament because they want a responsive site that’s fast. That seems to be our bread and butter, and it’s a lot of the reason we get reached out to.

Katie:

Do you have this master list anywhere of these resources?

Jeff:

I don’t have them offhand, but I will totally grab some for you so you can use them later. [Laughs] But yeah, a lot of it is we just keep on reading the latest journals that come out.

One of the partners at Filament Group has her ears so close to the ground all the time to this stuff, and if you put her in a meeting with somebody that doesn’t believe in performance-related things, she’ll just eat them alive. She’s so incredibly informed about the subject and so good at putting things into a business context. She’ll be like, “I’m going to listen in on this one. I’ll talk to them about it.” I’ll be like, “Hey Patty, what about this?” and she’s just able to rattle it off.

Katie:

What sort of documentation, resources, or education are you doing throughout the project to ensure that your clients keep it fast?

Jeff:

A big part to making sure that they keep it fast is drilling them on, “Here’s where your budget is,” and then also to fold the tooling that makes certain things fast into the building of their site.

An example is we have a tool called criticalCSS. CriticalCSS makes it so, in the grand scheme of things, the site renders significantly faster. It renders significantly faster by inlining CSS to the page for the first visit to the page. So, we have that built into a Grunt task, so when people are doing their builds, it’s just there, it’s put in, and nobody has to think about it. In having pieces that nobody ever has to think about, you have pieces that nobody ever ruins.

We go hard during the beginning times of how JavaScript is loaded into the page. As long as nobody changes these fundamental pieces of how the site is built, then it’s likely not going to damage performance too much.

A lot of our performance techniques are in tooling or in how we load things, and those are things that you’d set up at the beginning of a project a lot of the time. You can go through and rewrite stuff and fold them in, but once they’re in at the beginning of a project, it’s more of a pain to take them out; it’s a pretty big refactor to take them out, a lot of the time. So, that’s kind of a good way to maintain the speed part of it, is to say, “Hey, this is part of your workflow now.”

Katie:

And do they usually pick it up?

Jeff:

Yeah, it’s parts that they don’t have to think about. It’s, “I ran Grunt. It’s done, it’s in there now.” Most of the time it’s easy to convince engineering teams that I’ve worked with, like, “Hey, you guys are building a ton of stuff right now. This stuff right here you don’t have to think about. It’s part of your build,” and they’re like, “Awesome, I don’t have to think about it. I can go work on these other things.”

Then we try to instill, “Hey, when you are releasing new things, check it out. Look at it on WebPageTest, look at it on a few devices.” Once it’s out of our hands, it’s out of our hands, and it’s a little bit harder to continue to enforce that kind of activity. We have all sorts of things in-house to enforce that kind of activity while we’re working on stuff, but once it’s traded hands, a lot of it is just education.

The WebPageTest API provides some pretty excellent tooling that I would love for somebody, or myself at some point, to write a tool that when somebody does a poll request or something like that, it tells you what the performance difference is, or what the Speed Index change is, or something to that effect.

But as of right now, our tooling is mostly education for when we hand things off.

Tim:

When you hand it off, do you work with the clients at all to get some sort of ongoing monitoring system in place? Like a custom instance of WebPageTest, a SpeedCurve account, anything like that to help them keep tabs on things going forward?

Jeff:

We haven’t so far. A lot of the times they’ll have their own in-house testing if it’s a big client, or a big corporate place. They’ll have a lot of new relic pieces to tell at least how fast the back-end parts are, and you can quickly say, “Oh, you have these pieces in. Also make sure you test this other part,” and it seems to fall pretty quickly onto the devs, and the QA, and the teams there to go, “Okay, this is important. We already pay for this other piece. Why not also pay for this?” or “Why not also build this?”

So, we haven’t so far hooked them up with a system. We have our suggestions every once in a while. “Hey, use this to make sure you have a CDN,” “Hey, turn these things on,” and we can tell them how to set those up. But once we’re done handing over templates, which is what we hand over most of the time, that seems to be the end of us with that part.

Katie:

How much do you think being able to really foster this performance-focused culture—because I think you guys are like the model team of “We care about performance! All of us do! A lot!” but not everyone can have all of these awesome resources and then all of a sudden be known for it.

So, if someone just wanted to start to get their organization to think about it, what are some of the takeaways that you’ve learned about this culture that has really influenced that? Is that just being a really small team of seven who intimately know each other’s interests and workflows?

Jeff:

Undoubtedly that’s helpful. Having a small team where we all know each other well and we all know how each other works well, and where we know what each person focuses a lot on is helpful. I’ll never say it’s not. It’s really nice.

That being said, if you want to foster performance in-house, I feel like it all depends on who you need to target to make that happen. If you work at a company where you have the ear of people who make monetary decisions—I mentioned earlier, certain things are pretty easy to sell. Like, “Hey, it’s important because it’s important from a money standpoint.” We always have the “It’s important because it’s important for access.” But access can also mean that.

So, getting the ear of people who make those kinds of decisions and making it a priority in their heads, of, “Hey, do we want our competitors to be faster than we are?” That’s a measurable thing, and it’s a measurable thing in a way that you can get ego involved pretty easily. I’m preaching manipulation tactics here. [Laughs] But getting somebody’s ego involved in a project that you’re pitching is a pretty good way to get that project greenlit. So, that’s a really good system.

And it’s not exactly like preaching performance is the same kind of thing that’s going to sink anybody anytime in the near future. Performance has been a big deal since as long as I can remember. Like, the first really big web dev books that I read right when I got out of school were Steve Souders’, and he’s been doing that for well over a decade now.

But this stuff is important and it’s at the backbone of our entire system, and front-end and back-end ops, and everybody agrees: faster is better. So, I feel like it’s pretty easy to get everybody in on this and go, “Hey, we’re good at this. We can do this. We make things, and we can make them better, and we can make them better in a measurable way. Sign us up.” So, getting team buy-in kind of comes quickly with that, too.

Katie:

It seems to have, only recently in the past couple of years, impacted the design and front-end world, because they’re the ones that Tim and I get a lot of the same questions from, and they’re usually the more design-focused shops that are really struggling to implement this. How does your process help get all of those people involved as well?

Jeff:

I think that the switch in the focus over the last few years has really come with the rise of the underpowered device that we all carry in our pockets. All Filament employees have a test lab in-house. I lovingly refer to mine as the “Jank Tank,” and it’s a tub that I keep underneath my bed, and it has no less than ten devices in it that are just ranging in age. If you want front-end buy-in on performance concepts, hand anybody a $20 Android phone and say, “Now browse the site and use it, because this phone is really popular.”

We developers live in such a crazy bubble just as a group. I’m talking to you now through my brand new MacBook Pro and I’m outdated with my 5S that I use from day to day. Just super, super outdated. But most everybody that you’ll ever talk to that’s outside of our little circle will be like, “Yeah, I use my phone to text and take pictures and stuff, and occasionally I’ll go and search for something,” and they’ll pop on Facebook, they’ll do these things. But they’re not going to want to spend—or most of the time don’t have the freakin’ option to spend—$300 on a new phone. Let’s face it, the average household income in this country is $50k a year. That’s not a priority a lot of the time.

So, we have to think about that, and think about it really, really hard when we’re building things. You can hop on eBay and buy last year’s Samsung blank, that is just this tiny, underpowered Android device, and you can get it for $30 or $40 with no contract. You hand a few of those out to your team, which is a tiny investment in general for this kind of concept, and go, “Here, I want you to use this to browse our site for a bit. Tell me how you feel about it when you’re done.” Use it while you’re building the site. Test with it. As a person who wasn’t always gung ho about performance, that did the trick.

Katie:

Do you ever make them use it for a week? Like, “This is your only phone now. Have fun.”

Jeff:

If I was in charge of the world like that… No, I’ve never gone through that process before, but I’ve definitely been huge on “This is what I test with first always. Every site that we work on, this is what I pull out and this is what I test with.”

The first device that I use right now is just an Android Samsung S3. That thing lags so hard and it’s only a couple of years old. It’s a free phone now, so a lot of people are still getting those. Or I have three-models-ago iPhones sitting in my drawer—pull that out and check things on it. I know a lot of people who still have a 4S. I’ve never done the “Hey, this is your only device,” but I’m pretty sure if I did that, I would have a lot of broken phones.

Katie:

[Laughs] But everybody needs a Jank Tank.

Jeff:

Oh my god, yeah. It’s this investment that you think is really, really huge, like it’s going to be really expensive. But prepaid devices that are a couple of years old from Europe, like the UK, a lot of the time they’re like $25. That’s well worth it, in my opinion, to be able to say, “Okay, a lot of people use this,” or maybe, “This is what my baseline experience should be. Not what my high-end experience should be, but at least my baseline. I want to know that people can use this device, that they can access my site, that when they click on something, it doesn’t spend 30 seconds opening the panel from the righthand side.” So, that’s an investment that I strongly believe in.

Tim:

Do you do similar things with network? Do you occasionally make everyone load up their site on a 3G network with 300-millisecond round-trip latency or something?

Jeff:

I have Network Link Conditioner. That thing is my favorite tool. Network Link Conditioner is so, so good at absolutely destroying any notions that you’ve ever had that your site is fast. You make it so a bunch of packets drop, because that’s reality, is that nobody is sitting two feet away from their WiFi while they’re needing to do something.

It’s not uncommon for me to be out in the morning walking my dogs—my wife and I are looking at buying a home in the next couple of years, so I’ll see a real estate ad. “Oh, okay, cool. Let me visit their website.” It didn’t work. I never remember to go look again. I forget. Their site is gone. Their house might as well not exist in my head. That’s a terrible thing, because that’s a really important decision that I need to make. But I’ve got stuff to think about, I guess, like breakfast or whatever, and I just forget that this thing that I walked by existed when I walk by it at 5:45 in the morning.

The reality of things is that your connection most of the time is just beat to death anyway. I live in Seattle—we’re supposed to have awesome everything-everywhere technology. I think people think everybody from Seattle is mostly robots with beards.

Tim:

And Starbucks.

Jeff:

Yeah, robots with beards and coffee. That’s what we have.

Katie:

And rain.

Jeff:

And the rain. That’s our entire city—just rusting robots.

So yeah, we have this great stuff, but everything is beat down anyway. So, Network Link Conditioner is so, so good at making sure that I can set something and go, “Alright, well I’d like to just destroy my connection and see what it looks like when I hit the site.” Or WebPageTest’s thing where you can knock out a CDN. That’s great. Have you ever wanted to see if a site just holds on render because one of the CDNs got knocked out? Yeah, do that; that’s another good test for that.

Katie:

How else do you break things? I’m noticing a theme between what you and Lara talk about, which is like, “Just break it. Just make it not as good as we’re used to.”

Jeff:

Yeah, I’m always looking for ways to do that because not everybody is surfing on what I have. Not everybody works at the type of desk that I have, not everybody has the internet connection that I have at home. I would venture to say everybody doesn’t have that. I’m in such a statistically insignificant area, everybody else is vastly different than mine. Because I have to have it this way, otherwise I couldn’t communicate with my work. I work remotely—it’s important that I can download things fast and what not.

I’m always looking into ways of breaking into things. Network Link Conditioner is huge. Going through and knocking out CDNs is big. At Filament, we have a cool CI system. Every time you push something to a branch on a project, it creates a new URL for that branch. So, if I have a change I’d like to make—this helps with super fast iteration and also with all of this testing that I was talking about earlier, like how we test whether or not things work—is we’ll just be like, “Oh, and I’ve got this new branch and it is called ’Jank JavaScript Loading.’” We’ll push that up and then it has “Jank JavaScript Loading” as the subdomain for this thing that we’re building on our test server. Occasionally you can just add things in, like, “Oh, and here’s a thing that will act like ads,” and it will just block something, or beat something up here. Having a system in place for that is super nice.

But I would say my major pieces are going through WebPageTest and knocking out certain things, or inserting things where it’s like, “What happens if the font is missing from here?” or “What happens if the CSS just can’t be found?” which, by the way, that normally ends up pretty poorly. But yeah, those are the main breaking tools. I’d love to come up with some more, just stuff that normal companies can use. I know that if you’ve got yourself a really, really big corporation, you’ve got access to Netflix-level knockout poll servers business that most of us just don’t have.

But most of my messing around is messing around with where WebPageTest is or what I can do locally. I know that I can mess with my router, but I haven’t gotten into tinkering with that yet.

Katie:

You could open source the anti-tools, the tools that break everything for you.

Jeff:

Yeah, that’s a lucrative market right there, I think.

Tim:

It would totally flip the Filament reputation, which is sort of, “We fix every problem on the internet right now,” like responsive images and all these other things. Now you guys can be “the agency that breaks everything on the internet.” I think that would be a great selling pitch.

Jeff:

We could just turn heel. That’s awesome. That’s good stuff, I’m writing this down. I’m going to pitch that at our next meeting. “Hey… Did you guys ever think that we could be supervillains? ’Cause that’s also cool.”

Katie:

We were just talking about Joffrey earlier.

Jeff:

Just have everybody collectively wanting to slap us.

Katie:

But it can’t be that bad, because you’re just kind of shining a mirror, like, “This is your real performance. You think you’re good, but you’re not.” You would be like, “Ugh, I want to be mad, but I can’t, because you’re right.”

Jeff:

Yeah, that’s not like getting mad at Comcast, where you’re like, “I’m just mad because your stuff doesn’t work. And you’re mean to me at the same time. Why did you charge me for that?”

We’re in the business of trying to help people. You’re right: shining the big, bright lights on the ugly spots where performance hiccups are is important. That’s why people come to us and what our analysis is early on all the time, is, “Hey, this is really broken in a lot of ways that you can make better,” and then we show them how to make it better. So, that part is good.

I’m a big fan of the end part, or even partially through it, where people are like, “Holy cow! This feels good. I’m using this and I’m able to purchase something in less than a minute that I already knew that I wanted. I google’d for it, hey, it came up here—pop, pop, done.” Or facilitated conversation between people, because it was a classified ad or something to that effect. We’re here to make it so people don’t think about the negative parts of your site while they’re using your site. Instead, they think about, “Oh, well that was easy.”

Katie:

That leads into my next question, which is perceived performance is a pretty big part of what you guys do. Can you talk a little bit about that for people who may not totally know how to grasp that?

Jeff:

Your page can be really, really heavy and can still feel really, really light depending on how you load things. It turns out that nobody really cares—well, some people do when they look at their data bill at the end of the month, as Tim’s website points out—but the upfront loading part of a site is what really, really affects people. That amount of time that it takes for your page to be useable does not necessarily reflect how large the site is.

A great example of this is when using fonts that are not just arial and helvetica, or your standard web fonts that are in your browser already. You can get somebody’s page going in, let’s say, three seconds because it took two and a half seconds for a font to load on Chrome. Everybody’s seen this—you’ll go to a site and you’re looking at everything except for the text. Everybody notices right then and there that the page didn’t work until the text was loaded. Or you can use a flash of unstyled text, which some people don’t like, but I’m here to convince them that it’s much, much better this other way, to a half second in, “Hey, the page loaded. Start reading it.” Or heck, even if your brain is not fully processing it yet, you can still see the text there, and then once the font is fully loaded, it changes the font to match the font that was intended in the first place.

That little hiccup, that little change right there in fonts, that is nothing in most people’s heads to the concept of “I stared at a blank screen for a bit,” and both pages have the same amount of weight, like overall page size. It’s just where you prioritize what loaded first. So, perceived performance and our whole thought process behind it is “Load the bare essentials to get your page looking the way it is, and then in the background load everything else.”

Katie:

Awesome. Yeah, I think that’s a really great concept to keep in mind when working, and even to get out of our own heads when we get super-focused on our performance budget, like, “Okay, not only that, but there’s this other layer that we can add to that.” So, I think that’s super helpful.

Jeff:

The page loading time matters. It really does in the big scheme of things. But I’m definitely the kind of person who, if the length that I want on a page is accessible to me before the page is finished loading, I’m clicking on it. I think that’s not just me. “Hey, I read to this point here. Oh, hold on, I’m going to wait until the whole page is done loading. I can see the spinner going…”

I think if people have access to a piece of information faster, then that’s all they’ll think about, and they’ll just start processing. I don’t think most people want, for example, their face in their phone when they’re out walking their dogs in the morning for lengthy periods of time. Every once in a while, we need to clear our heads.

Tim:

Yeah, it’s nice to take a breath. I know some of the folks at Chrome have been talking about that, what you were just saying, where interacting with a page actually before it’s been fully loaded, but as soon as stuff starts becoming useable, people are starting to scroll and click and explore. So, getting stuff to a useable point is very important.

Jeff:

I think user thought in general on how load a page should take to load used to be, “Oh, well I’m on my phone, so, you know, it might take a while…” I don’t think that people find that acceptable anymore. I’ve definitely watched people get frustrated with something that wasn’t at least useable in a few seconds.

Who cares if your carousel works right away. I can guarantee that that’s not the most important thing on the page almost 100% of the time. People are looking for some details about the thing that they’re looking at, they’re looking for further navigation, they’re looking for parts where they can get to where they’re going. We’ve got little anxiety-causing notification bombs in our pockets all the time, and we want things to move fast so that we can put them back away. That’s just me.

Katie:

I think I’m in the mind already that I use my phone for everything for the internet. Like, when I’m not working and I put my laptop away for the day, I don’t have an iPad, I don’t use my laptop at home, I exclusively browse the internet on my phone.

Jeff:

I’m there with you on that one. I just think you don’t want to spend time waiting once you’re doing that, right?

Katie:

Oh yeah, totally. That’s what I’m saying: right now it’s the norm that if something were to load slow, that’s not acceptable because there are people that only have a phone.

Jeff:

Yeah, like a lot of them. A whole lot. That’s a crazy statistic: there are 6.8 billion internet-connected devices in the world, and most of them aren’t laptops.

Tim:

I think that’s what I like about the general theme of what you were talking about with everything that Filament Group has been doing and how they approach this in terms of making sure you’re breaking things and testing all of these different scenarios. You’re allowing for the incredible variety that comes with something like the web that can be accessed by anything, and ensuring that if somebody is coming on a phone on a 2G network—or what Brad Frost wrote about recently, someone using a Kindle for accessibility reasons—you’re allowing for the fact that you can’t predict all the different places that your site is going to go. Performance is sort of a safety valve for that.

Jeff:

Yeah, for sure. That’s the great, awesome part about all of what we’re building out here: we don’t know what people are accessing it with, and that’s the fun part. Yeah, that’s the frustrating part, but it’s also the fun part. That’s the part where we get to build things that cater to our users, and our users are going to do whatever it is that they want with it. That’s pretty neat.

Katie:

I think that’s a really beautiful sentiment to end on.

Tim:

[Laughs] It really is, absolutely. Well, thank you Jeff. That was fantastic.

If people want to follow along with you or Filament Group and see what everyone is up to after the podcast, where do they do that?

Jeff:

We do quite a bit of writing at filamentgroup.com/lab. Or, if you just go to filamentgroup.com, there’s an “Articles” link right at the top. There’s quite a few little things there about performance, about accessibility, about design, a lot about SVGs.

Tim:

And how about you personally? Is there any place to follow you? Are you on Twitter?

Well, thank you so much again for joining us. We’re super excited to have Filament Group here.

Jeff:

Awesome. Thank you very much. It was really, really great.

Tim:

Thank you for listening to this episode of the Path to Performance podcast. You can subscribe to the podcast through iTunes or on our site, pathtoperf.com. You can also follow along on Twitter @pathtoperf. We’d love to hear what you thought, so feel free to drop us a note on Twitter or leave a raving and overly-kind review on iTunes. We like to read those. And if you’d like to talk about being a guest or sponsoring a future episode, feel free to email us at hello@pathtoperf.com.

Your hosts

Katie Kovalcin is a senior product designer at Vox Media. She writes, speaks, and teaches about the intersection between performance and design.

About

The Path to Performance is a podcast dedicated to fostering a culture around web performance in organizations. We talk to guests who have successfully integrated performance as part of their culture and the benefits they have seen. Hosts Katie and Tim also discuss relevant and interesting news in the world of performance.