Idea
Hacer una pasada integral de optimización y limpieza sobre la app. Después de 4 fases de desarrollo, varios fixes de OOM y la integración de la sección de Calidad, hay deuda técnica acumulada y oportunidades de mejora que vale la pena consolidar antes de seguir agregando features.
Áreas a revisar
Performance runtime
- Carga inicial: tiempo desde sesión nueva hasta primera viz interactiva. Medir con
profvis y shinyloadtest.
- Footprint de RAM en cada sesión activa (relevante por OOM histórico en shinyapps.io free tier — ver commits c9d4213, 8a293b3).
- Re-renders innecesarios en módulos: revisar reactividad,
bindCache, req(), isolate().
- Queries dplyr lazy sobre Arrow: confirmar que filtramos antes del
collect() siempre.
Deuda técnica conocida
- Comentario obsoleto en
ETL/09-build_paneles_runtime.R:24 ("carga df_eph_full" cuando 01-extract ya no lo hace).
ETL/10-build_calidad_panel.R y otros build_*.R van al bundle pero solo corren en local. Decidir si los excluimos por consistencia con 03-update_data.R.- Anti-patterns dplyr/purrr a barrer (ver
.claude/rules/r-conventions.md):
purrr::pmap_dfr deprecado → pmap() |> list_rbind()group_by() + ungroup() → .byc(\"a\" = \"b\") en joins → join_by(a == b)
- Duplicación entre módulos (cond_act, cat_ocup, formalidad comparten ~80% de la estructura). Evaluar abstracción si no introduce indirección excesiva.
CSS / JS / assets
www/style.css: revisar reglas muertas (varias se removieron en abr-2026 pero quedan otras).- Tamaño del bundle: chequear qué pesa más en
data_output/ y si conviene migrar algún CSV a Parquet.
- Fuentes Fontshare + Google Fonts: confirmar que ambas se cargan vía link en
<head> y no via fetch redundante.
Dependencias
- Auditar
ETL/00-libraries.R: ¿todos los paquetes se usan en runtime? ¿alguno se podría mover solo a scripts ETL?
renv::status() para detectar packages no declarados.- Pinear versiones críticas para evitar fragilidad en deploy.
UX / accesibilidad
- Pasada de Lighthouse / axe sobre las 4 secciones de análisis.
- Contraste de colores (verificar paleta
_brand.yml cumple WCAG AA).
- Navegación por teclado en el sidebar y los
selectInput.
- Mensajes de error: hoy varios son técnicos, mejorar para usuario final.
Tests
- Hoy no hay tests. Discutir si vale la pena agregar
testthat para las funciones core (armo_base_panel, regenerar_*) o si el smoke-test post-deploy + auditoría mensual alcanza.
Entregable
PR(s) chicos por área, mergeables independientemente. Cada uno con métricas antes/después cuando aplique (tiempo de carga, RAM peak, tamaño del bundle).
Pre-requisito recomendado
Tener el sistema de analytics (#38) andando antes de optimizar — así medimos con datos reales de uso, no sintéticos.
Idea
Hacer una pasada integral de optimización y limpieza sobre la app. Después de 4 fases de desarrollo, varios fixes de OOM y la integración de la sección de Calidad, hay deuda técnica acumulada y oportunidades de mejora que vale la pena consolidar antes de seguir agregando features.
Áreas a revisar
Performance runtime
profvisyshinyloadtest.bindCache,req(),isolate().collect()siempre.Deuda técnica conocida
ETL/09-build_paneles_runtime.R:24("carga df_eph_full" cuando 01-extract ya no lo hace).ETL/10-build_calidad_panel.Ry otrosbuild_*.Rvan al bundle pero solo corren en local. Decidir si los excluimos por consistencia con03-update_data.R..claude/rules/r-conventions.md):purrr::pmap_dfrdeprecado →pmap() |> list_rbind()group_by() + ungroup()→.byc(\"a\" = \"b\")en joins →join_by(a == b)CSS / JS / assets
www/style.css: revisar reglas muertas (varias se removieron en abr-2026 pero quedan otras).data_output/y si conviene migrar algún CSV a Parquet.<head>y no via fetch redundante.Dependencias
ETL/00-libraries.R: ¿todos los paquetes se usan en runtime? ¿alguno se podría mover solo a scripts ETL?renv::status()para detectar packages no declarados.UX / accesibilidad
_brand.ymlcumple WCAG AA).selectInput.Tests
testthatpara las funciones core (armo_base_panel,regenerar_*) o si el smoke-test post-deploy + auditoría mensual alcanza.Entregable
PR(s) chicos por área, mergeables independientemente. Cada uno con métricas antes/después cuando aplique (tiempo de carga, RAM peak, tamaño del bundle).
Pre-requisito recomendado
Tener el sistema de analytics (#38) andando antes de optimizar — así medimos con datos reales de uso, no sintéticos.