Transcript

Chris LoSacco You put a long rant in the Postlight.com channel after we ran that test. Let the record reflect. [Gina laughs.] 

[Music fades in, ramps up, plays 10 seconds.]

Gina Trapani Hey Chris.

CL Hey Gina. [Pause. Both laugh.] We should have coordinated who was going to say what.

GT Yeah, we were both waiting and then we both—that happens sometimes and that’s okay.

CL We’re just on the same wavelength, that’s all it is.

GT Exactly. Exactly. How’s it going today?

CL It’s going great. How are you?

GT Doing well. Doing well.

CL Good. We’re going to talk about speed. So I feel like we need to talk quickly. We should probably take a breath and settle into it.

GT [Laughs.] This is easier for me. I feel very passionate about this. When I feel very passionate I talk very quickly. This is my plight as a New Yorker.

CL Yes. We need to dial it down. Let our content do the talking for us. [Gina laughs.] The setup here is we are going to go deep on the most underappreciated feature of every digital platform that is out there. And it’s not, it’s not on a feature list. I mean, sometimes it is, but it should be on every feature list: and that’s speed.

[1:15]

GT It’s only on the feature list when it’s too late, because it’s slow. 

CL There you go. 

GT Cause you could flip the framing here and say, what is the most annoying thing about any digital experience? What is the most annoying thing? Spinners. Bones. Progress bars. The little flashing bones. 

CL The skeletons. 

GT The skeletons. [Laughs.] I don’t know what I was saying, but skeletons—flashing skeletons, like progress bars, the spinner, the little gray spinner. Oh—

CL It is the worst.

[1:44]

GT It’s the worst. I have the Hulk in me. I turn green. I bust open my shirt. [Chris laughs.] I just get so angry because when you think about the number of seconds that I had to wait for a page or an interface in an app to load and multiply that by the millions of humans, assuming that this is like a popular and well-used app, right? Which you can, for a lot of apps—the millions of people who had to wait all those seconds. Then if you added all those seconds together, the years of humanity wasted.

CL [Laughs.] Of wasted human productivity.

[2:16]

GT Wasted watching a spinner—it’s galling.

CL And the thing is—it’s so, I shouldn’t say easy, that’s the wrong way to frame it, but it should always be at the top of your priority list, period. Like every single product team that is working on building a software platform, at the top of your list should be, is it fast?

GT Is it fast? 

CL It should come before everything else. Because if it’s not fast, you’re going to introduce drag and annoyance and frustration in every single thing that the person who is using your platform is trying to do. And it is devastating. It is devastating as a user, like when you’re trying to get something done, but it’s also bad when you’re trying to, you know, if you’re a product manager or an engineer, and you’re trying to think about the future of your platform. And the dang thing is like not loading or it’s like trying to swim through molasses as you’re trying to get something done. Like it’s just so incredibly frustrating. There’s no excuse—like it should be at the top of everyone’s priority list.

[3:15]

GT It breaks trust, right? Like the person, you know, the person who’s trying to get a thing done is just like this app is not the bicycle for the mine. [Laughs.] No. It’s like the sledgehammer for like the brick wall. You’re just like, I’m just trying to get things done. You’re slowing me down. But it’s so common. I mean, it’s just so common, particularly like big complex platforms that have to do big, important things. I mean, the first example that comes to mind for me is health insurance websites. Like if I have to log on to check a claim, I mean, you wrote about this on our site, like just multiple refresh, login, handoff progress bars, spinners, skeleton, the whole, I mean, and you’re just like, okay, just, I’m just trying to log in here. And you’re just like, doesn’t this annoy the people who work at this place, like who? Like for whom is this okay? Like I’m sitting here with my like Fios connection and modern browser and I’m tapping my fingers waiting for this platform to load. How does this happen? Why do things get so slow?

