[WEB_DEV] HTML 성능 최적화를 위한 일반적인 고려사항
브라우저는 크게 인터페이스/렌더링 엔진/JS엔진/네트워킹/데이터 저장소로 구분이 가능하다.
브라우저 주소창에 URL을 입력하면, 브라우저는 서버에게 GET request를 날린다. 첫 번째 웹 페이지의 요청은 HTML 소스이다. 이 HTML 이 얼마나 빨리 도착하는지가 퍼포먼스의 핵심 목표이다.
-
TTFB(Time to First Byte)를 줄이는 것이 첫걸음
초기 HTML 요청은 몇 스탭으로 나눠지는데, 각각의 스탭은 시간이 걸린다. 각각의 시간 소요를 줄이는 것이 TTFB(Time to First Byte)를 빠르게 하는 척 걸음이다. -
리디렉션 최소화
리다이랙트는 추가적인 HTTP 요청을 만들기 때문에 페이지 속도를 느리게 한다.
리다이랙트에는 두 가지 타입이 있다.
-
Same-origin 리디렉션: 자사 도메인 내의 리디렉션. 개발자가 통제 가능하므로 반드시 최소화해야 함.
-
Cross-origin 리디렉션: 외부 출처(광고, URL 단축 등)로부터의 리디렉션. 완전한 통제는 어렵지만, 체인 리디렉션(다단계 전환)을 피하는 것이 좋음.
- HTML 응답 캐싱 고려
HTML 응답을 캐싱하는 것은 어렵다. CSS, JavaScript, images, and other resource types으로 인해 동적으로 변하는 경우가 많기 때문.
이 리소스들은 독특한 fingerprint를 그들의 파일 이름에 가지고 있다.
따라서 HTML도 캐시가 되면, 참조하고 있는 파일들(JS/CSS 등)이 바뀌었을 때 문제가 생길 수 있으니 주의가 필요
c.f. 이런 방식의 이름을 "콘텐츠 기반 해시" 또는 "핑거프린트" 라고 한다.
JavaScript (main.abc123.js)
CSS (style.d34e5f.css)
이미지 (logo.9c7a8e.png)
폰트, SVG 등- 왜 해시를 파일 이름에 넣을까?
이유: 캐시 무효화(캐시 버스팅)
브라우저는 정적 파일을 캐싱해두기 때문에, 파일 이름이 바뀌지 않으면 예전 파일을 계속 사용할 수 있음. 하지만 해시가 들어가 있으면, 파일 내용이 조금이라도 바뀌면 파일 이름도 바뀌므로, 브라우저는 새로운 파일로 인식하고 최신 파일을 다시 다운로드함
그럼에도 불구하고 캐시를 아예 안 하는 것 보단 캐시 수명을 갖는 것이 더 이점이 있다.
- CDN에서 HTML을 캐시할 수 있게 되어, 원본(origin) 서버로의 요청 수가 줄고
- 브라우저에서도 HTML을 재검증(revalidate) 할 수 있어, 완전히 다시 다운로드 받는 대신 갱신 여부만 확인하고 빠르게 사용 가능
서울에 있는 A 사용자가 https://example.com/ 에 처음 접근 → CDN 서울 엣지 서버는 원본 서버에서 HTML을 받아와 캐싱.
이후:
같은 지역의 B, C 사용자도 접근 → 같은 캐시된 HTML을 응답받음 (서버까지 안 감)
뉴욕에 있는 D 사용자가 접근 → 뉴욕 엣지 서버에는 캐시 없음 → 원본 서버 요청 후 별도 캐시됨ETag란?
ETag = Entity Tag
HTTP 응답 헤더 중 하나로, 서버가 리소스의 버전을 구분하기 위해 만들어내는 고유한 식별자
이 값이 바뀌면 "내용이 바뀌었다"고 간주
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"