radEventListener: una historia sobre el rendimiento del marco del lado del cliente
React es popular, lo suficientemente popular como para recibir una buena cantidad de críticas. Sin embargo, esta crítica a React no es completamente injustificada: React y ReactDOM suman alrededor de 120 KiB de JavaScript minificado, lo que definitivamente contribuye a un tiempo de inicio lento. Cuando se confía completamente en la renderización del lado del cliente en React, se agita. Incluso si renderiza componentes en el servidor y los hidrata en el cliente, todavía se agita porque la hidratación de componentes es computacionalmente costosa.
React ciertamente tiene su lugar cuando se trata de aplicaciones que requieren una administración de estado compleja, pero en mi experiencia profesional, no pertenece a la mayoría de los escenarios en los que veo su uso. Cuando incluso un poco de React puede ser un problema tanto en dispositivos lentos como rápidos, su uso es una elección intencional que efectivamente excluye a las personas con hardware de gama baja.
Si parece que le tengo rencor a React, entonces debo confesar que me gusta mucho su modelo de componenteización. Facilita la organización del código. Creo que JSX es genial. La renderización del también servidor es genial, incluso si así es como decimos “enviar HTML a través de la red” hoy en día.
Aún así, aunque use felizmente los componentes de React en el servidor (o Preact, como es mi preferencia), determinar cuándo es apropiado usarlos en el cliente es un poco desafiante. Lo que sigue son mis hallazgos sobre el rendimiento de React mientras intentaba enfrentar este desafío de la mejor manera para los usuarios.
Preparando la escena
Últimamente, está trabajando en un proyecto paralelo de una aplicación de alimentación RSS llamada bylines.fyi. Esta aplicación utiliza JavaScript tanto en la parte posterior como en la frontal. No creo que los marcos del lado del cliente sean cosas horribles, pero con frecuencia observó dos cosas acerca de las implementaciones de marcos del lado del cliente con las que suelo encontrarme en mi trabajo e investigación diarios:
- Los marcos tienen el potencial de inhibir una comprensión más profunda de las cosas que abstraen, que es la plataforma web. Sin conocer al menos algunas de las API de nivel inferior en las que se basan los marcos, no podemos saber qué proyectos se benefician de un marco y qué proyectos están mejores sin uno.
- Los marcos no siempre proporcionan un camino claro hacia buenas experiencias de usuario.
Quizás puedas argumentar la validez de mi primer punto, pero el segundo cada vez es más difícil de refutar. Quizás recuerdes hace un tiempo cuando Tim Kadlec investigó un poco en HTTPArchive sobre el rendimiento del marco web y llegó a la conclusión de que React no tenía exactamente un desempeño estelar.
Aún así, quería ver si era posible usar lo que pensaba que era mejor de React en el servidor y al mismo tiempo mitigar sus efectos nocivos en el cliente. Para mí, tiene sentido querer utilizar simultáneamente un marco para ayudar a organizar mi código, pero también restringir el impacto negativo de ese marco en la experiencia del usuario. Eso requirió un poco de experimentación para ver qué enfoque sería mejor para mi aplicación.
El experimento
Me aseguro de representar todos los componentes que uso en el servidor porque creo que la carga de proporcionar marcado debe ser asumida por el servidor de la aplicación web, no por el dispositivo del usuario. Sin embargo, necesitaba algo de JavaScript en mi aplicación de fuente RSS para que funcionara una navegación móvil alternativa.
Este escenario describe con certeza lo que yo llamo estado simple. En mi experiencia, un excelente ejemplo de estado simple son las interacciones lineales de A a B. Activamos una cosa y luego la desactivamos. Con estado, pero simple.
Desafortunadamente, a menudo veo componentes de React con estado utilizados para administrar estados simples, lo cual es una compensación que es problemática para el rendimiento. Aunque por el momento puede parecer una afirmación vaga, lo descubrirás a medida que sigas leyendo. Dicho esto, es importante enfatizar que este es un ejemplo trivial, pero también es un canario. Espero que la mayoría de los desarrolladores no dependan únicamente de React para impulsar un comportamiento tan simple para una sola cosa en su sitio web. Por lo tanto, es vital comprender que los resultados que verás tienen como objetivo informarle sobre cómo diseñan sus aplicaciones y cómo los efectos de sus elecciones de marco podrían escalar en lo que respeta al rendimiento en tiempo de ejecución.
Las condiciones
Mi aplicación de alimentación RSS aún está en desarrollo. No contiene códigos de terceros, lo que facilita las pruebas en un entorno silencioso. El experimento que realicé comparó el comportamiento de alternancia de navegación móvil en tres implementaciones:
- Un componente de React con estado (
React.Component) renderizado en el servidor e hidratado en el cliente. - Un componente de Preact con estado, también renderizado en el servidor e hidratado en el cliente.
- Un componente de Preact sin estado renderizado por el servidor que no estaba hidratado. En cambio, los detectores de eventos habituales proporcionan la funcionalidad de navegación móvil al cliente.
Cada uno de estos escenarios se midió en cuatro entornos distintos:
- Un teléfono Nokia 2 con Android en Chrome 83.
- Una computadora portátil ASUS X550CC de 2013 con Windows 10 en Chrome 83.
- Un antiguo iPhone SE de primera generación en Safari 13.
- Un nuevo iPhone SE de segunda generación, también en Safari 13.
Creo que esta gama de hardware móvil será ilustrativa del rendimiento en un amplio espectro de capacidades de dispositivos, incluso si es un poco pesado por parte de Apple.
lo que se midio
Quería medir cuatro cosas para cada implementación en cada entorno:
- Hora de inicio. Para React y Preact, esto incluyó el tiempo que llevó cargar el código del marco, así como hidratar el componente en el cliente. Para el escenario del detector de eventos, esto incluía solo el código del detector de eventos.
- Tiempo de hidratación. Para los escenarios de React y Preact, este es un subconjunto del tiempo de inicio. Debido a problemas con la depuración remota que fallaba en Safari en macOS, no podía medir el tiempo de hidratación solo en dispositivos iOS. Las implementaciones de detectores de eventos no generaron costos de hidratación.
- Tiempo de apertura de navegación móvil. Esto nos da una idea de cuántos marcos generales se introducen en su abstracción de controladores de eventos y cómo se compara con el enfoque sin marco.
- Hora de cierre de navegación móvil. Al final resultó que, esto fue bastante menor que el costo de abrir el menú. Finalmente decidió no incluir esos números en este artículo.
Cabe señalar que las mediciones de estos comportamientos incluyen únicamente el tiempo de programación. Cualquier costo de diseño, pintura y composición sería adicional y fuera de estas medidas. Hay que tener cuidado de recordar que esas actividades compiten por el tiempo del hilo principal junto con los guiones que las desencadenan.
El procedimiento
Para probar cada una de las tres implementaciones de navegación móvil en cada dispositivo, siga este procedimiento:
- Utilicé la depuración remota en Chrome en macOS para Nokia 2. Para iPhones, utilicé el equivalente de Safari a la depuración remota.
- Accedí a la aplicación de fuente RSS que se ejecuta en mi red local en cada dispositivo a la misma página donde se podía ejecutar el código de alternancia de navegación móvil. Debido a esto, el rendimiento de la red no fue un factor en mis mediciones.
- Sin aplicar limitación de CPU o de red, comience a grabar en el generador de perfiles y recargue la página.
- Después de cargar la página, abra la navegación móvil y luego la cerré.
- Detuve el generador de perfiles y registré cuánto tiempo de CPU estuvo involucrado en cada uno de los cuatro comportamientos enumerados anteriormente.
- Borré el cronograma de desempeño. En Chrome, también hice clic en el botón de recolección de basura para liberar cualquier memoria que pudiera haber estado ocupada por el código de mi aplicación de una grabación de sesión anterior.
Repita este procedimiento diez veces para cada escenario y para cada dispositivo. Diez iteraciones parecieron datos suficientes para ver algunos valores atípicos y al mismo tiempo obtener una imagen razonablemente precisa, pero dejaré que usted decida a medida que repasamos los resultados. Si no desea conocer mis hallazgos paso a paso, puede ver los resultados en esta hoja de cálculo y sacar sus propias conclusiones, así como el código de navegación móvil para cada implementación.
Los resultados
Inicialmente quería presentar esta información en un gráfico, pero debido a la complejidad de lo que estaba midiendo, no estaba seguro de cómo presentar los resultados sin saturar la visualización. Por lo tanto, presentará los tiempos de CPU mínimo, máximo, mediano y promedio en una serie de tablas, todas las cuales ilustran efectivamente la variedad de resultados que encontré en cada prueba.
Google Chrome y Nokia 2
El Nokia 2 es un dispositivo Android de bajo coste con procesador ARM Cortex-A7. No es una potencia, sino más bien un dispositivo barato y fácil de conseguir. El uso de Android en todo el mundo ronda actualmente el 40% y, aunque las especificaciones de los dispositivos Android varían mucho de un dispositivo a otro, los dispositivos Android de gama baja no son raros. Este es un problema que debemos reconocer como un problema tanto de riqueza como de proximidad a una infraestructura de red rápida.
Veamos cómo se ven las cifras del costo inicial.
Tiempo de inicio
| Componente de reacción | Componente Preact | código addEventListener | |
|---|---|---|---|
| mín. | 137.21 | 31.23 | 4.69 |
| mediana | 147,76 | 42.06 | 5,99 |
| promedio | 162,73 | 43.16 | 6.81 |
| máx. | 280.81 | 62.03 | 12.06 |
Creo que dice algo que, en promedio, se necesitan más de 160 ms para analizar y compilar React e hidratar un componente. Para recordarle, el costo de inicio en este caso incluye el tiempo que le toma al navegador evaluar los scripts necesarios para que funcione la navegación móvil. Para React y Preact, también incluye el tiempo de hidratación, que en ambos casos puede contribuir al extraño efecto valle que a veces experimentamos durante el inicio.
A Preact le va mucho mejor, ya que tarda alrededor de un 73% menos de tiempo que React, lo que tiene sentido teniendo en cuenta lo pequeño que es Preact a 10 KiB sin compresión. Aún así, es importante tener en cuenta que el presupuesto de cuadros en Chrome es de aproximadamente 10 ms para evitar interferencias a 60 fps. El inicio de Janky es tan malo como cualquier otra cosa y es un factor al calcular el retardo de la primera entrada. Sin embargo, considerando todo, Preact funciona relativamente bien.
En cuanto a la addEventListenerimplementación, resulta que el tiempo de análisis y compilación de un script pequeño sin gastos generales es, como era de esperar, muy bajo. Incluso con el tiempo máximo de muestreo de 12 ms, apenas se encuentra en el anillo exterior del área metropolitana de Janksburg. Ahora echamos un vistazo solo al costo de la hidratación.
Tiempo de hidratación
| Componente de reacción | Componente Preact | |
|---|---|---|
| mín. | 67.04 | 19.17 |
| mediana | 70.33 | 26,91 |
| promedio | 74,87 | 26,77 |
| máx. | 117,86 | 44,62 |
Para React, esto todavía está cerca de Yikes Peak. Claro, un tiempo de hidratación promedio de 70 ms para un componente no es gran cosa, pero piense en cómo aumenta el costo de hidratación cuando tiene varios componentes en la misma página. No sorprende que los sitios web de React que pruebo en este dispositivo parezcan más pruebas de resistencia que experiencias de usuario.
Los tiempos de hidratación de Preact son bastante menores, lo cual tiene sentido porque la documentación de Preact para su método de hidratación indica que “omite la mayoría de las diferencias mientras aún adjunta detectores de eventos y configura su árbol de componentes”. No se informa el tiempo de hidratación para el addEventListenerescenario, porque la hidratación no es algo fuera de los marcos de VDOM. A continuación, echemos un vistazo al tiempo que lleva abrir la navegación móvil.
Tiempo de apertura de navegación móvil
| Componente de reacción | Componente Preact | código addEventListener | |
|---|---|---|---|
| mín. | 30,89 | 11.94 | 3.94 |
| mediana | 43,62 | 14.29 | 6.14 |
| promedio | 43.16 | 14.66 | 6.12 |
| máx. | 53.19 | 20.46 | 8.60 |
Estas cifras me parecen un poco sorprendentes, porque React requiere casi siete veces más tiempo de CPU para ejecutar una devolución de llamada de detector de eventos que un detector de eventos que usted mismo podría registrar. Esto tiene sentido, ya que la lógica de gestión del estado de React es una sobrecarga necesaria, pero uno debe preguntarse si vale la pena para interacciones lineales y simplistas.
Por otro lado, Preact logra limitar su sobrecarga en los detectores de eventos hasta el punto en que se necesita “sólo” el doble de tiempo de CPU para ejecutar una devolución de llamada del detector de eventos.
El tiempo de CPU involucrado en cerrar la navegación móvil fue bastante menor con un tiempo promedio aproximado de 16,5 ms para React, con Preact y los detectores de eventos simples llegando a alrededor de 11 ms y 6 ms, respectivamente. Publicaría la tabla completa de las medidas al cerrar la navegación móvil, pero aún nos queda mucho por examinar. Además, puedes consultar esas cifras tú mismo en la hoja de cálculo a la que me referí anteriormente.
Una nota rápida sobre ejemplos de JavaScript
Antes de pasar a los resultados de iOS, un posible punto conflictivo que quiero abordar es el impacto de deshabilitar las muestras de JavaScript en Chrome DevTools al grabar sesiones en dispositivos remotos. Después de compilar mis resultados iniciales, me pregunté si la sobrecarga de capturar pilas de llamadas enteras estaba sesgando mis resultados, así que volví a probar los ejemplos de escenarios de React desactivados. Al final resultó que, esta configuración no tuvo un impacto significativo en los resultados.
Además, debido a que las pilas de llamadas estaban truncadas, no pude medir el tiempo de hidratación de los componentes. El costo de inicio promedio con muestras deshabilitadas versus muestras habilitadas fue de 160,74 ms y 162,73 ms, respectivamente. Las cifras medianas respectivas fueron 157,81 ms y 147,76 ms. Yo consideraría esto directamente “en el ruido”.
Safari en iPhone SE de primera generación
El iPhone SE original es un gran teléfono. A pesar de su antigüedad, todavía disfruta de una propiedad devota debido a su tamaño físico más cómodo. Se envió con el procesador Apple A9, que sigue siendo un competidor sólido. Veamos cómo le fue en el momento del inicio.
Tiempo de inicio
| Componente de reacción | Componente Preact | código addEventListener | |
|---|---|---|---|
| mín. | 32.06 | 7.63 | 0,81 |
| mediana | 35.60 | 9.42 | 1.02 |
| promedio | 35,76 | 10.15 | 1.07 |
| máx. | 39.18 | 16,94 | 1,56 |
Esta es una gran mejora con respecto al Nokia 2 y es ilustrativa de la brecha entre los dispositivos Android de gama baja y los dispositivos Apple aún más antiguos con un kilometraje significativo.
El rendimiento de React todavía no es excelente, pero Preact nos mantiene dentro de un presupuesto típico para Chrome. Los oyentes de eventos por sí solos, por supuesto, son increíblemente rápidos, lo que deja mucho espacio en el presupuesto marco para otras actividades.
Desafortunadamente, no pude medir los tiempos de hidratación en el iPhone, ya que la sesión de depuración remota fallaba cada vez que recorría la pila de llamadas en DevTools de Safari. Teniendo en cuenta que el tiempo de hidratación fue un subconjunto del costo total de inicio, se puede esperar que probablemente represente al menos la mitad del tiempo de inicio si los resultados de las pruebas de Nokia 2 son un indicador.
Tiempo de apertura de navegación móvil
| Componente de reacción | Componente Preact | código addEventListener | |
|---|---|---|---|
| mín. | 16.91 | 5.45 | 0,48 |
| mediana | 21.11 | 8.62 | 0,50 |
| promedio | 21.09 | 11.07 | 0,56 |
| máx. | 24.20 | 19,79 | 1.00 |
React funciona bien aquí, pero Preact parece manejar los detectores de eventos de manera un poco más eficiente. Los oyentes de eventos básicos son increíblemente rápidos, incluso en este viejo iPhone.
Safari en iPhone SE de segunda generación
A mediados de 2020, compré el nuevo iPhone SE. Tiene el mismo tamaño físico que un iPhone 8 y teléfonos similares, pero el procesador es el mismo Apple A13 usado en el iPhone 11. Es muy rápido para su precio minorista relativamente bajo de $400 USD. Dado un procesador tan robusto, ¿cómo se comporta?
Tiempo de inicio
| Componente de reacción | Componente Preact | código addEventListener | |
|---|---|---|---|
| mín. | 20.26 | 5.19 | 0,53 |
| mediana | 22.20 | 6.48 | 0,69 |
| promedio | 22.02 | 6.36 | 0,68 |
| máx. | 23,67 | 7.18 | 0,88 |
Supongo que en algún momento hay rendimientos decrecientes cuando se trata de la carga de trabajo relativamente pequeña de cargar un solo marco e hidratar un componente. Las cosas son un poco más rápidas en un iPhone SE de segunda generación que en su variante de primera generación en algunos casos, pero no tanto. Me imagino que este teléfono afrontaría cargas de trabajo más grandes y sostenidas mejor que su predecesor.
Tiempo de apertura de navegación móvil
| Componente de reacción | Componente Preact | código addEventListener | |
|---|---|---|---|
| mín. | 13.15 | 12.06 | 0,49 |
| mediana | 16.41 | 12.57 | 0,53 |
| promedio | 16.11 | 12.63 | 0,56 |
| máx. | 17.51 | 13.26 | 0,78 |
Un rendimiento de React ligeramente mejor aquí, pero no mucho más. Curiosamente, Preact parece tardar en promedio más tiempo en abrir la navegación móvil en este dispositivo que su contraparte de primera generación, pero lo atribuiré a valores atípicos que distorsionan un conjunto de datos relativamente pequeño. Ciertamente no asumiría que el iPhone SE de primera generación sea un dispositivo más rápido basado en esto.
Chrome en una computadora portátil con Windows 10 antigua
Es cierto que estos fueron los resultados que más me emocionaba ver: ¿cómo maneja esto una computadora portátil ASUS de 2013 con Windows 10 y un Ivy Bridge i5 de la época?
Tiempo de inicio
| Componente de reacción | Componente Preact | código addEventListener | |
|---|---|---|---|
| mín. | 43.15 | 13.11 | 1.81 |
| mediana | 45,95 | 14.54 | 2.03 |
| promedio | 45,92 | 14.47 | 2.39 |
| máx. | 48,98 | 16.49 | 3.61 |
Las cifras no están mal si se tiene en cuenta que el dispositivo tiene siete años. El Ivy Bridge i5 era un buen procesador en su época, y cuando se combina eso con el hecho de que está enfriado activa (en lugar de pasivamente como lo están los procesadores de dispositivos móviles), probablemente no se encuentre con escenarios de estrangulamiento térmico con tanta frecuencia como los móviles. dispositivos.
Tiempo de hidratación
| Componente de reacción | Componente Preact | |
|---|---|---|
| mín. | 17,75 | 7.64 |
| mediana | 23.55 | 8.73 |
| promedio | 23.12 | 8.72 |
| máx. | 26.25 | 9.55 |
A Preact le va bien aquí, logra mantenerse dentro del presupuesto del marco de Chrome y es casi tres veces más rápido que React. Las cosas podrían verse bastante diferentes si hidrata diez componentes en la página en el momento del inicio, posiblemente incluso en Preact.
Tiempo de apertura de navegación móvil
| Componente Preact | código addEventListener | ||
|---|---|---|---|
| mín. | 6.06 | 2.50 | 0,88 |
| mediana | 10.43 | 3.09 | 0,97 |
| promedio | 11.24 | 3.21 | 1.02 |
| máx. | 14.44 | 4.34 | 1,49 |
Cuando se trata de esta interacción aislada, vemos un rendimiento similar al de los dispositivos móviles de alta gama. Es talentoso ver que una computadora portátil tan antigua aún se mantiene razonablemente bien. Dicho esto, el ventilador de esta computadora portátil gira con frecuencia cuando navega por la web, por lo que el enfriamiento activo es probablemente la salvación de este dispositivo. Si el i5 de este dispositivo se enfría pasivamente, sospecho que su rendimiento podría disminuir.
Pilas de llamadas poco profundas para ganar
No es un misterio por qué React y Preact tardan más en iniciarse que una solución que evita los marcos por completo. Menos trabajo equivale a menos tiempo de procesamiento.
Si bien creo que el tiempo de inicio es crucial, probablemente sea inevitable que cambie cierta cantidad de velocidad por una mejor experiencia de desarrollador. Aunque yo diría enérgicamente que tendemos a cambiar demasiado por la experiencia del desarrollador que por la experiencia del usuario con demasiada frecuencia.
Los dragones también residen en lo que hacemos después de que se carga el marco. Creo que la hidratación del lado del cliente es algo de lo que se abusa con demasiada frecuencia y, a veces, puede ser completamente innecesaria. Cada vez que hidratas un componente en React, esto es lo que estás arrojando al hilo principal:
Recuerde que en el Nokia 2, el tiempo mínimo que medí para hidratar el componente de navegación móvil fue de unos 67 ms. En Preact, para lo cual verá la pila de llamadas de hidratación a continuación, se necesitan unos 20 ms.
Estas dos pilas de llamadas no están en la misma escala, pero la lógica de hidratación de Preact está simplificada, probablemente porque “se omite la mayoría de las diferencias”, como indica la documentación de Preact. Aquí suceden bastante menos. Cuando te acercas al metal utilizando addEventListeneren lugar de una estructura, puedes llegar aún más rápido.
No todas las situaciones requieren este enfoque, pero te sorprendería lo que puedes lograr cuando tus herramientas son addEventListener, querySelector, classList, setAttribute/ getAttribute, etc.
Estos métodos (y muchos más similares) son en los que se basan los propios marcos. El truco consiste en evaluar qué funcionalidad puede ofrecer de forma segura fuera de lo que proporciona el marco y confiar en el marco cuando tenga sentido.
Si se tratara de una pila de llamadas para, por ejemplo, realizar una solicitud de datos de API en el cliente y gestionar el estado complejo de la interfaz de usuario en esa situación, este costo me parecería más aceptable. Sin embargo, no lo es. Simplemente hacemos que aparezca una navegación en la pantalla cuando el usuario toca un botón. Es como usar una topadora cuando una pala sería más adecuada para el trabajo.
Preact al menos llega al término medio:
Preact tarda aproximadamente un tercio del tiempo en hacer el mismo trabajo que hace React, pero en ese dispositivo económico, a menudo excede el presupuesto del marco. Esto significa que abrir esa navegación en algunos dispositivos se animará lentamente porque es posible que el trabajo de diseño y pintura no tenga tiempo suficiente para terminar sin entrar en un territorio de tareas largas.
En este caso, lo que necesitaba era un detector de eventos. Hace el trabajo siete veces más rápido en ese dispositivo económico que React.
Conclusión
Este no es un éxito de React, sino más bien un llamado a considerar cómo hacemos nuestro trabajo. Algunos de estos problemas de rendimiento pueden evitarse si nos preocupamos de evaluar qué herramientas tienen sentido para el trabajo, incluso para aplicaciones con una interactividad muy compleja. Para ser justos con React, es probable que estos errores existan en muchos marcos VDOM, porque su naturaleza agrega la sobrecarga necesaria para administrar todo tipo de cosas por nosotros.
Incluso si está trabajando en algo que no requiere React o Preact, pero desea aprovechar la componenteización, considere mantener todo en el servidor para empezar. Este enfoque significa que puede decidir si es apropiado extender la funcionalidad al cliente y cuándo, y cómo hacerlo.
En el caso de mi aplicación de fuente RSS, puedo gestionar esto colocando un código ligero de escucha de eventos en el punto de entrada de esa página de la aplicación y usando un manifiesto de activos para colocar la cantidad mínima de secuencia de comandos necesaria para que cada página funcione. .
Ahora supongamos que tiene una aplicación que realmente necesita lo que proporciona React. Tienes una interactividad compleja con mucho estado. Aquí hay algunas cosas que puede hacer para intentar que todo vaya un poco más rápido.
- Verifique todos sus componentes con estado (es decir, cualquier componente que se extienda
React.Component) y vea si se pueden refactorizar como componentes sin estado. Si un componente no utiliza métodos o estado de ciclo de vida, puede refactorizarlo para que no tenga estado. - Luego, si es posible, evite enviar JavaScript al cliente para esos componentes sin estado, así como hidratarlos. Si un componente no tiene estado, solo renderícelo en el servidor. Preprocesar los componentes cuando sea posible para minimizar el tiempo de respuesta del servidor, porque el renderizado del servidor tiene sus propios problemas de rendimiento.
- Si tiene un componente con estado con interactividad simple, considere prerenderizar/renderizar ese componente en el servidor y reemplazar su interactividad con detectores de eventos independientes del marco. Esto evita por completo la hidratación y las interacciones del usuario no tendrán que filtrarse a través de la lógica de gestión de estado del marco.
- Si debe hidratar componentes con estado en el cliente, considere hidratar lentamente los componentes que no están cerca de la parte superior de la página. Un Intersection Observer que activa una devolución de llamada funciona muy bien para esto y dará más tiempo al hilo principal para los componentes críticos de la página.
- Para los componentes lentamente hidratados, evalúe si puede programar su hidratación durante el tiempo de inactividad del hilo principal con
requestIdleCallback. - Si es posible, considere cambiar de React a Preact. Dado que se ejecuta mucho más rápido que React en el cliente, vale la pena conversar con su equipo para ver si esto es posible. La última versión de Preact es casi 1:1 con React para la mayoría de las cosas y
preact/compathace un gran trabajo al facilitar esta transición. No creo que Preact sea una panacea para el rendimiento, pero te acerca a donde necesitas estar. - Considere adaptar su experiencia a usuarios con poca memoria en el dispositivo.
navigator.deviceMemory(disponible en Chrome y navegadores derivados) le permite cambiar la experiencia de usuario para usuarios en dispositivos con poca memoria. Si alguien tiene un dispositivo así, es probable que su procesador tampoco sea tan rápido.
Independientemente de lo que decida hacer con esta información, la esencia de mi argumento es la siguiente: si utiliza React o cualquier biblioteca VDOM, debería dedicar algún tiempo a investigar su impacto en una variedad de dispositivos. Obtenga un dispositivo Android económico y vea cómo se siente su aplicación al usarla. Compara esa experiencia con tus dispositivos de alta gama.
Sobre todo, no siga las “mejores prácticas” si el resultado es que su aplicación excluye efectivamente a una parte de su audiencia que no puede permitirse dispositivos de alta gama. Sigue presionando para que todo sea más rápido. Si nuestro trabajo diario sirve de indicación, este es un esfuerzo que los mantendrá ocupados durante algún tiempo, pero está bien. Hacer que la web sea más rápida la hace más accesible en más lugares. Hacer que la web sea más accesible hace que la web sea más inclusiva. Ese es el trabajo realmente bueno que todos deberíamos hacer lo mejor que podamos.
Me gustaría expresar mi gratitud a Eric Bailey por sus comentarios editoriales sobre este artículo, así como al personal de CSS-Tricks por su disposición a publicarlo.
Deja un comentario