How I Reduced Firebase Loading Time from 5 Seconds to Under 100ms

Context

Muslifie의 투어 리스팅 페이지가 2~5초 로딩 시간으로 인해 저속 네트워크 사용자들의 이탈이 발생했다. 매번 앱을 열 때마다 캐싱 없이 Firestore에서 직접 쿼리를 실행했고, 가이드 프로필 200개 이상 증가에 따라 비용과 성능 저하가 심화되고 있었다.

Technical Solution

• Cloud Functions 인메모리 캐싱 도입: 5분 TTL(Time-To-Live)의 자동 갱신 메커니즘으로 캐시된 투어 데이터 반환
• 클라이언트 측 Flutter Firestore 영속성에서 서버 측 캐싱으로 마이그레이션: 클라이언트 캐시의 스테일 데이터 문제와 무효화 제어 불가 해결
• Cloud Function 인스턴스 워밍 활용: 함수 인스턴스가 15~30분 동안 메모리에 상주하는 특성으로 지속적 캐시 유지
• Firestore 쿼리 최적화: 활성 상태의 투어만 50개 제한으로 조회하도록 필터링 및 정렬
• Flutter 스켈레톤 로더 추가: Cold start 시 400ms 대기 중 사용자에게 로딩 피드백 표시

Impact

• 초기 로딩 시간: 2~5초 → 100ms 이하 (캐시 히트 기준)
• Firestore 일일 읽기 작업: 40,000회 이상 → 약 800회
• Firebase 청구액: 상승추세 → 평탄화
• Cold start 첫 사용자 대기 시간: 약 400ms
• Cold start 이후 사용자 대기 시간: 100ms 이하

Key Takeaway

불필요한 Firestore 읽기를 제거하는 것이 실제 최적화 지점이었으며, 프로파일링을 통해 병목을 정확히 파악하는 것이 추측성 최적화보다 우선한다. 체감 성능(skeleton loader로 로딩 시각화)도 실제 성능만큼 중요하다.