1. 강상진
sangjinn@gmail.com
웹에 날개를 달아주는
웹 성능 최적화 기법

2. 강사 소개
소개
- 강상진.
- 현) Akamai 클라우드 아키텍트(클라우드, 웹 성능, 보안, 스트리밍, ..)
- 전) Microsoft 소프트웨어 연구소 책임연구원
- 전) 삼성SDS 솔루션 개발센터 선임연구원
- 전) 성결대학교 미디어 소프트웨어 학과 겸임교수(객체지향 프로그래밍)
- 과기부 S/W Maestro 과정 기술 멘토
- 경기창조경제혁신센터 스타트업 IT기술 멘토
- 한국콘텐츠진흥원 문화 콘텐트 R&D과제 평가위원
- 테크유람 블로거 https://blog.naver.com/techtrip
- IT 도서 저자

3. 인터넷 속도의 향상

4. 우리나라는?

5. 웹의 무게도 지속적으로 증가

6. 빠른 인터넷 속도 ≠ 빠른 웹

7. 빠른 웹이 중요한 이유
https://walmart.com/

8. 웹 성능을 측정하는 방법
Google Core Web Vitals (CrUX)

9. 웹 성능을 측정하는 방법
Google Lighthouse

10. 웹 성능을 측정하는 방법
Chrome - 개발자도구

11. 웹 성능을 측정하는 방법
Chrome - 개발자도구

12. 웹 성능을 측정하는 방법
Chrome - 개발자도구

13. 웹 성능을 측정하는 방법
(WPT: WebPageTest.org)

14. 어느 구간을 개선할 것인가?
DNS time TCP연결 TLS연결 TTFB Download Rendering
백엔드 시간 프런트엔드 시간
사용자가 URL을 요청 하는 즉시 백그라운드(서버)에서 수행되는 모든 프로세스가 포함 • 실제 사용자가 웹 페이지를 볼 수 있도록 컨텐츠들을 로딩 하는데 걸리는 시간
• DOM Loading Time / DOM complete time / First Paint / FCP / LCP 등
다양한 Metric 이 front-end Time 의 지표에 포함됨.
• LCP(Largest Contentful Paint) 는 실제 사용자의 체감 성능을 측정 하는
지표로 가장 많이 사용됨.

15. 어느 구간을 개선할 것인가?
백엔드 프런트엔드
| 렌더링 완료
백엔드 프런트엔드

16. 어느 구간을 개선할 것인가?
Back-End Time
First Contentful Paint (FCP)
Largest Contentful Paint(LCP)
Page Load Time (PLT)
Loading…
FID(First Input Delay)

17. 측정과 분석의 시작
성능 측정 툴 분류 RUM(Real User Monitoring) Synthetic Tool
클라이언트
종류
실제 사용자 계측용 서버(Agent 기반)
클라이언트
위치
전체 사용자 위치
계측용 서버 설치 위치
(Node 가 없는 지역 많음)
측정 빈도 사용자 접근 시 마다
대상 Page에 대해 10회 측정 후
평균 값 적용
측정 방법 사용자 접근 시 마다 Script 생성
측정 Metric
다양한 Metric 제공
주로 Core Web Vital값 혹은 Page Load Time)
Page Load Time & LCP
한계
1. Transaction Time 을 알기 어려움.
2. 신규 페이지 오픈 전 성능 테스트 불가
1. 성능 측정 클라이언트의 위치가 벤더 사의 서버
설치 위치에 의존.
2. 실제 사용자가 느끼는 성능과 차이가 있음.
3. 제공하는 성능 Metric 이 제한적.
4. 성능과 비즈니스간의 연관 분석 불가.
5. 다양한 사용자 별 성능 측정 어려움

18. 성능 개선 방안
HOW FAST AM I? HOW FAST DO I NEED TO BE?
현재 사이트의 지연
요소를 찾아낸다
HOW DO I GET THERE?
비즈니스 영향도를
계산한다
진단하여 우선 개선할
점을 찾는다

