Combining Debouncing & The Doherty Threshold to Improve Search UX & Performance
Jeez, that's a mouthful...
I constantly need to find ways to reduce API calls to keep my app as cheap to run as possible. This is more true than ever now that I've been able to grow it to 32,000 users. I will stay on my $5/mo Digital Ocean droplet as long as I possibly can.
It's a fun challenge, and it forces me to learn new concepts. This week, I learned about "debouncing" and the "Doherty Threshold". Check out the world of difference it made for me:
Before Debouncing
Here's what searching looked like before debouncing: pic.X.com/Wy2m6luNyR
— joshua fonseca (@joshycodes) June 2, 2021
After Debouncing
And here's what it looked like after: pic.X.com/DF3n86psEH
— joshua fonseca (@joshycodes) June 2, 2021
What a difference!! Okay, let's get into it.
Problem 1: Unnecessary Server Calls
Each time a user enters a character in the search bar, it sends off an API call.
This is good because users get immediate feedback, but bad because it leads to a lot of unnecessary API calls. Nobody actually intends to see results after every keystroke, so why make an API call?
It's a waste of resources. Hundreds of search requests should really just be a fraction of that.
Solution: Debouncing
Google doesn't search everytime I hit a keystroke... Try it yourself; you'll notice immediately.
So, what do they do? Debounce.
Debouncing is when you wait for X milliseconds of uninterrupted time to pass before performing an action. It's used when you search for things, when you input your password incorrectly, etc..
Here is an overview of how I handle this:
- User enters input
- Timer begins to send API request
- If user types before timer is up, restart the timer with the new input
It's a simple concept, but I neither learned it in college, nor had to deal with at work! It was just something I had to learn in the wild, so I hope that this is helpful for you too.
Problem 2: A Bad User Experience
Debouncing instantly improves the user experience, and someone on X perfectly explained why:
Id add another point. Its incredibility frustrating and distracting when the page reloads on every character entered. Humans think not in characters but in words. It would be soo irritating if my friend said, hey do you want an a.. p.. p.. l.. e.. . Give me the Apple damn it! :)
— °𝐀llwyn 𝐅ernandes 📌 (@allwynpfr) June 3, 2021
Well said. So, the user experience is fixed, right?
Well, not exactly - there's still one crucial piece of information that's missing... How many milliseconds can I wait, and still keep responsiveness?
The best answer is to test it with your users, and ask them. However, I don't have that luxury. I have a full-time job and make this mobile app just as a passion project. It's free & there are no ads. I can't really justify testing so extensively.
So, what do I do? Guess?
Nah.
Solution: The Doherty Threshold
I rely on the Doherty Threshold!
From lawsofux: The Doherty Threshold states that productivity soars when a computer and its users interact at a pace (\<\400ms) that ensures that neither has to wait on the other.
My average api response time is about 100ms, so I decided to wait about 300ms.
Thanks for reading!
I hope you learned something new, or just enjoyed reading :) If you liked this, you can follow me on X and keep up to date with all the stuff I'm learning!