Optimización de Latencia Perceptual en GitHub Issues mediante Caching y Service Workers

El problema fundamental que aborda este artículo es la latencia percibida en aplicaciones web interactivas, especialmente en herramientas de desarrollo donde las micro-interrupciones afectan la productividad. La tesis es que, para alcanzar una experiencia de usuario 'instantánea', no basta con optimizaciones de backend marginales; es necesario un cambio arquitectónico que priorice la carga desde datos locales y la revalidación asíncrona. Esto se alinea con el concepto de 'speed of thought' en la interacción humano-computadora, donde la interfaz debe responder a la velocidad del pensamiento del usuario para mantener el 'flow'.

Históricamente, las aplicaciones web han dependido del renderizado del lado del servidor (SSR) o de la carga completa del cliente en cada navegación, incurriendo en costos de red y computación que se traducen en latencia. A medida que las expectativas de los usuarios evolucionan hacia experiencias 'instantáneas', impulsadas por herramientas 'local-first' y clientes altamente optimizados, la arquitectura tradicional se convierte en un cuello de botella. El desafío es cómo ofrecer esta inmediatez en un sistema distribuido y con un gran volumen de datos como GitHub Issues, sin comprometer la consistencia de los datos.

Arquitectura del Sistema

La arquitectura implementada se basa en un modelo de aplicación 'local-first' con 'stale-while-revalidate' (SWR). El corazón del sistema es una capa de caching persistente en el cliente, utilizando IndexedDB para almacenar payloads de issues. IndexedDB fue elegido por su durabilidad, modelo de objetos indexado para búsquedas eficientes y mayor cuota de almacenamiento comparado con localStorage.

Sobre esta capa de almacenamiento, se implementó la lógica SWR: en una navegación 'soft' (dentro del runtime de React), se intenta primero hidratar la UI desde el cache local para un renderizado instantáneo. Paralelamente, se emite una solicitud de red en segundo plano para revalidar la frescura de los datos y se reconcilia el store en memoria si hay cambios. Para mejorar la tasa de aciertos del cache, se introdujo una estrategia de 'preheating'. A diferencia del prefetching tradicional, el preheating solo carga datos de issues referenciados en superficies de alta intención (listas, dashboards) si no están ya presentes en el cache del cliente, priorizando la disponibilidad de datos utilizables sobre la frescura absoluta. Una capa de cache en memoria se sitúa delante de IndexedDB para servir payloads 'calientes' de forma síncrona, eliminando la latencia de IndexedDB en el critical path.

Para extender los beneficios a navegaciones 'hard' (carga completa del navegador) y 'Turbo' (transiciones de Rails Turbo), se integró un Service Worker. Este script, que opera fuera del hilo principal de la página, intercepta las solicitudes de red. Si los datos del issue están en el cache local, el Service Worker añade un header a la solicitud saliente, indicando al servidor que puede enviar un 'thin HTML shell' (layout mínimo + JS) en lugar de una página completamente renderizada. Esto permite que React renderice desde el payload cacheado localmente, reduciendo la carga del servidor y el tiempo de respuesta. En caso de cache miss o indisponibilidad del Service Worker, el sistema fallback al renderizado estándar del servidor. Para optimizar aún más las 'hard navigations', se implementó code splitting por ruta (React.lazy) y preloading dinámico, cargando solo el código necesario para la vista inicial y difiriendo módulos no críticos.

const IssueEditor = React.lazy(() => import('./IssueEditor'));

function MyIssuePage() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <IssueEditor />
    </Suspense>
  );
}

Fundamentos Teóricos

Este enfoque se conecta directamente con principios de sistemas distribuidos y bases de datos. El patrón 'stale-while-revalidate' es una forma de consistencia eventual, un concepto fundamental en el teorema CAP, donde se prioriza la disponibilidad y la tolerancia a particiones sobre la consistencia estricta en todo momento. En este caso, la 'disponibilidad' se traduce en una latencia percibida mínima para el usuario, mientras que la 'consistencia' se logra asincrónicamente en segundo plano. La idea de servir datos 'stale' para mejorar la experiencia del usuario se ha explorado en sistemas de caching distribuidos y CDNs durante décadas.

La optimización de la latencia perceptual también tiene raíces en la psicología cognitiva y la investigación de la interacción humano-computadora, donde se ha demostrado que umbrales de respuesta de 100ms a 1 segundo son críticos para mantener la sensación de interacción directa y evitar la pérdida de 'flow'. Conceptos como el 'Highest Priority Content' (HPC) son análogos a métricas como Largest Contentful Paint (LCP) de Web Vitals, que buscan cuantificar la experiencia del usuario más allá de las métricas de carga de página brutas, enfocándose en cuándo el contenido significativo se vuelve visible. El uso de Service Workers para interceptar y servir respuestas desde el cache local es una aplicación práctica de los principios de caching a nivel de red, similar a cómo los proxies y los caches de navegador han funcionado históricamente, pero con una programabilidad mucho mayor.