Así Hicimos Que Postman Se Iniciara el Doble de Rápido

Hola a todos. Hace un tiempo, nuestro CEO fue a Amazon y luego escribió la laptop más barata que pudo encontrar. Y simplemente ordenó la laptop y la trajo a la oficina. Así que la trajo a la oficina. Era una laptop Acer Celeron, de muy bajas especificaciones, muy, muy similar a un Chromebook, y decidió probar Postman en esta laptop realmente, realmente barata. No nos sorprendió que fuera doloroso de ver. Era muy, muy, muy difícil hacer que Postman funcionara en esa laptop. Era muy lento. A veces tarda unos 30, 40, 50 segundos en iniciarse, y simplemente comenzará a fallar. La CPU comienza a dispararse. Y fue algo muy difícil de ver. Y sabíamos que teníamos un problema de rendimiento. Pero solo entonces nos dimos cuenta de lo grave que era el problema.

Hola a todos. Así que mi nombre es Ruben Casas, soy ingeniero de planta en Postman, y hoy voy a mostrarles cinco consejos sobre cómo mejorar el rendimiento de su aplicación. Desde elegir la métrica correcta, para entender su problema, hasta revisar y crear un plan de acción para unir a la empresa y resolver el rendimiento de su aplicación. No importa si es una aplicación móvil, una aplicación de escritorio, o una aplicación de React, debería poder usar estos consejos para comenzar y mejorar el rendimiento como lo hicimos con Postman. Entonces, ¿por dónde empezamos? En rendimiento, el único lugar para comenzar es medir, medir, medir. Necesitas comenzar a medir el rendimiento. No puedes comenzar a resolver un problema a menos que comiences a medir el rendimiento. Y luego, después de medir el rendimiento, lo primero que necesitas hacer es elegir una métrica estrella del norte. Puedes medir múltiples cosas, muchas cosas, pero necesitas elegir una métrica y comenzar a obsesionarte con esa métrica y arreglar y mejorar esa métrica. Así que ya teníamos las métricas, algunas métricas en Postman, teníamos lo habitual, teníamos los Core Vitals, las métricas de Lighthouse. Pero para resolver este problema, porque era tan complicado, sabíamos que teníamos que profundizar para entender el problema.

Entonces, ¿cuál? ¿Cuál elegimos de Lighthouse? ¿Qué métrica? Decidimos ir por un camino diferente. Recientemente encontré este concepto llamado TTF. Y TTF se usa en juegos móviles. Y como puedes ver en el GIF de Super Mario aquí, es el tiempo que lleva divertirse. Así que desde el momento en que comienzas un juego de Mario, inmediatamente comienzas a divertirte. Comienzas a saltar, matar enemigos, conseguir dinero, conseguir potenciadores.

Así que tienen este término en los juegos móviles llamado tiempo para divertirse. Asegúrate de que tan pronto como las personas abran su aplicación, comiencen a divertirse. Ahora, nuestra aplicación no es una aplicación móvil que puedas usar, pero me inspiré en eso y decidí elegir una métrica diferente llamada TTU. Y TTU significa Time to Usability. Así que Time to Usability es una métrica que hemos elegido para mejorar el rendimiento de nuestra aplicación. ¿Y qué es Time to Usability? Bueno, hay ejemplos de otras aplicaciones que están usando esta métrica. No lo llaman TTU. Y TTU es un término que se me ocurrió. Pero algunas otras compañías como VS Code tienen un concepto de Time to Usability. Y para ellos, Time to Usability es el tiempo que tarda un usuario en obtener un cursor parpadeante y comenzar a codificar en VS Code. Otras compañías como Slack, por ejemplo, tienen lo mismo, que es cuán rápido hasta que el usuario puede abrir un chat y enviar un mensaje.

