Firebase 로드 시간을 5초에서 100ms 이하로 줄인 방법

Source: Dev.to

문제점

Muslifie가 출시될 때, 투어 리스트 페이지가 2–5 초 정도 걸렸습니다. 파키스탄, 이집트, 인도네시아와 같은 느린 연결 환경의 사용자들은 데이터가 나타나기도 전에 이탈하고 있었습니다.

원인? 사용자가 앱을 열 때마다 Firebase가 새 Firestore 쿼리를 실행했으며—캐시도, 배치도 없이 매번 원시 읽기를 수행했습니다.
가이드 프로필이 200개 이상이고 계속 늘어나면서 비용도 늘고 속도도 느려졌습니다.

처음에는 Flutter 내장 Firestore 영속성을 이용한 클라이언트‑사이드 캐싱을 시도했습니다. 약간은 도움이 되었지만:

• 첫 로드는 여전히 느림
• 재설치 시 데이터가 오래됨
• 캐시 무효화 제어 불가

가이드 가용성이 매일 바뀌는 마켓플레이스에는 충분하지 않았습니다.

해결책

무거운 작업을 Firebase Cloud Functions 로 옮기고 메모리 내 캐싱을 활용합니다.

// functions/index.js
let cachedData = null;
let cacheTime = null;
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

exports.getTours = functions.https.onCall(async (data, context) => {
  const now = Date.now();

  // Return cache if still fresh
  if (cachedData && (now - cacheTime)  ({ id: doc.id, ...doc.data() }));
  cacheTime = now;

  return cachedData;
});

핵심 인사이트: Cloud Function 인스턴스는 호출 사이에 따뜻한 상태를 유지하므로, 인스턴스가 살아 있는 동안(보통 15–30 분) 캐시가 메모리에 남아 있습니다.

콜드 스타트 후 첫 사용자는 약 400 ms를 기다립니다. 이후 모든 사용자는 100 ms 이하로 캐시된 데이터를 받습니다.

지표

인지된 성능

성능 개선은 첫 콜드 스타트 동안 사용자가 빈 화면을 바라보지 않을 때만 효과가 있습니다. 이를 위해 Flutter에서 스켈레톤 로더를 함께 적용했습니다.

// lib/widgets/tour_list.dart
Widget build(BuildContext context) {
  return FutureBuilder>(
    future: fetchTours(),
    builder: (context, snapshot) {
      if (!snapshot.hasData) {
        return TourSkeletonList(); // Show skeleton while loading
      }
      return TourList(tours: snapshot.data!);
    },
  );
}

인지된 성능은 실제 성능만큼 중요합니다. 사용자는 무언가 진행 중이라는 것을 보면 로딩을 견딜 수 있습니다.

향후 개선 사항

오늘 Muslifie를 다시 만든다면 다음을 추가하겠습니다:

• Redis 캐싱 – Firebase Extensions를 이용해 다중 인스턴스 간 캐시 공유
• 점진적 로딩 – 상위 10개 투어를 즉시 표시하고 나머지는 백그라운드에서 로드
• 앱 실행 시 프리페치 – 사용자가 화면을 이동하기 전에 앱이 열리자마자 데이터 가져오기 시작

교훈

• 일찍 최적화하지 말고 먼저 프로파일링하라.
• 병목은 Flutter 위젯이나 네트워크 속도가 아니라 불필요한 Firestore 읽기였다.
• 20줄 정도의 간단한 캐싱 함수만으로도 읽기 횟수와 비용을 크게 줄일 수 있다.
• 모든 데이터 가져오기마다 로깅을 추가하고 실제 시간이 어디에 쓰이는지 확인하라; 답은 생각보다 단순한 경우가 많다.

원문은 buildzn.com 에서 처음 공개되었습니다.