Enlaces sobre Performance II

Acabo de tener un par de enlaces de buen rendimiento que me están haciendo un agujero en el bolsillo, así que los blogueo como un buen pequeño blogger.

Recetas de rendimiento web con Puppeteer

Puppeteer es una biblioteca de Node para crear una copia de Chrome “sin cabeza” (es decir, sin interfaz de usuario) y controlarla. La gente lo usa para cosas como tomar una captura de pantalla de un sitio web o ejecutar pruebas de integración. Incluso puedes ejecutarlo en un Lambda.

Otro caso de uso es ejecutar pruebas de rendimiento sintético (es decir, no basadas en usuarios reales), como algunas de estas nuevas Web Core Vitals.

Addy Osmani enumera varias de estas “recetas” para medir ciertos aspectos del rendimiento en Puppeteer. Serían muy útiles como parte de un proceso de compilación junto con otras pruebas. ¿Pasaron las pruebas unitarias? ¿Pasaron las pruebas de integración? ¿Pasaron las pruebas de accesibilidad? ¿Pasaron las pruebas de métricas de desempeño?

NavegadorStack SpeedLab

BrowserStack lanzó una herramienta para medir su sitio y brindarle una puntuación de rendimiento.

Obtienes las pruebas súper rápidas, lo cual es genial. Puedo ver cómo herramientas como estas son buenas para iniciar conversaciones con los equipos sobre cómo mejorar el rendimiento.

Pero… ese número parece un poco extraño. No documentan exactamente cómo se calcula, pero parece basarse en cosas como el tiempo hasta el primer byte (TTFB) y el evento de carga de la página, que no son métricas de rendimiento particularmente útiles.

No está mal que exista esta herramienta ni nada por el estilo, pero no creo que sea para practicantes que realizan trabajos de interpretación.

Cinco errores comunes que cometen los equipos al realizar un seguimiento del rendimiento

Karolina Szczur de Calibre documenta algunas luchas comunes en el equipo, como, por ejemplo, que un equipo pueda identificar problemas reales a partir del ruido de la variabilidad.

Muchas personas de diferentes orígenes pueden ver paneles de rendimiento. No saber qué constituye un cambio significativo que necesita investigación puede resultar en falsos positivos, falta de confianza en el monitoreo y ciclos dedicados a buscar razones de regresiones o actualizaciones de rendimiento que no existen.

¿Sus largas tareas de JavaScript frustran a los usuarios?

50 ms. Ese es el tiempo que transcurre hasta que una tarea particular de JavaScript comienza a afectar la experiencia del usuario. También podría rastrearlos y (idealmente) arreglarlos.

Cuando el hilo principal del navegador alcanza el máximo de CPU durante más de 50 ms, un usuario comienza a notar que sus clics se retrasan y que el desplazamiento por la página se vuelve entrecortado y no responde. Las baterías se agotan más rápido. La gente se enfurece y hace clic o se va a otra parte.