897: Making Your App Feel Faster Than It Really Is ![rw-book-cover](https://wsrv.nl/?url=https%3A%2F%2Fstatic.libsyn.com%2Fp%2Fassets%2F6%2F4%2Fb%2F8%2F64b8ee9cb432ec4188c4a68c3ddbc4f2%2FSyntax_Cover_Art.png&w=100&h=100) ## Metadata - Author: [[Syntax - Tasty Web Development Treats]] - Full Title: 897: Making Your App Feel Faster Than It Really Is - Category: #podcasts - URL: https://share.snipd.com/episode/1d514ea2-1357-4712-aa90-7628a3b2c400 ## Document Notes ## Highlights - **Use Pointerdown Over Click** - Use pointerdown or mousedown events instead of click to trigger actions faster on user interaction. - Be cautious as this can cause unwanted UX issues, especially on touch devices. Transcript: Wes Bos First one we have here is using a mouse down or probably should be using a pointer down event versus a click. Now, this is not always a good idea. Not blanketed. It certainly got a lot of people angry on Twitter about it. But the trick here is that you can fire things off when somebody mouses down or touches the screen versus when they let go. A click is registered when you let go. A touch is registered when you let go. So if you listen for the initial start or down, you can make things feel much faster. So Adam Wathen of Tailwind tweeted the other day that he couldn't figure out why his select dropdowns just felt slower than all the other UI libraries out there. And it turns out they were the only one listening for click. The rest of them were listening for pointer down events or mouse down or touch start events. So that's very important. That can make it feel much faster because you fire off whatever it is you want right away. It can also be really bad UX as well because often I find myself, if it's like a button where you want to navigate somewhere, I'll find myself touching it. And then if you drag your finger off or if you accidentally touch something just with your finger, that shouldn't necessarily always register an actual action, right? There's this weird thing with iOS. Apparently iOS still has a 40 millisecond delay in firing off a click event. For the longest time, we use this thing called fast click, where if you wanted to, like, for example, like check boxes, right? If you want to tap like three check boxes, you just want to go boom, boom, boom. Like that's, you're really quick at that. And often if there is a delay in registering that click or that touch event, then you might hit it twice because you think it didn't actually do it. ([Time 0:02:34](https://share.snipd.com/snip/3100b085-097d-4e4a-8b2f-28c83f172c49)) - **Keep Animations Fast** - Make UI animations very fast, typically around 0.1 to 0.2 seconds for responsiveness. - Avoid slow animations that frustrate users and block interactions. Transcript: Scott Tolinski And so that's a big part of it. Another one here is that animations should be fast. And it's not like every animation, there's certainly some animations that can be slower or more lethargic for specific aesthetic reasons, but we're talking UI animations. And for the longest time, I defaulted to 0.3 seconds for all of my transitions and animations. Way too long. Since moved that to 0.2. Yes. I was like, you know what? Whatever it is, dial it back one more, because a lot of people they they fall in love with the fact that the thing is animating and they want to see that animation right they're like oh yeah That's a great users don't have time for that and for the most part you want your animations to be speedy definitely something that you don't want to take a second half a second any of that Stuff you know no you know two tenths of a second probably fine yeah you think about if you want to do several things very fast whether it's let's say you want to open up three boxes and and Wes Bos Each of those takes an animation right 300 milliseconds to click so that means you're clicking three boxes it takes you a full second to click three boxes whereas like you could probably Tap or click those and i don't know how long but not not a second you could do much faster um so just start with like 0.1 0.2 it depends obviously what your animation is if you're sliding An entire thing that's probably much uh can can be longer but these like micro animations they should be very very fast or or even like entirely taken off like if you look at a lot of the Stuff on on osx or mac os when you are moving around switching windows there's no animation at all it simply just pops ([Time 0:05:57](https://share.snipd.com/snip/2669f986-c90c-4079-a0bf-18a8856e1e5b)) - **Make Animations Cancelable** - Ensure animations are cancelable and reversible to avoid blocking user interactions. - When reversing, animations should continue smoothly from the current state, not jump to start or end. Transcript: Wes Bos On that same point animation should be like cancelable the one that drives me crazy is spotify if you want to view our stats on the spotify podcasters you open up the date input and you Click on the back arrow to go back a month. And first of all, you should be able to select custom ranges. But if I want to select three years worth of dates, I got to hit the back arrow 36 times to go back for three days or for three years. And what happens is I have to click the arrow and I have to wait until the animation finishes and then click it again. Because if I click it too quickly, it either breaks the entire thing after reload the page, or it just doesn't react to the click as well. So if there is an animation in flight and somebody hits that thing again, especially like you open something and you go, oh, I didn't mean to do that. And you quickly hit the the close button. Yeah, that should react to the action immediately. ([Time 0:08:20](https://share.snipd.com/snip/76707a4d-5512-4886-8505-8b2d244ebc02)) - **Use Optimistic UI** - Implement optimistic UI to immediately update the user interface on action before server confirmation. - Handle errors later to rollback or confirm changes after API response. Transcript: Scott Tolinski Let's talk about an optimistic UI. Optimistic UI is one of these things that can do what we said just a moment ago and make your application respond the moment that you touch something. So too often times what we're doing is you click a button to perform an action. It goes off and does some kind of fetch or does some kind of data call. It hits the API. It hits a server or something. That thing takes who knows how long, could take a little bit of time, a lot of bit of time. Wes Bos Even like 400 milliseconds, like you add something to a list and it needs to refresh the list. You're sitting there being like, did it work? Scott Tolinski Did it work? And so the right answer isn't to put a loading screen here or anything like that. The right answer is to perform the update to the UI, the moment that you click something like the moment I hit enter, perform the update to the UI, and then send that information to the Server in the background. And then once that information comes back, what you're doing is you're either responding to an error state and saying, oops, like something failed and remove the one from the list or Whatever. Or you're just now in the current state that you're in, like if you're using an each loop with some IDs, and you update that data in any of the modern frameworks, it's not going to re render That thing. So what you'll want to do is like, let's say I'm adding something to to a to do list, I hit enter, the framework, even before it kicks off that API call should be adding that text to the list Of data. That way, it pops in immediately. And then this is called optimistic UI. A number of frameworks have this kind of thing built in. So if you're looking to see if your data fetching loading framework has it in, it's going to be called optimistic UI. ([Time 0:10:50](https://share.snipd.com/snip/29261c84-ab34-444b-bc3e-e8caf0f2ca30)) - **Prefer Local-First Data** - Adopt local-first data storage so app updates instantly without waiting for server sync. - Use background syncing to keep data consistent and provide seamless experience. Transcript: Wes Bos Yeah. And even one step further than optimistic UI, and I know you'll like this one, is don't have an optimistic UI and just save the data locally and use a sync engine. Yeah. Like the whole idea behind local first is that you just store the data locally. There's no need to wait around, right? You get rid of loading states, you get rid of optimistic states, it simply just immediately updates. And then the sync engine will update it in the background. Yeah. Scott Tolinski And so optimistic UI is kind of like local data light, where you are handling just that data change, right? And you're monitoring, but with local data, you're essentially caching that data on device in a database. So therefore, even on page refresh, it's going to be instantaneous or as fast as it possibly can be. And then again, on that change, it's instantaneous or as fast as it can be. ([Time 0:12:37](https://share.snipd.com/snip/30d8240b-0de4-41dd-8ed9-65165fc6f0d1)) - **Delay Loading Indicators** - Delay showing loading indicators to avoid flicker when operations complete quickly. - Show progress indicators only after 100ms or suitable threshold to improve perceived speed. Transcript: Wes Bos Delay loading indicators if something happens quickly. So we often will show like a spinner when something is being worked on. But in a lot of cases, it's so fast that it actually doesn't make sense to show a loading indicator that something is happening because it's just like a split second where you're showing That like like a quarter of a spinner and that is kind of like a weird janky ui right so what you can do if you are showing a loader or using like a react suspense or something like that throw A minimum display value on that and if it does not need to show like like basically you would render out your loader but in the first hundred millisecond uh life of that component show Nothing because in in an ideal circumstance you you would go from your submission state to your finished state. And you don't have to show a loader there because it's so quickly. Same with changing pages as well. When you change from one page to another, it often makes sense to show a loading bar on the top. I had this with my own website. I developed the whole thing locally. I click on the page. It's nice and fast. I have caching in production. It's nice and fast. But there are some cases where maybe there's no cache hit or maybe somebody's on a really slow connection where you click on something and nothing happens. And you have to provide some sort of like loading indicator that the pages change from one to another because you can't make the little browser things spin. You can't, you know, normally when you go from a regular HTML page to another HTML page, you can you can make the browser spin. But when you're using a single page app and you're using push state, you're not actually reloading the page. So you have to show the user that something is happening. So I'm telling you, both show the user that something is happening, but don't show them too quickly. Because if it is a very fast application, maybe you don't even need to show them. The way they know that it worked is that it literally worked. ([Time 0:13:36](https://share.snipd.com/snip/5b0fa69b-1ea7-4809-a06f-e03dcf0ce8b0)) - **Preload On Hover** - Preload page content on hover to improve navigation speed. - Some frameworks like SvelteKit and Gatsby already implement this for faster route loading. Transcript: Scott Tolinski Right. Totally. Exactly. Another good tip here is preload on hover. So you can have an event to listen for on hover, then fire off your API call, whatever that may be. Many frameworks that like take over data loading do this for you. Even like SvelteKit is like one of the default behavior for links is that when you hover over a link, it's preloading that route. But like Gatsby was one of the first ones to make this a core part of the experience. And one of the things that people really felt when they used a Gatsby site, like even in alpha, when Gatsby was an alpha, back when I was a user, because once something goes out of alpha, I'm over it. That's how I work. But so in Gatsby, you'd use a Gatsby site, you'd click something, and it would just feel like the fastest darn loading experience on the planet. ([Time 0:15:45](https://share.snipd.com/snip/b99513f3-29f3-45d1-9475-2f5f74a73f58)) - **Avoid Full-Page Spinners** - Avoid showing full-page spinners on every UI change as it disrupts user flow. - Batch interactions or provide manual triggers to reduce loading spinners frequency. Transcript: Wes Bos One other super annoying thing that I hate on websites and like this is so clear probably for most of you but like throwing up a full page spinner on every single change. So like this especially hits when you're trying to filter products and like let's say I'm on like the Home Depot website and I want to filter for three different categories and two different Colors. Every single time I check a box, it's like rerunning that. So it throws up a whole spinner and then it brings it back and maybe it's going to change what's available in the sidebar. That's so obnoxious to me. And I much rather be able to just check the three things I want and then either have some sort of delay oh he hasn't interacted with the the filters ([Time 0:18:52](https://share.snipd.com/snip/67bef37e-16c3-41eb-b2c3-6c8290d4ac97)) - **Use Quality Spinner Animations** - Avoid pixelated spinners as they feel cheap and slow down perceived app speed. - Use smooth, polished loader animations to improve user perception. Transcript: Wes Bos Either obnoxious or is pixelated. It just makes me mad and it makes me feel like the website is slow. Scott Tolinski Here's something that can feel slow or fast depending on, like I feel like this thing can be really helpful, but at the same time frustrating skeleton screens, which are like basically Like a skeleton version of your app, usually missing images using missing like the actual text. Yeah, using gray boxes that sometimes have like a loading indicator. There's nothing more frustrating when it's like a skeleton screen for like 10 seconds or something like that. And you're just like, Oh, it's so close. But in reality, like, sometimes that's really frustrating, because it's just like oh that wait this isn't actually loading like it should be it should have some sort of like cancelable Like oh this is taking too long it's clearly like hit it hit a snag or something i have no idea sometimes this is such a vibe thing to me like i think skeleton loaders can be super useful when Done correctly but also oftentimes not done correctly. ([Time 0:20:16](https://share.snipd.com/snip/95f8c41d-9e8d-4568-8b98-d09968e9de96)) - **FedEx Mobile Site Frustrations** - FedEx's mobile site shows only the footer while loading, confusing users about page status. - Lack of loading messaging makes users unsure if the site is broken or slow. Transcript: Wes Bos I'm using FedEx's mobile website right now. And let me show you. Scott Tolinski I know this. I know this experience. I've used this. And I know what you're about to say. It is so awful. Okay. Wes Bos Am I showing anything sensitive? I don't believe so. All right. Watch FedEx's website when I open it up. Look at the footer. Scott Tolinski In your footer. The footer. Wes Bos Oh, yes. There it is. There it is. Scott Tolinski Dude, I knew exactly what you were going to say. I've had this experience so many times in the past. Whoever knows that. And I go to it. I'm like, oh, it's the footer. Is this broken? Is this a wrong link? Is this like, oh, no, it's just loading. Okay. At least put the text loading. Wes Bos At least put the text. The very least you could do is put the word loading. And nothing. The worst case is they say about our company is the first thing that you see when you click on a tracking link for FedEx. It's the footer. Scott Tolinski Yeah. Okay. You're FedEx. You have such a good brand opportunity here. We're delivering your information. Hold one second. You know. Yes. Here's a tracking code for you. A little computer on the back of a thing. Wes Bos A little database. Anything. That's being held by a guy. Yeah. There's so much. Scott Tolinski Yeah. A guy's walking with a computer. Yeah. You've got options, guys. FedEx. You've got options. You're known for being the company that put the arrow in the logo. Like, we're attention to detail oriented. We put a logo. We put an arrow in our logo. Wes Bos Yeah, don't coast on that arrow in your logo. Keep it going. Yeah, yeah. Just anything. Scott Tolinski Crazy. ([Time 0:21:55](https://share.snipd.com/snip/337271ba-9ca1-44cd-8134-06d7d9a044e8)) - **Use Blurred Image Placeholders** - Load a blurred low-resolution image before the full image to improve perceived loading speed. - Always specify image aspect ratio or size to avoid layout shifts during load. Transcript: Scott Tolinski You know, sometimes those things can take a little while. A blurred low res version of that photo loading first in the exact same spot, to me, looks better than a blank space where that photo is going to be. I mean, you could even have a blank space with a color, but like a blank white space. Okay, so let's go good, better, best. I think best is the thing loading fast. Good is the blurred thing or background color that then fades the image in. And then bad is nothing. And then your page loads and then all the content shifts down. Throw that in the trash because that's garbage. But yeah, do something there for images that just images popping in left and right user goes to click on something, the whole thing moves like, yeah, that's that's trash talk. Wes Bos Yeah. And especially if you are using a framework that makes you or you should be embedding the width and height or at least the aspect ratio of your images so that when they do load, you don't Get content shift. ([Time 0:23:53](https://share.snipd.com/snip/3d8ac078-fcf0-4dad-9442-897f0831b2d6)) - **Search On Input, Not Click** - Trigger search queries on input rather than waiting for a click or form submit. - Cancel ongoing requests on rapid input to reduce unnecessary fetches and improve responsiveness. Transcript: Wes Bos Instead of search on click. This is, if you ever wonder how search is so fast on some of these websites, it's often because what they're doing is they're firing off the fetch request on like a key down. That's another one. Instead of waiting for key up, do it on key down. And what they're doing is if you keep typing, then they'll just cancel or abort those requests in the background because you're starting a new one. And for a lot of people, it's worth those extra requests versus having to wait for a user to actually go ahead and hit the search button. Or you can even just wait for 200 milliseconds after somebody has finished typing, then go ahead and fire it off so they don't have to go grab their mouse and mouse over and click the search Button. ([Time 0:25:53](https://share.snipd.com/snip/50eeac57-e7d1-40da-b867-c260782a1343)) - **Animate Progress Between Steps** - For multi-step processes, animate progress indicator between steps for clear activity feedback. - Avoid static progress bars that can confuse users if steps take varying times. Transcript: Wes Bos Word. Another one, progress loaders that move in between steps. So often a progress loader is not going to give you a very clear zero to 100% of how something is doing. It's because there are steps. Like let's say you want to like resize an image right you got to upload it you have to wait for the job to start you got to actually resize the image and then you got to send it back and those Five or six steps might be your progress but if one of them takes a long time it's often good to to show animation moving in between those steps so the user actually knows that something Is actually happening. ([Time 0:26:46](https://share.snipd.com/snip/a725d3e2-d754-4545-9f3c-74de7f6fce93)) - **Denver Airport Bag Mix-up** - At Denver airport, mistakenly overlooked a bag on the carousel causing embarrassing moment. - Highlights how users can misinterpret waiting or missing items due to perception errors. Transcript: Scott Tolinski I tell you an embarrassing story we went to mexico for spring break and uh, when we came back, we were standing at the bear, the baggage carousel at the Denver airport, which does take A while. And all of our bags, except for Courtney's bag, uh, had come out and we all had them. We were standing around and the guy comes over to us and he's like, Oh, are you missing a bag? What, you know, whatever. Uh, and we're like, yeah, her bag hasn't come out yet. So we're just waiting, see if there's anything else coming out. Everybody's long gone. And there's one bag going around on the carousel. And he's like, that's not it. We're like, no, we've already looked at this bag three or four times. It's not it. And the bag just keeps going around. He's like, all right, let me go check. He goes off to his computer. And as he's checking, I'm like, let me just go look at this bag one more time it was her bag the whole time no and the poor guy i had to go up to him and be like hey man i'm so sorry it was actually That bag oh man i swear i looked at it it was crazy i i i don't know if i was just sleep deprived or what. I felt so embarrassed. ([Time 0:29:37](https://share.snipd.com/snip/b92dd001-26a4-4cde-a0e0-432563b7b53b))