with Steve Souders and Mark Zeman

On today’s episode we sit down with Steve Souders and Mark Zeman of SpeedCurve. We talk about the benefits that come from Developers and Designers working side by side, and how the users are often a key component in uniting these (and other) disciplines.

Mark discusses “perceived performance”, and we talk more about flowing the user experience over time, and some techniques on how to do that. We also talk about the difficulty in determining which metrics you should be measuring for your website.

Transcript:

Katie Kovalcin:

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

Tim Kadlec:

And I’m your other host Tim Kadlec. This episode is sponsored by Catchpoint. Catchpoint is one of the leading performance analytics companies out there that provide end user experience monitoring platform that gives you some really detailed performance analysis. They’re used by a lot of large organizations, in fact, they have over 350 customers in over 30 countries using Catchpoint to do performance monitoring. It’s a well designed product, it’s definitely one of the best options on the market and, more importantly, I think there’s a lot of good people over there doing really good work. I’ve gotten to know a lot of the Catchpoint people over the years and it’s just a really friendly group of people. And it’s always nice to be
able to mutually support organizations like that. You can get a free trial at catchpoint.com/freetrial.

So episode 11, Katie, it’s a we—had a little bit of a break here. Didn’t we?

Katie:

Yeah, we kind of organically ended season one after a ten episode
run and took a little bit of break that turned into a little bit longer of a break that turned into lots of other life things and here we are now kicking off season two.

Tim:

Yes! Yeah! Season two! And we’re gonna kick it off with a bang, it’s a good one. I just wanted to mention though, ok, so one of the life things: you switched jobs.

Katie:

I switched jobs…

Tim:

And states!

Katie:

And, yeah, coasts! I went from no coast to gulf coast. Yeah, I started working for Vox product in February which is really cool because we have a performance team! So a definitely performance-minded organization. We’ll be sure to get some of those folks on in a future episode. And I moved to beautiful New Orleans! So if you’re in New Orleans, say “Hi”.

Tim:

It’s nice and cool there right now.

Katie:

Oh definitely, yeah, it’s very breezy.

Tim:

Yeah, no that’s awesome, Vox is cool. I think it’s a really cool story that’s happening there performance-wise. Like how, you know, Vox really I
mean, we talked about it in season one, during one of the episodes at least. The post about declaring performance bankruptcy and, you know, such a huge turnaround for an organization that had one of the publications very vocally talking about how the web was slow because of browsers but then I don’t know exactly how that story happened but internally there was this huge push and commitment to fixing this problem and I think that that’s super cool.

And it’s a killer team.

Katie:

Yeah, yeah, they’re doing some awesome stuff over on that team so I’m excited to talk to them.

Tim:

That’ll be good, yeah. So we did take this sort of organic break, like you said, kind of grew and grew and grew so it ended up being a very nice hiatus for us. So with season two, though, we’re gonna be doing I mean, I think it’s safe to say that if you enjoyed season one of Path to Perf, you’re gonna enjoy the stuff in season two. But we are gonna probably start to include a few different topics here and there.

Kate:

Yeah.

Tim:

Yeah, we’ve been doing, sort of branching out, it’s all gonna still center around that performance culture and performance design sort of theme but we’ve got some really interesting topics and ideas sort of in mind herefor where we’re gonna go. It should be good.

Katie:

Yeah, and if, as always, we love to hear people’s different performance stories or anything like that so, if you are interested in being a guest or think that you have something super interesting that you would like to talk to please email us at hello@pathtoperf.com.

Tim:

Yeah, absolutely, always excited to get emails about that, about cool performance stories to be able to tell.

Yeah, so there’s actually so much because of the long break, there’s actually
so much news that we could potentially talk about here that I think it’s a little overwhelming so I think we decided just to kinda keep it simple for the first episode here.

So, for starters, just wanted to mention that in the last episode of season one, episode ten, we interviewed Tammy Everts, which was, I think was both of our, one of our favourite discussions, she’s just incredible. And we mentioned her book, Time is Money, which is now actually out. It just came out recently so you can actually get it now in print. I’ve actually got a copy right now on my desk and it is fantastic. It is all about what performance means in terms of business impact, looking at all sorts of key metrics. It is a fantastic resource, can’t recommend that one highly enough.

Katie:

Yeah, I got one of the little, pre-release copies when I met her last year at Velocity Amsterdam because that happened a few weeks after we recorded that last episode which is a long time ago now at this point but, still stands: great book. I definitely think that you should go check it out.

