Remixando un Symfony

[♪ Música reproduciéndose ♪ ¡Hola a todos, bienvenidos! Mi nombre es Emily Kaufman. Soy una ingeniera de software con sede en Pittsburgh, Pensilvania. De hecho, di esta charla en la- fui una oradora suplente en la primera conferencia de Remix, así que si ya la viste, esto puede sonar bastante familiar. Pero mi charla de hoy tratará sobre el viaje de rendimiento que ha experimentado Harvey, la empresa donde trabajo, en los últimos años y cómo eso finalmente nos llevó a Remix.

Muy bien, Harvey es un servicio de entrega de comestibles, donde todos nuestros productos provienen de granjas y productores locales. Así que comenzó, creo que hace unos diez años, como un programa de agricultura apoyada por la comunidad, si estás familiarizado con eso. Es un CSA. Básicamente, pagas a la granja una cierta cantidad de dinero al año y luego cada semana o cada dos semanas, recibes una caja con lo que hayan producido en ese tiempo. Es una forma realmente excelente de apoyar a los productores y granjas locales. Entonces, lo que hizo Harvey es proporcionar una plataforma para que realmente pudieras personalizar lo que recibías en tu caja. Hasta hace unos tres años, dos años y medio, eso era todo lo que hacía Harvey. Teníamos varias granjas en la plataforma de diferentes lugares y proporcionábamos la forma para que los clientes ingresaran, vieran el contenido de su caja, hicieran adiciones si querían cambiar cosas y luego esperaran su entrega.

Y luego llegó la pandemia. Entonces, tal vez recuerdes que al principio el mundo comenzaba a cerrarse. Muchas personas en el área de Pittsburgh recurrieron a Harvey como su principal fuente de comestibles, para evitar tener que ir a una tienda de comestibles. Y por otro lado, todos estos productores que solían ir a mercados de agricultores, instalar puestos en algún lugar para que pudieras venir y hacer compras, ya no tenían realmente un lugar adonde ir. Así que comenzaron a unirse a Harvey como productores para poder mantenerse en el negocio. Entonces, como puedes imaginar, tuvimos esta gran afluencia tanto de clientes como de productores y Harvey comenzó a crecer y evolucionar desde este programa de CSA hasta convertirse en una tienda de comestibles completa.

Por supuesto, durante cualquier tipo de crecimiento a gran escala en un corto período de tiempo como este, vas a experimentar algunos problemas de crecimiento y nosotros definitivamente los tuvimos. Esta es una prueba de Lighthouse que realicé a finales de 2020, y era simplemente una página de contenido simple en Harvey, que es una aplicación Symfony, y obtuvimos esta puntuación de rendimiento. Este era el paquete de JavaScript, las solicitudes a la API, las consultas a la base de datos, incluso con la interfaz de usuario mínima para renderizar en esta página de contenido básica, teníamos una puntuación base en los 30. Así que esto no estaba correcto. Algo no cuadraba. Esto, junto con algunos clientes molestos, algunos comentarios de los clientes, ayudó a catalizar este renovado interés y compromiso con el rendimiento en Harvey. La página del catálogo, donde puedes ver todos los productos, se había convertido recientemente, creo que un año antes de eso, de la combinación Symfony, jQuery, Twig en parte de una nueva aplicación de una sola página de React. Y esto fue lo más afectado. El cambio a React abordó muchas preocupaciones de experiencia de usuario que teníamos. Modernizó nuestra pila tecnológica, pero aún se quedaba corto en términos de rendimiento. Así que la arquitectura subyacente simplemente no podía manejar el peso de todos los nuevos productos. Tomaba varios segundos agregar algo a tu carrito o quitar algo o hacer un intercambio.

Y así, muchos miembros simplemente abandonaban por completo el sitio. Pero debemos recordar que hemos pasado de ofrecer quizás 30 a 40 productos hace un par de años a probablemente más de 600 en este momento. Y por lo tanto, la página simplemente no se estaba escalando correctamente. Entonces, cuando pensamos en soluciones para esto, nuestra primera iteración fue una especie de modo de crisis. Nuestro equipo de ingeniería se reunió y nos preguntamos qué podíamos hacer a corto plazo para solucionar algunos de estos problemas.

Así que pasamos unas horas sentados alrededor del panel de red en la pestaña de performance y revisamos cada paso de la carga de la página y organizamos lo que vimos en algunos grupos según quién los resolvería realmente. Así que teníamos DevOps y redes. Teníamos el backend, que incluía la API y la database, y luego teníamos el frontend. A partir de ahí, tomamos lo que encontramos y clasificamos esto en soluciones rápidas y fáciles, correcciones involucradas, y esto podría ser parte de un rediseño futuro.

Para DevOps y redes, no tuvimos que hacer mucho aquí porque en su mayoría eran manejados por servicios y tooling. Pero valió la pena sentarse y revisarlo y asegurarnos de que no hubiera cuellos de botella. Para la API del backend, tuvimos varios problemas con la carga de imágenes en el sitio. Tenemos un banner principal en casi todas nuestras páginas, y por alguna razón tardaba como siete segundos en cargarse y parecía bloquear la primera pintura. Así que hicimos mucho trabajo en torno a la optimization de imágenes y el almacenamiento en caché, y eso redujo segundos reales en el tiempo de carga de nuestra página. No puedo hablar de todo lo que hicieron mis compañeros de backend, pero las correcciones más involucradas incluyeron la actualización de los puntos finales y las consultas a la database para asegurarnos de que solo estamos consultando lo mínimo necesario, tratando de evitar operaciones innecesarias y computacionalmente costosas. Un ejemplo de esto es cualquier cosa que tenga que pasar por un proveedor externo. Por ejemplo, si estuviéramos verificando la información de la tarjeta de crédito de un usuario, podríamos hacer esto solo en una o dos páginas. Entonces no debería estar en un componente de nivel superior como el diseño principal porque entonces estaría sucediendo mucho más de lo necesario. En general, todas estas actualizaciones surgieron simplemente porque nos sentamos como equipo y nos quedamos mirando el panel de desarrollo durante unas horas e identificamos problemas.

Para el frontend, también conocido como mi problema, porque soy el único desarrollador frontend en Harvey, esto es cuánto tiempo tarda en descargar el contenido, qué tan grande es el script, testing conexiones más lentas y todo eso. Identificamos varias soluciones fáciles que sabíamos que requerirían un esfuerzo de desarrollo relativamente pequeño pero que aumentarían drásticamente la experiencia del usuario. Así que comenzamos por ahí. Por un lado, el paquete era simplemente demasiado grande, era demasiado grande. Había tanto código que un usuario tenía que descargar antes de poder interactuar con la página. Y utilizamos el plugin Webpacks. Utilizamos el plugin Webpacks Bundle Analyzer, si estás familiarizado con él, y esto nos ayudó a identificar muchas áreas problemáticas que pudimos abordar. Una de ellas fue nuestro uso de paquetes de localización de Moment.js. Así que estamos principalmente en el área de Pittsburgh. Tenemos granjas en todo el país, pero principalmente en los Estados Unidos. Entonces había muchos paquetes de localización que no eran realmente relevantes para nosotros en este momento, así que los eliminamos, estableciendo el objetivo de cambiar eventualmente a algo diferente que no sea Moment.

Revisé todas las dependencias en el package.json y traté de entender por qué estaban allí, si aún eran necesarias, si podían actualizarse. Y pudimos eliminar una buena cantidad de ellas.

Así que tengo esta captura de pantalla divertida y estresante de la pestaña de performance. Esta es nuestra página de catálogo. Uno de los mayores problemas que teníamos en el frontend, especialmente en la página de catálogo, era simplemente la gran cantidad de elementos que teníamos. Como dije antes, en un momento dado, tal vez teníamos 40 tarjetas de productos, cada una con una imagen y algunos botones, ya sabes, cosas normales de comercio electrónico. Y ahora tenemos casi 600. Entonces, incluso sin todas las optimizaciones que estamos haciendo ahora, hace dos años, esta página funcionaba perfectamente, funcionaba bien. Porque recuerda, Harvey nunca fue pensado para ser más grande que un pequeño programa de CSA. Entonces, una de las primeras cosas que hicimos aquí, después de ver esto, fue agregar carga perezosa a la página, y de inmediato dejó de bloquearse, lo cual tiene sentido. Pero puedes ver en la captura de pantalla que básicamente estamos tratando de cargar 500 imágenes a la vez.

OK, no me adentraré demasiado en todo lo que hicimos en el frontend, porque solo tengo 20 minutos, pero tengo una lista no exhaustiva aquí. Mejor división de código. Esto podría incluso ser una división de código más reflexiva. Realmente tomarse el tiempo para pensar en qué necesita cargarse realmente en cada ruta. Entonces, con nuestra aplicación de una sola página, no dedicamos mucho tiempo a considerar qué modules realmente necesitaban estar en cada página. Entonces, una de las cosas que esto llevó a hacer fue dividir nuestro código de miembro y administrador en dos proyectos separados con sus propias compilaciones, y luego hice una biblioteca de componentes donde ambos podían compartir. Entonces eso redujo mucho el tamaño del paquete. Comenzamos a usar compresión de texto. Agregamos esto a todos nuestros archivos de JavaScript. Y creo que nuestro CSS usando Gzip, y eso tuvo un efecto positivo. Minimizar y diferir scripts de terceros. A veces esto puede parecer una batalla constante con el marketing. Esto incluye cosas como Zendesk, Hotjar, Analytics, cualquier cosa que, ya sabes, tal vez el marketing esté usando para rastrear eventos en tu sitio web. Entonces revisamos esto y nos aseguramos de que todos los que estábamos usando todavía fueran necesarios, e intentamos identificar lugares donde pudiéramos diferirlos cuando fuera posible. Minimizar llamadas costosas a la API. Toqué esto antes, pero mucho de esto fue simplemente mover dónde estábamos haciendo estas llamadas, fuera de un diseño y dentro de un componente o una ruta. Solo para que no se hicieran todas en cada página. Entonces todos estos cambios que mencioné llevaron a una diferencia sustancial en términos de carga de página, y especialmente en dispositivos móviles. Y ayudaron en cierta medida con las interacciones de la página después de la carga, como agregar, eliminar, intercambiar elementos de la tarjeta.

Pero sabíamos que nuestro diseño actual simplemente no iba a soportar el nuevo modelo de negocio, el modelo de supermercado más grande que estábamos tratando de lograr. Y así sabíamos que era hora de un rediseño.

Una cosa que hicimos, esta es nuestra página rediseñada aquí. En lugar de cargar cada producto individual en la página, los cargamos por categoría. Así que ya no teníamos tantos elementos en la página. Una nota divertida sobre esto, sin embargo. Nuestras categorías están creciendo lo suficiente como para que ahora estemos empezando a considerar la paginación o algo así, debido al crecimiento.

Eliminamos partes de la tarjeta de producto, la descripción, la información del productor, y las movimos a una página de detalles para que no tuviéramos que cargar todas esas cosas para cada producto en el catálogo. Generamos múltiples tamaños de imagen para cada una de ellas, así que teníamos una miniatura, que puedes ver en la parte inferior de esta imagen aquí. Teníamos una vista de detalles, que es esta más grande, la vista de tarjeta, y coincidían con cómo se mostrarían en la página. Eliminamos algunas funcionalidades, como el botón de intercambio. Solíamos tenerlo para que, si estabas en tu carrito de compras, pudieras intercambiar. Por ejemplo, si no querías brócoli, podías cambiarlo por zanahorias. Pero simplemente no estaba aportando suficiente valor para el cliente para el problema de rendimiento que estaba causando, así que decidimos deshacernos de él.

Y eso llevó a esta forma de pensar. Como cuando incluyes un compromiso con el rendimiento como un principio esencial del diseño, entonces cuando estás pensando en el rendimiento cada vez que estás construyendo una nueva funcionalidad, el diseño se volverá más ligero. Así que me encuentro haciendo esto mucho. Entonces diremos, oh, deberíamos agregar esto al sitio. Esto haría esto. Sería realmente genial. Y luego nos damos cuenta de que va a haber un impacto en el rendimiento. Y es como, ¿realmente vale la pena agregar tanto tiempo a la carga de las páginas? ¿Vale la pena recibir ese golpe? Y muchas veces la respuesta es no.

Bien, veamos si esto carga. Así que nuestra página rediseñada estará a la izquierda y la página existente estará a la derecha. La página rediseñada se carga considerablemente más rápido que la página existente. Pero aún no es suficiente. Quería deshacerme de todos los indicadores de carga. Y a pesar de que nuestro tiempo de carga era mucho mejor, nuestra puntuación de Lighthouse seguía siendo bastante baja, lo cual fue sorprendente.

Bien, vamos a remix. A principios de 2020, me compré una licencia de remix como regalo de cumpleaños para mí mismo.

Y he estado probándolo en varios proyectos de hobby, simplemente testing lo que podría hacer y en general pasando un buen rato. Fue para mí. Y me di cuenta de que la colocación de las solicitudes de carga de página con los componentes, con el diseño, podría ayudarnos a salir de este problema de giro nuevamente que estamos teniendo, como lo llama el equipo de remix. Así que todavía no tengo nada desplegado públicamente, por mucho que quiera, pero pude poner en marcha nuestras nuevas páginas de comestibles con remix. Y creo que los resultados hablan por sí mismos.

Ejecuté este informe de Lighthouse solo para tener una idea de si, sabes, va a marcar alguna diferencia para nosotros. Y sí, puedes verlo. Entonces, uno de los puntos fuertes de remix es que minimiza la cascada de solicitudes. Y ese fue el caso para nosotros en algunas partes de la aplicación. Estábamos haciendo múltiples solicitudes de API al cargar la página y simplemente teníamos ese spinner en la interfaz de usuario. Veamos este video. ¿Está reproduciéndose? Lo haré de nuevo. Tan rápido. Ahí vamos.

Bien, este video está ligeramente sesgado porque la aplicación existente tiene más integraciones de terceros como un widget de soporte y algunas características más en general. Pero aún puedes ver esa segunda ola de solicitudes que se dispararon en los efectos de uso en el componente. Así que eso es en nuestra página existente. Si cambio a Remix, esta es la misma cascada pero en la versión de Remix. Entonces, en la versión de Remix, tenemos un tiempo de carga de documento más largo pero un número mínimo de solicitudes adicionales. Y como solo cargamos lo necesario para esa página, este JavaScript que se carga es mucho más pequeño. Así que todo esto sin aprovechar al máximo algunas de las características como el enrutamiento anidado en el que estamos empezando a trabajar ahora. Pero sí, fue una mejora inmediata para nosotros. Fue realmente emocionante.

Entonces, en el futuro, nuestro plan es seguir moviendo estas páginas existentes que actualmente están en nuestro código orientado a los miembros a nuestra aplicación de Remix hasta llegar a un punto en el que tengamos suficiente para implementarlo y que sea público. Pero el uso del framework se ha convertido en una progresión natural de nuestro viaje de performance en Harvey, y definitivamente ha valido la pena el esfuerzo, y ayuda que realmente disfruto trabajando en él. Entonces, si hemos aprendido algo en los últimos dos años, es que el rendimiento y la construcción para la escala no son negociables cuando estamos lanzando nuevas características. Tiene que estar integrado en todo lo que hacemos y verificar constantemente si hay regresiones. Entonces, nuestras listas de productos, nuestra base de clientes, siguen creciendo a un ritmo rápido. Y sí, tengo confianza en que lo que estamos haciendo ahora va a respaldar cómo se ve el negocio tal vez dentro de cinco a diez años. Así que es un momento emocionante. Muy bien. Gracias por escuchar. Nuevamente, mi nombre es Emily Kaufman. Si tienes alguna pregunta, puedes encontrarme en Twitter o puedes leer la publicación del blog detrás de esta presentación en mi sitio web. Así que gracias.