CL It’s a great question. It shouldn’t happen. I mean, one of the ways I think, is that things get caked on. It doesn’t start slow. But then you add a lot more data into your database or you put in a few extra features that cause undue burden on the backend and you don’t spend the time to shore up what you’ve built. And these things kind of like accumulate, like layers on top of the core piece of functionality that was screaming fast. And before you know it, everything’s taking 4, 5, 10 seconds to load. It is an ongoing process. As you build and enhance your platform to have new things, you also have to be thinking about what modernizations do I have to be making to what is already there, to make sure that it’s running super quickly. I mean, a gimme thing, and I know the engineers listening will appreciate this is database indexes. Like you’ve gotta make sure that you are thinking about having proper indexes on your database tables so that queries can be fast. We’ve done work with some of our clients around their elastic search and other search infrastructure where you’ve gotta make sure that things are configured and tuned properly, especially as your data set grows, so that you’re getting results quickly as the platform is evolving. It’s not just like you do the work and you’re done. You need to constantly be thinking about as you are adding stuff and things are getting slower. If they’re getting slower, you are addressing it so that they stay fast through time rather than getting slower over time.

[5:49]

GT Yeah. I mean that caking on thing, it’s like, oh, we’re just going to add in this extra handshake. Oh, we’re just going to drop in this other piece of advertising, you know, like Javascript. 

CL Oh my God. 

GT Oh, like we just got this other third party integration we’re going to like land in there, and you know, that ticket gets done, right? Like that thing it’s like, okay, done. Marked off, like cool. We have that new thing. But what has to happen is that you have to look holistically at the user experience, like end to end. I have initiated this action and now look at the entire journey through the caked-on layers of all the things and how many—and literally a lot of times for these bigger platforms, especially these more complicated experiences, it’s in seconds, you can measure it in seconds. What’s the typical rule of thumb that a user starts to feel slowness. It’s like half a second or a quarter of a second? No, it was even less than that, isn’t it?

CL It’s less than that. I think it’s like a hundred milliseconds.

GT A hundred milliseconds is the place where users—

CL You can perceive it.

GT Perceives that like, there are tiny little mice on a crank, running on the wheel inside the servers. Yeah. [Laughs.]

CL You made such a good point before. Some business folks think you get it for free when you just drop something else into the platform, you know? Oh, we have Google tag manager. So it doesn’t matter if we put another tracker in here or if we put another different ad provider, whatever, it’s fine. Like it’s so little work. But the reality is there is a real user impact there because when you add something that is controlled by a third party, and you’re trying to funnel it through your system, if you are not thinking about smart ways to do that, or, you know, optimizing, when it gets loaded, basically to the user’s view, you’re going to have a real impact on your user experience. And things are going to slow down and we’ve seen it countless times where we have to come in and clean up tracker after tracker of things that were just plopped in by a marketing lead or a business lead, who wasn’t thinking about what is the core experience of this product.

[7:46]

GT Right. Everyone’s going to watch this page paint itself from here on in, because of this extra thing that we dropped it in.

CL Exactly. Right. For so little value on the other side. Oh my gosh. I’m getting frustrated just talking about it. I want to go back to something else you said, Gina, as you were talking, you said, I’m sitting here on my Fios connection and you know, why are things so slow? And you’re right. If you have a high bandwidth, strong connection, it’s even less okay that things are not responsive like they should be. But you’ve got a huge population of the world out there that does not have access to high bandwidth connections. And it’s something we’ve thought about in various ways with our clients over the years, but thinking about a good experience for low bandwidth users and by the way, sometimes I’m driving upstate and my phone starts to get a bad connection. And guess what? I’m a low bandwidth user [Laughs]. So you need to be thinking about how your app gracefully degrades, so that as you’ve got a smaller pipe to send bits through, you’re still getting a passable, ideally a good, experience. Even if you don’t have the full facility about you when it comes to grabbing data. And this is something you need to think about from a user experience angle, not just from a smart engineering angle.

