En la mayoría de los sistemas informáticos, la definición de rendimiento es lo suficientemente clara: hacer más trabajo en menos tiempo con menos recursos. Para una aplicación web frontend, esto rara vez es el caso. Las aplicaciones frontend no solo deben ser eficientes en recursos, sino que también deben "sentirse" eficientes para el usuario. Esto hace que el rendimiento en el frontend sea principalmente un problema de experiencia del usuario.
Únete a mí mientras nos sumergimos en las métricas de rendimiento importantes de una aplicación frontend moderna, cómo medirlas y cómo optimizarlas tanto para la máquina como para el usuario.
This talk has been presented at JSNation 2022, check out the latest edition of this JavaScript Conference.
FAQ
El rendimiento pasivo en el desarrollo de software se refiere a cómo perciben los usuarios la ejecución de una aplicación. Es una medida subjetiva que evalúa si los usuarios sienten que la aplicación funciona bien, independientemente de su rendimiento técnico.
El rendimiento pasivo se puede medir indirectamente observando las tasas de rebote, donde un alto número de rebotes puede indicar que los usuarios perciben la aplicación como lenta o poco satisfactoria.
Para mejorar el rendimiento pasivo se pueden utilizar técnicas como mejorar el tiempo de carga con cachés compartidas, HTTP2, precargar solicitudes importantes y el uso de CDN. También es efectivo el renderizado en el lado del servidor para mostrar contenido inmediatamente.
HTTP2 es un protocolo de red que permite la carga de recursos de manera paralela y más rápida que su predecesor HTTP1. Esto mejora significativamente el rendimiento de los sitios web que manejan muchos recursos como imágenes o archivos CSS y JavaScript.
El uso de spinners puede hacer que los usuarios perciban un sitio web como más lento, ya que solo ven un indicador giratorio sin saber cuánto tiempo tardará la carga. Es recomendable utilizar barras de progreso que muestren el avance real de la carga para mejorar la percepción del usuario.
El renderizado en el lado del servidor implica generar el contenido de una página en el servidor antes de enviarla al navegador. Esto permite que el contenido sea visible inmediatamente para el usuario, mejorando la percepción de rapidez y disminuyendo el tiempo de espera.
Evitar bloquear al usuario significa no detener la interactividad de la aplicación durante operaciones intensivas como la carga o procesamiento de datos. Esto se logra mediante el uso de hilos de trabajo para operaciones pesadas y asegurando que el usuario pueda seguir interactuando con otras partes de la aplicación.
La charla de hoy trata sobre el rendimiento del software y la optimización del frontend para el usuario. Se enfatiza la importancia del rendimiento pasivo, que es una medida subjetiva de cómo los usuarios perciben el rendimiento de la aplicación. Las técnicas para mejorar el rendimiento incluyen el uso de una caché compartida, HTTP2, la precarga de solicitudes y CDN. La optimización del rendimiento del frontend implica evitar el bloqueo del hilo principal, cargar los recursos necesarios primero, utilizar barras de progreso e implementar patrones optimistas. También se destaca la importancia de tener en cuenta las expectativas cambiantes de los usuarios a lo largo de su interacción con la aplicación.
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
Short description:
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
Short description:
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.
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.
Today's Talk discusses the future of performance tooling, focusing on user-centric, actionable, and contextual approaches. The introduction highlights Adi Osmani's expertise in performance tools and his passion for DevTools features. The Talk explores the integration of user flows into DevTools and Lighthouse, enabling performance measurement and optimization. It also showcases the import/export feature for user flows and the collaboration potential with Lighthouse. The Talk further delves into the use of flows with other tools like web page test and Cypress, offering cross-browser testing capabilities. The actionable aspect emphasizes the importance of metrics like Interaction to Next Paint and Total Blocking Time, as well as the improvements in Lighthouse and performance debugging tools. Lastly, the Talk emphasizes the iterative nature of performance improvement and the user-centric, actionable, and contextual future of performance tooling.
I'm Nadia, a developer experienced in performance, re-renders, and React. The React team released the React compiler, which eliminates the need for memoization. The compiler optimizes code by automatically memoizing components, props, and hook dependencies. It shows promise in managing changing references and improving performance. Real app testing and synthetic examples have been used to evaluate its effectiveness. The impact on initial load performance is minimal, but further investigation is needed for interactions performance. The React query library simplifies data fetching and caching. The compiler has limitations and may not catch every re-render, especially with external libraries. Enabling the compiler can improve performance but manual memorization is still necessary for optimal results. There are risks of overreliance and messy code, but the compiler can be used file by file or folder by folder with thorough testing. Practice makes incredible cats. Thank you, Nadia!
PlayCanvas is an open-source game engine used by game developers worldwide. Optimization is crucial for HTML5 games, focusing on load times and frame rate. Texture and mesh optimization can significantly reduce download sizes. GLTF and GLB formats offer smaller file sizes and faster parsing times. Compressing game resources and using efficient file formats can improve load times. Framerate optimization and resolution scaling are important for better performance. Managing draw calls and using batching techniques can optimize performance. Browser DevTools, such as Chrome and Firefox, are useful for debugging and profiling. Detecting device performance and optimizing based on specific devices can improve game performance. Apple is making progress with WebGPU implementation. HTML5 games can be shipped to the App Store using Cordova.
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía). En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también. Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso. (Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Construir aplicaciones web instantáneas a gran escala ha sido elusivo. Los sitios del mundo real necesitan seguimiento, análisis y interfaces y interacciones de usuario complejas. Siempre comenzamos con las mejores intenciones pero terminamos con un sitio menos que ideal. QwikCity es un nuevo meta-framework que te permite construir aplicaciones a gran escala con un rendimiento de inicio constante. Veremos cómo construir una aplicación QwikCity y qué la hace única. El masterclass te mostrará cómo configurar un proyecto QwikCity. Cómo funciona el enrutamiento con el diseño. La aplicación de demostración obtendrá datos y los presentará al usuario en un formulario editable. Y finalmente, cómo se puede utilizar la autenticación. Todas las partes básicas para cualquier aplicación a gran escala. En el camino, también veremos qué hace que Qwik sea único y cómo la capacidad de reanudación permite un rendimiento de inicio constante sin importar la complejidad de la aplicación.
- Introducción- Prerrequisitos para la masterclass- Estrategias de obtención: fundamentos- Estrategias de obtención – práctica: API de obtención, caché (estática VS dinámica), revalidar, suspense (obtención de datos en paralelo)- Prueba tu construcción y sírvela en Vercel- Futuro: Componentes de servidor VS Componentes de cliente- Huevo de pascua de la masterclass (no relacionado con el tema, destacando la accesibilidad)- Conclusión
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Veía una interacción lenta, probaba una optimización aleatoria, veía que no ayudaba, y seguía probando otras optimizaciones hasta que encontraba la correcta (o se rendía). En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Hacía una grabación en Chrome DevTools o React Profiler, la examinaba, intentaba hacer clic en cosas al azar, y luego la cerraba frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también. Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos cómo analizar cualquier problema de rendimiento de React, paso a paso. (Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, cubriremos el rendimiento de interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js es un marco convincente que facilita muchas tareas al proporcionar muchas soluciones listas para usar. Pero tan pronto como nuestra aplicación necesita escalar, es esencial mantener un alto rendimiento sin comprometer el mantenimiento y los costos del servidor. En este masterclass, veremos cómo analizar el rendimiento de Next.js, el uso de recursos, cómo escalarlo y cómo tomar las decisiones correctas al escribir la arquitectura de la aplicación.
Acabas de llegar a una página web y tratas de hacer clic en un elemento en particular, pero justo antes de hacerlo, se carga un anuncio encima y terminas haciendo clic en eso en su lugar. Eso... eso es un cambio de diseño. Todos, tanto los desarrolladores como los usuarios, saben que los cambios de diseño son malos. Y cuanto más tarde ocurran, más interrupciones causarán a los usuarios. En este masterclass vamos a analizar cómo las fuentes web causan cambios de diseño y explorar algunas estrategias para cargar fuentes web sin causar grandes cambios de diseño. Tabla de contenidos:¿Qué es CLS y cómo se calcula?¿Cómo las fuentes pueden causar CLS?Estrategias de carga de fuentes para minimizar CLSRecapitulación y conclusión
Comments