Rendimiento de pantallas con uso intensivo de jQuery

Buscando estresar la aplicación para detectar pérdida de rendimiento

Realizando las primeras pruebas de carga sobre el sistema GIN con consultas sobre un colección de entre 50.000 y 100.000 elementos ha emergido una problemática que no era esperada: Además de la esperada caída de rendimiento de la base de datos (es lo que se buscaba, para diseñar el sistema de índices), se ha visto que la cantidad de datos a mostrar influye enormemente. Concretamente no el extraerlos, sino el dibujarlos en pantalla.

tiempos redibujar

Dibujar mucho con jQuery es lento

Si bien el tiempo de traerse 10 o 20 filas ocupaba 30ms de base de datos mongoDb, al aumentar a 500 filas es normal que se dispare a 400ms. En cambio, el tiempo desde que se recibían los datos del servidor hasta que se mostraba al usuario los resultados en pantalla es desorbitado.

La pantalla problemática es una típica con filtros de búsqueda y resultados, de la que se permite mostrar hasta 500 resultados en pantalla. Este es el aspecto con 10 filas a la vez. Nada especial.

pantalla principal

Al llegar los datos del servidor, éstos se procesan pero tampoco se aplica una lógica que justifique los más de dos segundos.

Un análisis más profundo muestra que el 95% del tiempo que consume el cliente (el navegador) se destina a operaciones jQuery de dibujado de pantalla. En el diseño original el grid se borraba y dibujaba de nuevo a cada refresco: layers, tablas, filas, celdas, etc… y esto es una operación sumamente costosa. Se puede observar como una simple operación de utilizar un selector y cambiar un atributo (el típico $(‘#idControl’).val(‘checked’, ‘true’) ) ya consume  milisegundos. La creación de un nodo, su inserción y el cálculo de estilos posterior es sumamente costos. Si para dibujar 500 filas estamos realizando esta operación varios miles de veces entonces hemos explicado la lentitud (dibujar cara fila gasta entre 2,5 y 5 milisegundos).

En este detalle se observa como prácticamente todo el tiempo se consume con jQuery creando y poniendo nodos (las flechas). Los cálculos que se realizan sobre la lógica y datos ni aparecen.

renderrow

Soluciones

Hay muchas páginas con pequeños trucos sobre como optimizar aplicaciones jQuery (lazy load de scripts, usar detach al modificar un nodo, usar ‘css’ en lugar de ‘width’ o ‘height’, evitar acceder propiedades de estilo de elementos dibujados porque es costoso y guardarlos calculados, etc…) pero en este caso solo obtendriamos pequeñas mejoras.

El problema principal es que a cada refresco se borra todo y se vuelve a dibujar. La tabla y todas sus filas no deberían borrarse sino “reciclarse” y modificar su contenido y ocultarse cuando no se hayan de ver. Esto es aplicable a todas las aplicaciones HTML, pero lo que mucha gente acostumbra a hacer es un $(‘idLayer’).empty() a la primera de cambio. En breve compartiremos el resultado de este gran cambio a la hora de renderizar las pantallas.

En resumen: dibujar con jQuery es muy costoso: pues dibujemos lo menos posible.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.