Guía de rendimiento

El renderizado rápido comienza antes de Canvas2D. Mantenga los datos columnarios, transfiéralos una sola vez, evite la decodificación en el main thread y permita que el gráfico represente solo lo visible.

Comience con la autoselección de worker y la política LOD por defecto, luego mida la carga real. Use el LOD calibration lab antes de cambiar densidad, ratio de rebasing o cuantización.

Pipeline de carga recomendado

1. Muestre una vista previa pequeña que preserve los extremos cuando la latencia del primer fotograma importe.
2. Inicie la descarga en red y la decodificación en un data worker dedicado.
3. Lea solo las columnas y rangos necesarios desde un formato columnario.
4. Valide longitudes alineadas, X ordenada y finita, unidades y huecos declarados.
5. Transfiera las columnas tipadas al renderizador de gráficos una vez.
6. Termine el data worker tras la transferencia para que no conserve otra copia.

Para lecturas HTTP por rangos, asegúrese de que el host estático soporte byte ranges y que los caches intermedios los conserven. Una caída al modo descarga completa correcta aún puede ser demasiado costosa para usuarios móviles.

Mantenga el bundle inicial pequeño

• Importe dinámicamente decodificadores de datos pesados y demos opcionales.
• Monte solo el gráfico actualmente visible o seleccionado.
• No envíe datos de demostración de varios millones de filas a una landing page solo para demostrar que el renderizador puede aceptarlos.
• Mantenga los catálogos de temas y ejemplos secundarios fuera de la ruta protegida del primer fotograma.
• Prefiera ejemplos curados o adaptativos en dispositivos limitados y enlace a un workbench completo.

Elija el modo worker

Use renderMode: "auto" en aplicaciones generales y mida el modo resuelto. El modo main-thread es útil para tests y gráficos estáticos pequeños, pero los conjuntos de datos interactivos grandes normalmente deben ejecutarse en un worker.

Ajuste la presentación de líneas según la carga de trabajo

lod.density es el control principal fidelity/work. Comience en 0.75. Auméntelo cuando el detalle local sea visiblemente insuficiente y el tiempo por frame siga siendo cómodo. Redúzcalo para rangos rellenados de múltiples pasadas, altas relaciones device-pixel o navegadores donde el coste de llenado de Canvas2D predomine.

La suavidad de la representación depende de rebaseRatio y quantizationStep, no solo de la densidad. Valores más finos reducen cambios individuales de textura pero hacen que las consultas de jerarquía sean más frecuentes. Ajuste sobre gestos reales de zoom y compare el tiempo por frame en estado estable, visitas a consultas, vértices de presentación y estabilidad visual.

Use setStatsCallback temporalmente durante el desarrollo:

chart.setStatsCallback((stats) => {
  console.table({
    frame: stats.frameTime,
    mode: stats.presentationMode,
    vertices: stats.presentationVertices,
    visits: stats.presentationQueryVisits,
    ready: stats.lodReady,
  });
}, { intervalMs: 250 });

Desactive el callback en producción cuando la aplicación no consuma telemetría.

Agrupe actualizaciones

• Use APIs de arrays tipados en bloque cuando ya exista un lote completo.
• Use batch() para varios cambios imperativos sincrónicos causados por una acción de UI.
• Evite construir arrays o formatear cadenas dentro de callbacks por fotograma.
• Debouncee las reconstrucciones por streaming en la aplicación e ignore resultados asíncronos obsoletos.

Preserve el significado de los datos

La reducción de rendimiento debe conservar los extremos y los huecos reales. Nunca pre-promedie un sobre de rango, conecte intervalos faltantes ni muestree a la baja cada entrada de área apilada de forma independiente. Para OHLCV, agregue open-first, high-maximum, low-minimum, close-last y volumen sumado sobre observaciones reales.