피드로 돌아가기
Dev.toFrontend
원문 읽기
Cache-first 전략으로 24.5초의 대기 시간을 0초로 단축한 비동기 UX 설계
Building a cache-first dashboard — explicit fetch and a "closes-but-keeps-running" notice
AI 요약
Context
다수 WordPress 사이트에 대해 병렬 SSH 스캔을 수행하는 대시보드 구조로 인해 매 접속 시 평균 24.5초의 응답 지연 발생. 실시간성보다 최신 상태 확인이라는 사용자 목적에 집중하여 데이터 획득 시점을 제어하는 구조로 전환함.
Technical Solution
- localStorage 기반의 Cache-first 렌더링 도입을 통한 초기 로딩 시간 제거
- 7-day TTL 설정 및 Maintenance 완료 시점에 맞춘 Cache Invalidation 훅 구현으로 데이터 정합성 유지
- Auto-load 방식을 사용자 명시적 요청(Explicit Fetch) 기반으로 변경하여 무거운 작업에 대한 심리적 대기 시간 완화
- Fetch 작업을 Promise 기반의 백그라운드 프로세스로 처리하여 모달 닫힘 상태와 독립적인 데이터 업데이트 구조 설계
- 'Close-but-keeps-running' 알림을 통한 UX 단절 방지 및 재접속 시 즉시 렌더링 경로 제공
Impact
- 캐시 히트 시 대시보드 렌더링 속도 24.5초에서 0초로 개선
- 7일의 데이터 유효 기간 설정을 통한 불필요한 SSH 네트워크 트래픽 감소
Key Takeaway
실시간 모니터링이 필수적이지 않은 도구의 경우, 데이터의 신선도(Freshness)와 사용자 경험 간의 Trade-off를 분석하여 '계획 도구'로 프레임을 전환하는 것이 성능 최적화의 핵심임.
실천 포인트
- 응답 시간이 긴 집계 작업 시 'Immediate-display path'가 존재하는지 검토 - 고비용 작업 실행 전 사용자에게 명시적 동의를 받는 UI/UX 적용 여부 확인 - UI 컴포넌트의 생명주기와 데이터 Fetching 프로세스를 분리하여 백그라운드 처리 가능 여부 분석 - 상태 변경 시점에 맞춘 정밀한 Cache Invalidation 전략 수립