Velocidad de búsqueda: Haciendo más rápido los vuelos de Expedia

Antes de profundizar en el tema, permítanme compartir primero la motivación, lo que nos lleva a mejorar el rendimiento en la página de búsqueda de vuelos. En primer lugar, en la página de búsqueda de vuelos, el tema de búsqueda está en su punto máximo. Y si la página no es eficiente en rendimiento, conduce a un aumento en la latencia y, por lo tanto, la experiencia del usuario se ve afectada y, por lo tanto, también se ve afectada la atención del usuario.

También, antes de comenzar con el experimento de rendimiento, permítanme hablar sobre las métricas de rendimiento. Para la medición, hay un conjunto común de métricas de Lighthouse que se pueden monitorear. Algunas de las más importantes para las páginas son el primer pintado de contenido, comúnmente conocido como FCP. Luego está el primer retraso de entrada. También hay cambio de diseño acumulativo y tiempo de interacción. Además de eso, también podemos utilizar algunas métricas de rendimiento derivadas. Dos de ellas para Expedia que nos ayudaron a monitorear la métrica de rendimiento para los usuarios son el tiempo de uso de la página. Y luego está la sobrecarga no suministrada. El tiempo de uso de la página es la métrica que se marca cuando se monta el componente principal de la página de búsqueda de vuelos. Y la sobrecarga no suministrada es el tiempo total de uso de la página en la página de búsqueda de vuelos menos la sobrecarga suministrada. Eso significa que el tiempo total que Expedia tarda en llegar al componente de búsqueda de vuelos sin depender del suministro. Además de eso, también hay un límite de tamaño que hemos establecido en la página de búsqueda de vuelos para asegurarnos de que el tamaño del paquete y el paquete que tenemos dentro de la búsqueda de vuelos no superen el umbral.

Ahora vamos a hablar del primer experimento de rendimiento, que es la precarga. La precarga significa que estamos obteniendo los recursos de antemano durante el tiempo de inactividad del navegador. Y cuando llegamos a la página actual, no obtenemos los recursos de la ruta del CDN, sino de la caché de precarga. Esto nos ayuda a obtener los recursos más rápido. Y antes de pasar a la precarga, es importante preparar qué recursos quieres precargar. Es decir, no es importante que todos los recursos se precarguen en la página anterior, sino los recursos importantes, idealmente los que se utilizan comúnmente en varias páginas, se pueden precargar para que la recuperación sea más rápida. Además, la precarga es impactante para los nuevos usuarios. Los usuarios que no obtienen, que no utilizan los recursos de la caché del navegador. Para los usuarios existentes, los recursos ya provienen de la caché del navegador y, por lo tanto, la precarga puede no tener un impacto allí. O si estás abriendo desde el modo incógnito, tampoco tiene un impacto. Pero si eres un nuevo usuario, tendrá un gran impacto. Luego, el siguiente experimento que tenemos es la búsqueda preventiva.

Entonces, con búsqueda preventiva nos referimos a que estamos llamando de forma preventiva a la respuesta de búsqueda. Es decir, la respuesta se predice incluso antes de que el usuario llegue a la página de búsqueda de vuelos. Esto se logra conociendo todas las entradas de búsqueda que tenemos en la página anterior, es decir, la página de inicio de búsqueda de vuelos. Y tan pronto como el usuario activa el botón de búsqueda, sabemos que esta es la respuesta de búsqueda que el usuario va a solicitar. Por lo tanto, almacenamos en caché la respuesta de antemano y cuando el usuario llega a la página de búsqueda de vuelos, recibe la respuesta almacenada en caché. Este fue un experimento muy importante en términos de medición de rendimiento y nos ayuda a mejorar el rendimiento en casi un 50% tanto en web como en nativo.

