Acabo de tener un par de enlaces de buen rendimiento quemando un agujero en mi bolsillo, así que los blogueo como un buen blogger.
Recetas de rendimiento web con Titiritero
Puppeteer es una biblioteca de nodos para hacer girar 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 puede ejecutarlo en un Lambda.
Otro caso de uso es ejecutar pruebas de rendimiento sintéticas (es decir, no basadas en usuarios reales), como algunos de estos nuevos Web Core Vitals
Addy Osmani enumera un montón de estas “recetas” para medir ciertas cosas de rendimiento en Puppeteer. Estos serían muy útiles como parte de un proceso de construcció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 rendimiento?
Navegador Stack SpeedLab
BrowserStack lanzó algo para medir su sitio y darle una puntuación de rendimiento.
Obtienes las pruebas súper rápido, lo cual es genial. Puedo ver cómo herramientas como esta son buenas para iniciar conversaciones con los equipos sobre cómo mejorar el rendimiento.
Pero… ese número parece un poco raro. No documentan exactamente cómo se calcula, pero parece estar basado 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, pero no creo que sea para los practicantes que hacen trabajo de rendimiento.
5 errores comunes que cometen los equipos al realizar un seguimiento del rendimiento
Karolina Szczur de Calibre documenta algunas dificultades comunes del equipo como, por ejemplo, tener un equipo capaz de identificar problemas reales a partir del ruido de variabilidad.
Muchas personas de diferentes orígenes pueden ver los 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 para regresiones de rendimiento o actualizaciones que no existen.
¿Sus tareas largas de JavaScript frustran a los usuarios?
50 ms. Ese es el tiempo que transcurre hasta que cualquier tarea de JavaScript en particular comienza a afectar la experiencia del usuario. También podría rastrearlos e (idealmente) arreglarlos.
Cuando el subproceso principal del navegador alcanza la CPU máxima durante más de 50 ms, un usuario comienza a notar que sus clics se retrasan y que el desplazamiento de la página se vuelve irregular y no responde. Las baterías se agotan más rápido. La gente se enfada con el clic o se va a otra parte.