FE -CDN 도입 성능 보고서

준비

• CDN도입 전 : S3
• CDN도입 후 : CloudFront

 

측정 환경 세팅

• 측정 환경 : 동일한 PC / 윈도우 / Chrome
• 측정 도구 : Chrome 개발자 도구 - Network, Performance, Lighthouse

 

기대 효과

• TTFB 감소: 요청이 지역 엣지 서버로 라우팅.
• 대역폭 최적화: 압축 및 캐싱으로 전송 비용 감소.
• 성능 일관성: 사용자 위치에 따른 성능 차이 감소.

 

#성능 측정

Queueing (대기열)

요청이 브라우저의 네트워크 큐에 대기한 시간

 

Stalled (중단됨)

요청이 실행되기 전 네트워크 자원 확보를 기다린 시간

• 저하 원인 분석 & 개선
  1. DNS 조회 및 TCP 연결 증가 → AWS CloudFront에서 Keep-Alive 설정 _ 하려고 했으나 CloudFront는 원칙적으로 keep-alive가 적용된 HTTP/2를 이미 지원
  2. HTTP/2 또는 HTTP/3 설정 누락 → 이미 설정됨
  3. 캐시 히트율(Cache Hit Ratio) 저조 → 이미 CacheOptimized 적용됨
  4. TTL(Time-to-Live) 연장 → 이미 권장 설정만큼 되어 있음
• 두 페이지 모두 다시 강력 새로고침 실행

 

DNS Lookup Time (DNS 조회)

도메인 이름을 IP로 변환하는 시간

 

Initial Connection

TCP/SSL 연결을 설정하는 데 걸린 시간

 

Request sent(요청 전송됨)

클라이언트(브라우저)가 서버로 요청을 전송하는 데 걸린 시간

 

TTFB (Time to First Byte)

Waiting for server response

서버가 요청을 처리하고 첫 바이트를 반환할 때까지의 시간

• ≠ Latency
  • TTFB = Latency + 서버의 첫 응답 생성 시간
  • Latency는 서버와 클라이언트 간 데이터 전송 지연시간

 

Download Time

콘텐츠 다운로드 시간.

 

Content-Encoding

CDN은 압축 및 최적화를 통해 전송 데이터 크기를 줄임

LCP (Largest Contentful Paint)

웹페이지의 주요 콘텐츠가 화면에 표시되는 시간

페이지 로딩이 사용자에게 체감되는 속도

• 🟢 2.5초 이내 /🟡 4초 이내 / 🔴 4초 이상
• 개선 팁
  • 이미지 최적화(WebP, AVIF 포맷 사용)
  • 렌더링 차단 리소스 최소화(CSS, JS)
  • CDN을 통한 콘텐츠 전송 가속

CLS (Cumulative Layout Shift)

페이지 콘텐츠의 레이아웃이 예상치 못하게 변경되는 정도

사용자 경험(UX)을 직접적으로 저하

광고, 이미지, 폰트 로딩으로 인한 레이아웃 변경 방지

• 🟢 0.1 이하 / 🟡 0.25 이하 / 🔴 0.25 초과
• 개선 팁
  • 이미지, 광고에 크기 속성(width/height) 명시
  • 웹 폰트 FOIT/FOUT 현상 방지(font-display: swap 사용)
  • 동적 콘텐츠 추가 시 레이아웃 예약 공간 확보

 

INP (Interaction to Next Paint)

사용자의 입력(클릭, 탭, 키 입력)에 대한 반응성 측정

사용자가 버튼을 눌렀을 때 페이지가 얼마나 빠르게 반응하는지 확인

UI 반응성이 사용자의 만족도에 직접적인 영향을 미침

• 🟢 200ms 이내 / 🟡 500ms 이내 / 🔴 500ms 이상
• 개선 팁
  • 메인 스레드 작업 최적화(long task 줄이기)
  • 필요할 때만 JS 로드(코드 스플리팅)
  • RequestAnimationFrame, requestIdleCallback 적절히 활용

 

Lighthouse

CDN적용 전은 Performance (성능)면에서 뒤쳐짐. 웹 페이지의 로딩 속도와 사용자 체감 성능이 비교적 나쁘다는 것을 의미.

 

특히 TBT에서 좋지 않은 모습을 보였다

BestPractices는 Http설정 등과 연관되어있어 다루지 않음.

 

---

새롭게 알게된 점

• S3리전을 아시아로 설정하고 진행했어서, CDN을 적용해도 크게 달라지지 않을 줄 알았는데 성능 차이가 나서 신기했다. 단순히 가까운 edge location으로 먼저 연결해주는 게 아니라는 것을 알게되었다.
• 생각보다 어렵지 않게 성능 개선하는 방법이 있다는 것을 알게 되었다.

---

궁금한 점

• 네트워킹 탭의 Stalled가 CDN도입 후 오히려 늘어나서, 이 부분을 해결하려고 여러 시도를 해보았는데 이미 잘 설정되어 있었다. 이 부분에 대해서 피드백을 받아보니 해소가 되는 느낌!

1️⃣ CloudFront 캐싱 상태(Warm-Up) 문제