Ahora, ¿qué pasa con TTI, Time to Interactive? Ya tenemos una métrica en Lighthouse llamada Time to Interactive. Y esta métrica de Time to Interactive mide el tiempo que tarda la aplicación en permitirte hacer clic y hacer cosas a su alrededor. Pero el problema con TTI es, en resumen, que está técnicamente listo. Así que tu aplicación está lista desde el sentido técnico, por lo que no está bloqueada, puedes comenzar a hacer cosas. Sin embargo, no te dice cuándo puedes realmente comenzar a obtener beneficios de tu aplicación. En este caso, TTU es probablemente una mejor métrica porque refleja la usabilidad real y las cosas reales que los desarrolladores están haciendo con tu aplicación. Y podemos optimizar para lo que realmente importa a nuestros usuarios.

Así que seleccionamos nuestro TTU, Time to Usability, y el Time to Usability para Postman fue el tiempo que tarda el Workbench, que es el espacio de trabajo principal donde realizas la mayoría de las operaciones en Postman, y para la parte principal de la aplicación, que es enviar solicitudes para estar activo. Pusimos esto como nuestra ruta crítica. El Time to Usability fue el tiempo que tardó alguien en hacer clic en el icono de la aplicación de escritorio para que esta página se renderizara y para que ese botón estuviera listo para que pudieras enviar una solicitud, que es lo que la mayoría de los usuarios de Postman hacen exactamente cuando inician la aplicación. Así que hemos elegido nuestro TTU y lo hemos definido.

Ahora, ¿cómo lo medimos? Porque podemos simplemente decir, este es el tiempo que tarda en lanzarse Postman y mostrar el botón, pero necesitamos datos reales para medir esto. Y como mencioné, TTU es una métrica inventada que se me ocurrió. No es algo que se proporcione con Lighthouse o con los Core Web Vitals. Así que necesitábamos medir esto.

Y la forma en que lo hicimos fue insertando marcas para la inicialización de la plataforma, la evaluación de JavaScript, la obtención de datos, el renderizado. Luego también capturamos los recursos de navegación. ¿Cuánto tiempo tarda en descargarse ese JavaScript, si viene de la red o del service worker? Convertimos esto en spans y los enviamos a nuestra RAM y nuestros laboratorios sintéticos para el seguimiento.

Y nuestros usuarios están en todo el mundo. Hay diferentes CPUs, diferentes laptops. Así que tuvimos que obtener paneles segmentados por CPU y región solo para ver cómo variaba el rendimiento entre esas regiones y diferentes usuarios. Puedes hacer esto. Puedes medir con solo una API de navegador incorporada, performance.mark. Así que performance.mark es muy poderosa, que básicamente, la agregas a tu código y comienzas a medir desde el momento en que pones un marcador hasta la siguiente parte en que pones este marcador, medirá el tiempo que toma.

Entonces, por ejemplo, en este caso, este es un pseudocódigo de lo que comenzamos a medir. Medimos desde el momento en que la plataforma se inicializó, el tiempo que tomó para que los paquetes de JavaScript se cargaran, ejecutaran, analizaran y compilaran, el tiempo que tomó para que nuestra obtención de datos obtuviera todos esos datos para mostrar al usuario, y el tiempo que tomó para que ese renderizado de la interfaz de usuario crítica se mostrara en la página. Y al final, simplemente marcamos esto con, está bien, esta característica principal está lista y nuestro tiempo de usabilidad está listo para nosotros.

Ahora, ¿cómo ves esto localmente y en el monitoreo sintético? Puedes hacer esto yendo a la sección de rendimiento en las herramientas de desarrollador, ejecutas un perfil de rendimiento en tu laptop, y estos marcadores comenzarán a aparecer en la sección de tiempos de ese perfil de rendimiento. Ahora, no queremos solo hacer esta prueba en nuestras laptops, queremos asegurarnos de que podemos medir en usuarios reales y dispositivos de usuarios reales. Así que, aunque podemos hacer esto localmente, también queríamos agregar y publicar estos a nuestras métricas de usuarios reales.

Así que usamos otra API llamada performance.measure que recopila todos esos marcadores de rendimiento que te mostramos hace un minuto. Y puedes tomar esos marcadores y luego enviarlos a tu servicio de análisis. En este caso, solo estoy registrando esto en la consola, pero puedes simplemente crear una API que envíe esta información a tu sistema de métricas de usuarios reales. Ahora, esto te permitirá crear muchos paneles, y creamos muchos paneles. Tenemos segmentaciones, cuántos usuarios estaban viendo el camino crítico de la aplicación en menos de 10 segundos, cuántas personas lo veían en menos de 20, 30 segundos.

