Cepillado Diario para la Velocidad del Sitio Web: Abrace el Ritual del Presupuesto de Rendimiento

Hola a todos. Mi nombre es Ned Haddawood. Soy un ingeniero de software senior que trabaja para Miro y un experto de Google en rendimiento web. Hoy, voy a llevarlos en un viaje para impresionar con los rituales del presupuesto de rendimiento web. Pero antes de eso, imaginemos juntos si el sitio web es como el cuerpo humano. El cuerpo humano crece al comer comida. Cuanto más comes, más necesitas cepillarte los dientes, más necesitas usar hilo dental a diario, ¿verdad? Si imaginas el sitio web como un cuerpo humano, yo imagino el rendimiento como tus dientes. Así que cuanto más alimentas tu sitio web con nuevas características, más necesitas cuidar el rendimiento. La similitud entre ambos es que si tienes un problema en los dientes, vas a visitar a un dentista para que te lo solucione. Si tienes un problema de rendimiento, podrías visitar o contratar a un experto en rendimiento para solucionarlo. Ambos problemas no pueden ser solucionados porque con una pequeña inspección, descubrirás que no te has preocupado demasiado por ellos.

Algunas personas podrían argumentar y decir, Bueno, no estamos haciendo eso y resulta que todo está bien. Al igual que estos dos caballeros. Pero aquí hay dos hechos. En primer lugar, los dientes malos también funcionan. Puedes comer con dientes malos, pero créeme, no vas a disfrutar de la comida. El otro hecho es que no sabes durante cuánto tiempo no vas a sufrir de un problema con tus dientes o tu rendimiento. Puede pasar mucho tiempo hasta que descubras que hay muchos problemas surgiendo. Así que cuanto antes actúes, mejor. Así que vamos a continuar.

Si tienes un problema. Lo primero que debes hacer es medir este problema para ver cuán grande o pequeño es este problema para que puedas actuar en consecuencia.

Entonces, para medir el performance, tenemos dos tipos de medición del performance. El primero es la testing sintética, también conocida como testing de laboratorio utilizando algo como Lighthouse. Tiene algunos beneficios y algunas desventajas. Lo bueno es que es muy consistente, es gratuito y es útil. Es fácil de hacer, pero no es súper preciso. Este es un problema. ¿Por qué no es súper preciso? Porque depende mucho de la máquina en la que se está ejecutando.

El otro tipo es la testing RAM, medición de usuarios reales, o también conocida como testing de campo. Esto es más interesante para nosotros hoy. Y esto viene con usuarios reales, plug in, opt in, y estamos obteniendo un montón de información sobre ellos que nos ayudará a tomar decisiones más y mejores. Es como geolocalización, navegador y tiempo, conexión a Internet, y así sucesivamente. Es muy preciso y podemos confiar en él, pero no siempre es gratuito. Una opción gratuita podría ser el Informe de User Experience de Chrome. Pero otras opciones de pago, como Calibre, Speedcurve, y así sucesivamente, también valen la pena. Como verás en un momento.

Entonces, utilizando ambos, puedes medir muchas métricas que son muy útiles para nosotros para medir el performance y para decidir si nuestro sitio web es suficientemente eficiente o no. También vienen con algunos umbrales de investigación y recomendaciones. Por ejemplo, frente a nosotros, tres recomendaciones basadas en los core web vitals. Para el LCP por ejemplo, necesitamos hacerlo en menos de 4 segundos al menos para que funcione bien. Y 2.5 segundos es una recomendación para una buena experiencia para el usuario. Esto es muy útil para establecer tu objetivo de performance. Y hay una diferencia entre el objetivo de performance y el presupuesto de performance como veremos en un momento.

Entonces, tienes un problema, fuiste al gerente y dijiste, Oye, tenemos un serio problema en nuestro performance. Tenemos problemas de performance. Simplemente dijo, está bien, podemos posponerlo después del próximo trimestre futuro, ¿verdad? Mostró el número. Esto no está afectando al negocio, ¿verdad? Pero sí, por supuesto, está afectando a tu negocio en línea. Y sugieres hacer una masterclass de performance para todo el equipo centrado en el performance para mejorarlo. Hiciste un buen trabajo, tú y tu equipo, y convertiste todo en verde.

Tu gerente estaba realmente contento. ¿Has visto a este tipo feliz antes? Este es tu gerente. Y dijo, bueno, vamos a compensar este tiempo que pasamos sin añadir nuevas características o añadiendo características de lista. Vamos a añadir más características ahora, ya que tenemos un buen performance.

