El 27 de junio de 2025 mi mundo cambió de golpe. Una lesión medular T3-T5 me puso en una silla de ruedas y me obligó a reaprenderlo todo. Pero hubo algo que no cambió: mi código.
En ese momento entendí que la Soberanía Tecnológica no es un debate filosófico para geeks de Twitter. Es mi rampa digital. Si mi web es lenta, si depende de servicios que no controlo o si su accesibilidad es un "después vemos", estoy perdiendo mi autonomía.
En este post te explico por qué el rendimiento extremo no es un lujo: es un derecho. Y por qué en campa.dev construimos software que respeta tu tiempo, tu energía y tu humanidad.
Debido a mi condición física, mi tiempo productivo en la silla está restringido por la hinchazón de mis pies. Esta limitación me obliga a ser un ingeniero de la eficiencia extrema: cada milisegundo de carga ahorrado es tiempo de autonomía ganado.
No podemos hablar de inclusión digital si obligamos al ciudadano a gastar sus limitados datos móviles descargando megabytes de JavaScript innecesario para un trámite básico. En 2026, el rendimiento web en Paraguay debe dejar de ser una sugerencia y convertirse en un requisito de ley. La velocidad es accesibilidad.
El muro invisible del software pesado
Imaginate esto: un productor de Itapúa necesita renovar una guía de traslado. Está en el campo, tiene un smartphone de hace 4 años y su señal 4G es, en el mejor de los casos, inestable. Abre el portal oficial y... espera. Pasan 10 segundos. La página pesa 5.8MB porque está llena de librerías de trackers, imágenes sin optimizar y un framework pesado que no debería estar ahí para un simple formulario.
Lo viví de cerca. El año pasado, optimizando la plataforma de un exportador local en Itapúa (como mencioné en mi post sobre sitios rápidos), descubrimos que el 40% de los usuarios abandonaban el proceso de carga de fletes simplemente porque el bundle de JavaScript inicial bloqueaba el navegador en teléfonos de gama media. No era falta de interés, era un bloqueo técnico.
Ese ciudadano acaba de pagar un "impuesto invisible" en tiempo y saldo de datos. El software lento es, por definición, excluyente.
Análisis al Estándar de Software 2.0 (MITIC)
El MITIC lanzó la consulta pública para el Estándar de Software Versión 2.0. Ya hice un análisis preliminar del estándar donde destaqué avances que aplaudo: la soberanía del código, la propiedad intelectual para el Estado y la transparencia. Se acabó el "secuestro" tecnológico por parte de proveedores que no entregaban el código fuente.
Sin embargo, el borrador actual tiene un punto ciego que nos va a costar caro: el rendimiento no tiene métricas obligatorias.
Si el estándar exige seguridad (que debe) y accesibilidad WCAG (que debe), ¿por qué no exige un puntaje mínimo de Lighthouse o Core Web Vitals? Como aplico en mi propia ingeniería de portafolio, la métrica no es vanidad, es garantía de servicio.
Pros
- Soberanía del código fuente
- Propiedad Intelectual para el Estado
- Estándares de seguridad rigurosos
Contras
- Rendimiento web como sugerencia opcional
- Falta de presupuestos de performance
- Poca claridad en KPIs de velocidad real
El costo real de la ineficiencia
En Paraguay, el acceso a internet móvil sigue siendo costoso en relación al ingreso. Cada megabyte cuenta.
Cuando una licitación pública acepta un portal que demora 15 segundos en cargar, el Estado no solo está comprando software; está transfiriendo el costo de su ineficiencia al hardware y al bolsillo del ciudadano. Un portal liviano no es un capricho de ingeniero; es respeto al recurso público.
Propuesta Técnica: El Rendimiento por Ley
Para que el Estándar 2.0 sea realmente transformador, necesitamos incluir criterios de aceptación técnicos e irrefutables. Sé que esto asusta a algunos proveedores porque exigir calidad tiene trade-offs:
- Lighthouse Score ≥ 85: Ningún portal del Estado debería ponerse en producción con un score de performance menor a 85.
- Core Web Vitals (LCP < 2.5s): El contenido principal debe ser visible en menos de 2.5 segundos bajo una red 4G simulada.
- Presupuestos de Performance (Performance Budgets): Límites estrictos de transferencia inicial (ej. < 500KB de JS).
Trade-offs de la alta exigencia:
- Curva de Aprendizaje: Los equipos deben adoptar herramientas modernas (Astro, Qwik) en lugar de soluciones heredadas.
- Supervisión Senior: La fiscalización requiere un nivel técnico más alto para validar los presupuestos de performance.
- Inversión Inicial vs. Gasto Recurrente: El costo de desarrollo puede ser mayor al inicio, pero el ahorro en infraestructura y soporte a largo plazo es masivo.
Conclusión
La soberanía tecnológica no es solo tener las llaves del código; es asegurar que ese código sirva a todos por igual, sin importar si navegan desde un iPhone 15 en Asunción o un modelo básico en los silos de Itapúa.
Es hora de codificar la eficiencia en nuestras leyes. Porque una web que no carga, para el ciudadano que la necesita, simplemente no existe.
Referencias y Enlaces de Interés
- MITIC - Consulta Pública Estándar de Software 2.0
- Portal Paraguay - Participación Ciudadana
- W3C - Web Performance Working Group