Tim:

Yeah, and then also we wanted to give a shoutout to perf.email which is a new newsletter. The newsletter thing seems to be pretty popular nowadays.

Katie:

It’s coming back! Email’s hip again.

Tim:

Yeah, apparently. This is like, I think this is like fanny packs, right? I think I remember you telling me at one point that fanny packs were making a comeback, correct?

Katie:

I don’t remember saying that but it sounds like something I would say! But I also think that the resurgence of fanny packs is also already gone away.

Tim:

Oh, ok…

Kate:

I hate to break it to you.

Tim:

No that’s fine, I couldn’t remember who it was. I assumed it was you. And I also couldn’t remember if this was a serious thing or if somebody was just trying to get me to do something embarrassing in public by wearing fanny packs again or something…

Kate:

That could be.

Tim:

…thinking it was hip. But anyway, email newsletters are hip again, apparently, and perf.email it’s actually, it’s only got a few issues out but it’s really nicely curated newsletter with all sorts of different performance links and things to follow. Katie, you’re mentioned in one of the issues.

Katie:

Yeah, thanks perf.email folks.

Tim:

Yeah, so definitely check it out if you are like, you know, you listen to Path to Perf and you’re like when we talk about these links you feel like you need more, perf.email is fantastic. Yeah, I think that they’re gonna do twice a month it sounds like, too. And, actually, if you want, if you are really into the performance stuff, they actually have a t-shirt and a poster—a #perfmatters tshirt and poster.

Katie:

Yeah, I saw that on Cotton Bureau and I was like, “Woah, that is some dedication to fast websites”.

Tim:

Yeah, apparently. So you could probably wear your #perfmatters tshirt and put your poster up in your bedroom or, you know, wherever it is that a #perfmatters poster should go.

Katie:

You know, what I actually appreciated about the tshirt was the cool design. And I was like, “Hell, yeah! Performance doesn’t have to be boring!”

Tim:

Right, no, it’s nice! You don’t want a performance ,atters tshirt
designed by me, for example. Like this is designed by someone who could do it, which is nice, it’s refreshing a little bit. That way you don’t have to stare at I mean mine would’ve probably literally been something in, I dunno, comic sans or something to make it fun. It would’ve been good. I might still make that. Anyway, yeah, perf.email definitely worth checking out. So shall we get to the discussion then?

Katie:

We should cuz it’s really good because we have a designer and an engineer on so it’s a good four-person discussion, evenly distributed roles…

Tim:

Yeah really good stuff!

Katie:

And I had a lot of fun.

Tim:

I think we both did. It’s Steve Souders and Mark Zeman of Speed Curve which
we’ve mentioned oh, I dunno, maybe in every single episode as being a really well-designed tool to help with performance monitoring. So, it is getting a chance to talk like you said, Mark’s got the design background, Steve’s got the engineering background. The combination, I think, just makes for an awesome discussion.

Tim:

And we’re back with Steve and Mark from SpeedCurve. Steve and Mark, thanks for coming onto Path of Performance, we are super excited to be talking to you guys today.

Steve Souders:

Thanks, Tim. Thanks, Katie.

Mark Zeman:

Awesome to be here.

Steve:

Really miss you guys.

Tim:

You know, it’s been awhile and I know we usually try to keep more in touch than we have it’s just kind of all gone to the side. You know, for some of the people who aren’t lucky enough to know both of you do you mind giving a little background on the two of you as well as SpeedCurve?

Steve:

Yeah, Mark, you wanna go first?

Mark:

Sure, so I’m Mark Zeman, I’m based down here in lovely New Zealand and, interestingly, my kinda background is much more a design background. So spent the last twenty ideas doing web design and had various incarnations of career through those.

It was really about sort of about three or four years ago that I started to get into performance when I was a creative director at an agency and I was asked the question by the management teams and the board members of how fast was our website? What is our user experience like? And how to we compare to our competitors out there in the marketplace and, also, in different countries, you know, how are we doing in China versus the US and the UK? So they really got me interested in the whole design and performance overlap.

And through researching the tools that are out there I came across WebPageTest which I’m sure you’ve talked about extensively on the podcast and we all know and love and is sorta considered the gold standard of open source web performance testing.

