지연에서 즉시로: GitHub Issues 탐색 성능 현대화

GitHub Issues는 탐색 지연을 줄이기 위해 서버 중심 흐름을 바꾸고, 클라이언트에 이미 있는 데이터를 먼저 렌더링한 뒤 뒤에서 갱신하는 stale-while-revalidate 모델로 옮겼다. 목표는 평균 지연보다 사용자가 실제로 체감하는 즉시성을 높이는 것이었다.

성과 기준은 내부 지표인 **HPC(Highest Priority Content)**였다. Web Vitals LCP와 비슷하게 가장 중요한 콘텐츠가 처음 그려지는 시점을 측정하며, 기준은 다음과 같이 나눴다.

• Instant: HPC < 200ms
• Fast: HPC < 1000ms
• Slow: HPC >= 1000ms

초기 트래픽에서는 hard navigation이 **57.6%**로 가장 큰 비중을 차지했고, HPC도 hard 2.05, Turbo 1.76, React 1.04로 갈렸다. GitHub가 아직 Rails 렌더링과 React 프론트엔드를 함께 쓰는 전환기인 만큼, 두 경계를 넘을 때마다 전체 로드가 발생하는 구조가 병목이었다.

첫 번째 개선은 IndexedDB 기반 클라이언트 캐시였다. 메모리 스토어를 확장해 이슈 데이터를 저장하고, 읽기는 캐시 우선, 쓰기는 백그라운드 재검증으로 처리했다. 여기에 service worker를 도입해 새로고침이나 hard navigation 뒤에도 캐시 데이터를 재사용하게 했다.

캐시 적중률을 더 올리기 위해 무작정 prefetch를 늘리지 않고 preheating을 택했다. 약 **30%**의 캐시 적중률을 초기 기준으로 삼았고, 이슈 목록에서 다음에 열 가능성이 높은 항목의 데이터를 미리 준비하되 요청 폭증과 N+1 패턴은 피했다.

롤아웃 뒤 React 네비게이션의 **22%**가 instant 구간으로 들어갔고, 도입 전 **4%**에서 크게 상승했다. 이는 전체 요청의 약 **15%**에 해당했으며, 캐시 적중률은 약 33%, 서버/캐시 불일치는 4.7% 수준으로 관리됐다.