Búsqueda Rápida: Haciendo los Vuelos de Expedia Más Rápidos

Hola a todos. Soy Hina. Soy de Expedia Group. Esta charla trata sobre la velocidad de búsqueda que está haciendo que los vuelos de Expedia sean más rápidos. Nos centraremos en las iniciativas de rendimiento que se llevan a cabo en la página de Búsqueda de Vuelos en Expedia y las investigaciones realizadas hasta ahora.

Así que, en primer lugar, la motivación detrás de esto fue que en la página de Búsqueda de Vuelos hay un tráfico de búsqueda máximo que llega a FSR, que es la página de Búsqueda de Vuelos. Y luego va a la Información de Vuelos y de ahí a la página de Pago. Así que con la latencia la experiencia del usuario se estaba viendo afectada y, por lo tanto, también las reservas. También era muy importante retener a los usuarios mejorando el rendimiento.

Así que cuando se trata de rendimiento, también observamos que el monitoreo es muy crucial. Y para ello, se definieron algunas métricas personalizadas. Una de ellas es el tiempo de uso de la página, es decir, el tiempo que tarda un componente en renderizarse en la página de Búsqueda de Vuelos. El componente principal en la página de Búsqueda de Vuelos es la lista de ofertas que aparece. Así que tan pronto como la página se renderiza y la lista de ofertas se renderiza, se marca el tiempo de uso de la página. La segunda métrica es la sobrecarga no suministrada, que también es una métrica PERF personalizada. Esto significa que el tiempo total que la página de Búsqueda de Vuelos va a tomar menos el tiempo de sobrecarga de suministro. También hay algunas otras métricas comunes de Lighthouse, como First Contentful Paint, First Input Delay, Cumulative Layout Shift, y Time to Interactive que también fueron monitoreadas. Aparte de eso, asegurar que el tamaño del paquete no esté aumentando el umbral sugerido y asegurar que la aplicación sea ligera es también muy crucial cuando se trata de rendimiento.

Ahora, hablaré sobre la precarga. Esta es una de las iniciativas PERF que se llevó a cabo en la página de Búsqueda de Vuelos. Así que la precarga se refiere a obtener los paquetes de JS de antemano para que tan pronto como el usuario llegue a la página de Búsqueda de Vuelos, el tiempo que se consume en obtener las rutas CDN se pueda ahorrar al almacenar en caché esos paquetes de JS de antemano. Así que lo que hicimos aquí es que obtuvimos los paquetes en la página anterior, que es la página de inicio, y la obtención de recursos ocurrió durante el tiempo inactivo del navegador. Esto significa que no había restricción en la página de inicio cuando se trata de rendimiento, y los recursos se obtienen utilizando la caché de precarga. Esto es impactante para los nuevos usuarios, para los usuarios existentes si en caso de que los usuarios estén navegando en la página de Búsqueda de Vuelos, los paquetes ya están en caché utilizando la caché del navegador. El experimento de precarga es algo que es bueno tener en las páginas web, y la iniciativa PERF, esta iniciativa PERF nos ayudó a ganar alrededor de 100ms. No fue una mejora muy significativa, pero fue bueno tenerla y hizo que la recuperación de la ruta CDN fuera muy rápida en comparación con la experiencia del usuario anterior.

Luego, el siguiente experimento que tenemos es la búsqueda preventiva. Así que por búsqueda preventiva, queremos decir que podemos predecir la respuesta de Búsqueda de Vuelos incluso antes de que el usuario llegue a la página de búsqueda. Es decir, en la página anterior, que es la página de inicio en sí, pudimos averiguar la respuesta utilizando las entradas que dieron los usuarios, como siempre que el usuario proporciona origen, destino, fecha de salida, fecha de llegada, pudimos averiguar la respuesta, y en el lado del servidor, almacenamos en caché la respuesta para una recuperación más rápida. Tan pronto como el usuario llega a la página de Búsqueda de Vuelos, los datos vienen entonces de la caché en lugar de recuperarlos en tiempo de ejecución.