El siguiente experimento de rendimiento que tenemos son las microconsultas. Inicialmente, en la página de búsqueda de vuelos, teníamos una consulta principal a nivel de página que nos daba todas las respuestas de una vez. Una vez que dividimos esa consulta principal voluminosa en microconsultas, pudimos obtener las respuestas por partes en lugar de cargar todas las respuestas de una vez. Esto nos ayuda a asegurarnos de que el usuario pueda ver la información importante a nivel de página de antemano y luego obtener la información que no era necesaria durante el tiempo de carga de la página. Con eso, logramos mejorar el rendimiento de la página en casi un 20%. También separamos parte de la información, como los detalles de la tarifa, que no son necesarios de inmediato por el usuario.

Otro aspecto importante en cuanto al rendimiento es asegurarse de que las consultas se realicen de manera asíncrona. Para ello, el primer paso para cualquiera de las páginas que analizamos es el diagrama de cascada de la página para asegurarnos de que las llamadas de red se estén realizando como se espera. Es importante que las llamadas no estén esperando entre sí a menos que dependan una de la otra. En nuestro caso, las consultas de carga y cargadas son independientes entre sí. Nos aseguramos de que estas llamadas se activen al mismo tiempo y no estén esperando entre sí. Observamos una mejora de casi el 8% al mejorar cómo se ejecutan las consultas y al mejorar el diagrama de cascada de la página.

Lo siguiente es asegurarse de que se siga una arquitectura de micro front-end en la página. Esto también depende de la página y de los requisitos. Para nosotros, la arquitectura de micro front-end ha sido útil hasta ahora. Lo que significa es que descomponemos los componentes a nivel de página en paquetes compartibles al hacer que esos componentes a nivel de página, como los detalles de la oferta y los detalles de la tarifa, sean paquetes flexibles y compartibles. Los paquetes también se pueden reutilizar en diferentes páginas. Por ejemplo, la página de búsqueda de vuelos y la página de información de vuelos están correlacionadas entre sí, por lo que pudimos reutilizar esos paquetes compartibles. También podemos optimizar de manera eficiente a nivel de paquete en lugar de a nivel de página. Otra cosa a tener en cuenta es que los paquetes son mantenibles. Pudimos definir quién se encargaría de mantener cada paquete, lo que nos dio un sentido de propiedad cuando se trata de los paquetes de manera muy eficiente.

También pudimos mejorar el tamaño de compilación al mejorar el límite de tamaño de paquete en general. De esta manera, no solo pudimos refactorizar el code sino que también nos ayudó a mejorar el rendimiento porque pudimos analizar los componentes un poco mejor de lo que podríamos haber hecho a nivel de página.

Otro aspecto aquí es que pudimos mejorar mucho la matriz de rendimiento siguiendo este experimento de rendimiento. Como se puede ver en la diapositiva, hay un impacto visible en el percentil 90 superior en el tiempo de uso de la página en un 52% y en el percentil 90 superior en los gastos generales no relacionados con el suministro.

Por supuesto, me gustaría concluir la charla sobre el rendimiento diciendo que es un proceso continuo. Una vez que terminamos con el experimento de rendimiento, también nos aseguramos de que se esté realizando monitoreo. Existe un proceso de automatización en caso de que el umbral de rendimiento supere un límite específico o si encontramos alguna versión de confirmación defectuosa que esté causando alguna degradación del rendimiento, entonces se nos alerta de antemano.

Ahora dejaré que la audiencia haga preguntas y respuestas. No dude en comunicarse a través de mi correo electrónico o mi perfil de LinkedIn para lo mismo. También estaré en la conferencia para lo mismo. Así que en caso de que alguien tenga alguna pregunta, no dude en establecer contacto conmigo.

También hay un conjunto de referencias que he agregado. El primero es el Medium Log. Esto es sobre la descripción detallada de los experimentos de rendimiento que acabo de mencionar. Luego hay un enlace muy útil que encontré sobre el prefetching y la puntuación de rendimiento. Así que no dude en consultar las referencias también para una mejor comprensión.

Gracias por su tiempo.