Cuando las Optimizaciones Salen Mal

Entonces, sí, el tema de mi charla es cuando las optimizaciones salen mal. Se trata de casos en los que logras alguna optimization común pero a su vez, hace que la aplicación sea más lenta, no más rápida.

Entonces primero, hablemos de las CDNs. ¿Quién aquí usa una CDN en producción? Hm, bastantes personas. Bien. Hubo una vez, hace un tiempo, yo era un desarrollador en una gran y compleja aplicación web, y la pestaña era lenta. Las aplicaciones lentas no son agradables, así que tuvimos un proyecto para hacer la aplicación más rápida, y como parte de ese proyecto, decidimos implementar una CDN.

Ahora, una CDN es un servicio que acerca tus archivos al usuario, ¿verdad? Si tu servidor está en los Estados Unidos, y el usuario está en India con una CDN, la solicitud para el paquete no necesita ir todo el camino de vuelta a los Estados Unidos. Puede simplemente ir al servidor CDN más cercano al usuario en India. Entonces nuestro servidor estaba en los Estados Unidos, y nuestros usuarios estaban en todo el mundo. Así que decidimos probar esta optimization. Configuramos los buckets para subir los resultados construidos, configuramos la CDN delante de eso, y apuntamos todas las URLs en la aplicación a ese servidor CDN. Básicamente, nuestro index.html, en lugar de parecerse a esto, empezó a parecerse a esto, con el origen de la CDN delante de todas las URLs.

Hasta ahora todo bien, ¿verdad? Pero cuando ejecutamos las pruebas de performance, descubrimos que de repente, el sitio se volvió no más rápido, sino más lento. ¿Alguien, por cierto, tiene una idea de por qué? Basándose en las optimizaciones, basándose en el cambio que hicimos, ¿alguien tiene una idea de por qué sucede esto? No hay manos. Bien. Bueno para mí. Así que intentemos investigar esto, como si lo estuviera investigando hoy con el conocimiento y los métodos que tengo ahora.

Entonces, lo importante que hay que saber sobre la puntuación de lighthouse es que no es solo una puntuación de performance abstracta, ¿verdad? Se calcula en base a estas cinco métricas. Si una métrica empeora, toda la puntuación empeora. Si una métrica mejora, toda la puntuación mejora. Incluso hay una calculadora para esto. Ahora, la mayoría de las métricas en estas dos pruebas, antes de agregar una CDN y después de agregar una CDN, se mantuvieron más o menos igual. La Pintura con Contenido de Lars incluso mejoró, lo cual es bueno, pero una métrica, la Primera Pintura con Contenido, empeoró significativamente. Entonces, la Primera Pintura con Contenido es una métrica que mide cuán rápido se renderiza el primer contenido. Es el tiempo desde el momento en que el sitio comenzó a cargar hasta el momento en que el sitio renderizó su primer contenido, y empeoró.

Entonces, siempre que tengo un sitio que tiene mejores velocidades de renderizado, como la Primera Pintura con Contenido o la Pintura con Contenido de Lars, lo que me gusta hacer es mirar el renderizado cuadro por cuadro de ese sitio, la cascada de red de ese sitio, y luego compararlos para intentar averiguar qué demonios ha pasado. Entonces, en este caso, si comparo ambas versiones de este sitio, una sin CDN y una con, notaré dos cosas grandes. La primera es que las respuestas ahora realmente tardan menos tiempo, como se pretendía. Con la CDN, estas pruebas se hicieron desde Canadá, por ejemplo, utilizando webpagetest.org, y con la CDN, este error estaba más cerca de los usuarios, por lo que el viaje de ida y vuelta fue más corto, por lo que el archivo tardó menos tiempo en descargarse que sin CDN.

En segundo lugar, a pesar de que nuestros archivos tardaron más en descargarse, la primera pintura ocurrió más tarde. Puedes ver que, sin la CDN, la primera pintura ocurrió alrededor del segundo 2.0. Y cuando agregamos la CDN, la primera pintura comenzó a ocurrir alrededor del segundo 3. Y si intento averiguar por qué sucede, si miro la parte de la cascada que precede a la primera pintura, la primera pintura e intento comparar qué cambió, notaré esto.

¿Alguien sabe qué significa eso? Oh, no puedo oír desde aquí, resulta. Pero, está bien. Algunas personas están levantando la mano. Oh, está bien. Alguien sabe. Genial. Entonces, este fragmento de la cascada, esta parte de la cascada es lo que nos venció en aquel entonces cuando intentábamos configurar una CDN. Y ahora que estoy trabajando con clientes, ahora que soy un consultor independiente, lo veo mordiendo a mis clientes también.