Segmentamos esto por usuario, dispositivo, sistema operativo, el diferente tipo de aplicación de Postman, si era web, de escritorio, o si estaba en Windows o macOS. Ahora, establecimos nuestro objetivo. Nuestro objetivo era reducir el tiempo de usabilidad de 35 a 40 segundos que se tomaba en P90 a 10 segundos. ¿Y por qué decidimos elegir 10 segundos? Bueno, hicimos algunas investigaciones, y 10 segundos es el tiempo máximo que alguien esperará a que algo suceda antes de distraerse e ir a hacer otra cosa. Así que 10 segundos fue nuestro punto de referencia. Y aunque teníamos muchos dispositivos que se lanzaban en menos de 10 segundos, algunos de ellos eran como dos, tres, cinco segundos, pero esos eran como los Macs súper potentes que ejecutarían la aplicación. Y queríamos apuntar a cada dispositivo, incluso los de baja potencia para que funcionaran en menos de 10 segundos. Así que este es nuestro objetivo. Hemos elegido esto como nuestro objetivo para el TTU.

Así que esto es lo que nos lleva a nuestra conclusión número uno. Elige esa métrica de no-inicio y luego obsérsate en esta métrica hasta que la logres. Mejora, mide, obsérsate, y luego ve por ello. Entonces, ¿qué sigue? Elegimos nuestra métrica. Medimos nuestra métrica. Así que ahora lo que necesitamos hacer es entender el problema. Sabíamos que teníamos un gran problema de rendimiento, pero no sabíamos qué estaba causando ese problema. Así que la gran pregunta del millón de dólares es, ¿por qué nuestra aplicación es tan lenta? ¿Por qué tarda tanto en iniciar? Tomamos todas esas mediciones y dividimos el tiempo de lanzamiento de la aplicación en diferentes secciones que nos permitirán entender a dónde se iba ese tiempo.

Así que en la primera parte, nos dimos cuenta de que era alrededor del 22% del tiempo que estaba tomando sobre Electron y el proceso principal de Electron, solo todo ese proceso iniciándose. Luego, nuestra vista web comenzará a descargar, analizar JavaScript y compilarlo. Y eso estaba tomando alrededor de 40 segundos. Luego, el espacio de trabajo, renderizando todas las llamadas API, la obtención de datos y el renderizado estaba tomando el resto del tiempo. De esta manera, podemos visualizar y segmentar las diferentes partes de la aplicación y luego enfocarnos en esos diferentes problemas. La conclusión número dos es que no puedes resolver un problema que no entiendes. Así que primero, necesitamos entender el problema y necesitas comenzar a medir el progreso hacia la solución de ese problema.

¿Y ahora qué? Sabemos cuál es el problema. Hemos medido el problema. ¿Qué necesitamos hacer? Necesitamos idear un plan. Así que necesitábamos un plan de acción. Y lo primero que hicimos fue, bien, ¿qué hemos hecho hasta ahora? ¿Qué cosa ha funcionado? ¿Qué cosas no han funcionado? Y lo más importante, ¿cuál es el fruto más fácil de alcanzar, las cosas obvias que podemos hacer para mejorar el rendimiento de nuestra aplicación?

Así que había una sección obvia que destacaba y era que el 40 por ciento de nuestra aplicación estaba descargando, analizando y compilando JavaScript. Había una gran parte, casi el 50 por ciento del tiempo estaba en esta sección, que es básicamente incluso antes de comenzar a renderizar, nuestra aplicación estaba tomando tanto tiempo, pero solo descargando y analizando JavaScript. Nuestro tamaño de bundle era increíblemente grande. Era de 14 megabytes de JavaScript comprimido y minificado con gzip.

Y esta es la representación de cómo se veía eso y todo el código que estábamos enviando al principio. Y sé lo que estás pensando. 14 megabytes de JavaScript, ¿estás loco? Bueno, hay una explicación para esto.