But, you know, Pat (Meenan) will admit himself that there’s a lot of detail in there and it’s not always the most attractive so SpeedCurve really came out of the need to present that information in a more digestible way, not just for the engineering folk, but actually for designers and management teams and everyone to be able to have a shared conversation around performance. And so a lot of the visualization work that we do is about trying to help people understand performance in its relationship through to the user experience. And that’s where those user metrics are really important. So that’s me!

Steve:

And I’m Steve Souders. I’ve been working on performance for about twelve or thirteen years. Started at Yahoo where I started the exceptional performance team and we did things like YSlow and “the first fourteen rules” and then was the head performance engineer at Google where we did lots more great stuff. Commuted up to San Francisco for a year as chief performance officer at Fastly. I love Fastly. They’re an awesome CDN but the commute killed me so now I have a 28-foot commute from my bedroom to by garage, working at SpeedCurve!

Tim:

Nice! The grandfather of performance, is that right?

Mark:

No! Godfather! Godfather!

Tim:

I always get them confused.

Steve:

You know, I’m dying the grey hair so I’d appreciate not having the senior citizen references there.

Tim:

I think that’s one of the reasons why Katie and I were so excited to talk to you. Katie is a—she is an awesome designer who is very performance-minded. I’m a developer who can’t design anything and so there’s just even in our conversations and with the podcast I think we’ve both really enjoyed having that the different perspectives on everything and that’s what you and Mark both have. You know, the two of your at SpeedCurve is you have this developer/designer working together and you’re each coming at it from different viewpoints or different backgrounds, which I think is great.

And that’s something that you’ve been talking a lot about, right? I believe you just got done talking in a presentation about how the importance of devs and designers getting together and I think you admitted to cuddling with each other but I think that’s actually beyond the comfort level that most of us are at. But that’s an important thing, right? The developers and the designers working next to each other.

Steve:

Yeah, I think it is. Tim, I don’t know if you remember but the way I talk about how this bringing developers and designers closer together started was a conversation at Velocity New York two years ago with you, me, Jason Grigsby, I think Lara Hogan was there, and we just talked about how websites would be much better from a performance perspective but from a user experience perspective overall if designers were pulled in earlier on.

Amd this was before Lara’s book and before Katie’s talk and Yesenia’s talk where they talk about this design perspective performance and so it was kinda a new idea then and so it’s really, for me, it’s been exciting to see that come about in the real world and we’re just coming off Velocity New York and Velocity Amsterdam. And at both of those we had a design track at Velocity. So we’ve made a lot of progress in two years…from that perspective, from the community perspective. And I know that was something that got me really excited about what Mark was doing and bringing our two backgrounds together at SpeedCurve.

Tim:

Have you noticed with the way you’re working together at SpeedCurve have you noticed some benefits of having cuz Mark you’re coming from that creative director/design background and Steve you’re coming from the exceptional performance/technical background. Have you noticed a benefit in the two of you working head to head for the last how long has it been?

Steve:

Seven months. Eight months.

Mark:

Yeah, I think, I’ve seen a lot of benefits. Certainly the quality of my code has improved. And I think the quality of Steve’s kerning and the quality of Steve’s kerning has improved quite significantly over the last few months as well.

Katie:

Nice!

Mark:

I think the thing that is really interesting is and you’ll see this in our talks is that we both talk about user experience. And I think that’s something that Steve has always talked to me about is that, even though he’s a performance engineer, his motivations are actually to just make a better experience for people and so that’s the thing that’s really kind of binded us in our pursuit of visualizing this information and trying to help people understand what the user experience is like because we actually just care both really deeply about having good experiences on the web.

We know how much it sucks to have a slow, frustrating website and that how competitive the landscape is as well like if something is slow I can just flick over to another website and get a better experience. So I think there’s been real benefits therein having that shared conversation, actually understanding what are our motivations for both an engineering background and a design background to have that shared conversation around UX.

Katie:

So what are some of those common ground of the user experience that you both can talk about? I think a lot of teams really struggle with the designer kind of having a different idea in mind whether that’s more of the heavy brand aesthetics and things like that that I think a lot of designers think is not really performance isn’t really an exciting design consideration. So what are those things that you both really can geek out about together that isn’t necessarily in favour of one over the other?

Steve:

I think, when it comes to geeking out, I think one thing that we’re trying to be innovative about at SpeedCurve is getting better metrics that track this user experience we throw around this term “user experience” kind of loosely and yet we have these very kind of historical ideas of what performance metrics are. You know: “time to first bite” or “page load time”.