GT Yeah. I mean, definitely this is the thing the mobile revolution happened, right? Everyone has to access things on their mobile device. A lot of the innovation that was required. I mean, one of my favorite, low bandwidth or speed innovations stories is about how Facebook got to load the newsfeed—you know, if you look at your newsfeed in Facebook, there’s so many pieces of information, right? There’s like information about users, there’s information about the post there’s information about the links, there’s information about the likes, all the hearts and the reactions, and most of Facebook’s users were on mobile. And they were sending these giant ABI payloads over mobile connections, low bandwidth connections. And they were like, the experience was so slow. Their absolute mandate was stickiness and keeping users engaged and users don’t stay engaged when they’re just waiting for stuff to load. And this is how GraphQL was born, right? Like GraphQL is an API interface or format that sends only the information that you need ,no more and no less, you know. One single call that stays optimized and small as possible. And it’s a very widely accepted, I mean, it’s kind of the best practice or the standard now for great modern APIs. Because every time you make a network connection that creates drag, every time you send over data, that isn’t going to be shown in the front end, that’s just like wasted bits over the wire or over the wire wireless connection. So all the tools are there. Like if you can make an experience that works on a phone, on a low bandwidth connection, then, you know, in the full browser on a fast connection, that’s a gimme. But in reality, that hasn’t really played out. I mean, a lot of platforms like split their mobile and their web experiences, but there was some part of me that’s like, we have everything we need to make everything super fast because you know, we’ve been there. It’s been years. It’s been how many—it’s been 20 years since smartphones have started browsing the web. And yet it’s still like a lesson I think that a lot of people who make products and build products are like, oh, this thing is super slow. You don’t wanna get the ticket that’s like, this took me five seconds to load. Lots of things went wrong in order for that ticket to get to you.

[11:15]

CL Totally. And not to be like, cavalier about it, but how did that happen? Like how do you get to the point where you’re like, you’ve got end users saying this is taking five or 10 seconds to load. It’s unbelievable. Like your product people, your designers, your development team, like you should be catching those things. It should be again, I’m repeating myself, it should be at the top of your list for every single release. You should make sure that you are not introducing additional slowdowns or bottlenecks as you’re releasing features. Yeah. I also, I think about the difference between how much processing are you requiring your users to do like on their devices versus how much processing are you taking on the server, on server side? I don’t think there’s one right answer that we can say to people. I think it’s platform dependent, but it’s an interesting trend that I feel like we’ve seen in our work, especially with big publishers, is that as front ends have gotten more and more complex and you want to do cooler things on the editorial side, the weight of the page and the JavaScript payloads that you’re sending down are getting bigger and bigger, and you’re requiring the user’s device, right? Their laptop or their phone to do a lot of processing on things that you probably don’t need to process at the end. It could be a lot faster if you’re handling those things on the server and then delivering pre-rendered stuff that goes over the wire and shows up—it literally gets painted on the screen much quicker. I don’t wanna say that that’s a hard and fast rule. Like I think that’s a conversation as you’re looking at your product, but thinking critically about your platform’s architecture and specifically how much client side processing your app is doing versus server side processing is something that every team should be thinking about.

GT I mean, definitely it’s—I don’t know how many sites, websites or like media sites or publishing sites that I’ve worked on where it’s like, oh, we’re downloading, you know, multi megabyte images that are being resized the browser. And there was just no reason to do that download advertising. And those little bits of JavaScript are a big one as well. I mean sometimes it’s hard because you’re dealing with CMS and you have non-technical people uploading multi gigabyte image files and they want it to be really beautiful. And they’re not thinking about—it’s a particular mindset of like, how do I minimize and optimize? But a lot of the stuff you can build in to handle, you know, on the server side.

[13:25]

CL It shouldn’t be the user’s responsibility. I mean, if you’ve got a photo editor who wants to put big, beautiful images up into the CMS, they should, that should be a good thing. And it’s the platform, it’s the software that should help optimize and say, oh, I’ve got a user on a low bandwidth connection. I’m going to respect the fact that they’re requesting smaller images and adjust accordingly. Right? I mean that particular example, there are some great services out there right now that’ll resize images on the fly and provide like different encodings to make sure that things are super efficient. It’s up to the engineering teams to make use of those and build those in from the outset so that you’re not requiring users to basically work around the system to make sure that it’s fast. That shouldn’t be the requirement.

GT Right. It’s true. Yeah. Totally agree.