Después de unas pocas iteraciones con nuevas características con menos o ninguna mantenimiento, nuestras puntuaciones se han visto afectadas. Así que el performance ahora es ámbar. No es rojo, pero es ámbar. No es verde como antes. El gerente, mira y dice, bien, estará bien, igual que el tipo al principio de esta presentación. Y sigue añadiendo algunas nuevas características sin mantenimiento para performance. Y esta vez, estamos afectados. Estamos muy afectados en el negocio.

Y descubrió que hay un problema. Está sentado y reuniéndose con el equipo, preguntando, ¿qué podemos hacer para esta regresión en performance con la adición de nuevas características? Y dice, está bien, hagamos una iteración de performance. Dijo, bueno, lo intentamos antes. Estamos alcanzando nuestros objetivos, pero no ayuda en la regresión, como puedes ver. Otro tipo dijo, bueno, ignoremos a los usuarios. Estamos construyendo nuevas características. Nos gustará. Y dijo, no, necesitamos preocuparnos por los usuarios. Esas son las personas que nos están pagando. El tercero dijo, un consejo muy sabio. Dijo, no nuevas características sin un presupuesto de performance. Lo más probable es que el gerente no escuchara la última parte, pero ya estaba enfadado con no nuevas características sin un presupuesto de performance. Pero fue un consejo muy sabio, muy importante. Aquí está lo que es un presupuesto de performance que será una solución muy útil para lo que tenemos. El presupuesto de performance es simplemente una forma de limitar las posibilidades de arruinar el performance. Lo mismo que tenemos de tu aplicación proporcionando algunas reglas y revisando diariamente. Su objetivo principal es prevenir las regresiones tanto en UX como en los objetivos de negocio. Esta es la solución perfecta para esta situación, ¿verdad? Así que empecemos con los rituales.

Tenemos algunos pasos para los rituales. Lo primero de todo es crear un presupuesto, es aplicar el presupuesto. Hazlo permanecer. Y lidiar con nuevas características. Este mal que está afectando nuestros objetivos de performance.

Entonces, en primer lugar, cómo crear un presupuesto. Hay pasos si ya tienes algunos problemas de performance en tu sitio web mientras empezamos a pensar en un presupuesto. En primer lugar, mide la performance utilizando las herramientas de las que hablé al principio. Y establece metas para cada una de las métricas que te importan. A continuación, planifica y soluciona la mayoría de los problemas hasta que estés bastante satisfecho con el resultado. No tiene que ser perfecto. Después, puedes establecer esta meta que alcanzaste como un presupuesto de performance. Y sigue iterando. Cada vez que estás haciendo un nuevo progreso y sientes que este presupuesto puede ser mejorado, puedes mejorarlo. Mide, soluciona y mejora el presupuesto.

Si estás añadiendo un nuevo proyecto o en una etapa temprana del proyecto, es muy recomendable empezar con un presupuesto. Puedes usar esta hermosa calculadora en línea. Sólo dale el tiempo de carga objetivo y la conexión del usuario objetivo. Al igual que 4G o 3G o lo que sea. Y te da recomendaciones sobre los activos que tienes. El presupuesto viene en forma de archivo JSON, similar a este. Esto viene con la especificación del camino objetivo, especificando el tipo de presupuesto, tamaño o recuentos. Y especificando el tipo de recurso, script, terceros y así sucesivamente. Si estás midiendo tamaños, viene con número. Este número está en kilobytes. Si estás midiendo recuentos, viene con solo un número de este recurso. Entonces, tenemos un presupuesto. ¿Cómo aplicarlo? Hay toneladas de herramientas por ahí. Algunas de ellas son gratuitas y otras son de pago. Empecé con una herramienta gratuita llamada Bundlesize.

Puedes usar un paquete, archivo budget.json o package.json para agregar estas reglas. Basado en eso, puede integrarse en tus GitHub Actions o algo así y verificar cada vez que estás construyendo si estás en presupuesto o no.

Otra herramienta gratuita, en Webpack, si ya tienes Webpack en tu proyecto actual, puedes configurarlo para performance y te da sugerencias similares para el tamaño del paquete y te dice mientras estás construyendo si estás excediendo el presupuesto o no con este hermoso mensaje de error.

