Highlights
Restaurant Search - Large reduction in time to look up a restaurant in the store locator
Platform
Core
Restaurant Search - Locating the closest restaurant for pickup and delivery used to be a time-consuming task, with an average wait time exceeding 5 seconds, occasionally reaching 10 seconds. Our implemented enhancements have significantly reduced response times across various code sections, resulting in an average wait time of 1 second in our test environments (QA), effectively minimizing overall waiting time.
🔍 Problem Statement
The process of searching for the closest restaurant for both pickup and delivery experiences a considerable delay of up to 10 seconds, which negatively impacts the user experience, as customers must wait for an extended period before proceeding with their orders.
Research shows the importance of having low loading times:
A 10-second delay will often make users leave a site immediately. And even if they stay, it's harder for them to understand what's going on, making it less likely that they'll succeed in any difficult tasks.
(Nielsen, 2010) https://www.nngroup.com/articles/website-response-times/
Loading time benchmarks in a selected market (UK) show that other QSR players have much faster restaurant lookups.
🔢 Success Metrics
Decrease in average wait time.
Improved CVR from entering the store locator to selecting a restaurant.
⚙️ Methodology
Our methodology consisted of analyzing what’s behind the loading time to understand where the largest opportunity lies.
We analyzed the Pick Up restaurant lookup process shown in Figure 2.
In our tests, this action took an average of 5 seconds. When breaking down the underlying performance times of this action, we quickly realized that a large part of the loading time comes from backend processing, as can be seen in Figure 3.
In summary, the majority (~90%) of the elapsed time is attributed to waiting for a response from our backend, as can be seen in the following table.
Step | Time | % |
|---|---|---|
Time between the user clicking on the address and the loading starting | 135 ms | 3,2% |
Backend processing | 3.69 s | 89,5% |
Frontend processing | 95 ms | 2,3% |
Fade Animation | 200 ms | 4,8% |
💡 Improvements
We analyzed our backend code and ran 200 tests to understand execution times for individual parts.
It became evident that section 4 of the analyzed code deviates significantly from the remaining sections.
We then looked deeper into section 4 (listBySearchParams) – we divided its code into five subsections and evaluated the performance of each. Sections 1 and 4 proved to be the most critical
In subsection 1 we attained some improvements using data filtering and caching strategies.
In subsection 2 we obtained more significant improvements by leveraging batch requests, parallel processing and caching.
Results
The implemented changes drastically reduced the overall runtime of the listBySearchParams section 4.
After these changes, the response times across various code sections resulted in an average wait time of 1 second.
Note that all tests have been performed in testing environments (QA). Although we expect similar results in production, we can’t guarantee the exact same behavior. We will be tracking the improvements in production to identify any other opportunities.