El problema es que cada vez que intentamos cargar algo desde un nuevo dominio, el navegador tiene que establecer primero una conexión con ese dominio. Y eso es sorprendentemente lento. Así que el proceso de conexión consta de tres pasos. El primer paso es la resolución de DNS. El navegador obtiene el nombre de dominio que has referenciado en tu HTML o algo y busca su dirección IP. Eso idealmente toma un viaje de ida y vuelta. El segundo paso es la conexión TCP. Una vez que el navegador tiene la dirección IP del servidor, necesita establecer una conexión con el servidor detrás de esa dirección. Eso implica un viaje de ida y vuelta. Así que un ping al servidor y luego una respuesta del servidor. Así que si hay un retraso de 100 milisegundos entre el cliente y el servidor, esto va a tomar 200 milisegundos. Y el tercer paso es el handshake TLS. Una vez que el navegador se ha conectado al servidor, necesita cifrar la conexión para actualizar HTTP a HTTPS, y esto toma dos viajes de ida y vuelta más. Así que establecer una conexión tiene estos tres pasos y en una conexión 4G típica, estos pasos normalmente toman 500, 600 milisegundos para completarse, como en esta cascada.

Entonces, en este caso, lo que sucedió fue que al agregar una CDN, también agregamos accidentalmente el retraso de la conexión porque la CDN estaba en un dominio separado, y como resultado de eso, retrasamos los archivos CSS que la página utiliza en 600 milisegundos y como la página no puede renderizar sin CSS, la primera pintura con contenido también se retrasó. Así que movimos los archivos CSS a la CDN, los archivos CSS se retrasaron, la primera pintura con contenido ocurrió tarde. ¿Correcto? Entonces, en aquel entonces, en realidad no descubrimos qué pasó, así que tuvimos que abandonar la optimización de la CDN. Hoy, afortunadamente, sé cómo solucionar esto, sé cómo evitarlo.

Entonces, para la optimization de la CDN, para la optimization del costo de conexión, para el costo de conexión a notebook fire, necesito asegurarme de no agregar ningún costo de conexión nuevo. No agrego ningún dominio nuevo. Y la única forma de hacer eso es poner una CDN frente a todo el origen, no solo para algunos archivos. El término técnico correcto que quieres usar es CDN de extracción, que es algo que quieres usar versus la CDN de empuje que quieres evitar. Esto es un poco más complicado de configurar que simplemente empujar algunos archivos a un bucket y poner una CDN frente a eso, pero si haces eso, bueno, no vas a tener una regresión de performance lo cual es bueno.

Ahora, algunos de mis clientes a quienes introduzco en este problema de costo de conexión tienen una preocupación diferente. Dicen, como, hey, Luke, entiendo que hay un costo de conexión, pero en mi caso, uso la fuente Roboto de la CDN de Google Fonts, y es, como, realmente popular en muchos sitios. ¿No estará simplemente en caché cuando el usuario usa solo sitios? ¿No evitará simplemente el costo de conexión completamente en este caso? Entonces, si un usuario llega a algún sitio que usa Roboto de Google Fonts, el navegador almacenará esa fuente en caché, ¿verdad? Y si cinco minutos después el usuario llega a mi sitio, que también usa Roboto de Google Fonts, el navegador tomará la fuente de la caché y el archivo estará disponible de inmediato sin ningún retraso de conexión, ¿verdad? Entonces la respuesta es no. Hace un tiempo, esto realmente funcionaba como lo describí. Sin embargo, hace unos años, esto cambió. Entonces, a finales de 2020, Chrome lanzó algo llamado partición de caché. La idea de la partición de caché es que cada archivo que un navegador almacena en caché se almacena en caché solo para ese sitio. Entonces, si tienes otro sitio.com solicitando un robot.font, ese archivo se almacenará en la caché de otro sitio.com. Si tienes mi sitio.com también solicitando el robot.font, ese archivo se almacenará en la caché de mi sitio.com. No se tomará de otro sitio.com. Esto se hace por razones de privacidad. Y se ha implementado en todas partes desde principios de 2021. Entonces, si estás pensando, pero estoy cargando algún archivo popular, probablemente estará en caché de otros sitios, no lo estará. Para que los costos de conexión no se vuelvan en tu contra, necesitas cargar todo desde tu propio origen. Incluso cosas como Google Fonts. En general, la regla de oro con las CDN y los dominios es que todo debe estar detrás del mismo dominio. Mientras sigas esta regla, deberías estar bien. Si te alejas de esta regla, se volverá en tu contra. Entonces, esta es la primera optimization.