Otra herramienta gratuita, si estás usando Lighthouse CI o no, pruébalo. Ahora viene con soporte para presupuestos con algo como una billetera ligera. Lo que es genial de eso es que usas un archivo separado, un archivo budget.json y puedes ejecutarlo contra cualquier URL agregada a tu CI y puedes ejecutarlo también contra el sitio web de tus competidores y ver cómo se comportan con el mismo presupuesto que estás estableciendo para ti mismo.

Una gran herramienta llamada SpeedCurve. Viene con este hermoso tablero que te dice qué está en presupuesto, qué está por debajo del presupuesto y qué está excediendo el presupuesto. Esto es muy útil y muy práctico, pero desafortunadamente es una herramienta de pago pero vale totalmente la pena con esta hermosa forma y con todas las advertencias y todas las notificaciones. También viene con una versión de prueba. Lo que es genial, viene con esta tendencia para cada una de estas métricas. Te dice cuándo agregaste algo que está excediendo tu presupuesto y así sucesivamente. Esto es muy útil y muy práctico. Otra herramienta de pago llamada Caliper. Puedes usarla más. Está haciendo lo mismo que SpeedCurve y viene con estos web hoax y también te da toda la información que necesitas sobre el usuario. Cuál es el perfil, cuál es el dispositivo utilizado, y cuál es la conexión a Internet en este momento. Y mucho más, puedes consultar en línea solo para nombrar algunos. Pero puedes consultar en línea y descubrir cuál se adapta mejor a tu negocio.

Ahora es el momento de hablar brevemente sobre cómo hacer que perdure. No permitir que los desarrolladores lo eviten. En primer lugar, necesitas hacer tu presupuesto concreto. Puedes decir que necesitamos lo más rápido posible. Puedes decir que quiero que LCP esté por debajo de tres segundos en móvil o conexión 4G. Eso es muy específico, muy concreto. O decir que quiero que la puntuación de performance sea superior al 95% para escritorio.

Necesitas hacerlo significativo. Así que no dirías que me gustaría simplemente mejorar la performance porque es una tendencia o algo así. No. Tienes que conectarlo a los objetivos de negocio, a las necesidades del negocio. Que sirva para algunas métricas de negocio como la tasa de rebote o la tasa de conversión y así sucesivamente.

Necesitas integrarlo. Así que no puedes simplemente ejecutarlo cada vez manualmente o en un script específico localmente. Necesitas integrarlo en un pipeline de ucicd. Así se ejecuta automáticamente y te da informes. Necesita ser visible para los stakeholders y los desarrolladores para actuar en consecuencia. Los stakeholders podrían necesitar algunas pausas para su velocidad y decirles que algunas características podrían afectar la performance. Es muy importante establecer esta cultura en el equipo.

También necesitas hacerlo aplicable. Así que cada vez que lo excedemos lo modificamos. Esa es una mala cultura. La buena cultura es que esta es una línea dura. Todos se unirán a ella y esto es algo para cambiarlo. Tiene que estar basado en data. Tenemos que tener algunos data específicos sobre el usuario que ha cambiado y en base a eso estamos cambiando lo que tenemos. Tenemos una nueva característica, ¿qué hacemos? En primer lugar, optimiza la característica existente. La mayoría de las características que están causando problemas en performance son características que se han añadido en una etapa temprana o en MVP. Simplemente adelante y optimízalo para dejar espacio para nuevas características. Elimina la característica existente.

Si lo eliminas, si ya no es válido o al menos quítalo del camino crítico. No añadas nuevas características. Sí, algunas características pueden ser muy molestas para el performance o al menos no las añadas al camino crítico. Solo repiénsalo cada vez basándote en esta visibilidad frente a los stakeholders y desarrolladores que será más fácil.

Finalmente, solo ejecuta cualquier nueva característica que pueda afectar el performance en EBTesting y descubre la medición y las métricas cómo se están comportando con la nueva característica. Con eso, los rituales deberían hacerse y deberías sentir la fuerza a tu alrededor. Estás protegido y cualquier victoria de performance que estés logrando estará protegida contra ser rota.

Solo recuerda que el performance es un viaje en curso al igual que la higiene dental, tiene que ser diario. Y promete cepillarte con performance junto con tus dientes a diario porque ambos mantendrán una sonrisa brillante en tu cara justo como esta. Muchas gracias por ver y si te gusta esta presentación se compartirá más tarde en mi Twitter, en este handle y para más información y más contenido como este lo encontrarás en mi blog metahut.dev Conectémonos. Gracias por ver.