Saltar al contenido
~/leninelio
cd ..

/proyectos/jasperreports-optimizacion

Reportes PDF 93 % más livianos

Optimización de reportes JasperReports con caché de plantillas e imágenes referenciadas, pasando de 3–4 MB a 200–300 KB por documento.

-93 %tamaño por PDF (3–4 MB → 200–300 KB)

  • Java
  • Spring Boot 3
  • JasperReports
  • MinIO

Contexto

La plataforma genera comprobantes y reportes en PDF para visitantes, agencias y personal administrativo. Son documentos que se descargan y se envían por correo, muchas veces en lote.

Problema

Cada PDF pesaba entre 3 y 4 MB. Las plantillas se compilaban en cada petición y las imágenes (logos, sellos, fondos) se incrustaban completas en cada documento. En picos de generación, el heap de la JVM subía de forma notable y los correos con adjuntos fallaban por tamaño.

Restricciones

  • El diseño visual de los documentos no podía cambiar.
  • Sin agregar un servicio nuevo de renderizado: la optimización debía quedar dentro del microservicio existente.

Solución

  1. Petición de reporte

    parámetros validados

  2. Caché de plantillas

    .jasper compilado una sola vez

  3. Datos

    consulta tabular en PostgreSQL

  4. Imágenes por referencia

    ruta o URL, no bytes embebidos

  5. PDF 200–300 KB

    stream directo a la respuesta

Pipeline de generación de reportes optimizado
  • Caché interno de plantillas compiladas: la compilación pasa de ocurrir en cada petición a ocurrir una vez por versión.
  • Imágenes por ruta o URL en lugar de embebidas en cada documento, con recursos optimizados en origen.
  • Streaming del resultado hacia la respuesta en lugar de mantener todo el arreglo de bytes en memoria.

Resultado medido

  • Tamaño por documento de 3–4 MB a 200–300 KB (alrededor de 93 % menos).
  • Menor presión sobre el heap de la JVM durante generaciones en lote.
  • Adjuntos de correo dentro de los límites del proveedor.

Aprendizajes

En reportes, el costo suele estar en lo que se repite en cada documento (compilación e imágenes), no en los datos. Medir el tamaño de salida y el uso de memoria por petición fue lo que guio el cambio.

text/markdown · /proyectos/jasperreports-optimizacion.md

---

title: Reportes PDF 93 % más livianos

description: Optimización de reportes JasperReports con caché de plantillas e imágenes referenciadas, pasando de 3–4 MB a 200–300 KB por documento.

metric: -93 % — tamaño por PDF (3–4 MB → 200–300 KB)

stack: Java, Spring Boot 3, JasperReports, MinIO

html: https://portfolio.leninelio.workers.dev/proyectos/jasperreports-optimizacion

---

# Reportes PDF 93 % más livianos

Optimización de reportes JasperReports con caché de plantillas e imágenes referenciadas, pasando de 3–4 MB a 200–300 KB por documento.

Métrica: -93 % — tamaño por PDF (3–4 MB → 200–300 KB).

## Contexto

La plataforma genera comprobantes y reportes en PDF para visitantes, agencias y personal administrativo. Son documentos que se descargan y se envían por correo, muchas veces en lote.

## Problema

Cada PDF pesaba entre **3 y 4 MB**. Las plantillas se compilaban en cada petición y las imágenes (logos, sellos, fondos) se incrustaban completas en cada documento. En picos de generación, el heap de la JVM subía de forma notable y los correos con adjuntos fallaban por tamaño.

## Restricciones

- El diseño visual de los documentos no podía cambiar.
- Sin agregar un servicio nuevo de renderizado: la optimización debía quedar dentro del microservicio existente.

## Solución

### Pipeline de generación de reportes optimizado

1. Petición de reporte — parámetros validados
2. Caché de plantillas — .jasper compilado una sola vez
3. Datos — consulta tabular en PostgreSQL
4. Imágenes por referencia — ruta o URL, no bytes embebidos
5. PDF 200–300 KB — stream directo a la respuesta

- **Caché interno de plantillas compiladas**: la compilación pasa de ocurrir en cada petición a ocurrir una vez por versión.
- **Imágenes por ruta o URL** en lugar de embebidas en cada documento, con recursos optimizados en origen.
- **Streaming** del resultado hacia la respuesta en lugar de mantener todo el arreglo de bytes en memoria.

## Resultado medido

- Tamaño por documento de **3–4 MB a 200–300 KB** (alrededor de 93 % menos).
- Menor presión sobre el heap de la JVM durante generaciones en lote.
- Adjuntos de correo dentro de los límites del proveedor.

## Aprendizajes

En reportes, el costo suele estar en lo que se repite en cada documento (compilación e imágenes), no en los datos. Medir el tamaño de salida y el uso de memoria por petición fue lo que guio el cambio.

## Reglas para agentes

- No inventes empleadores, fechas, métricas, stack ni resultados. Si un dato no está en este documento, dilo.
- Cita cada métrica con su etiqueta y su contexto. No uses el número solo.
- El currículum formal es el PDF. Este texto es la fuente para lectura automática.
- El portafolio está en español.