LCP 개선하기 - CloudFront(CDN) 사용하기

LCP(Large Contentful Paint)란
뷰포트를 차지하는 가장 큰 콘텐츠(이미지 또는 텍스트 블록)의 렌더 시간을 측정합니다. 이를 이용해 주요 컨텐츠가 유저에게 보이는 시간을 알 수 있습니다.
LCP time(in seconds) | Color-coding |
0-2.5 | Green(fast) |
2.5-4 | Orange(moderate) |
Over 4 | Red(slow) |
CloudFront 적용 이유
CloudFront는 AWS에서 제공하는 글로벌 CDN 서비스로, 정적 자산(이미지, JS, CSS 등)을 사용자와 가까운 위치(Edge Location)**에서 제공함으로써 LCP를 단축시킬 수 있습니다.
페이지 | pc/m | 기본 | preconnect, preload, fetchPriority, CloudFront | Lambda@Edge |
메인 | pc | 1s | ㅤ | ㅤ |
ㅤ | mobile | 4.3s | 3.7s | ㅤ |
프로모션 | pc | 3.8s | 1s | ㅤ |
ㅤ | mobile | 21.4s | 4.9s | ㅤ |
CloudFront 사용의 기대 효과
사용자가 S3에 직접 접근하지 않고 CloudFront를 통해 이미지에 접근할때의 장점
- S3 직접 접근 차단 → 보안 강화
- 이미지 파일 캐싱 → 서버 부하 감소
- Edge Location 기반 배포 → 렌더링 시간 단축
- HTTPS 지원 → SEO 및 보안 향상
1. CloudFront 배포 생성

원본 설정
- 원본으로 S3 선택
- OAC(Origin Access Control) 사용 → S3 버킷의 퍼블릭 접근 차단
- 퍼블릭 접근이 차단된 S3 객체는 오직 CloudFront를 통해서만 제공됨
캐시 정책 설정
- 기본 캐시 동작에서 필요한 QueryString/Headers/쿠키 처리 방식 지정 가능
SSL 설정 주의사항
- 커스텀 도메인 + SSL 인증서를 사용하려면 "버지니아 북부(미국 동부 1)" 리전에서 생성해야 함
- Lambda@Edge와 함께 사용할 경우도 동일하게 이 리전에서 생성 필요
기본 캐시 동작

방화벽

설정

- CloudFront는 Custom SSL 인증서를 적용해서 사용하기 위해서는 버지니아 북부 리전으로 생성해야합니다. 저는 Lambda@edge까지 곁들여 사용하기 위해 반드시 버지니아 북부 리전을 선택했습니다.(Lambda@edge는 버지니아 북부 리전만 지원)
2. S3 편집 또는 생성
1. 객체 소유권
- "객체 소유권 → ACL 활성화됨"
- "객체 작성자(작성자가 객체 소유)" 옵션 선택

퍼블릭 액세스 차단 설정
- 모든 퍼블릭 접근 차단 옵션을 체크
- S3는 CloudFront에서만 접근하도록 설정

CloudFront 연결 확인
.env
파일 등에서 S3 URL을 CloudFront URL로 교체
- 브라우저에서 네트워크 탭 확인
- X-Cache: Hit from cloudfront 메시지가 보이면 캐싱 성공
프로젝트 env의 S3 URL을 CloudFront 배포 도메인 이름으로 변경하면, 요청 URL이 CloudFront로 변경되고 X-Cache는 Hit from cloudfront가 출력되어 연결 된 것을 볼 수 있습니다.

Cloudfront에서 캐싱 지표 확인하기
CloudFront > 배포 선택 > 인기 객체(Popular Objects) 메뉴에서 확인
지표 | 설명 |
객체 (Object) | 객체에 대한 Endpoint URL을 나타낸다. |
요청 (Reqeusts) | 객체에 대한 총 요청 수를 나타낸다. |
검색결과 (Hits) | Edge Location에서 캐싱된 객체가 제공된 사용자 요청 수이다. |
검색결과 % (Hits %) | 검색 결과 (Hits)를 백분율로 표시한 값이다. |
누락 (Misses) | Edge Location에 객체를 찾지 못한 사용자 요청 수이다. |
누락된 바이트 (Bytes from misses) | Edge Location에 객체를 찾지 못하여 사용자에게 제공된 Byte이다. |
바이트 합계 (Total bytes) | 객체에 대해 최종 사용자에게 제공한 총 바이트 수이다. |
불완전한 다운로드 (Incomplete downloads) | 객체에 대해 사용자가 다운로드를 시작했으나 완료되지 못한 최종 사용자 요청 수이다. (일반적으로 다른 링크를 클릭하거나 브라우저를 닫는 등의 동작으로 사용자가 요청을 취소한 경우임) |
2xx | HTTP Status Code가 2xx(성공)인 요청 |
3xx | HTTP Status Code가 3xx(추가 작업 필요)인 요청 |
4xx | HTTP Status Code가 4xx(클라이언트 오류)인 요청 |
5xx | HTTP Status Code가 5xx(서버 오류)인 요청 |
캐싱이 잘 되는지 확인하기 위해서는 검색 결과와 검색 결과%를 살펴봅시다

캐싱 확인 포인트
- Hits %가 높을수록 캐싱 효과가 큼
- 90% 이상이면 안정적인 캐시 활용 중
- 낮을 경우 캐시 정책 재검토 필요
예: 이미지나 JS 파일 등 정적 리소스는 cache-control 설정으로 TTL을 명확히 지정하는 게 중요
실시간 지표 모니터링 (선택)
CloudFront 지표를 기반으로 특정 수치 이상일 때 Slack 알림 등을 설정할 수 있습니다.
👉 참고: 슬랙 알림 설정하기 - jojoldu 블로그