CL It’s so important. Speed also—it trumps some of these other things. If you’re trying to get something done, you know, you might be able to do it, but if it takes you 10 or 20 times as long as it should because you’re waiting for screen after screen to load, you’re going to get frustrated and you’re going to go somewhere else. So you’ve gotta also balance and weigh essentially the fact that functionality can get, even if you’ve got some amazing differentiating next generation stuff, if the users can’t get to it fast, they’re going to go elsewhere.

GT It’s meaningless.

CL It’s meaningless.

GT And I think this is why you don’t hear from users: Oh, this is slow because they’ve left. They’ve left already. They’re like, I don’t have time. Like I just don’t have time for this. I mean, the reality is that I sound incredibly impatient and demanding, but our attention span on these devices when most people don’t wanna be logging into their healthcare platform or they’re trying to get something done. They just need to get done and get on with their lives. It’s just too easy to be like, ah, screw it. I just don’t have time for this. [Laughs.]

[15:09]

CL Yeah. No, it’s true. I’ll give you another example where we, I feel like we see it is gaming. And when I say gamer, , I’m taking a broad definition of gamer. I’m not just talking about, you know, pro eSports players who are on a team. I’m talking about like even casual gamers. They expect that the interface is going to load really quickly. And that even the things that they’re doing that are not the core, I mean, the core game has to function well, but the whole experience has to be fast. And if it’s not fast, they’re going to go somewhere else. You know, my son is nine and his tolerance is even lower than most people’s. [Gina laughs.] And if he’s looking at a spinner, there’s not even a second thought. I mean, he’ll just delete the app wholesale and be like, I guess I can’t play that game.

[15:50]

GT Guess I can’t play that game. That’s not for me. Next. [Laughs.] Right. Are there any particular, like, I don’t know. I know there are a ton of tools out there. There’s a whole art, right? Especially there’s front end, there’s backend. You wrote a piece for our website about health insurance sites and why they’re so bad. And speed was one of them. It was an incredibly damning video of the spinners going. Are there particular tools that you turn to, to go, just like, Hey, this isn’t good. This isn’t working here. You know, beyond developer tools. I mean, bringing up developer tools in the browser and just watching all the network requests and how long they take alone can tell you a lot.

CL Yeah. Let’s start there. I feel like, you know, we have a lot of engineers who listen to the podcast. The developer tools are incredibly powerful, even for non-developers. I mean, we’ve had product people or designers who pull up the inspector and yeah, you can look at the network. You can also look at how things are painting and see where there are delays in the rendering of the actual app. That’s worth looking at. Google has a tool called Lighthouse, which I believe is built into developer tools, which allows you to run an audit on your pages. This is especially useful for like publishing sites. Where you’re looking at statically generated pages, cause it’ll give you a really good sense of like here’s how your page scores and here’s where you’re slow. And it’ll call things out like image optimizations and payloads that are too big and CSS that is unused. Those kinds of things. Some of them are small, but they add up and you know what we were saying before, how things gotta get caked on, it’s a compounding problem because when you don’t address one thing, more get added and before you know it, you’re looking at multi-second page loads. So that’s something that I would say is like, you know, should be the first stop as you’re thinking about where things are slow on the server side, we’ve used a tool called Honeycomb. Which is really good, partially for debugging. It’s good at seeing how traffic is routing on the server side. But in addition to diagnosing issues, it can also be really good to say where’s the latency, where are things slow? And then it may not tell you how to solve the problem, but it’ll tell you where to start looking for it, which could be very, very valuable when you’re looking at a slow database query or something wrong in your search infrastructure, a tool like Honeycomb or another server side analysis tool will point you in the right direction to say, let me figure out how I can start diagnosing it. And hopefully ultimately fixing this.

[18:14]

GT That’s right. I forgot about Honeycomb, it’s very useful. I’ve seen the reports. I have a sad confession to make, which is that we ran postlight.com through Google page speed insights. 

CL Wasn’t pretty. 

