들어가며
지난 포스팅에 이어 렌더링 최적화에 대해 이야기하려 합니다.
이번 포스팅과 다음 포스팅에서는 CRP가 아닌 다른 과정에서 최적화를 이룰 수 있는 어떤 방법들이 있는지 간단히 소개하려고 합니다.
리소스 요청 및 응답
CRP 과정 전에 반드시 거쳐야 할 과정은 바로 HTML, CSS, JavaScript, Font 등 렌더링에 필요한 리소스를 다운로드 받는 것입니다.
만일 파싱과 실행에 필요한 리소스 다운로드가 지연된다면 효율적으로 CRP 최적화를 위한 노력이 퇴색될 것입니다.
TCP 커넥션 관리
브라우저가 서버에 리소스를 요청하고 응답받기 위해서 먼저 TCP 커넥션이 생성되어야 합니다.
HTTP와 TCP 등의 프로토콜에 대한 내용은 다른 포스팅에서 자세히 다루려 합니다.
리소스를 응답받기까지 다음의 과정을 거치게 됩니다.
- URL에서 호스트명을 추출한다.
- 추출한 호스트명에 대한 IP 주소를 DNS 서버로부터 응답받는다. (DNS Server Recursive Query)
- 포트번호를 얻는다.
- IP주소와 포트로 TCP 커넥션을 생성한다.
- 서버로 HTTP 요청 메세지를 보낸다.
- 서버로부터 HTTP 응답 메세지를 받는다.
따라서 여러 개의 TCP 커넥션을 맺어 병렬로 리소스를 요청하는 병렬 커넥션,
TCP 커넥션을 끊지 않고 재사용하는 지속 커넥션 등을 통하여 초기 렌더링에 필요한 리소스 다운로드를 빠르게 완료시킵니다.
지속 커넥션의 경우 HTTP/1.1부터는 기본적으로 적용되어 있습니다.
병렬 커넥션 원리를 이용하여 여러 개의 도메인으로 리소스들을 요청하는 도메인 샤딩 기법이 소개되기는 하지만 권장하고 있지는 않으며, 요즘은 커넥션 관리 알고리즘이 발전된 HTTP/2로 전환하는 것을 권하고 있습니다.
WebFont 최적화
브라우저에 따라서 폰트가 다운로드되기 전에 개발자의 의도와는 다르게 렌더링 되는 현상이 있습니다.
- FOIT(Flash of Invisible Text): 폰트가 다운로드되기 전까지 텍스트가 보이지 않는 현상 (IE 브라우저)
- FOUT(Flash of Unstyled Text): 폰트가 다운로드되기 전까지 폰트가 적용되지 않은 텍스트가 보이는 현상 (IE 제외 브라우저)
웹폰트 최적화를 위하여 아래의 방법들이 제안되고 있습니다.
- 웹폰트 리소스를 미리 로드 (preload)
- JavaScript를 통해 폰트로딩 API를 사용
- 압축률 좋은 웹폰트 형식 사용
- 불필요 글자를 제거한 서브셋폰트 사용
- unicode-range 사용
마치며
다음 포스팅에서는 렌더링 최적화를 위한 또다른 방법인 Code Splitting과 Lazy loading을 간단히 정리해보겠습니다.
참고한 곳
HTTP/1.x의 커넥션 관리 - HTTP | MDN
Network DNS 과정
웹폰트 최적화 하기