And kind of since Tim, Jason, Lara and I talked about design and performance coming closer together, I’ve been talking about how the performance metrics that kind of started ten years ago don’t really correlate with user experience. You know they might or they might not. It’s kind of 50/50. And so we really need to get better performance metrics, better user experience metrics.

A lot of times when Mark and I are exchanging emails or we’re on slack, we’ll talk about UX metrics instead of performance metrics because we’re really trying to hit that common ground between design and development and actually everyone else who works at the company.

Hopefully, everyone who’s working at a company that’s building a web app or a website wants to create this engaging, enjoyable user experience, have their users look forward to coming to the site and engaging with it and so what Mark and I say a lot of times is that’s what everyone wants and so it’s pretty clear that if we have a way of measuring that everyone on the team: design, development, marketing, sales, ops, QA, everyone should be interested in what these metrics have to say. And so I find it exciting, having done this you know I’m going on my thirteenth year of working on web performance that there’s kind of like new ground to uncover and be innovative in. That’s exciting to me.

Katie:

So that kind of it took you some rethinking of how you sort of viewed and worked in performance into more thinking of it in those design/UX terms?

Steve:

Yeah and I think more came about just in the way that the web has changed. You know, certainly five years ago, most sites were still very web 1.0-ish. You know, where each click that the user made was a new web page and so if you were tracking window.unload you actually were measuring something that was pretty, you know, relevant

And today with single-page apps and also, five years ago, there wasn’t so much ability to do asynchronous stuff and prerendering and preloading and prefetching and so things were just simpler and so we could have this not very smart metric: window.unload. But our websites were simpler so that was an ok metric and now websites are really complex even to the point of having single-page apps and so it’s probably no surprise that we need to have more sophisticated metrics to try to capture the user experience of this more complex app.

Mark:

Something that’s always surprised me a little bit is just how disconnected how some of these cultures have become. And that’s always been a little surprising to me. And I’m a little bit old-school in my thinking around this because I started web development in the nineties. And you know at that time if you were a designer you always did your own code. So a big part of my ethos and my creativity actually comes out of playing with the code and prototyping.

And so I’m quite a firm believer in having to understand the technical side of it, not to be a great coder but to be able to understand the concepts and the principles so that you can be creative within those constraints. And something that’s really surprised me is seeing big silo teams and organizations where designers will run away with marketing and they’ll create some kind of beautiful vision in Photoshop and then they’ll throw it over the fence to a development team and they’ll just expect it to come out fast and so we know that that’s just is impossible. And also if you put a lot of time constraints and pressure and functionality into the design then it’s more likely that development teams will throw extra frameworks that just quickly get that functionality in place and we know that frameworks can cause issues with start/render times and things like that.

So it’s been quite surprising to me to see how disconnected those cultures are and I think that’s where user experience, whether you like the term or not, can be a really useful tool in actually just binding those teams back together around, “Hey, what are we all here to do?” And the one technique that I have used, and you can do this with just WebPageTest or we can do it even easier with SpeedCurve, is just put a whole lot of websites together, test them, and show those filmstrips to people because we can talk all day about start/rendering speed index and trying to explain what it is but when you see a filmstrip of your site versus a competitor’s site and you have a big, wide gap at the beginning, you don’t have to say anything.

And I’ve been in situations where I’ve put that in front of management teams and just been quiet and it only takes a CEO a minute to go, “Hey, why is there a big huge gap at the beginning of the start/render of that filmstrip?” So I think those visual tools and talking about UX can help bring those cultures together.

Steve:

And just another thing that seems simple but I just love hearing Mark talk about this stuff. We have a lot of common vocabulary but just you can tell from the way he talks about websites and the creative process that he comes from this design background and I think that that’s really important when you’re getting up in front of a team at a company that is mixed with developers and designers but also other people, you know managers and maybe people from product and marketing. I think having someone who doesn’t just come from a techy/dev implementation background talk about the value of a fast, engaging experience. I think that just carries a lot of
weight.

Katie:

That’s another interesting thing that you talk about, Mark, is perceived performance and how you’re doing some work around that in design, can you talk a little bit about that?

Mark:

Yeah, sure, so perceived performance is a pretty simple technique really. It’s all about looking at those filmstrips and just thinking about what is happening as the page loads and the way I like to think about this and this is still something that we struggle with on a daily basis is that, to me, the web is inherently a timebased medium. And I know Tim’s done some great kind of presentations on this where we really need to think about how we flow the user experience into the browser over time.