Ahora, hablemos de otra optimization, la división de code. Entonces, ¿quién aquí ha hecho la división de code en sus proyectos antes? Vale, sí, mucha gente. Eso es como una meta anónima de división de code. Entonces, cuando estaba trabajando en la aplicación, la respuesta no fue lo único que intentamos para hacer la aplicación más rápida. Otra optimization que intentamos fue la división de code. Al principio de la ronda de optimization, nuestro paquete se veía más o menos así.

Teníamos cuatro o cinco rutas independientes separadas, cada una de ellas con sus propios componentes, sus propias dependencias. Pero todas estas rutas se estaban agrupando en solo dos fragmentos, el fragmento principal y el fragmento del vendedor, diez megabytes en total.

Entonces, ¿qué intentamos para resolver esto? Por supuesto que intentamos la code división de código. Nuestra aplicación de una sola página se construyó a partir de un solo punto de entrada, tenía múltiples rutas, y utilizaba el enrutador de React para seleccionar la ruta correcta a servir. Si buscas guías de code división de código para el enrutador de React o el enrutador de View, ambos te recomendarán prácticamente lo mismo. Toma tu componente raíz, frótalos con importaciones, y code divídelos. Que es precisamente lo que hicimos.

Y así lo hicimos, revisamos nuestro paquete, y notamos que definitivamente se está haciendo más pequeño, como en lugar de servir todo el blob de diez megabytes de inmediato, ahora podemos cargar solo cinco megabytes de code. Yay. Sin embargo, una vez que ejecutamos las pruebas de performance, nos dimos cuenta de que la aplicación ahora en realidad tarda más en renderizar. Los primeros elementos de la UI aparecen antes, pero toda la aplicación UI se renderiza dos segundos completos después.

¿Alguien ha visto algo así antes? No, no hay manos. Entonces, para debug este problema, volvamos a mirar la cartera de red. Así es la cartera original. Repasemos lo que sucede aquí. Primero, solicitamos index.html. Cuando llega index.html, solicitamos los archivos que son referenciados por eso. y nuestros paquetes. Cuando llega el paquete, hay una pausa en las solicitudes de red porque ejecutamos el paquete. Puedes ver esto por estos delgados rectángulos rosados de ejecución de JS. Y luego, una vez que se completa la ejecución de JS, enviamos algunas solicitudes de API. Y luego, una vez que eso se completa, renderizamos la aplicación. Puedes ver esto por esta barra vertical verde punteada que indica la mayor console paint en WebPageTest.

Ahora, esta es la cascada actualizada, la que creamos. Aquí es lo que sucede. Nuevamente solicitamos index.html. Cuando llega index.html, solicitamos el paquete y CSS, prácticamente como la vez anterior. Cuando llega el paquete, ejecutamos el paquete. Pero ahora, cuando el paquete termina de ejecutarse, ahora solicitamos otro conjunto de archivos JavaScript, los fragmentos para la raíz dividida de code que la aplicación necesita renderizar ahora. Hemos dividido nuestra raíz y ahora la aplicación tiene que descargar la raíz para renderizar, pero no sabe que necesita esa raíz hasta que tiene el paquete principal. Así que la aplicación ahora puede renderizar realmente solo después de que estos fragmentos divididos de code se hayan descargado y ejecutado, que es dos o tres segundos después. Entonces, al dividir el código de la aplicación, básicamente hicimos nuestro paquete más pequeño, pero también introdujimos una cascada de solicitudes. En lugar de cargar todo de una vez, todo el code que la aplicación necesita, ahora lo estamos haciendo en múltiples pasadas. Y a pesar de que el code se hace más pequeño, el rendimiento de la aplicación en realidad empeora. Así que este fue un error que cometimos en aquel entonces, y hoy en día este sigue siendo un problema bastante común que veo en las aplicaciones con las que trabajo. Tampoco ayuda que las guías oficiales recomienden esta solución. Entonces, para evitar que esto te perjudique, puedes hacer una de estas cosas. Primero, puedes usar Next.js o Nuke.js o si usas Angular no sé qué podemos usar. Así que estos frameworks hacen la división de código por ti y abordan la división de código de manera diferente. En lugar de usar esta función de importación dinámica para cargar las rutas actuales, construyen un paquete separado para cada ruta y gestionan el intercambio de code entre cada paquete. Así que prácticamente consigues que todo se haga por ti.

