Hace tres años, desde IDT, recibí un correo que decía: «El portal tarda 8 segundos en cargar». El usuario no mentía. Abrí Chrome DevTools, revisé las métricas, y encontré algo que ya sospechaba: 47 peticiones HTTP innecesarias, tres librerías JavaScript que no usábamos, y un servidor respondiendo en 3.2 segundos antes de que el navegador siquiera empezara a renderizar.
La pregunta obvia sería: ¿por qué no lo arreglamos de una?
Bueno, no exactamente... el problema no es la ignorancia técnica. Es más complejo. Cuando trabajé en la Secretaría Jurídica Distrital, descubrí que los portales lentos no nacen de la nada. Son el resultado de capas y capas de decisiones, la mayoría tomadas hace cinco o seis años por personas que ya no están allí.
El lastre de las decisiones antiguas
Hablemos claro: cada portal institucional que administré cargaba con tecnología heredada. Sistemas de caché que nadie sabía configurar. Bases de datos sin índices. Servidores compartidos donde conviven 40 sitios diferentes compitiendo por ancho de banda. Y lo peor —ojo con eso— es que nadie se atreve a tocar nada porque "funciona".
En FONTUR pasé meses intentando migrar a una arquitectura más ágil. Los números eran claros: con CDN y compresión de imágenes, podíamos bajar de 6 segundos a 1.8. Pero ¿sabes qué pasó? Los proveedores existentes ya tenían contrato. Las aprobaciones presupuestales estaban congeladas. Y aunque la solución era técnicamente bacano, políticamente era un caos.
Y entonces llega el verdadero problema. No es que no sepamos cómo hacerlo. Es que los incentivos están al revés.
El incentivo perverso
Un portal rápido no gana votos. No sale en la prensa. Nadie celebra que el RAP-E cargue en 800 milisegundos. Pero un portal bonito, con animaciones, con colores nuevos, con rediseño cada dos años —eso sí genera titulares.
Entonces los presupuestos van al frontend visual, no a la infraestructura. Los desarrolladores jóvenes aprenden a hacer interfaces, no a optimizar. Y los consultores que llegan venden soluciones que se ven bien en la presentación.
Todavía no entiendo por qué nadie calcula el costo real de esa lentitud. Cuántas solicitudes no se hacen porque la gente se aburre esperando. Cuánta información pública se deja sin consultar. En el Archivo General de la Nación, con 15 millones de registros, ese tiempo de respuesta es la diferencia entre un investigador que persevera y uno que desiste.
Aunque hay esperanza
Los equipos que he visto moverse rápido —literalmente, en rendimiento— tienen una cosa en común: alguien con poder decidió que esto importaba. No es magia. Es Core Web Vitals, es lazy loading, es minificar CSS, es elegir bien el servidor. Cosas que sabemos hace una década.
Pero requiere presupuesto. Requiere decir no a otras cosas. Requiere que alguien entienda que la velocidad es experiencia de usuario, y que la experiencia es servicio público.
¿Cuándo decidiremos que un portal lento es un portal que falla?