Comparación de rendimiento de componentes React: Gravity UI vs otras bibliotecas

Soy desarrollador core de Gravity UI, y periódicamente en el equipo recibimos preguntas sobre el rendimiento de los componentes React de nuestra biblioteca @gravity-ui/uikit. Decidí hacer un pequeño estudio sobre este tema, y todo lo escrito a continuación es un punto de partida para futuras investigaciones y un intento de responder a la pregunta de por qué Gravity va lento.

Normalmente esta solicitud se escribe sin detalles adicionales, así que parto de la suposición de que uno de los principales problemas de rendimiento (aunque, por supuesto, no el único) es un tiempo de renderizado largo. En el marco de este estudio analizamos el coste del primer renderizado de componentes individuales de cada biblioteca en un entorno aislado. Para la comparación se eligieron las bibliotecas @adobe/react-spectrum, @mui/material y antd.

Metodología del estudio

Stack técnico:

• Playwright — framework para automatizar pruebas en distintos navegadores.
  Más información
• PerformanceObserver API — API del navegador para medir el rendimiento.
  Más información

Condiciones de ejecución de las pruebas:

• Cada prueba se ejecuta en un contexto de navegador independiente.
• Solo se ejecuta una prueba a la vez (configuración workers en el config de Playwright), lo que garantiza la asignación de la misma cantidad de recursos a cada prueba.
• Cada prueba se repite 50 veces.
• Las pruebas se realizan con diferente número de nodos (10, 100, 1000).

Orden de ejecución de una prueba:

• Abrir una nueva página en el navegador.
• Inicializar PerformanceObserver.
• Iniciar la recopilación de métricas.
• Renderizar los componentes.
• Finalizar la recopilación de métricas.

Proceso de medición:

Al inicio de cada prueba se crea un PerformanceObserver que rastrea eventos del tipo 'measure'. Todas las métricas recopiladas se guardan en el objeto global __PERFORMANCE_METRICS__. El observer recopila automáticamente datos sobre el tiempo de ejecución de las operaciones, incluido el nombre de la métrica, el tipo de evento, la hora de inicio y la duración. Mediante el evento measure registramos nuestra medición total-render-time.

Resultados

Los resultados de las mediciones no contienen cifras absolutas. De un entorno a otro, por supuesto, pueden variar. Pero estas cifras son más que suficientes para ver algunas dependencias y, basándose en ellas, sacar conclusiones:

• @gravity-ui/uikit muestra resultados competitivos:

  • En la mayoría de las pruebas se sitúa en la parte alta del ranking.
  • Demuestra un tiempo de renderizado estable con diferente número de nodos.
  • Es especialmente eficiente en los componentes Button, Checkbox y Switch.
  • Tiene problemas con el tiempo de renderizado del componente TextArea.

• @mui/material también muestra buenos resultados:

  • Lidera en casi todas las categorías (por ejemplo, Text, Label) con un número pequeño de nodos.
  • Presenta un aumento visible del tiempo de renderizado en función del número de nodos.

• antd y React Spectrum:

  • Muestran un tiempo de renderizado más alto en la mayoría de las pruebas.
  • Tienen una mayor dispersión entre el tiempo mínimo y el máximo.

Con esta herramienta se pueden realizar mediciones de rendimiento en tu máquina local y también añadir pruebas para componentes que aún no existen. Nos será de ayuda si la despliegas por tu cuenta y envías en un PR el resultado obtenido en tu ordenador.

En este artículo he mostrado uno de los ejemplos de cómo trabajamos con la biblioteca. Pero para nosotros es muy importante el feedback de la comunidad: si tienes un ejemplo concreto en el que Gravity UI se comporta mucho peor que otras bibliotecas, o si ves un error en nuestra metodología de pruebas, ven a los comentarios de este post o crea un issue; lo discutimos. ¡Y no olvides darle estrellas al proyecto!