1. Introducción al rendimiento del software
Hoy estamos hablando de su experiencia optimizando el frontend para el usuario. El rendimiento del software es una medida de qué tan bien se está ejecutando su aplicación, realizando su tarea y utilizando los recursos del sistema. En el frontend, el rendimiento del software incluye cómo se sienten los usuarios acerca de la aplicación. El rendimiento pasivo es una medida subjetiva de qué tan bien el usuario piensa que la aplicación está funcionando. Se puede medir indirectamente a través de las tasas de rebote, que indican si los usuarios abandonan después de unos segundos. Para mejorar el rendimiento pasivo, puede reducir el tiempo entre la entrada del usuario y la carga del sitio web mediante el uso de una caché compartida.
su experiencia optimizando el
frontend para el usuario.
Mi nombre es Chinayan Onwebu. Soy un ingeniero de software senior en HubSpot. ¿Qué es el rendimiento del software? Todos sabemos qué es el rendimiento del software, o al menos tenemos una idea. Básicamente, es una medida de qué tan bien se está ejecutando su aplicación, qué tan bien está realizando su tarea y qué tan bien está utilizando los recursos del sistema que están disponibles para ella. En el frontend, sin embargo, el rendimiento del software es todo esto, más cómo se sienten los usuarios acerca de la aplicación. Entonces, si el usuario no se siente bien acerca de la aplicación, no importa qué tan rápido sea su aplicación en realidad, su aplicación no está funcionando bien. Porque el frontend se ejecuta para el usuario, medimos el rendimiento del frontend en relación con el usuario. Por eso lo llamamos rendimiento pasivo. Esto es una medida subjetiva de qué tan bien se está ejecutando su aplicación. Qué tan bien el usuario piensa que su aplicación está funcionando. El rendimiento pasivo es muy difícil de medir. No se puede medir directamente. No hay forma de saber cómo se sienten los usuarios acerca de su aplicación. Hay formas de medirlo indirectamente. Primero, puede utilizar las tasas de rebote. Si obtiene muchas rebotes, significa que muchos usuarios abandonan después de los primeros segundos en su sitio web. Por lo general, es una señal de que su aplicación no está funcionando muy bien. Los usuarios piensan que su aplicación es lenta. Tal vez las páginas no se están cargando. Por supuesto, también podría ser algún otro problema. Tal vez no sea el contenido que esperan. Pero por lo general, es una señal de un mal rendimiento. Los usuarios piensan que su aplicación tiene un mal rendimiento. Las investigaciones han demostrado que los usuarios abandonarán un sitio web entre tres y cinco segundos después de esperar a que el sitio web Si su aplicación no muestra contenido en los primeros cinco segundos, hay una alta probabilidad de que pierda muchos usuarios. ¿Cómo mejoramos realmente el rendimiento pasivo de nuestra aplicación? Siempre puede mejorar el rendimiento pasivo mejorando el rendimiento real. En primer lugar, desea reducir el tiempo entre cuando el usuario ingresa a su sitio web, presiona enter y cuando su sitio web realmente se carga. Queremos utilizar una caché compartida,
2. Mejorando el rendimiento del software
Si un usuario visita una página que ya está en caché, un segundo usuario recuperará la caché. El uso de HTTP2 puede mejorar enormemente el rendimiento, especialmente para sitios web con muchos recursos. La precarga de solicitudes importantes y el uso de una CDN como Cloudflare también pueden mejorar el rendimiento. El renderizado en el lado del servidor permite a los usuarios ver el contenido de inmediato, mejorando el rendimiento pasivo. Evite bloquear al usuario utilizando trucos como evitar tareas intensivas de CPU en el frontend y cargar recursos gradualmente.
por ejemplo. Una caché compartida es una caché que se comparte entre usuarios. Entonces, si un usuario visita una página y esta página ya está en caché, un segundo usuario que visita la misma página también recuperará una caché de esta página. También puedes usar HTTP2. HTTP2 mejorará enormemente tu rendimiento. Esto es especialmente cierto si tu sitio web carga muchos recursos. Esto incluye sitios web que tienen muchas imágenes, por ejemplo, o sitios web que cargan muchos scripts, mucho
CSS. HTTP2 hará que la carga de recursos en paralelo sea mucho, mucho más rápida que HTTP1. También puedes precargar solicitudes importantes. Hay varias formas de hacer esto. Precargar solicitudes importantes hará que tu sitio web o tu aplicación se sientan más ágiles para el usuario. El uso de una CDN resolverá una serie de problemas en tu aplicación sin que tengas que hacer nada. Usar
Cloudflare, por ejemplo, te dará una caché compartida sin que tengas que hacer nada. También te dará HTTP2 sin que tengas que hacer nada. Por último, puedes usar el renderizado en el lado del servidor. El renderizado en el lado del servidor se asegura de que cuando se carga la página, el usuario vea el contenido de inmediato. Entonces, el usuario no tiene que esperar a que se cargue todo el
JavaScript antes de poder ver el contenido de tu sitio web. Usando el renderizado en el lado del servidor, los usuarios ya pueden ver el contenido y luego puedes inyectar el script, hidratar la página más tarde para la interacción del usuario. Luego puedes mejorar directamente el rendimiento pasivo haciendo algunos trucos. Estos trucos no cambian nada en tu sitio web. No cambian cómo funciona tu sitio web en realidad, pero cambian cómo perciben los usuarios la aplicación de forma pasiva.
3. Optimizando el rendimiento del frontend
Cuando se realizan tareas intensivas de CPU en el frontend, evite bloquear el hilo principal. Cargue solo los recursos necesarios al principio para evitar bloqueos en el renderizado. Use barras de progreso en lugar de spinners para brindar a los usuarios una sensación de progreso. Implemente patrones optimistas para marcar las tareas como completadas antes de que finalicen. Evite bloquear a los usuarios permitiéndoles seguir utilizando la aplicación mientras esperan que se completen las tareas. Considere las expectativas cambiantes de los usuarios a lo largo de su interacción con la aplicación.
y uno de ellos es evitar bloquear al usuario. Entonces, si está realizando algunas tareas intensivas de CPU en el
frontend, digamos que está renderizando imágenes, debe evitar bloquear el hilo principal. Siempre use un hilo de trabajo para cualquier tarea que tome más de unos pocos milisegundos. El estándar recomendado es de 16 milisegundos. Si va a tomar más de 16 milisegundos, debe moverlo a un hilo separado. No debe bloquear el renderizado. Bloquear el renderizado es muy, muy fácil de hacer y muy difícil de evitar. Pero una regla simple para evitar bloquear el renderizado es cargar solo los recursos que necesita al principio y luego cargar el resto más tarde. Entonces, en
Webpack por ejemplo, puede dividir su script en fragmentos y luego cargar solo los fragmentos importantes primero y luego cargar los otros fragmentos más tarde o según sea necesario. De esta manera, no bloqueará el renderizado de la página. Solo solicitará lo que es necesario al principio. También puede evitar el uso de spinners y en su lugar utilizar esqueletos. Los spinners hacen que los usuarios piensen que su sitio web es lento. Es psicológico. No saben lo que están esperando. Solo saben que están esperando algo. Cuando sea posible, intente usar una barra de progreso en lugar de solo un spinner. El progreso le dice al usuario el progreso real de lo que están esperando para que no se queden en la oscuridad. Use patrones optimistas. Hay muchos recursos en línea que explican lo que esto significa. Cuando usas patrones optimistas, marcas una tarea como completada antes de que realmente se complete. Y solo cuando falla, le dices al usuario que esto ha fallado. Gmail es un muy buen ejemplo de esto. Cuando envías un mensaje, Gmail te dice que el mensaje se ha enviado antes de que el correo se haya enviado. Te hace sentir como si Gmail fuera instantáneo, pero no lo es. No bloquees al usuario. Este es un error muy común. ¿Qué significa bloquear al usuario? Si, por ejemplo, un usuario envía un formulario en tu aplicación y luego muestras un spinner de espera a pantalla completa, diciéndole al usuario que espere hasta que el formulario se envíe antes de que puedan continuar. Esto rompe la experiencia del usuario y hace que el usuario sienta que tu aplicación es más lenta de lo que realmente es. En lugar de hacer esto, puedes mostrar una notificación o puedes permitir al usuario usar otras partes de la aplicación mientras espera que se envíe este formulario. Finalmente, debes tener en cuenta que las expectativas del usuario cambian a menudo mientras están en tu aplicación. La expectativa de un usuario que acaba de llegar a tu aplicación es muy diferente de la expectativa de un usuario que está en la página de pago. Los nuevos usuarios tienen menos paciencia que los usuarios que ya están comprometidos con lo que tienes para ofrecer, así que tenlo en cuenta y esto te ayudará. Muchas gracias por asistir y espero verte nuevamente la próxima vez.