19. 웹 사이트 성능 측정
75p
75p
75p
비즈니스 지표
Guide < 1s < 4s < 5s
< 0.1 < 100ms < 2.5s
75p
웹 성능 지표
특정 페이지
그룹이 느림
트래픽이 높은
페이지 파악
성능 KPI는 무엇으로?

20. 웹 사이트 성능 측정
LCP (6.5s) PLT(15s) PLT(12s)
LCP (3s)
Back-end
Video Video
JavaScript
JavaScript
Back-end가 bottleneck JavaScript가 bottleneck

21. 프런트엔드(Frontend) 최적화
실제 사용자 환경
(네트워크, 디바이스, 브라우저, …)에 알맞은 최적화

22. 프런트엔드(Frontend) 최적화
• 스크립트 병합 (script combination)
• 스크립트 최소화 (script minification)
• 스크립트 압축 전달 (gzip Encoding)
• 브라우저 이미지 형식 최적화 (e.g. WebP)
• 이미지 (비)손실 압축 (compression)
• 브라우저 캐시 사용 (cache-control 헤더)
• DNS 조회 최소화
• DNS 정보 미리 읽어오기 (DNS prefetching)
• CSS/JS 위치 조절 (Top/Bottom)
• 페이지 미리 읽어오기 (page prefetching)
• 서드 파티(3rd party) 스크립트 조정
• …

23. 기본적인 네 가지 최적화 방안
• 요청과 응답 회수가 적어야 한다. (less round-trip)
• 콘텐츠의 크기(file size)는 작아야 한다. (smaller size)
• 최대한 캐싱한다. (cache as much as possible)
• 사용자 환경에 최적화된 콘텐츠를 보여준다. (optimize)

24. 기본적인 네 가지 최적화 방안
• 요청과 응답 회수가 적어야 한다 (least RTT)
→ 이미지 스프라이트, 서버 푸시, 불필요한 호출 제어
• 콘텐츠의 크기는 작아야 한다 (least size)
→ 압축(brotli), 스크립트 minify, WebP, AVIF
• 최대한 캐싱(caching) 한다
→ CDN, 브라우저, WebView, ..

25. 스크립트 최적화
• 사용하지 않는 불필요한 스크립트로 인한 바이트 낭비 최소화
• Chrome ­ 개발자 도구 ­ Coverage 모듈

26. 스크립트 최적화
• 스크립트 최소화 13,292 라인, 462kb -> 8 라인, 277kb
• 스크립트 압축

27. 이미지 최적화
• 이미지 압축(불필요한 메타데이터 제거)
JPG 원본 이미지 크기: 5.8MB 이미지 압축 후 이미지 크기: 2.6MB

28. 이미지 최적화
• 최적의 이미지 형식
JPG 원본 이미지 크기: 5.8MB 이미지 압축 후 이미지 크기: 2.6MB AVIF로 변환 후 이미지 크기: 1.87MB

29. 이미지 최적화
• 최적의 이미지 형식

30. 이미지 최적화
• 최적의 이미지 형식

31. 전송 최적화
• 전달 구간 전반에서 캐싱(caching)의 활용
원본 웹 서버
CDN 중계 서버
CDN 캐싱 서버
CDN 캐싱 서버
CDN 캐싱 서버
CDN 캐싱 서버
CDN 캐싱 서버
브라우저 캐싱
브라우저 캐싱
브라우저 캐싱
브라우저 캐싱
브라우저 캐싱
브라우저 캐싱
브라우저 캐싱
브라우저 캐싱

32. 웹 성능 개선 사례
• Repeat View 느림
• LTE에서 측정한 LCP가 5.113초에 달함
• 첫 HTML 응답이 느림
• 대역폭 정상 / CPU Intensive 발견
• 웹 폰트를 로딩 후반에 다운로드(PC와 다름)

