O time de engenharia do GitHub reformulou a arquitetura de navegação do GitHub Issues para combater um dos maiores vilões de produtividade dos desenvolvedores: a latência de rede em fluxos repetitivos. Transferindo a maior parte do processamento e da renderização para o lado do cliente (client-side), a plataforma conseguiu elevar a taxa de navegação instantânea de apenas 4% para 22% das interações.

A mudança foca no comportamento de usuários que navegam constantemente entre listas de tarefas, detalhes de chamados e visões correlacionadas. Nesses cenários, em vez de disparar requisições completas ao backend a cada clique, a nova estrutura adota uma abordagem local-first, renderizando imediatamente os dados já disponíveis no navegador enquanto sincroniza informações atualizadas em segundo plano.

Para garantir que a interface responda sem travamentos, o sistema passou a utilizar múltiplas camadas de armazenamento no navegador. Dados persistentes ficam salvos no IndexedDB, enquanto informações acessadas com alta frequência durante a sessão ativa são mantidas em memória.

  • Estratégia Stale-While-Revalidate: Ao reabrir uma página ou lista visitada anteriormente, a aplicação exibe os dados salvos localmente sem esperar o servidor. Uma sincronização roda em background para atualizar a tela caso haja mudanças no backend.
  • Uso estratégico de Service Workers: Um Service Worker intercepta as requisições do navegador para checar a disponibilidade do recurso localmente. Se os dados existirem na máquina do usuário, a renderização é imediata; caso contrário, a requisição segue o fluxo tradicional até o servidor.
  • Prefetching e Preheating: Com base no padrão de navegação do usuário, o sistema antecipa e pré-carrega os dados dos links e Issues com maior probabilidade de clique.

Equilibrar a velocidade da interface com a consistência dos dados foi o principal desafio da equipe. Alexander Lelidis, engenheiro sênior de software no GitHub, destacou que o objetivo principal ia além dos números brutos:

"Latência não é apenas uma métrica. É uma troca de contexto."

A otimização trouxe ganhos significativos em praticamente todas as faixas de distribuição de latência (percentis):

  • P10 (navegações mais rápidas): Despencou de aproximadamente 600ms para 70ms.
  • P25: Caiu de 800ms para 120ms.
  • P50 (Mediana): Reduziu de 1.200ms para 700ms.
  • P75 e P90 (cauda longa de latência): Caíram de 1.800ms para 1.400ms e de 2.400ms para 2.100ms, respectivamente.

Especialistas da comunidade também ressaltaram importantes lições técnicas sobre essa mudança de paradigma. Em análise sobre o prefetching, o BareStack pontuou uma distinção essencial sobre quando a técnica realmente compensa:

"O prefetching vale a pena quando o grafo de dados é pequeno e focado em leitura, como no Issues. A maioria das aplicações tem um grafo maior com colisões de leitura/escrita, então visões pré-carregadas podem precisar de refetch após o pouso na página. O padrão reutilizável aqui é a renderização primeiro do shell + hidratação via cache-hit, não o prefetching em si."

Complementando a visão sobre a maturidade da engenharia empregada, Oguz Guven também enfatizou o impacto real dessa evolução técnica:

"Mudar do cauda P99 para a qualidade da distribuição como um todo é a verdadeira maturidade de engenharia aqui."