2023-11-14 Release Notes

Owned by Manolache, Alin-Theodor (Deactivated)
Last updated: Nov 22, 2023 by Benet, Anton
3 min read

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.

Figure 1. Loading times benchmark.

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.

Figure 2. Pick Up restaurant lookup process.

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

%

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 overall restaurant lookup time has been reduced to an average of 1 second in our testing environment.

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.