Speed Search: Making Expedia Flights Faster

Hello, everyone. I'm Hina. I'm from Expedia Group. This talk is around the search speed that is making Expedia flights faster. We will focus on the performance initiatives that are carried out on the Flight Search page on Expedia and the investigations done on that so far.

So first of all, the motivation behind the same was that on Flight Search page, there is a peak search traffic that lands on FSR, that is Flight Search page. And then it goes to Flight Information and hence to the Checkout page. So with the latency overhead, the user experience was getting impacted and hence the bookings as well. It was also very important to retain the users by improving the performance.

So when it comes to performance, we also observed that monitoring is very crucial. And for the same, there were some custom metrics that were defined. One of that is page usable time, that is, the time that a component takes to render on the Flight Search page. The main component on Flight Search page is the list of offers that appears. So as soon as the page renders and the offers list gets rendered, the page usable time gets marked. The second metric is non-supply overhead, which is also a custom PERF metric. So that means that the total time that the Flight Search page is going to take minus the supply overhead time. There are some other Lighthouse common metrics as well, such as First Contentful Paint, First Input Delay, Cumulative Layout Shift, and Time to Interactive that were also monitored. Apart from that, ensuring that the bundle size is not increasing the threshold suggested and ensuring that the app is lightweight is also very crucial when it comes to performance.

Now, I'll discuss around prefetching. This is one of the PERF initiatives that was carried out in Flight Search page. So prefetching refers to fetching the JS bundles beforehand so that as soon as the user is going to land on Flight Search page, the time that is consumed on fetching the CDN paths can be saved by caching those JS bundles beforehand. So what we did here is that we fetched the bundles on the previous page, that is the homepage, and the fetching of resources happened during the browser ideal time. So that means that there was no constraint on the homepage when it comes to performance, and the resources are fetched using the prefetch cache. This is impactful for the new users, for the existing users if in case the users are navigating on the Flight Search page, the bundles are already cached using the browser cache. The prefetching experiment is something that is good to have on the web pages, and the PERF initiative, this PERF initiative helped us gain around 100ms. It was not a very significant improvement, but it was good to have and it made the CDN path retrieval very fast as compared to the older user experience.

Then the next experiment we have is preemptive search. So by preemptive search, we mean that we are able to predict the Flight Search response even before the user lands on the search page. That is, on the previous page, which is homepage itself, we were able to figure out the response using the inputs that were given by the users, such as as long as the user provides origin, destination, departure date, arrival date, we were able to figure out the response, and on the back end side, we cache the response for faster retrieval. As soon as the user lands on the Flight Search page, the data then comes from the cache instead of retrieving it runtime.

So, this helped us improve the page performance to up to 50% on both web and native, and this is something that helped us lead to a faster user experience. Also, preemptive search is something that was not targeting 100% of the traffic because we are predicting the response. We don't know whether the user is going to land on the same search input or not, but it helped us gain the path improvement by product analysis. So, we knew that for which field the user is going to land on the Flight Search page more, and that data helped us determine when we should cache and when we should move.

Then, the next PERP initiative is microqueries. So, by microqueries, we mean that we actually broke down the bulky queries into microqueries. So, on the Flight Search page, initially, there was one query that helped us fetch the entire list of search offers, and that was very time consuming because of the fact that there are a lot of search offers involved and the computation gets increased because of the bulkiness. What we did here is that we broke down the query into subqueries and those queries happened in parallel. So, for example, we fetched the say first five offers and then the subsequent offers and so on. So, this helped us ensure that as soon as the user lands on Flight Search page, the user is able to see some chunks of the search offers rather than not showing anything at all. And this also helped us break down the queries which are not needed immediately, such as fair detail information, and we were able to see a significant improvement with this initiative that is nearly 20% of PERP initiative performance improvement.

Then, the next initiative that was carried out is Async Loading and Loaded Query. So, by Async Loading and Loading Query, I mean that we need to analyze the waterfall diagram of the page, and whenever we look at the queries, we need to check like do we actually need to wait or not for the network calls. For Flight Search page, as per the waterfall diagram analysis, we got to know that the loaded query was getting executed at a very later stage. Then, what is expected for the same? The loading and loaded queries could be fetched at the same time in parallel, but that was not happening. And once this change was made, we again observed nearly 8% of performance improvement. It all depends on the page. This was specific to Flight Search page, but again it's very important when it comes to PERP initiative that we analyze the waterfall diagram and observe how the network calls are getting executed. Are they getting executed sequentially when that should not be the case.

The next work here is Micro-Front-end Architecture. So, within Expedia, in flights, we make sure that our page-level components are broken down into shareable packages so that they can be reused and hence can be monitored very efficiently. The packages are also very flexible and it also helped us to maintain those packages by assigning the package-level ownership rather than having the page-level components at once. It also helped us see improvement in bundle size because we were able to break down the components into multiple shareable packages and each package can be then analyzed. So, conclusion is that with all the PERP initiatives, we were able to see visible impact on the top 90th percentile on page usable time by nearly 52% and on top 90th percentile on non-supply head by nearly 40%.