Así que esto nos ayudó a mejorar el rendimiento de la página hasta un 50% tanto en web como en nativo, y esto es algo que nos ayudó a llevar a una experiencia de usuario más rápida. Además, la búsqueda preventiva es algo que no estaba dirigido al 100% del tráfico porque estamos prediciendo la respuesta. No sabemos si el usuario va a aterrizar en la misma entrada de búsqueda o no, pero nos ayudó a mejorar la ruta mediante el análisis de productos. Así que, sabíamos para qué campo el usuario iba a aterrizar más en la página de Búsqueda de Vuelos, y esos datos nos ayudaron a determinar cuándo deberíamos almacenar en caché y cuándo deberíamos movernos.

Luego, la siguiente iniciativa PERP son las microconsultas. Así que, por microconsultas, queremos decir que realmente desglosamos las consultas voluminosas en microconsultas. Así que, en la página de Búsqueda de Vuelos, inicialmente, había una consulta que nos ayudaba a obtener toda la lista de ofertas de búsqueda, y eso consumía mucho tiempo debido al hecho de que hay muchas ofertas de búsqueda involucradas y el cálculo aumenta debido a la voluminosidad. Lo que hicimos aquí es que desglosamos la consulta en subconsultas y esas consultas ocurrieron en paralelo. Así que, por ejemplo, obtuvimos las digamos las primeras cinco ofertas y luego las ofertas subsiguientes y así sucesivamente. Así que esto nos ayudó a asegurar que tan pronto como el usuario aterriza en la página de Búsqueda de Vuelos, el usuario pueda ver algunos fragmentos de las ofertas de búsqueda en lugar de no mostrar nada en absoluto. Y esto también nos ayudó a desglosar las consultas que no se necesitan de inmediato, como la información detallada de tarifas, y pudimos ver una mejora significativa con esta iniciativa que es casi un 20% de mejora en el rendimiento de la iniciativa PERP.

Luego, la siguiente iniciativa que se llevó a cabo es la Carga Asíncrona y la Consulta Cargada. Así que, por Carga Asíncrona y Consulta Cargada, quiero decir que necesitamos analizar el diagrama de cascada de la página, y siempre que miramos las consultas, necesitamos verificar si realmente necesitamos esperar o no para las llamadas de red. Para la página de Búsqueda de Vuelos, según el análisis del diagrama de cascada, supimos que la consulta cargada se estaba ejecutando en una etapa muy posterior. Luego, lo que se espera para lo mismo. Las consultas de carga y cargadas podrían ser obtenidas al mismo tiempo en paralelo, pero eso no estaba sucediendo. Y una vez que se hizo este cambio, nuevamente observamos casi un 8% de mejora en el rendimiento. Todo depende de la página. Esto fue específico para la página de Búsqueda de Vuelos, pero nuevamente es muy importante cuando se trata de la iniciativa PERP que analicemos el diagrama de cascada y observemos cómo se están ejecutando las llamadas de red. ¿Se están ejecutando secuencialmente cuando no debería ser el caso?

El siguiente trabajo aquí es la Arquitectura de Micro-Front-end. Así que, dentro de Expedia, en vuelos, nos aseguramos de que nuestros componentes a nivel de página se desglosen en paquetes compartibles para que puedan ser reutilizados y, por lo tanto, puedan ser monitoreados de manera muy eficiente. Los paquetes también son muy flexibles y también nos ayudó a mantener esos paquetes asignando la propiedad a nivel de paquete en lugar de tener los componentes a nivel de página de una vez. También nos ayudó a ver una mejora en el tamaño del paquete porque pudimos desglosar los componentes en múltiples paquetes compartibles y cada paquete puede ser entonces analizado. Así que, la conclusión es que con todas las iniciativas PERP, pudimos ver un impacto visible en el percentil superior del 90 en el tiempo de uso de la página en casi un 52% y en el percentil superior del 90 en la cabeza no suministrada en casi un 40%.