Así que si estás familiarizado con Electron, puedes obtener todos los archivos JavaScript y luego simplemente enviarlos con el bundle de Electron para que no necesites descargar nada de la red. Pero después de años de iteración, dependencias circulares, terminamos con una aplicación grande y masiva con mucho código. Y no teníamos la necesidad de dividir el código o cargar de manera diferida porque todo estaba dentro de un bundle de Electron, por lo que no tenías que pagar ese costo de red. Ahora, después de eso, nos movimos a la web y comenzamos a enviar actualizaciones por aire. Así que comenzamos a descargar ese JavaScript desde nuestro CDN en lugar del bundle de Electron para permitirnos hacer actualizaciones más rápidas. Así que no teníamos que descargar el bundle de Electron cada vez. Pero como puedes imaginar, eso significaba que ahora en lugar de tener los 14 megabytes de JavaScript dentro de Electron, teníamos que descargar 14 megabytes a través de la red, lo cual era un poco loco. Y esa es la razón por la que nuestra aplicación era tan grande.

Creé esta visualización. Fui a las estadísticas de webpack y luego intenté crear una visualización de cómo se veía nuestro gráfico de módulos y nuestro bundle. Terminé con este gif increíble y genial de nuestro bundle, al que llamo el Supernova Module Graph. Recuerdo que bloqueé mi portátil algunas veces solo tratando de renderizar esto. Era imposible entender todas las conexiones y todas las cosas que sucedían en nuestro gráfico de módulos que hacían ese bundle de 14 megabytes de JavaScript. Así que la pregunta es, esto es muy obvio. Es grande. Es mucho JavaScript. Pero la gente podría estar preguntando, ¿importa el tamaño del bundle? Y en realidad, sí importa. Hicimos algunas investigaciones y el JavaScript, incluso si lo compilas, si lo comprimes en Gzip, tomará mucho tiempo para que el navegador lo ejecute. Así que no es lo mismo que tener una imagen JPEG masiva. El tamaño del bundle, la ejecución de JavaScript, afecta a tu aplicación, no solo desde la parte de descarga, desde la transferencia de red, sino también el análisis y la compilación.

Así que si te preguntas, ¿importa el tamaño del bundle? Sí, importa. Y aquí es donde queríamos comenzar a reducir ese bundle. Comenzamos a aplicar todas las optimizaciones de Performance 101, las cosas básicas, las cosas que aprendiste que tienes que hacer. Así que comenzamos a dividir la aplicación en partes más pequeñas usando carga diferida y haciendo algo de división de código, asegurándonos de que solo cargamos las partes que eran necesarias para el camino crítico. Y también introdujimos un almacenamiento en caché con service worker. Así que cada vez que se lanza la aplicación, almacenamos en caché todos los activos en el service worker, para que no tengas que descargarlos de la red nuevamente. Y cuando hay una actualización, almacenamos esos activos en caché en segundo plano. Así que cuando abres la aplicación, ni siquiera notas que la aplicación ha descargado algo de la red, porque ya está precargado en el service worker.

But that was not enough and we had to go deeper. And I found a tool that I considered was the tipping point that helped us solve this problem. And the tool was called a StatusScope. And there is a new tool called Iris Doctor, which is very similar. I recommend you taking a look into it, which helps you understand that super NOA model graph and understand how you can start pulling things apart from that. The bundle analyzer has this very powerful feature. So StatusScope shows you, for example, in this case, why lodash is being included into the bundle. And now lodash is a really big dependency. And that was the first thing that we did, was like, okay, who is using lodash and why is lodash being bundled up front? And it tells you what file, what line is importing this module, so you can go and lazy load it or just completely remove it, which is what we recommend with lodash. So the results were incredible. We went from 14 megabytes of JavaScript compiled minified gzip to under 2.7 megabytes. There was still a lot of room for improvement, but Postman is nearly like a code editor. So we have a lot of things like the Monaco editor, which are really, really big and we cannot just remove.