CloudFront는 첫 요청 시에는 원본 S3에서 콘텐츠를 가져와야 하므로 캐시 미스(Cache Miss)가 발생합니다.

이후 요청에서는 캐싱된 콘텐츠를 제공하면서 응답 속도가 빨라지지만, 특정한 이유로 인해 캐시가 무효화되거나 만료되면 다시 원본 요청을 수행해야 하므로 Stalled 시간이 증가할 수 있습니다.

• 캐시가 완전히 빌드되기 전 테스트한 경우: 처음 요청에서는 캐싱이 적용되지 않아 Stalled 시간이 증가했을 수 있습니다.
• 테스트를 다시 실행했을 때 성능이 개선된 이유: 캐싱이 활성화되어 CloudFront의 엣지 서버에서 콘텐츠를 제공했기 때문일 가능성이 높습니다.

✅ 확인 방법

• Chrome DevTools의 Network 패널 > Headers 탭에서 x-cache 값을 확인
  • x-cache: Miss from CloudFront → 원본 요청을 수행한 상태 (Stalled 증가 가능)
  • x-cache: Hit from CloudFront → 캐싱된 콘텐츠 제공 (Stalled 감소)

✅ 해결 방법

• CloudFront 캐시를 수동으로 미리 로드(Warm-up)하는 스크립트를 사용해 초기 요청을 미리 수행
• 배포 직후 특정 페이지에 대한 사전 요청을 실행하여 주요 리소스를 캐시에 저장

2️⃣ 네트워크 상태 변동 또는 CDN 경로 변경

CDN은 요청하는 위치(사용자의 ISP, 지역 등)에 따라 라우팅되는 경로가 달라질 수 있습니다.

CloudFront의 경우 다양한 엣지 로케이션(POP, Point of Presence)이 존재하며, 사용자의 요청이 라우팅되는 경로는 CDN 내부 정책에 따라 동적으로 변경될 수 있습니다.

• 테스트를 수행했던 시간대별 네트워크 트래픽 부하 차이가 영향을 미쳤을 가능성
  • 네트워크 부하가 적은 시간대(예: 새벽)에는 더 빠른 응답
  • 트래픽이 많은 시간대(예: 저녁)에는 라우팅이 다르게 설정될 가능성

✅ 확인 방법

• CDN 라우팅 경로 및 엣지 서버 정보 확인
  • Chrome DevTools → Network 패널에서 CloudFront POP 정보를 확인
  • 예: x-amz-cf-pop: ICN50-C1 (서울 엣지 서버)

✅ 해결 방법

• 테스트할 때 같은 지역에서 같은 ISP를 사용하여 환경을 통제
• 여러 번 테스트 후 평균값을 계산하여 데이터 변동성을 줄임

3️⃣ DNS 캐싱 이슈

CloudFront는 DNS 기반으로 라우팅되므로, 로컬 DNS 캐시가 영향을 줄 수 있습니다.

• 특정한 이유로 인해 클라이언트 측에서 이전 S3 IP 주소가 캐싱된 상태에서 요청을 보낼 경우, 요청이 예상과 다르게 처리될 수 있음

✅ 확인 방법

• nslookup d2a4btkl9b5lcr.cloudfront.net (CloudFront 도메인)
• nslookup zenna-bucket.s3-website-ap-southeast-2.amazonaws.com (S3 도메인)

✅ 해결 방법

• 로컬 DNS 캐시를 플러시하고 테스트 수행
  • macOS/Linux: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
  • Windows: ipconfig /flushdns

4️⃣ 브라우저 캐시가 잘못 적용된 경우

브라우저의 캐싱 정책에 따라 일부 리소스가 로컬 캐시에서 제공되었거나, 반대로 캐시되지 않고 다시 요청되었을 가능성이 있습니다.

✅ 확인 방법

• Chrome DevTools → Network 패널에서 Size 값을 확인
  • disk cache 또는 memory cache로 표시되면 브라우저 캐시에서 제공됨
  • from CloudFront 또는 from S3이면 실제 네트워크 요청 발생

✅ 해결 방법

• 강제 새로고침 (Shift + F5)을 실행하여 브라우저 캐시를 무시하고 테스트
• 개발자 도구 > Network 패널에서 Disable Cache 옵션을 활성화하고 테스트

결론

Stalled 시간이 CDN 도입 후 오히려 늘어난 이유는 CloudFront의 초기 캐싱 상태(Warm-Up) 또는 특정 네트워크 조건(라우팅, DNS 캐시, 브라우저 캐시)의 영향을 받았을 가능성이 높음

→ 이후 다시 테스트했을 때 성능이 개선된 것은 CloudFront 캐시가 활성화되었거나, 네트워크 조건이 달라졌기 때문일 가능성이 큽니다.

💡 추가 확인할 점

1. CloudFront의 x-cache 응답 값을 확인하고, 초기 요청 시 Miss 상태였는지 체크
2. x-amz-cf-pop 값을 비교하여 다른 엣지 서버에서 요청이 처리된 것은 아닌지 확인
3. 브라우저 캐시가 영향을 주었는지 Disable Cache 설정 후 다시 테스트