Because it’s far too easy to just go, “Right. I’m gonna put
these five frameworks in place and then chuck a whole lot of design at it and I’m just gonna expect the page to load”. And we can see now that that can take you know 5, 6, 7 seconds for something to even begin to render. And we know that people give up after a few seconds and they go elsewhere so perceived performance is really about thinking about every millisecond of that load in the same way that a designer would craft every pixel on screen. And really thinking about, “Well, what am I gonna need on screen first?” And “how do I flow that in over time?”

And there’s some really easy, simple techniques that are easy to apply when you’re first building something which is to prioritize the most important pixels on screen and the most important content and to load that as quickly as possible. And then beyond that, things like skeleton screens we see those on Facebook, Pinterest does some really nice stuff as well, where they’re just rendering just the skeleton of what the app is going to feel like.

So one thing Ilya Grigorik talks about a lot is the first 14k of a request because if you try to deliver on mobile under a second that’s pretty much all you’ve got, is one request and 14k. So that may not sound like much but as a designer if you say to me, “You’ve got as much CSS as you’d like as long as it’s under 14k. What can you draw on screen?” Using some inline CSS or an inline SVG, to me, that is a huge amount of bandwidth. You know, I can put some colour in, I can paint a logo, I can probably sketch out some blocks on the page and probably get a few icons and things in there, all under 14k.

And when I’ve done tests with this, you know you can take existing sites, and you can go, “Right, under 14k, how much of that site could I recreate?” And when you see the load difference. Like, I did a test with a Nikelodeon website where I think their start render time was something like 8 seconds. And I did a perceived performance, “What can I do in 14k?”, and I got that rendering in under half a second. And you know, I had the logo and I had the colour and it felt like you had arrived at the right place. So I think there’s a really interesting crossover there between design and the development cultures where you need to know code, you need to express your design and your creativity in the code itself to really bring to life some of those perceived performance benefits and then you can load in all the frameworks, then you can stream in all the JavaScript and extra functionality you need.

Tim:

Well and that’s one of the things about the intersection of the designers and the developers and them working more closely together that gets me really excited. One part of it is just doing things a little better, being able to work side by side helps you do things that you’ve been doing but do a better job of it when you have a little bit of that design perspective and a little bit of the developer perspective but especially when you pair that with some metrics and stuff that are more focused on the actual user experience, what really excites me is the newer things, the newer, innovative ideas like the skeleton screens or, I think in one of your talks, Mark, you mentioned a site that you had worked on where you did some interesting stuff with low-quality image sprites.

Like, it’s those other solutions that really only happen when you have that design thinking paired with the code knowledge and you have those two camps so closely together that they’re viewing it in a totally new lens.

Mark:

Yeah, that’s right and some of those projects. Like, to me, the most fun and the most creative projects that I’ve ever worked on have actually been the projects where the developers they’re there for the absolute outset of the project. So they’re there during the creative briefing stage and they’re really thinking about “How are we going to deliver this?” And it’s gone as far as where those developers have actually had a direct influence over the content itself so they’re there right from the outset actually helping shape not only what this is gonna look like as an experience but really thinking about how they deliver it over time.

And, in my experience, developers are some of the most creative people people around and I think it’s a tragedy that we have sometimes these silos where designers run away and try and craft something in isolation and throw it over the fence so I really strongly encourage those small, cross-disciplinary teams where you can really experiment and innovate with prototypes very early on.

Katie:

I 1000% agree.

Mark:

It’s so much fun too. It’s so much fun.

Tim:

So let me ask—so going to the user-based metrics that we’ve been talking about, I know that you both have talked and I think, Steve, you mentioned it earlier in this conversation, the importance of looking at things like Speed Index or, even better yet, some sort of a custom timing based on your own site. How does a company get there because the user timing—the custom marks and everything—that’s been there for a couple years but it seems like the adoption’s been slow. So what stands in the way of that really taking off and how does a company go about deciding what they should be looking at there?

Steve:

I think that’s really hard. I think that’s why window.unload was and still is such a popular metric because it’s really easy. You don’t have to do anything. You can just check your URL in a service like SpeedCurve or Webpagetest or add an off-the-shelf RUM product and you kinda get this sense of comfort that you’re tracking performance but it’s really, for most websites, a false sense of security because it’s measuring something that really is irrelevant to what your users are doing. And so I think that’s one of the things that’s holding the adoption of User Timing back is you have to go through and write JavaScript code and put it inside your page and even before you do that you have to figure out what are the most important things in the page that you wanna track. And that’s not easy. I’ll tell you, starting about a year, a year and a half ago, I really started beating this drum of “We need to use usertiming and create custom metrics that focus on the most important stuff on the page”. And you can see how that resonates with what Mark was just saying about we need to think about websites as like mini films where the content is flowing in over time. So if you have a metric like Speed Index or start render or onLoad time that treats all the pixels in the viewport the same, gives them all an equal value, that tells you that that’s not a good metric because for most websites different content, different elements on the page have different value value to the user and to the business. So you got to measure those things. And I know I’m going through speedcurve.com, our own website, and I’m adding these user timing metrics and it is hard to figure out, 1) to figure out what are the most important things to measure on this dashboard, what’s the most important thing?; and then 2) to figure out how to write the JavaScript to measure that.

And it’s been especially hard because we do a lot of asynchronous stuff in our website and so you know it’s just tricky JavaScript code. And I think maybe in a year we’ll have some good wrapper libraries around it but teams are still gonna have to roll up their sleeves or at least are gonna have to figure out what in the page they want to measure. And I think for at least for another year or two they’re gonna have to roll up their sleeves and add that JavaScript to the site.

Tim:

You know and that really emphasizes the importance of this holistic view of it because if you think about the start of project when you’ve got the content strategy process and the initial design steps, that’s where a lot of those conversations about what is priority and what is not are coming into play. So that’s another argument for why that performance aspect and why the developer needs to be involved at that point as well because those initial steps of the project are often where you’re hammering out what takes priority on this page and what takes priority on that page.

Steve:

That is so true and I’ve been in a lot of, over the last ten years, I’ve been in a lot of meetings where we didn’t set those priorities at the outset and we tried to sit down after the product was launched and figure out what mattered the most to the users and to the business and there was a lot of disagreement on the team. So, yeah, it’s really good to have that process up front.

Mark:

Well, and the other value of it is just how that binds an entire organization. Like, I think the best example is Twitter’s time to first tweet. And so you can imagine how something like that works in an organization where everyone is really clear on “this is the most important metric”.

And I don’t know if you remember but remember how Twitter went through that whole hashbang kind of “we’re gonna load up big JavaScript frameworks” and things like that? I wonder if the time to first tweet really came out of that experience where it was like, “Hey, what is it that we’re actually trying to optimize here?” And it’s actually getting that tweet on screen as quickly as possible. And so having a metric like that, think about what it might be for your organization, it can really help the creative process as much as the development process so the designers know “Hey, what’s my time to first tweet?” Is it this hero image? Is it this product image? You know, what’s on screen that’s most important for the user experience?

Tim:

Yeah see this is why I think what Steve was saying earlier and what Katie was talking about how this is like this exciting, learning, new-think territory because it’s really just it’s taking everything we’ve been doing for the last decade or so of performance and just making it so much more mature and so much more focused on the user. And it takes a combination of everything that we’ve been talking about today: the developers and the designers but also the different metrics. It’s a big problem that has many facets to it and in order to push it forward.

Steve:

And I really, I think everyone can really get behind this idea of putting the user first. You know, I think that it can bring all parts of the company together and bring agreement. And so, to me, it’s like great to highlight that and push that as the focus of design and of the design and performance work that we’re trying to do.

Tim:

Yeah, I think that’s music to our ears over here for sure.

Katie:

Yeah, I really like this idea of the user as kind of being that common ground and that conversation piece and just really that key component to unite all of the disciplines.

Tim:

Yeah, that’s the way it should be.

So I know that we’ve gotta get going which is too bad because I feel like we could probably pick both of your brains for I dunno, what do you think, Katie? Like another, oh…

Katie:

Several days.

Tim:

Yeah, that seems about right.

So what we may have to do is we may have to bring you back too at some point in the future because I feel like there’s a lot of little rabbit holes we could go down. But this has been really good and I think this a really important topic to talk about.

Steve:

We agree.

Mark:

It’s been a pleasure, love to come back any time.

Tim:

Alright.

Katie:

Awesome!

Katie:

Thank you so much!

Tim:

Yeah, thank you.

Steve:

Thanks, bye Katie, bye Tim!

Mark:

Thanks guys!

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.