GT And after this rant, I’m here to tell you it wasn’t pretty. And I was embarrassed because this is the thing, that point you were making earlier about things kind of get caked on or you like add a few things here and there and you’re not, you’re not like, okay, let me go back and now test end to end speed. Like, like stuff happened that shouldn’t have happened and it wasn’t optimized. Right? Like checking in on speed. It kind of has to be like a regular part of the end to end test or just, it’s similar to SEO. Like SEO isn’t like, oh, I’m going to structure my site well and write content that you know, is going be useful for others to find. And then I’m done. Especially a site that you’re constantly publishing on. It’s something that you have to think about as an ongoing concern. Because if speed isn’t an ongoing concern, like you just lose track of it. And the next thing you know, your marketing people will be like, why are the website’s pages so slow? And you’re the CEO of a technology company. And you can’t believe what’s happening. 

CL Hypothetically. 

GT Hypothetically speaking of course. [Both laugh.]

[19:20]

CL Let me ask you something, Gina. What does it mean when someone says the UI is non-blocking or the interface doesn’t block? What does that mean when we’re thinking about building an interface? Here’s how I interpret that. I think about that like making experience choices that allow things to happen in the background or asynchronously, right? It’s a very common pattern for engineers to think, how can I offload processing to happen asynchronously? But I think product people and designers are not always thinking that way when they’re thinking about the user interface, right? The actual thing that people are interacting with. But the same kinds of methods apply. Right? If you, you know, we worked on this big platform for the MTA. One of the features is that you can write a message and publish it to many channels with the same user action. But the way we wrote and designed that user interface is that when you hit publish the UI doesn’t wait for all of those things to happen.

GT That’s right. 

CL The UI is immediate. It comes back and it says, great, we got your request. And then there are separate threads that happen that get kicked off for sending an email posting to Twitter, putting it on the website, etc etc etc, putting it on screens. And the UI updates in real time when you get responses from those various output channels, but the net effect to the user is they’re not waiting. Even though things are happening on different time scales, they’re not having to sit there and look at a spinner. And it feels to me like this is a major gap in a lot of UI design that’s out there is the whole interface blocks when you try to do something, even if the things that are happening could be happening in separate processing channels. You know what I mean?

GT Absolutely. I’m old enough to remember when you’d press a button on a webpage and it would submit the form and it’s higher. It would post back to the server and then the server would have to process and then return, you know? Right. And then we moved into, I could press a button and it’s going to process the API request and the page doesn’t—whole page refreshes are no longer a thing. I mean, they are still a thing, you know, on some of the slow stuff. Like waiting for the confirmation page to load. That’s a very old pattern, right? The new patterns are interactive, reactive interfaces where things can happen while you wait. Those design choices really kind of tell you a lot about how the thing was designed, whether or not it’s using sort of modern best practices. And so, yeah, I’m a big fan of non-blocking UI. Take me on my journey. Go do what you gotta do. Let me know when it’s done.

[21:57]

CL Exactly. The same thing applies, I feel like, in mobile apps, like this is not just, I’m using a webpage or a browser sitting on my laptop. 

[Outro music fades in, ramps up.] 

CL If you can let people get around the interface while work is happening, I can think of several instances where I try to log into an app on my phone or I try to submit a form, not submit a form so much, but like make a request to do something. And the whole app just hangs and I can’t do anything. Right. It’s completely frustrating and it makes the whole thing feel slow—the whole experience feel slow. And if you just let that happen in the background, everyone’s going to be better off.

GT Yeah. It’s true. Let the user keep going.

CL Let the user keep going. You need that on a t-shirt: let the user keep going.

GT Just let the user keep going. [Both laugh.] This was very cathartic for me. I’m so glad that we had the speeds conversation—even with my confession. I’m about to go to our website right now and see how slow or fast it is right now because people are going to hold us to this and they should.

CL That’s true. We’re going to get emails to hello@postlight.com saying why isn’t your website faster?

GT We would love to get those emails. 

CL That’s right. 

GT Please reach out. Thank you so much for listening to the show. We are a strategy, design and engineering firm based in New York City and all around the country. Postlight. You should send us a note: hello@postlight.com.

CL We’d love to hear from you. Thanks Gina.

CL Thanks Chris. Talk soon.