That was huge. That was an incredible reduction of bundle from 14 megabytes to 2.7 megabytes. One thing that we made sure that we introduced was, okay, we need to make sure that we don't regress. That we don't, after reducing the bundle size in such a manner, we don't want people to go and add a new module that is going just to undo all the work that we have done. So we decided to introduce PR blocking checks on every single pull request. It will give you a status code report that will tell you if you are increasing the bundle size and if you are impacting the critical path on our metric. So we introduced this and we started to implement the PR checks, so we didn't go back to where we started.

Now, the next thing was improving the network calls. And if you're a front-end engineer, you might be thinking, well, all of the optimizations are in the code, but actually some optimizations happen at the network level. We had so many network calls. There were hundreds of, for example, LaunchDarkly feature flags that were dead and we wanted to remove them. So that's the place we started. We started by removing LaunchDarkly flags, removing all those network calls, and we started prefetching the data. We took the critical path API calls that were required for us to render. And we started prefetching them upfront, even before your JavaScript started executing. So the data was already in parallel from the beginning, ready for you to use. And we also looked at the back-end.

Como desarrolladores front-end, nos gusta pensar que podemos hacer muchas micro optimizaciones aquí y allá, pero a veces el back-end es el que está tardando más y necesitas ir y hablar con el equipo de back-end y decir, está bien, necesitamos mejorar el rendimiento del back-end de estas APIs que se utilizan. Y te sorprenderá cuánto rendimiento puedes ganar solo con eso.

Ahora, lo último fue este 22% que encontramos, y fue el rendimiento de electron. Y podrías estar pensando, bueno, esto es electron. No hay nada que puedas hacer allí para mejorarlo. Bueno, estábamos equivocados. Era la sección de electron, así que era antes de que se lanzara el WebView, y era toda la sobrecarga pura de electron. Pero luego nos dimos cuenta de que había algunas cosas que podíamos mejorar para el rendimiento de electron.

Así que lo primero fue, mejoremos la sobrecarga de inicio de electron. Eliminar cualquier base de datos, bootstrap, scripts de inicialización que bloquean que están sucediendo en nuestra base de código que podemos simplemente eliminar y eliminar el bloqueo. Y también, comenzamos a agrupar el código del proceso principal. Así que en electron, una de las recomendaciones es usar un agrupador y realmente agrupar el código, el JavaScript, que se ejecuta en electron.

Y también, algo que encontramos que era muy intensivo en rendimiento eran las llamadas require. Cada vez que requieres un módulo de node dentro del proceso principal de Electron, eso estaba afectando el rendimiento total y la inicialización del lanzamiento. Así que para nosotros, fue simplemente comenzar a eliminar módulos innecesarios y dependencias necesarias de usar require.

Conclusión número tres, ejecución implacable. Así que, te mostré cómo dividir el trabajo, cómo identificar las áreas críticas, y luego simplemente ir y ejecutar. Eliminar todas estas cosas que están afectando tu aplicación, y comenzarás a ver los resultados. Ahora, después de unos meses trabajando en este proyecto, la realidad golpeó. Estábamos tan felices de haber reducido el tamaño del bundle tanto. Estamos contentos de que estamos haciendo mejoras en la red.

Pero luego, a pesar de todo esto, no estábamos viendo los resultados que esperábamos. Y no tenía sentido. Estaba mirando las métricas reales de los usuarios, y no tenía sentido. Esperaba una gran reducción, al menos en esa sección para la carga de JavaScript. Y no podía ver eso, a pesar de que el bundle se había reducido en un 90%. Así que, lo que tuvimos que hacer fue simplemente seguir adelante y profundizar más y reevaluar lo que estábamos haciendo y verificar los datos hasta que descubrimos algo.

Había un proceso que bloqueaba el renderizado en el proceso principal de Electron que competía con nuestros recursos en el renderer, haciendo que la descarga y el análisis de JavaScript fueran secuenciales. Así que, puedes imaginar que todavía tenemos mucho JavaScript, y luego el proceso principal está completamente bloqueando, deteniendo nuestra ejecución de JavaScript. Lo que significaba que no importaba cuántas reducciones de tamaño de bundle hubiéramos hecho, en realidad, todavía estaban esperando porque estaban bloqueados por el hilo principal. Y hay una regla principal en Electron, y es, no bloquees el hilo principal. Esa es la regla de oro. Y encontramos esto, y fue un momento de, bien, todas las mejoras que hemos hecho hasta ahora están comenzando a mostrarse porque eliminamos este error en particular que estaba afectando el hilo principal.