Esta es la opción uno. La opción dos, teóricamente también puedes replicar lo que estos frameworks están haciendo por tu cuenta. No voy a decir cómo hacerlo, porque no sé cómo hacerlo. Pero si te adentras en el code fuente y configuras estos plugins de Webpack y también revisas este artículo de inmersión profunda, que he enlazado y obtendrás en el... Está disponible en este enlace que se muestra en todas partes. Podrías ser capaz de configurar algo. Honestamente, nunca he hecho esto. Espero que nunca tenga que hacerlo. Pero la opción tres es si ya tienes un montón de code que usa importaciones dinámicas para rutas y no te apetece migrar a Next.js, todavía hay una forma de solucionar esto. Lo que puedes intentar hacer es intentar analizar los pasos de compilación de Webpack y detectar qué fragmentos necesita cada ruta. Y luego generar múltiples archivos HTML con los enlaces rel preloads relevantes para cada ruta para que cada ruta comience a precargar sus fragmentos que necesita de antemano. Es bastante complicado de hacer. Suena complicado. Es complicado de hacer. Pero enlazé a un caso cuando tuve que implementar esto para un cliente de código abierto mío con mucha documentation. Así que si te encuentras en esta situación, también podrías echarle un vistazo. De todos modos, la idea clave, la regla de oro aquí es que la próxima vez que decidas dividir el code algo, usa import solo para componentes perezosos, para componentes que no afectan el primer renderizado. Quizás sea un componente de modelo, quizás sea algo que no es visible para el usuario de inmediato. Para componentes críticos como tus componentes raíz, como componentes de los que depende la aplicación, no uses import. Usa múltiples puntos, o la división hará que tu aplicación sea más lenta y se vuelva en tu contra.

Muy bien. Hablemos de otra optimización, que son las imágenes de carga perezosa. Este es en realidad un ejemplo que doy a los asistentes en mi masterclass, y aquí hay una simple página de producto. Esta página lista 100 productos, cada uno de estos productos tiene una imagen. Cuando abres la página, la página carga inmediatamente 100 imágenes. ¿Cómo podrías solucionar esto? En realidad, ¿cómo podrías solucionar esto? ¿Cómo podrías solucionar esto? ¡Sí, carga perezosa! Muchos de los asistentes a mi masterclass identifican correctamente que lo que necesitan hacer es hacer que esta imagen se cargue de manera perezosa. Lo que hacen es encontrar el componente que renderiza cada tarjeta de producto, y el atributo de carga perezosa en él, que le dice al navegador, oye, ¿puedes evitar cargar esta imagen hasta que entre en el puerto de vista? Y luego revisan las DevTools y confirman que, sí, parece que el problema se ha resuelto. Ahora estamos cargando nueve imágenes antes de desplazarnos hacia abajo. Parece bastante efectivo, ¿verdad? Pero de nuevo, si miras los resultados de Lighthouse de antes y después, descubrirás que el LCP del sitio en realidad empeoró. ¿Por qué? Para averiguar por qué, tendrás que desplazarte por el informe y ver cuál fue exactamente el elemento de pintura más grande. El elemento que desencadenó el más grande en la página. El elemento de pintura más grande fue esta imagen, shell-gold-some-hash.jpg. Y luego, una vez que sepas cuál fue el elemento de pintura más grande, necesitas mirar la cascada y ver qué ha cambiado exactamente en la carga de esa imagen. Así que si miras la cascada, verás que antes de ayudar a cargar Lazy, esa imagen comenzó a cargarse alrededor de la marca de 0.8 segundos. Mientras que después de ayudar a cargar Lazy, esta imagen comenzó a cargarse en 1.6, en realidad 1.7 segundos marca. Aquí está, la misma imagen. Pero, ¿por qué exactamente ocurre esto? Así que si revisas el elemento LCP una vez más, notarás que el elemento LCP, la imagen LCP, tiene este atributo de carga perezosa porque aplicamos la carga perezosa a todas las tarjetas de producto. Y algunas de las tarjetas de producto eran en realidad elementos LCP. Resulta que las imágenes de carga perezosa no se retrasan solo porque son perezosas o algo así,, sino que se retrasan por razones técnicas. Se retrasan porque están bloqueadas por CSS. Cuando tienes una imagen perezosa, el navegador no puede descargar la imagen hasta que sabe si la imagen está dentro del puerto de vista. Y esto está controlado por CSS. Tu CSS puede tener cualquiera de estas reglas y el navegador no sabrá qué reglas tiene hasta que realmente tenga el CSS, así que antes de que el navegador pueda descargar imágenes perezosas, antes de que el navegador sepa si estas imágenes están dentro del puerto de vista, tiene que esperar a que el CSS termine de cargar. Y eso es lo que pasó aquí. Aplicamos la carga perezosa y las imágenes tuvieron que esperar a que el CSS se cargara, lo que causó que comenzaran a cargar casi un segundo tarde y se retrasaran. Así es como al aplicar la carga perezosa un poco demasiado agresivamente, en realidad perjudicamos nuestro rendimiento. Ahora de nuevo, ¿cómo evitar que esto se vuelva en tu contra? Primero, si usas el componente de imagen de Next o la imagen ng-optimizada de Angular, una cosa para recordar es que estos componentes usan la carga perezosa por defecto. Así que si tomas alguna imagen crítica y la envuelves con la imagen de Next y la pones por encima del pliegue y termina siendo el elemento LCP, retrasará tu LCP. Así que lo que necesitas hacer es recordar especificar atributos de prioridad verdaderos en imágenes críticas para que se carguen lo antes posible. Y en segundo lugar, para detectar realmente las imágenes críticas, una cosa que me gusta hacer es instalar la extensión de vitales web, habilitar el inicio de sesión en la consola en sus opciones, y simplemente hacer una costumbre de la mía para comprobar el elemento LCP del sitio en el que estoy trabajando. Así que, si instalo esta extensión y habilito el inicio de sesión en la consola, lo que la extensión empezará a hacer, empezará a registrar toda esta información en la consola.

