El rendimiento es la experiencia del usuario: Optimizando el frontend para los usuarios

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,

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.

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.