Entre SolidJS, Qwik y React, ha habido una importante innovación en el panorama del desarrollo frontend. Mrina Sugosh, Gerente de Relaciones de Desarrollo @ CK, tiene como objetivo unirlo todo y ayudar a los desarrolladores de React a adoptar enfoques modernos. Esta charla está diseñada para ofrecer ideas valiosas a los desarrolladores interesados en navegar por las tendencias del front-end y tomar decisiones tecnológicas bien informadas para sus proyectos.
This talk has been presented at React Summit 2024, check out the latest edition of this React Conference.
La charla de hoy explora los modernos frameworks de front-end React, SolidJS y Quick. La popularidad de React se atribuye a su arquitectura basada en componentes y su extenso ecosistema. SolidJS se distingue por su reactividad detallada, uso eficiente de la memoria y API amigable para los desarrolladores. Quick (QUIC) se destaca por sus tiempos de carga rápidos, capacidad de reanudación, renderizado en el lado del servidor y priorización de la experiencia del desarrollador. La función de carga bajo demanda de QUIC mejora el tiempo de carga inicial de la página al posponer la ejecución de código no crítico.
Hola a todos. Hoy vamos a hablar sobre la navegación de las innovaciones modernas en el front-end y algunos frameworks: React, Solid y Quick. Soy Renessa Ghosh, una defensora del desarrollo en CKDedder. Vamos a repasar rápidamente estos frameworks y discutir sus características y beneficios únicos.
Hola a todos. Soy Renessa Ghosh. Soy una defensora del desarrollo en CKDedder, y hoy vamos a hablar sobre la navegación de las innovaciones modernas en el front-end y lo que eso significa en este mundo de frameworks en constante cambio. Específicamente, vamos a hablar sobre algunos frameworks, React, Solid y Quick. Pero antes de eso, déjenme contarles un poco más sobre mí. Como dije, soy Renessa Ghosh. Soy desarrolladora y también especialista en marketing. Comencé mi carrera en IBM Cloud como ingeniera full-stack. Luego pasé al marketing para desarrolladores en DigitalOcean, y ahora soy desarrolladora en CKEdder. Si no recuerdan nada sobre mí, solo recuerden que me encanta viajar, y el país al que viajé más recientemente fue Islandia. Así que basta de hablar de mí.
La charla de hoy. La charla de hoy es una charla rápida, así que vamos a pasar rápidamente por tres cosas diferentes. React, vamos a hablar sobre ese poderoso ecosistema que todos conocemos y amamos, ¿verdad? Toda esta cumbre se llama Cumbre de React. Luego vamos a hablar sobre Solid.js. Redefinió esta cosa llamada reactividad, una reactividad detallada. Vamos a hablar un poco sobre eso, y luego vamos a hablar sobre Quick.js, donde la gran innovación de ese framework fue optimizar los tiempos de carga iniciales. Era un problema enorme que resolvieron. Y finalmente, vamos a decir cuál es la mejor decisión para tu proyecto. Y te voy a dar un poco de un framework para comenzar. Así que empecemos.
2. React y SolidJS
Short description:
React es más que una simple biblioteca, es todo un ecosistema. Tiene una arquitectura basada en componentes, un DOM virtual y un ecosistema extenso y en constante evolución. La popularidad de React se debe a su amplia adopción, soporte de la comunidad, integración con herramientas modernas y características avanzadas como el modo concurrente. SolidJS, al igual que React, tiene una reactividad detallada como una de sus grandes características.
React, definitivamente es más que una simple biblioteca hoy en día. Es todo un ecosistema. ¿Verdad? Ha estado a la vanguardia del desarrollo front-end, según mi opinión, durante años, desde que recuerdo el desarrollo front-end. Y las cosas que realmente lo destacan son estas cosas como el DOM virtual y la arquitectura basada en componentes, innovaciones realmente importantes para su tiempo. Así que hay seis cosas que creo que hacen que React se destaque, la arquitectura basada en componentes. La forma en que React está diseñado realmente gira en torno a componentes reutilizables, lo que facilita la gestión y escalabilidad de estas aplicaciones grandes. El DOM virtual, eso es bastante genial porque utiliza esta representación virtual del DOM en lugar de interactuar directamente con el DOM como lo hacen tus típicos HTML y JS, lo que le permite actualizar eficientemente la interfaz de usuario solo volviendo a renderizar los componentes que realmente necesitas, ¿verdad? Y finalmente, lo que hace es tener este ecosistema extenso o en constante evolución, como quieras llamarlo. Desde soluciones como Redux hasta Mobex, React Router e incluso cosas como Create React App, que por supuesto ahora está degradado, y Next.js para el renderizado en el lado del servidor, este ecosistema está en constante evolución y es tan vasto y versátil que prácticamente cualquier problema que puedas tener con cualquier tipo de aplicación web ya ha sido resuelto por la comunidad o por los mantenedores de React.
Entonces eso me lleva a esta amplia adopción y al soporte de la comunidad. La popularidad de React realmente se ha derivado del hecho de que tiene una comunidad tan grande y un ecosistema rico en bibliotecas y herramientas. La adopción es tan grande y la comunidad proporciona tantos recursos y apoyo, desde proyectos de código abierto hasta soporte profesional, que realmente mejoran la productividad y el aprendizaje de los desarrolladores. Y luego, hay algunas cosas como la integración con herramientas modernas. No es solo este antiguo framework que se queda en el fondo. Hoy en día, React se integra con Next.js y ofrece una solución integral con herramientas como Vite, por ejemplo. ¿Verdad? Así que realmente se integra en tus herramientas modernas y, por supuesto, mira hacia el futuro. Creo que hubo esta nueva función llamada modo concurrente, que permite que React prepare múltiples versiones de la interfaz de usuario al mismo tiempo, que son cosas muy nuevas y geniales que están sucediendo en React. Así que es un gran framework, ¿verdad? Y quiero asegurarme de decirlo aquí. Y veamos un ejemplo de cómo suele verse un componente en React. Tienes un componente de función, tienes una visualización de tiempo aquí, que es solo un contador que actualiza los segundos. Y aquí tengo tiempo y establecer tiempo, y lo mantiene actualizado con la fecha actual. Y 1000 me dice que cada segundo quiero actualizar mi tiempo y establecer el tiempo a la nueva fecha y luego seguir borrando el intervalo mientras hago esto. Y luego lo pongo en un div, ese fragmento de código, y listo. ¿Verdad? Y esto parece muy simple, pero lo que realmente estamos haciendo aquí es manejar estos datos dinámicos, como el tiempo, de manera muy eficiente simplemente colocándolos en esta función, conectándolos con el estado y dejándolos funcionar. Eso es realmente poderoso. Lo que acabamos de hacer es un fragmento de código y lógica muy simple, pero la separación de responsabilidades y la capacidad de manejar estos datos dinámicos de manera eficiente es realmente lo que distingue a React. Ahora, pensemos en SolidJS, ¿verdad? Acabamos de hablar de React y lo genial que es. SolidJS está ganando rápidamente popularidad, ya sea en Reddit, Twitter, en todas partes. Y honestamente, en mi opinión, es muy similar a React, porque adopta este modelo reactivo que difiere de React, pero el código se ve muy similar, ¿verdad? Entonces, ¿qué hace que esto sea genial? Estas son las seis cosas. Para SolidJS, hay algo llamado
3. Características de SolidJS
Short description:
SolidJS opera en un sistema de reactividad detallada, evitando renderizados innecesarios. Elimina el DOM virtual, lo que resulta en menos sobrecarga, actualizaciones más rápidas y uso eficiente de la memoria. El compilador optimiza el seguimiento de dependencias y la reactividad de los componentes, reduciendo la sobrecarga en tiempo de ejecución. SolidJS también tiene una API amigable para los desarrolladores, un ecosistema en constante evolución y es adecuado para aplicaciones de alto rendimiento y grandes.
Reactividad detallada. Hablé de esto al principio. Ahora profundizaré en ello. A diferencia de los frameworks más grandes que utilizan un DOM virtual, como React, SolidJS realmente opera en este sistema de reactividad detallada, por lo que realiza un seguimiento de los cambios a nivel de cada pieza de estado, lo que te permite actualizar la UI de manera precisa y evitar estos renderizados innecesarios, en mi opinión. Luego, el hecho de que SolidJS simplemente elimine el DOM virtual, dice, no lo necesitamos, ¿verdad? Es una gran diferencia con los frameworks como React. Entonces, mantiene un código que se ve muy similar, y lo veremos más adelante, pero elimina el DOM virtual. Por lo tanto, hay menos sobrecarga, actualizaciones más rápidas, y un uso más eficiente de la memoria. Y no estamos hablando de esto en términos que puedas darte cuenta en tu experiencia diaria, pero reduce mucha sobrecarga. Y luego, optimizaciones compiladas. El compilador de SolidJS optimiza el seguimiento de dependencias y la reactividad de los componentes durante la fase de compilación, por lo que gran parte de la lógica de reactividad se resuelve en tiempo de compilación, lo que significa que en tiempo de ejecución, en realidad tienes menos sobrecarga. Esto también es ligeramente diferente a cómo funciona React. Y luego, algunas otras cosas. Tiene una API amigable para los desarrolladores. Tiene
4. SolidJS y QUIC
Short description:
SolidJS es adecuado para aplicaciones de alto rendimiento y grandes. QUIC se destaca por lograr tiempos de carga rápidos sin sacrificar funcionalidad. Tiene capacidad de reanudación, renderizado en el lado del servidor, entrega incremental y optimización para SEO y rendimiento. QUIC también prioriza la experiencia del desarrollador y la mantenibilidad.
un ecosistema en constante evolución. Muchas personas lo han adoptado. Y en cuanto a los casos de uso y escalabilidad, es muy liviano y eficiente, lo que lo hace muy adecuado para estas aplicaciones de alto rendimiento y aplicaciones grandes. Veamos cómo se ve el código de SolidJS. Aquí podemos ver el sistema reactivo de SolidJS en acción. La función createSignal crea una señal reactiva para la matriz de elementos. Entonces, cuando se llama a la función addItem, solo los componentes que realmente dependen de los elementos se volverán a renderizar. Esto es el seguimiento preciso de Solid. Solo estamos escribiendo un código que creemos que es lo mismo y que establece los mismos elementos y todo eso, pero solo los componentes específicos y que dependen de la matriz de elementos se actualizarán. Y eso es bastante significativo porque no estás cambiando mucho desde una perspectiva de código, pero quería que vieras cómo esto puede cambiar y evolucionar y realmente hacerlo muy bueno incluso para el renderizado dinámico de listas. Ok. Pasemos a QUIC. QUIC es probablemente el contendiente más nuevo de estos tres frameworks, pero es realmente genial porque está diseñado para abordar uno de los aspectos más desafiantes del desarrollo web moderno. Y eso es lograr tiempos de carga rápidos sin sacrificar funcionalidad. Entonces, ¿qué significa eso? Bueno, aquí hay seis cosas que hacen que QUIC se destaque de los otros frameworks. Capacidad de reanudación, ¿verdad? QUIC tiene la capacidad de serializar y deserializar el estado de la aplicación, lo que permite pausar y reanudar los componentes exactamente donde se quedaron. Como un video, pero mejor. Esta capacidad asegura que solo se carguen y ejecuten el código y los datos absolutamente necesarios, lo que contribuye significativamente a esos tiempos de carga iniciales. Luego está el renderizado en el lado del servidor, ¿verdad? Pero es un poco diferente. Por eso tengo esa estrella allí. A diferencia del SSR tradicional, QUIC optimiza la entrega enviando un HTML mínimo y un código mínimo necesario para que la página sea interactiva. Y las funcionalidades adicionales, incluidas las funciones, solo se cargan según sea necesario, lo cual es un gran avance en comparación con las soluciones de SSR tradicionales de hoy en día. Luego tiene esta cosa llamada entrega incremental. Está basado en el concepto de reanudación que acabamos de mencionar, lo que permite a QUIC ofrecer entrega incremental tanto para la carga inicial de la página, creo, como para el estado. Esto significa que después de la carga inicial de la página, cualquier interacción adicional puede cargar dinámicamente más características y datos según la demanda, adaptándose al recorrido real del usuario con la aplicación. Y finalmente, QUIC, que se destaca, se optimiza para SEO y rendimiento. Muchos creadores de contenido y cualquier persona que quiera que su sitio web sea descubierto pueden emocionarse con esto, porque realmente asegura que los motores de búsqueda puedan llamar e indexar su contenido eventualmente, lo cual es crucial para el SEO. Y si alguno de nosotros ha trabajado con contenido, sabemos lo importante que es que nuestro sitio esté ahí fuera. Y luego, por supuesto, al igual que los otros frameworks, tiene experiencia del desarrollador y mantenibilidad que son igualmente
5. QUIC's On-Demand Loading
Short description:
La carga bajo demanda de QUIC mejora el tiempo de carga inicial de la página al posponer la ejecución de código no crítico en lugar de la carga inicial de la página.
importante. Un fragmento rápido de código de cómo se ve QUIC. En este ejemplo, podemos ver que es muy similar. Tienes este use store, así como un componente que obtienes del constructor de QUIC. Y lo que quiero señalar es que, si observas el controlador de clics, hay este signo de dólar , ¿verdad? Que estás trayendo el componente signo de dólar, que es lo que has traído. Y lo que esa sintaxis, ese signo de dólar le dice al compilador de QUIC es que esta función, state.count plus plus, o cualquier función que le siga, solo se cargará y ejecutará cuando el usuario haga clic en el botón. Entonces, honestamente, cuando cargas la página, esa función, en realidad, esa parte de JavaScript no existe. Entonces, imagina en una aplicación a mayor escala, la cantidad de botones y la cantidad de pequeñas piezas de lógica que están ahí, pero que realmente no necesitas cargar al principio. Entonces, este tipo de carga bajo demanda mejora el tiempo de carga inicial de la página, porque estás posponiendo toda esta ejecución de código no crítico, en lugar de la carga inicial de la página. Lo cual creo que es una innovación tan genial de QUIC. Entonces, decisiones. ¿Cómo eliges entre todos estos frameworks? Bueno, vamos a compararlos en una matriz de decisiones. En mi opinión, estas son tres cosas importantes cuando evalúas un framework para un proyecto de ingeniería de software. Rendimiento, tamaño del paquete y experiencia del desarrollador. Rendimiento, porque quieres saber qué te dará los tiempos de carga más rápidos para tus usuarios, si eso es lo que es importante para ti. ¿Verdad? Y los tres frameworks, honestamente, tienen un alto rendimiento. Pero React, como mencioné, debido a su DOM virtual, tiene mucho sobrecarga. Es alto, pero no es muy alto en comparación con Solid y QUIC. Solid, por supuesto, debido a su sistema de reactividad, tiene un rendimiento muy alto. Y QUIC es extremadamente alto simplemente porque tiene carga bajo demanda, y no se puede competir con la carga bajo demanda. Luego tienes el tamaño del paquete. Si miras React, el tamaño puede variar mucho dependiendo de la complejidad de la aplicación y cosas así. Entonces, es una aplicación de tamaño relativamente bueno que terminarás teniendo, especialmente si descargas muchas bibliotecas. SolidJS es en realidad bastante bajo. Solo produce paquetes más pequeños porque... Um... Sí, solo produce paquetes más pequeños, porque elimina la necesidad de un DOM virtual, por lo que no necesitas muchas bibliotecas que expliquen cómo comunicarse con eso. Y luego QUIC, por supuesto, su objetivo principal es tener el tamaño de carga inicial más pequeño posible, y solo carga el código necesario en tiempo de ejecución, lo que reduce drásticamente el tamaño del paquete. Y luego, en términos de experiencia del desarrollador, diría que, debido a que React es tan antiguo, tan popular, tiene la mejor experiencia del desarrollador, simplemente debido a este enorme ecosistema, en comparación con Solid y QUIC. En última instancia, creo que si miras todos estos frameworks, a primera vista, podrías pensar, okay, QUIC es mi opción porque me brinda un alto rendimiento y un tamaño de paquete bajo. Pero eso no es realmente cierto, porque como señalé, hay algunas peculiaridades y una pequeña curva de aprendizaje cuando se trata de QUIC y la documentación y la comunidad. Es tan nuevo que si te encuentras con algunos problemas de ingeniería más grandes, es posible que aún no se hayan resuelto. Es posible que los estés resolviendo tú. Y realmente necesitas determinar si tu equipo tiene el tiempo para resolverlos. Entonces, es rápido, es eficiente, pero la comunidad aún está creciendo, y eso es lo mismo para Solid JS. En última instancia, debes decidir qué funciona mejor para ti y tu proyecto. Entonces, finalmente, mis últimas palabras de sabiduría y pensamientos en torno a esto es simplemente abrazarinnovación y el desarrollo front-end, porque eso va a suceder mensualmente. Y con IA, no puedo imaginar lo que va a suceder con el mundo del front-end. Y solo estoy emocionado por lo que esa innovación va a traer. Y finalmente, si te llevas algo, simplemente recuerda que todas estas palabras de moda y tecnologías vendrán hacia ti, pero la mejor tecnología es aquella que resolverá tu problema específico de manera muy eficiente y efectiva. Gracias, ¿alguna pregunta?
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