Highlights
Large reduction in time to look up a restaurant in the store locator
Platform
Core
Restaurant Search - the process of finding the nearest restaurant for pickup and delivery was time-consuming, with an average wait time of more than 5 seconds, sometimes up to 10 seconds. Our applied improvements have shown response times under 1 second in our test environments (QA), drastically reducing 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 majority of response times post-implementation happened under 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.