갤러리 페이지 성능 개선 사례

안녕하세요. 갤러리 페이지의 성능 문제를 해결한 경험을 공유합니다. 진입할때마다 페이지가 느리다고 느껴서 혼자 프로젝트를 출시하기 전에 성능 개선을 해야겠다고 생각했습니다. Lighthouse로 페이지를 분석하니 예상대로 지표 역시 만족스럽지 못한 상태임을 확인했습니다.

(라이트하우스`#모바일`로 측정)

개선 방향 설정

문제를 해결하기 위해 두 가지 주요 개선 방향을 설정했습니다.

1. 코드 최적화
2. DB 이미지 처리 방식 개선
   우선, 코드 구조를 간소화하기 위해 사용하지 않는 삼항 연산자를 제거했지만, 성능 지표에는 큰 영향을 미치지 않았습니다. (성능 점수: 71 → 69). 이후, 페이지 내 컴포넌트들의 로딩 속도를 비교하며 서버와의 통신이 병목 현상의 주요 원인임이라 생각했습니다.

문제 원인 분석

갤러리 페이지에서 서버와의 통신이 느린 주된 이유는 이미지 데이터를 저장한 방식 때문이었습니다. 당시에는 1인 프로젝트라 비용 문제를 고려해 MongoDB에 Base64 포맷으로 이미지를 직접 저장하는 방식을 선택했습니다.

이러한 Base64 방식은 구현 속도가 빠르고 초기 비용이 들지 않는 장점이 있지만, 다음과 같은 단점이 있었습니다:

• 용량 증가: 이미지 파일 크기가 약 33% 증가해 데이터 로딩 속도에 영향을 미침
• 확장성 문제: 이미지 데이터가 많아질수록 DB 성능 저하

해결

새로운 접근: 이미지 저장소로 Vercel Blob 도입
이러한 문제를 해결하기 위해 Vercel Blob을 사용해 이미지 저장소를 분리했습니다. 이로써 MongoDB에는 이미지 주소(URL)만 저장하도록 구조를 변경했습니다.

Base64와 Blob 방식을 간단히 비교하면 다음과 같습니다:

Base64: 바이너리 데이터를 텍스트 형태로 변환해 저장. 가독성이 떨어지고 용량 증가 문제 발생
Blob: 바이너리 데이터를 객체 형태로 저장. 가볍고 효율적

S3 아닌 Vercel Blob을 선택한 이유

Vercel Blob은 S3 대비 다음과 같은 장점이 있어 선택했습니다:

1. 더 많은 무료 요청 횟수: S3보다 5,000회 더 많은 무료 요청 제공
2. Next.js와의 배포 호환성: Vercel 배포 환경에서 빌드 시 자동 설정
3. 사용 편의성: aws 보다 사이트가 직관적인 인터페이스와 간단한 설정

결과와 소감

Vercel Blob을 도입한 후, 서버와의 통신 속도가 눈에 띄게 향상되었습니다. 이미지 주소만을 저장함으로써 DB 부하가 줄어들었고, 클라이언트 로딩 속도도 크게 개선되었습니다.

first contentful paint는 16.5s -> 1.7s
largest contentful paint 는 18s-> 3.1s
로 개선되었습니다.

S3에 비해 설정이 직관적이고 간단했으며, Vercel 문서를 따라 구현하기 쉬웠습니다. 이번 개선 과정을 통해 비용과 성능, 그리고 사용 편의성 간의 균형을 잡을 수 있었습니다.

다음으로, 2. ux를 위해 로딩과 스켈레톤 도입, 썸네일 성능 개선에 사용하는 이미지 CDN 도입을 생각 중입니다.