Y así, si estoy trabajando en algún sitio, y veo que el elemento LCP es una imagen, y noto que la imagen tiene el atributo de carga y perezoso, entonces sé que estoy en peligro. Así que ese es el segundo punto. Y en general, recuerda la regla general. Todas las imágenes por encima del pliegue no deben tener carga y perezoso, siempre que sigas esta regla, de lo contrario, la optimization de la imagen no se volverá en contra.

Así que gracias. Este fue Ivan Akulov, soy un Experto en Desarrolladores de Google. Tengo Twitter donde publico curiosidades de performance. Así que tal vez quieras suscribirte. Sin presiones, amigos. Y gracias por tenerme.

Tenemos unos minutos para algunas preguntas tal vez, porque también recibimos algunas. Bien, veamos las preguntas. ¿Qué herramienta estás utilizando para generar estos gráficos de cascada? Es webpagetest.org. Esa es la respuesta. Así que esa es. Esto es genial. Sí, me encanta. Es genial. Eso es lo que la gente debería usar. Muy bien. ¿Es posible que demasiados fragmentos, demasiada división de code en realidad pueda empeorar el performance? Demasiada división de code. Bueno... De una manera... Siempre que evites esa caída de velocidad que compartí, probablemente no lo hará. Una cosa que leí en Twitter de Ado's money en algún momento es que... Pero son datos de 2020, así que podría haber cambiado. Cuando tienes más de 30 o 40 fragmentos de JavaScript, entonces los costos de comunicación entre procesos empiezan a aparecer. Sé que el conjunto de cosas simplemente comienza a ser más lento. Pero no tengo idea de los detalles, tal vez simplemente lo recordé mal. Lo sé.

En general, 100 archivos pueden ser una idea complicada. Muy bien. Déjame ver. ¿Cuánto ayudan los encabezados de link, pre-connect, pre-load con... Oh, se ha ido. Oh, no, no se ha ido. Ayuda con las cascadas de conexión y carga. Oh, esa es realmente una gran pregunta. Así que puede ayudar, pero solo si cargas tus archivos más tarde. Así que no estoy seguro... ¿Puedo seguir mostrando mis diapositivas? No. No, no. No. Eso es difícil ahora. Vale. Así que si tienes algo... Básicamente, si haces referencia a algún dominio de terceros desde tu HTML, link, real, pre-connect no te ayudaría en absoluto, porque link, real, pre-connect también llegaría en tu HTML. Y el navegador comenzaría a conectarse a tu dominio de terceros tan pronto como recibe el HTML. Así que no puedes mover esto más rápido. Bueno, tal vez puedas con el estándar HTTP, 103 early hints, pero eso es como cosas advanced. En general, no ayudan realmente para cosas críticas. Muy bien. ¿Uno más? Recursos recomendados sobre cómo mejorar el conocimiento de rendimiento. Me preguntaron sobre esto en Twitter hace dos días. Twittearé la respuesta. Eso es, sí. Es... Hay algunos. Así que tal vez repita su nombre de usuario en Twitter para que la gente pueda ir a su Twitter y echar un vistazo a esos. Oh, sí. En I am, Akulov, mi apellido. Perfecto. Gracias. Creo que esas son todas las preguntas que responderé. Aplaudamos calurosamente una vez más.