Y cómo lo encontramos, lo encontramos usando esta herramienta llamada Tracing. Y puedes usarla con Cron Dev Tools también. Pero este Tracing es para el proceso principal de Electron. Así que, este no es el proceso principal, el Tracing para la aplicación web, esto es para el proceso principal de Electron. Y nos dimos cuenta con esto de que podíamos encontrar el lugar donde estaba bloqueando el proceso de renderizado. Ahora, me lleva a las técnicas avanzadas. Así que, hemos hecho lo básico, hemos hecho todas estas cosas, pero este ejercicio de hacer el Tracing en Electron nos hizo darnos cuenta de que había más que podíamos hacer. Había más rendimiento que podíamos extraer. Y descubrimos esto llamado el caching de bytecode completo, el caching de bytecode completo.

Y el caching de bytecode completo es una optimización que podríamos implementar con nuestro service worker, donde básicamente puedes precompilar todo tu JavaScript. Así que, JavaScript se compila bajo demanda justo a tiempo. Pero con el service worker, podríamos simplemente, en el evento de instalación, generar el caché de código completo. Así que, estos scripts estaban precompilados. No compilé de manera perezosa, sino que instalé todo de una vez. Ahora, podríamos hacer eso porque teníamos nuestro service worker. Eso mejoró nuestro rendimiento de lanzamiento desde el lado de Electron y la carga conjunta aún más. Hubo otras técnicas y técnicas de rendimiento avanzadas que probamos, pero nos dieron resultados diferentes.

Por ejemplo, probamos con v8 snapshots. No sé si alguien está usando v8 snapshots para el proceso principal en Electron, pero fue un proceso muy complicado y frágil. Obtuvimos algunas mejoras con los v8 snapshots, pero decidimos optar solo por el caching de bytecode completo porque era más predecible. Así que, conclusión número cuatro, adapta e itera. Tuvimos que mirar las métricas, tuvimos que mirar los resultados, y luego averiguar qué cosas no estaban funcionando, y adaptarnos, y luego continuar iterando hasta obtener el resultado.

Ahora, lo último son los desafíos organizacionales. Quiero decir, somos desarrolladores, nos gusta un buen desafío técnico, pero al mismo tiempo, la mayoría de los problemas que tuvimos también fueron debido a desafíos organizacionales. No eran puramente técnicos. Tuvimos problemas como intentar tener un equipo de rendimiento para ir y solucionar el rendimiento mientras el resto de la empresa estaba lanzando características, y el problema es que este pequeño equipo enfocado no tenía todas las herramientas para ir y solucionar el problema. También tuvimos una falta de priorización.

Rendimiento, sabíamos que teníamos un problema, pero nadie simplemente comenzó a decir, oye, vamos a solucionarlo, lo que también genera una falta de responsabilidad. El rendimiento no es mi problema, es un problema del equipo de rendimiento, así que no me importa el rendimiento de las características cuando empiezo a agregar más características. Pero nuestro CEO, después de que trajo esta laptop, simplemente dijo, bien, esto es suficiente. El rendimiento es problema de todos, y reunió a toda la empresa, y nos dio un mandato para ir y solucionar el rendimiento. Así que nuestra empresa se enfocó durante unos meses, donde simplemente enfocamos a cada desarrollador, a cada equipo de producto en solucionar el rendimiento, y ese fue nuestro objetivo, y eso es lo que fuimos a hacer. Así que la conclusión número cinco es enfoque y priorización. Necesitas reunir a la empresa, reunir a los diferentes desarrolladores de diferentes equipos, y elaborar un plan y ejecutarlo como un solo equipo. No es solo responsabilidad de un equipo el rendimiento, cada desarrollador debe ser responsable del rendimiento de la aplicación.