33. 웹 성능 개선 사례
• 상당 수의 웹 폰트 파일

34. 웹 성능 개선 사례
• 사용중인 도메인으로 인한 DNS 조회 증가 (with small DNS TTL)
• 내부 도메인으로 합병
• 가중치가 적은 도메인 삭제
fonts.gstatic.com (117 requests)
example.jp (56 requests)
example. example.net (15 requests)
www.google-analytics.com (7 requests)
www.google.com (5 requests)
api. example.com (4 requests)
example2. example2.net (4 requests)
www.googletagmanager.com (3 requests)
www.gstatic.com (3 requests)
fonts.googleapis.com (2 requests)
connect.facebook.net (2 requests)
googleads.g.doubleclick.net (2 requests)
www.google.com.sg (2 requests)
www.facebook.com (2 requests)
www.googleadservices.com (1 request)
stats.g.doubleclick.net (1 request)
s. example.jp (1 request)
example.yahoo.co.jp (1 request)

35. 웹 성능 개선 사례
• CDN에서 캐싱하지 않는 SVG(Scalable Vector Graphics) 파일
• 브라우저 캐싱을 충실히 사용하지 않음

36. 웹 성능 개선 사례
• gzip보다 압축률이 우수한 brotli 알고리즘 사용을 권고 (일부 발췌)
URL 현재 크기(gzip) Brotli 크기 비교
https://example.com/ 225 KB 77.2 KB -148 KB
https://example.com/_next/s%20...%20es/_app-
1d39ec2daa3c18ff.js
140 KB
127 KB
-12.3 KB
https://example.com/_next/s%20...%20fc48cbd-
b6be2ef3b0837285.js
91.7 KB 80.8 KB -11.0 KB
https://example.com/_next/s%20...%20a88be26-
d6bb8f1b57ccf153.js
68.1 KB 61.4 KB -6.7 KB
https://example.com/_next/s%20...%20ks/5529.d1217bf69
375fb8a.js
791 bytes/
451 bytes
396 bytes -395 bytes
https://example.com/images/svg/ico_head_menu.svg
500 bytes/
306 bytes
258 bytes -242 bytes
https://example.com/images/svg/ico_head_library.svg
434 bytes/
251 bytes
226 bytes -208 bytes

37. 웹 성능 개선 사례
• API 호출과 응답에 대한 최적화
• API 결과에 대한 CDN 캐싱
• API 응답 가속
• Gzip 압축에서 Brotli 압축으로 권고

38. 웹 성능 개선 사례
• 웹 폰트 최적화
Anti-Pattern Best Practice

39. 웹 성능 개선 사례
• 웹 폰트 최적화

40. 웹 성능 개선 사례
• 웹 폰트 최적화 ­ 사용하지 않는 글립에 대한 삭제 및 자체 폰트로 전환

41. 웹 성능 개선 사례
• 이미지 최적화
Input (JPEG)
Chrome (AVIF) - Perceptual Quality
- Medium High
WebP reduction
1
https://image.example.com/?view=2b5
d1a00de42413b0b3b1261e8bf42ef58
2695947b23c0ad38
Byte savings: 59.92%
(66.54 KB vs. 166.02 KB)
Quality: 87
Content-Type: image/avif
91908/170009
46% reduction
2
https://image.example.com/?view=3b0
ff26af729c7fe30a80f04900e2b382c4d
94c761ba4931d3
Byte savings: 53.95%
(60.83 KB vs. 132.09 KB)
Quality: 86
Content-Type: image/avif
83846/135263
38% reduction
3
https://image.example.com/?view=d9e
7517d365c120ba4860574073dfb3a4d
053245ae8c3310eb
Byte savings: 60.53%
(55 KB vs. 139.34 KB)
Quality: 87
Content-Type: image/avif
77462/142685
46% reduction

42. 웹 성능 개선 사례
• Lighthouse를 사용한 개선 전후의 비교

43. - 감사합니다. -