In some respects, we have moved on from the trend to overload web pages with too many features, but it is still worth emphasizing why performance should be at the top of your list of priorities. Today we talk about progressive performance and some interesting ways to approach and think about creating the most user-friendly websites possible. To do this, we break down why this is necessary and how to go about it; from tools and tricks to the studies that have shown how users react to load times, and buggy pages. So to hear about how you can get away with slightly slower speeds, and why learning about the tools that you will be using to tackle these issues is so important, make sure you come down the Rabbit Hole with us, today!
Key Points From This Episode:
{{addCallout()}}
Transcript for Episode 230. Progressive Performance
EPISODE 230
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast, living large in New York. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.3] DA: Dave Anderson.
[0:00:10.1] MN: And our producer.
[0:00:11.3] WJ: William Jeffries.
[0:00:12.0] MN: And the intern.
[0:00:14.4] SC: Sophie Creutz.
[0:00:15.4] MN: Today, we’ll be talking about progressive performance for your application.
[0:00:20.5] DA: Yeah, I think a lot of times, when people think about web performance in their application, they think that everything has to be fast but I recently learned about this concept of progressive web performance from a colleague while we’re working on improving the page load times of an application and it’s like, “Wait, not everything has to be fast, you just have to do the right things first and deal with everything else later.”
[0:00:46.8] MN: It’s not just having really tiny images and then just showing it to the user because that’s the fastest way to get to –
[0:00:53.5] DA: I mean, that’s super important but if you have to choose between sending it a hundred images that the user is not going to see because they’re not going to scroll past the initial top of the page that they’re going to see and sending one really big image that they are going to see then, send the big image.
[0:01:15.2] MN: Right. I think the first thing that comes to mind is, suppose you have a website and I don’t know, 2008 where carousels was a really big thing.
[0:01:24.8] DA: it’s still a big thing, 2021, year of the carousel.
[0:01:31.0] MN: If you have 30 images in the carousel, the idea is not to load all 30, if you’re loading three and then you slowly slide, right? That’s the idea that we’re getting at?
[0:01:40.1] DA: Yeah, exactly.
[0:01:41.4] MN: Cool, we’ll talk about why this is important and how do you actually do it? Let’s talk about why. Why should we care about what performance at the end of the day?
[0:01:51.4] DA: Yeah, I don’t know, I just want more features, really. I don’t really care about web performance, we just need more buttons and carousels on the web page.
[0:02:03.7] MN: More carousels.
[0:02:03.7] DA: Yeah, basically.
[0:02:04.8] SC: What about that end user though? How do they feel about all these buttons and carousels?
[0:02:11.6] MN: I would think they want it, right? They got to use the website and the website has more buttons. Who wouldn’t want to use this website Sophie, what do you think?
[0:02:22.6] SC: Well, it certainly could be intriguing but we have to think about user engagement and I think folks are probably going to abandon the website if for instance, the loading time is too slow.
[0:02:39.0] DA: Right, yeah. If it takes 45 seconds to load my page with 20 carousels on it and the user only looks at the first carousel, then I guess I will have failed in some way.
[0:02:55.3] WJ: It seems like performance is one of those things that users don’t really ask for until it’s really desperately needed. I think a lot of people are used to the Internet being slow a lot of the times and there’s a pretty high tolerance for bad performance.
Users will tell you, “Oh, what I really want is some weird syncing thing," that actually for some reason, no other users want. You end up chasing down all these weird feature requests and trying to figure out how they tie in together when the thing that would actually increase sales the most would just be making the products load a hundred milliseconds faster. There was this study, an often-cited study from Amazon where they found that every hundred milliseconds of latency cost them 1% in revenue, which is a huge number, when you’re talking about Amazon.
[0:03:48.2] DA: Yeah, I think that’s one of the challenging things about web performance too because I was having a conversation with someone where there was a change that had to get reverted and they’re like, “Oh, well, this change was causing a problem for people, we had to revert it but it’s fine because it was only a small performance gain of 500 milliseconds.” And it’s like, “Wait, 500 milliseconds, that’s huge, that’s half a second.”
In the time of my life, 500 milliseconds is not that much, but in the time of the user’s attention in the age of the internet, it is, it’s a huge hit on user engagement and sales.
[0:04:31.3] SC: Why do you think in that moment that wasn’t prioritized? Did you need to get more buy-in from the stakeholders or project managers about how important these performance metrics are?
[0:04:44.9] DA: Well, I think at that time, there was an immediate issue that we had to address because there was some degradation of functionality. We did have to go back to the drawing board and rework it a little bit. In the end, when we put it back at place, I think there’s a shift in perspective, has to be there when you’re kind of chipping away at a performance now and where 300 milliseconds is massive and 100 milliseconds, that’s pretty good too.
[0:05:17.2] MN: I think, I don’t know if we mentioned this but what the expected time that a webpage should load? Is there a magic number that gets used?
[0:05:26.4] DA: There’s really good documentation out there, like really good article is written about the web and web performance by MDN and Google. MDN, they cite studies that show that there’s a general expectation that a website is going to load in two seconds or less and people are going to start fleeing from your webpage at three seconds.
You may have the more sticky users where, “Yes, I’m just going to wait 45 seconds for this,” or they may not have a choice also like if you’re using some kind of internal software and the user has to go through it. If the intranet takes 45 seconds to load, then I don’t know, I guess I’ll just think about something.
[0:06:18.8] MN: Go make coffee. Have a sword fight with your coworker.
[0:06:21.8] DA: Right, exactly.
[0:06:23.3] WJ: The other thing is, it’s much more complicated to measure how long a webpage loads than it is to measure how long a request takes, right? If you're designing an API, it’s very easy to say, “How long does my API — this particular end point on my API take to respond?” Because, there’s just one thing that happens.
On a webpage, it’s like, “Are we talking about time to first bite, are we talking about time to first paint, are we talking about the time until the last paint?” And if it’s a site that has something moving on it, how do you even know when the last paint happens? A lot of these React apps have so many little fun widgets, it’s kind of hard to know, is the page done?
[0:07:04.9] DA: Right, the page is never done, it’s a work of art, it just keeps loading forever. Yeah, I think that’s a great point, back-end performance, you have this really tightly bound system that you can kind of consider if you're trying to optimize an end point or a step in a transaction, if you have a queue processing a number of request per second.
You can really get a microscope on that but then, front end developers for sometimes being B lined for working on something that’s a little bit more squishy then back end, the performance problem really is so much more exploded because there are so many components that are coming in like you’re loading the index and then getting all the resources from the index, all your Java Script bundles, all the images, all the external dependencies and they’re all coming at different times and like on different computers and different Internet connections.
There’s so many thing out there, web performance is not like absolute, you have to consider what it actually is in the wild, but there are really good tools that can help you measure that.
[0:08:20.4] WJ: Yeah, what are some of your favorite tools for performance?
[0:08:24.8] DA: Going back to the metrics that you were talking about, I think it’s a really great tool for learning about the metrics and also, seeing how – really, how many of these small rules you might be breaking for performance just to run PageSpeed Insights or Lighthouse.
PageSpeed Insights is just like a hosted version of Lighthouse. It’s a little easier just to let go of there and start it up but Lighthouse, you can run it in your dev tools and it’s great because it will give you an absolute number, which is like a little fuzzy. It’s just like, “This is your score, I ran it on Stride’s webpage and we’ve got some work to do, we’ got 23 out of a hundred.”
[0:09:09.8] MN: Okay.
[0:09:10.7] WJ: Brutal.
[0:09:11.7] DA: Yeah, then it tells you the different metrics that what you were talking about William, like a first content full paint. That’s a big one, we got a red flag on that but we’re good on the layout shift, our layout is static. It doesn’t change but it takes a long time to load.
[0:09:28.8] WJ: One tool I like for react apps in particular, if you’re trying to implement progressive rendering is the React dev tools which has a mode for highlighting components that are actively rendering. If you do that, you can see on the page, where things are rendering when.
If you want to optimize how fast this site takes to load or a p articular component on the site is taking to load, you can load the page or navigate to wherever that particular widget lives and then watch and see all the other things that are happening first and see is this happening, are things being rendered in the right order? Especially if it’s very slow.
[0:10:08.1] DA: That’s part of the React dev tools package?
[0:10:10.4] WJ: Yeah, then Chrome dev tools for just in general has a whole bunch of performance tools and they’re not that intuitive to be honest so I highly recommend doing a training course. If people are on teams working on websites that need performance optimization, I think it’s just super worth it to tell people, spend a couple of days doing trainings on performance optimization tooling so that you are properly equipped to solve these problems.
Because if you don’t have a tool for benchmarking, it becomes very difficult to quantify how much faster things are getting because individual measurements that you take on your machine are not going to be very reliable, there’s just too much involved. It becomes very frustrating because you can’t really tell if what you're doing is working.
[0:11:02.4] DA: There is a great article related to PageSpeed Insights and Lighthouse talking about all of the variability that is present in this numbers that they are presenting to you and you can mitigate variation in speed of downloading by simulating the speed, like introducing a throttling or hosting the PageSpeed Insight in a lab rather than running it on your machine to produce any obstruction on your local network or your local CPU.
[0:11:40.8] WJ: Another thing you can do that makes things feel faster without actually being faster is just have stuff move around on the page really fast. This is kind of a silly thing but you know, humans, we’re pretty dumb and it turns out that you can have something load in 500 milliseconds and have it feel slow or you can have something load in one second but add a loader bar that is very wide and so the loader moves really fast because you know, to move a very large just in server one second makes it look fast. And people will report that the second experience, which takes twice as long as being subjectively, seeming faster.
[0:12:22.7] DA: More shiny and then you shoot confetti out when it’s fully loaded.
[0:12:26.8] WJ: Yeah.
[0:12:28.4] MN: Yeah, “It me. I’m dumb human,” I would definitely take a loader bar over waiting patiently for nothing.
[0:12:37.4] DA: Yeah and I mean, that kind of goes back to the principle like progressive web performance, where it’s like getting something in front of the user is so much better than nothing or something that’s completely unusable. Even if that thing is a loader bar that looks beautiful and does backflips or whatever to entertain them while they’re waiting, that’s much better than blank screen.
[0:13:00.7] WJ: The other thing is when you do those — so like Google is notorious for this really clever interesting animations that obey all the laws of physics and are really fascinating to watch, those only work if they’re smooth. As soon as you introduce any kind of jank then people hate them. It’s like minimizing jank is I think often more important than reducing load times. If you are just scrolling up and down the page and it’s sort of janky as you scroll, that’s going to feel worse than if you scroll to the bottom and the infinity scroll takes a second to add more content.
[0:13:44.2] DA: Yeah because it is like the interaction has to be smooth. There is a static page load but then the dynamic page interactions are kind of like a different beast entirely where you’re kind of like in a different zone of like cognitive psychology. It is not just like wait, dealing with people’s attention and they’re waiting. It is their perception of subtle motions and all that.
[0:14:13.6] SC: Yeah, I read somewhere that the supposed ideal is that your interactions with a website should happen at the speed of thought, right? For example, as soon as you think about clicking on something, it reacts. As soon as you think about scrolling to a certain part of the page, there is no additional mental overhead to doing that other than thinking that thought and then taking that action.
[0:14:42.7] DA: Yeah, maybe if you want the really big brain users that think really fast, you got to have the good performance otherwise you’ll just be stuck with all like the slow-brained people who are like taking 30 seconds to think of the webpage.
[0:14:58.0] MN: I do have a question, William. You did mentioned earlier for dev teams to take the time to learn the tools and I think I realized I have not done that. I think I only learned through just right clicking and running Insights a millions times and learning things slowly but surely, are there resources that you know exists to learn about the tool not just the tool itself that you are familiar with?
[0:15:27.8] WJ: Yeah, absolutely. There are really good courses on Udemy and Coursera and Google has some free courses that are quite good on how to use the Chrome developer tools for performance optimization and just having somebody sit down or explain or like in a video explain what a flame chart is and how to read it and how to navigate through a flame chart and drill down and then match that to your actual code is super valuable and definitely not something I would have ever figured out just by right-clicking on stuff.
I was on a project where when the manager very insightfully realized that it would deliver massive returns on investment if you just told everybody to spend a day doing trainings on these tools and then one of the people on the team ended up leading a workshop on how to use the tools, it was super effective.
[0:16:26.3] MN: How did the project manager feel about that? The person who wants all those buttons up on the screen and you know, those features need to be rolled out and you’re like, “Oh, wait a second, we got to do some more training” “Trainings for what? You can make components, why do you need to do that?” Was there any pushback?
[0:16:43.8] WJ: There wasn’t. We were lucky we had a really good product manager who was you know, not micromanaging at all and also I think there was a general understanding amongst the stakeholders that performance was both a problem and a worthy use of time to try and fix and I think in general on that team there was a culture of learning so it was fine but –
[0:17:08.5] SC: That’s awesome. If you find that perhaps you don’t have that kind of insightfulness in your particular team or environment, we’ve already talked about a couple of reasons why performance is important, sighted some studies but is there anything else you can do, do you think to get by in?
[0:17:27.9] WJ: One thing that I like to do is to just do the needful like if what is needed is for you to do a training course then just be like, “Oh it is part of delivering the story. I had to do a training course on this tool and I am not even going to tell anybody about it. I am just going to do it because they don’t need to know the implementation details,” right? That is my job. I am the one that figures out how to make it work but you just decide whether it works the way they wanted or not.
[0:17:54.9] DA: I think also as a developer, it’s kind of like the idea of tech debt or accessibility, you know tech debt as far as like architectural tech debt and accessibility debt or performance debt, if you know what tradeoffs you’re making you can prioritize the performance thing, wins that are going to be most effective while you’re doing the initial work and make sure that you’re mitigating it as you go as a part of like the story as a developer just as your personal responsibility.
[0:18:28.7] WJ: Another thing that I think you can do to sell it is to make a recording of the before and after of a performance improvement and then show that off because people respond really well when they say, “Oh wow, this page used to load in…” you know, “Wow, that felt slow. Oh, this is how fast the page loads now. Wow, that feels faster. How do I get more of that feeling?”
[0:18:53.4] DA: Also you can take some of those metrics like that we’re talking about before, like your first content full pain time and a lot of tools will record that as like a web health analytics like New Relic does it, Datadog does it or like PageSpeed Insights. You can graph those overtime and see how is the arrow gate performance of the website going, how is the arrow gate bundle size-changing overtime and if you can, if you have a history of gathering the information and looking at it as you are going, you can correlate that with other effects on the webpage.
[0:19:38.9] SC: Yeah, I imagine it’s easier too, like you mentioned Dave, to implement these things as you go rather than have to implement them after the fact.
[0:19:50.2] WJ: Yeah and I think you can usually find somebody at a senior level in the organization who has had the experience of working on a product that go progressively slower as the years dragged on and so you can usually scare them into action by showing them graphs that show, “Hey, guess what trajectory we’re on?”
[0:20:12.5] DA: Yeah.
[0:20:12.9] MN: We’re slowing down baby, we’re slowing down. I think that what I guess developer teams need to realize is that web performance is just as important as the features that are coming out, right? You want to make sure that the features that you’re – all those carousels that you want to put on the website, whether it’s actually going to get to the user in a way that it is an enjoyable experience and that it’s fast so that, you know, I don’t know, if you have a website about bikes and you can carousel, you know, bike around that’s great but it needs to be quick and fast so that the user can experience the website at the speed of thought.
I know that’s a really good way of thinking about how your application should run. We have the tools to talk about that was mentioned before. Any other parting words that people may have in terms of tooling or web performance?
[0:21:05.7] SC: Yeah, I think in general just remember to have empathy for your users, you know? Really think about the user experience and think about different kinds of user experience with different types of devices and bandwidths, et cetera and I think that will get you pretty far.
[0:21:20.5] MN: If you haven’t taken a course on the tooling that will make your website faster, please do that. I think I am going to try and find one myself and I’ll report back if anything.
[END OF INTERVIEW]
[0:21:30.1] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
