스티븐 루딘, 하비에르 가르사 님의 "러닝 HTTP/2" 책을 정리한 글입니다.
1. 오늘날의 성능 문제
- 페이지 내 수 백개의 개체, 수천 개의 도메인, 변동이 심한 네트워크, 광범위한 디바이스 기능이 존재하는 환경
- 일관되고 빠른 웹 경험을 만들어 내는것은 쉬운 일이 아님
- 사용자와의 상호작용을 원활하게 하기 위해 웹 페이지 렌더링 단계마다 내재된 문제를 이해하는것이 필요함
웹 페이지의 요청 과정
- 브라우저에서 링크를 클릭해서 웹 페이지가 표시될 때까지 일어나는 일을 이해하는 것이 중요
- 브라우저는 웹 페이지에 필요한 모든 정보를 반복적으로 요청하는 방식으로 일함
fetching
| 단계 | 설명 |
| 1️⃣ Fetch Queue 추가 | 가져올 URL을 fetch queue에 push |
| 2️⃣ DNS 조회 | 호스트 이름(IP 주소) 조회 |
| 3️⃣ TCP 연결 |
호스트로 TCP 연결 시도 (HTTPS인 경우 TLS 핸드셰이크 포함)
|
| 4️⃣ 요청 전송 | 웹 서버로 요청(Request) 전송 |
parsing & rendering
| 단계 | 설명 |
| 1️⃣ 응답 수신 | 서버로부터 응답(Response) 받기 |
| 2️⃣ HTML 파싱 | HTML 문서 분석 |
| 3️⃣ Fetching 요청 시작 |
CSS, JS, 이미지 등 추가 리소스 요청 (우선순위 고려)
|
| 4️⃣ 렌더링 시작 | 필수 개체 다운로드 완료 후 화면 그리기 시작 |
| 5️⃣ 렌더링 반복 |
추가 개체 다운로드 완료 시, 화면 업데이트 반복
|
- 이러한 반복적인 절차는 네트워크와 디바이스에 부담을 줌
- 최적화와 성능 튜닝이 필요함
중요 지표
| 성능 요소 | 설명 |
| 지연 시간 (Latency) |
IP 패킷이 한 지점에서 다른 지점으로 이동하는 데 걸리는 시간. 성능의 주요 병목점.
|
| 왕복 시간 (RTT) |
요청이 전송되고 응답이 돌아오는 데 걸리는 시간.
|
| 대역폭 (Bandwidth) |
네트워크가 초당 전송할 수 있는 최대 데이터 양.
|
| DNS Lookup |
도메인 네임을 IP 주소로 변환하는 과정. 호스트 이름당 한 번만 수행됨.
|
| 연결 시간 |
TCP 연결을 설정하는 시간 (3-way Handshake).
|
| TLS 협상 기간 |
HTTPS 요청 시 TLS 암호화가 설정되는 시간.
|
| TTFB (Time To First Byte) |
클라이언트가 페이지 탐색을 시작한 후 서버의 첫 번째 바이트를 받을 때까지 걸리는 시간.
|
| 콘텐츠 다운로드 시간 | 페이지 콘텐츠가 다운로드되는 시간. |
| 렌더링 시작 시간 |
브라우저가 처음으로 화면에 콘텐츠를 그리기 시작하는 시간.
|
| 문서 완성 시간 |
웹 페이지의 DOMContentLoaded 이벤트가 발생하는 시점.
|
성능 저하 요인
| 요인 | 설명 |
| 바이트 수 증가 |
전송되는 데이터의 크기가 커질수록 성능 저하.
|
| 개체 수 증가 |
웹 페이지 내 이미지, 스크립트, 스타일시트 등 개수가 많을수록 요청이 증가하여 성능 저하.
|
| 복잡도 증가 |
웹 페이지의 구조가 복잡해질수록 렌더링 속도가 느려짐.
|
| 호스트 수 증가 |
요청해야 할 도메인이 많아질수록 DNS Lookup 및 연결 시간이 증가하여 성능 저하.
|
| TCP 소켓 수 증가 |
호스트 수 증가로 인해 동시에 열려 있는 TCP 연결 수가 많아지면 네트워크 병목 발생 가능.
|
HTTP/1.0의 문제점
| 문제 | 설명 | 주요 원인 | 영향 |
| HOL 블로킹 (Head-of-Line Blocking) |
HTTP/1은 파이프라이닝을 지원하지만, 응답이 순서대로 도착해야 함 |
요청 순서대로 응답을 받아야 하므로, 앞선 요청이 지연되면 뒤 요청도 대기 |
페이지 로딩 지연 |
| TCP의 비효율적 사용 | TCP 혼잡 제어는 공평한 트래픽 처리를 위해 설계됨 | 최적의 혼잡 윈도우 크기를 얻으려면 여러 번의 왕복이 필요함 | 전송 속도 저하 |
| 비대한 메시지 헤더 | HTTP/1은 메시지 헤더를 압축하지 않음 | 요청 헤더 크기가 커서 불필요한 데이터 전송 증가 |
대역폭 낭비
속도 저하 |
| 제한적인 우선순위 지정 | 개체 간 우선순위를 설정할 수 있는 옵션이 제한적 | 중요하지 않은 개체도 대기 상태로 빠짐 |
중요한 리소스 로딩 지연
|
| 서드파티 개체 문제 | 웹 페이지에는 제어 불가능한 외부 리소스(서드파티 개체)가 포함됨 | 외부 리소스가 느리면 전체 페이지 로딩이 지연됨 | 성능 저하 |
2. 웹 성능 기법
<!--td {border: 1px solid #cccccc;}br {mso-data-placement:same-cell;}-->
| 연도 | 주요 인물/기업 | 내용 |
| 2000년대 초 | 스티브 사우더스 | 웹 브라우저에서 웹 페이지 로딩 속도를 높이는 기법을 제시 |
| 웹 사이트 최적화 기법을 정리한 『초고속 웹사이트 구축』 저술 | ||
| 2010년 | 구글 | 성능이 비즈니스에 미치는 영향을 연구 |
| 성능을 URL 순위 선정의 주요 파라미터로 추가하여 검색 랭킹에 반영 |
웹 성능 모범 사례
| 카테고리 | 모범 사례 | 설명 및 최적화 방법 |
|
DNS 조회 최적화
|
고유한 도메인/호스트 수 제어 | 불필요한 DNS 조회를 줄여 지연 시간 감소 |
| 조회 지연 시간 줄이기 | 도메인 이름을 캐싱하여 재사용 | |
| rel="dns-prefetch" 활용 | 미리 DNS 조회 수행하여 페이지 로딩 속도 개선 | |
|
TCP 연결 최적화
|
rel="preconnect" 활용 | 필요한 호스트에 미리 연결을 수립하여 TCP/TLS 핸드셰이크 단축 |
| 조기 종료 사용 (CDN 활용) | 데이터가 가까운 위치에서 제공되도록 설정 | |
| TLS 모범 사례 적용 | 최신 TLS 버전 사용, 세션 재사용 활성화 | |
|
리다이렉션 최소화
|
리다이렉션 사용 자제 | 불필요한 추가 연결 방지 |
| CDN 활용 | 클라우드에서 리다이렉션 수행하여 성능 최적화 | |
| 서버의 Rewrite Rules 활용 | 동일한 호스트에서 리다이렉션을 최소화 | |
|
클라이언트 캐싱
|
Cache-Control의 max-age, Expires 설정 | 요청 횟수 감소 및 성능 개선 |
| 적절한 TTL 설정 | 정적 콘텐츠는 길게, 동적 콘텐츠는 세션 시간 2배 정도 캐싱 | |
|
네트워크 경계에서 캐싱
|
CDN 활용 | 여러 사용자가 동일한 캐시를 활용 가능 |
| 민감한 데이터 캐싱 금지 | 개인정보 및 실시간 데이터는 캐싱하지 않음 | |
|
조건부 캐싱
|
If-Modified-Since 활용 | 콘텐츠가 변경되지 않았을 경우 304 응답 반환 |
| ETag 활용 | 개체 변경 여부를 엔티티 태그를 통해 판별 | |
|
압축과 축소화
|
Gzip, Brotli 활용 | 텍스트 콘텐츠 크기 최대 90%까지 압축 가능 |
| CSS/JS 축소화 | 불필요한 공백, 주석 제거로 파일 크기 감소 | |
|
CSS/JS 차단 피하기
|
CSS는 문서의 <head>에 배치 | 초기 렌더링이 차단되지 않도록 최적화 |
| JS의 async 속성 사용 | 실행 순서가 중요하지 않을 때 병렬 다운로드 | |
| JS의 defer 속성 사용 | 실행 순서가 중요하지만, DOM 로딩 이후 실행 가능할 때 사용 | |
|
이미지 최적화
|
불필요한 오버로딩 방지 | 화면보다 큰 이미지 불필요하게 줄이지 않도록 설정 |
| 메타데이터 제거 | 파일 크기 감소 및 성능 최적화 |
조건부 캐싱
- 클라이언트가 서버에 그 개체가 변경되었으면 보내주고, 그렇지 않으면 그냥 동일하다 알려달라 요청하는 기능
- 캐시 TTL이 만료되면, 클라이언트는 서버에 요청을 보냄
- 대부분 그 응답은 캐싱된 사본과 동일할 것이므로, 조건부 기능을 활용함
- 자주 변경되지 않지만, 최신 버전을 사용해야 할 경우 사용
JS 차단 피하기
- JS는 기본적으로 HTML 내의 코드가 위치한 지점에서 반입되어 파싱되고 실행됨
- 브라우저는 이 작업이 끝날 때까지 자원 다운로드 및 렌더링이 차단됨
- 기본적인 차단 동작은 대게 불필요한 지연을 발생시키고 단일 장애점을 유발할 수 있음
- 경우에 따라 차단을 푸는것이 성능상 좋을 수 있음
안티 패턴
| 기법 | 설명 | HTTP/2 영향 |
| 스프라이팅 | 여러 개의 작은 이미지를 하나의 큰 이미지로 통합 한 번의 요청으로 처리 |
병렬 요청이 가능한 HTTP/2에서는 불필요 |
| 샤딩 | 여러 개의 호스트 이름을 사용하여 다중 연결을 열기 병렬 다운로드 수행 |
HTTP/2에서는 샤딩 해제 과정이 번거로움.
대신 공통 인증서를 활용한 연결 수립 수 감소가 유리 |
| 쿠키 없는 도메인 | HTTP/1에서는 쿠키 크기를 줄이기 위해 쿠키가 필요 없는 정적 콘텐츠(이미지, CSS, JS 등)를 별도 도메인에서 제공 |
HTTP/2에서는 헤더 압축과 헤더 이력 저장이 가능하여 쿠키 없는 도메인이 불필요
|
쿠키 없는 도메인
- 웹 페이지를 요청할 때 모든 요청에 쿠키가 포함됨.
- 정적 콘텐츠(이미지, CSS, JS 등)에는 쿠키가 필요 없지만, 브라우저는 모든 요청마다 쿠키를 전송해야 했음.
- 불필요한 데이터 전송으로 인해 네트워크 대역폭이 낭비됨.
- 정적 콘텐츠(이미지, CSS, JS 등)를 쿠키가 없는 별도의 도메인에서 제공하여 쿠키 전송을 방지함.
- www.example.com (쿠키 사용, 동적 콘텐츠 처리)
- static.example.com (쿠키 없이 정적 콘텐츠 제공)
'Network' 카테고리의 다른 글
| [러닝 HTTP/2] 5. HTTP/2 프로토콜 (0) | 2025.03.30 |
|---|---|
| [러닝 HTTP/2] 4. HTTP/2로의 전환 (0) | 2025.03.30 |
| [IBM Technology] What are DNS Zones And Records? (0) | 2025.03.29 |
| [IBM Technology] What is DNS? (0) | 2025.03.29 |
| [러닝 HTTP/2] 2. HTTP/2 맛보기 (0) | 2025.03.29 |