브라우저가 어떻게 웹 페이지를 사용자에게 보여주는 지 그 과정을 자세하게 아는 것은 프론트엔드 개발자에게 꼭 필요한 지식이라고 생각한다. 따라서 면접 때 충분히 물어볼 수 있고, 면접 때 설사 물어보지 않더라도, 실무에서 트러블 슈팅을 할 때 알고 있어야 하는 내용이라고 생각을 해서 나름대로 정리를 해 보려고 한다.
먼저 아래의 그림을 보자. W3에서 말하는 사용자 액션이 발생하고(ex. https://www.google.com 을 브라우저 url에 입력한다) 브라우저가 이를 감지해서 웹 페이지를 아래의 그림 순서대로 로드한다. 여기에서 노란색 부분은 웹 페이지에서 벗어난 후 문서를 읽어들이기 전을 의미하고, 파란색 부분은 자바스크립트 이벤트는 없고 전부 네트워크 레벨에서 일어나는 일이다.
첫 번째 일어나는 일은 Prompt for unload 이다. 현재 페이지에서 다른 페이지로 이동하려고 할 때 발생하는 이벤트이다. 일반적으로 뒤로 가기나 링크를 통해 다른 페이지로 이동할 때 알럿 창이 뜨는데 이 메시지를 처리하는 단계로 볼 수 있다.
두 번째로는 Redirect 이다. 여기서부터 네트워크 레벨에서 이루어지는 과정이 시작하며, 요청을 받아 HTML 등의 리소스를 브라우저로 가져오게 된다. 서버에서 Redirect 신호를 받은 브라우저는 해당 URL(https://www.google.com)로 HTTP 요청을 보낸다.
세 번째는 App Cache이다. App Cache는 HTTP 요청을 보낼 때, 해당 요청에 유효한 응답이 이미 캐싱되어 있는지를 확인한다. 서버에서 리소스를 불러오는 것에 비해 캐싱되어 있는 데이터를 가져오는 것이 성능상에 이점이 있기에 브라우저에서 퍼포먼스 향상을 위해 사용한다.
네번째는 DNS 이다. DNS(Domain Name System)는 HTTP 요청을 통해 보낸 도메인(https://www.google.com)을 실제 HTML 파일 등의 리소스를 가지고 있는 서버의 IP 주소 (ex. 8.8.8.8) 로 변환해 주는 역할을 한다. 서버 IP 주소는 32bit 혹은 48bit의 숫자값인데 이를 사용자가 직접 사용하면 어려우므로, 사용자에게 친숙한 도메인으로 매핑시켜준다.
DNS에 요청을 보내기 전에 먼저 Browser에서 해당 Domain이 캐싱 되어있는지 확인하고, 없을 경우 로컬에 저장되어 있는 hosts 파일에서 참조 가능한 도메인이 있는지 확인한다. 여기까지 해도 실패했다면, 네트워크 스택에 구성되어 있는 DNS로 요청을 보낸다. (DNS는 일반적으로 Local Router, ISP의 캐싱 DNS)
그 다음 ARP(Addres Resolution Protocol)로 대상의 IP와 MAC 주소를 알아낸다. ARP 브로드캐스트를 보내려면 네트워크 스택 라이브러리가 조회할 대상의 IP 주소와 ARP 브로드캐스트에 사용할 인터페이스의 MAC 주소를 알아야 한다. ARP 캐시는 대상 IP에 대한 ARP 항목을 확인해서 캐시가 있을 경우 MAC 주소를 반환한다. 만약 ARP 캐시가 없는 경우, local subnet을 조회해서 관련 인터페이스를 사용하거나 gateway subnet 관련 인터페이스를 통해 ARP 요청을 보낸다.
여기까지 과정을 통해 IP를 알 수 있으며, 이 IP를 가지고 TCP 통신을 통해 서버에 연결한다. (削除) 이 한 문장 안에 정말 많은 절차들이 있는데 이 부분은 따로 블로그 포스팅을 통해 설명하도록 하겠다 (TCP Socket, SSL, TLS Handshake 등) (削除ここまで)
HTTP Request를 보내면 HTML 을 Response로 받는다. (削除) 이 과정도 따로 포스팅으로 다룰 정도로 양이 많다 ᄒᄒ (削除ここまで)
그 다음은 자바스크립트가 할 일이다. Processing 에는 파일(HTML, CSS, JS, image 등)을 파싱하고 렌더링 하는 단계까지 포함한다.
- domInteractive : userAgent가 현재 문서의 준비 상태를 interactive 로 세팅하는 시점
- domContentLoadedEventStart : DOMContentLoaded 이벤트를 시작하는 시점
- domContentLoadedEventEnd : DOMContentLoaded 이벤트를 완료하는 시점
- domComplete : 현재 문서의 준비 상태를 complete로 세팅하는 시점
그렇다면 여기서 말하는 DOMContentLoaded는 어떤 이벤트일까? 이 이벤트는 초기 HTML 문서를 완전히 불러오고 분석했을 때 발생한다. 여기에는 스타일시트(CSS), 이미지, 하위 프레임의 로딩은 포함되지 않는다. DOMContentLoaded의 원본대상은 다 불러온 Document이다.
(削除) 렌더링 과정도 조만간 별도로 자세하게 포스팅으로 정리해야 할 듯.. ᄒᄒ (削除ここまで)
렌더링이 마무리 되면 마지막으로Load 과정에서는 서브리소스(이미지, 동영상 등)까지 모두 다운로드 받아서 보여준다. 이 과정에서 DOM을 생성하는 과정과 파일을 다운로드 하는 과정이 병렬적으로 수행이 된다. 기본적인 순서가 다음과 같다는 것만 알아두면 좋을 것 같다.
참고자료
https://www.w3.org/TR/navigation-timing-2/#processing-model
Navigation Timing Level 2
3.1 Relation to the PerformanceEntry interface PerformanceNavigationTiming interface extends the following attributes of PerformanceEntry interface: Note A user agent implementing PerformanceNavigationTiming would need to include "navigation" in supportedE
www.w3.org
https://jooonho.com/js/2021-01-24-timing-api/
웹 페이지 로드 과정
웹 페이지 로드 과정
jooonho.com
https://yeoulcoding.tistory.com/167
[Browser] 웹 페이지 로드 과정
위 포스팅은 W3C의 스펙과 구글 개발자 문서를 참고하여 작성되었습니다. Overview 효율적인 웹 페이지를 작성하기 위해서는 이 웹 페이지를 다운로드하고, 파싱 하고, 렌더링 해서 사용자에게 보
yeoulcoding.tistory.com
https://owlgwang.tistory.com/1
웹 브라우저에 URL을 입력하면 어떤 일이 일어날까?
우리가 흔히 쓰는 웹 브라우저(Chrome, Internet Explorer, Firefox)에 URL(Uniform Resource Locator)을 입력하고 Enter를 치면 어떻게 웹페이지가 우리 눈에 보여질까? 1. 주소표시줄에 URL을 입력하고 Enter를..
owlgwang.tistory.com
https://developer.mozilla.org/ko/docs/Web/API/Window/DOMContentLoaded_event
DOMContentLoaded - Web API | MDN
DOMContentLoaded 이벤트는 초기 HTML 문서를 완전히 불러오고 분석했을 때 발생합니다. 스타일 시트, 이미지, 하위 프레임의 로딩은 기다리지 않습니다.
developer.mozilla.org
'Web Frontend Developer' 카테고리의 다른 글
| [테스트] How To Test #1. Unit Test (feat. jest) (1) | 2021年11月24日 |
|---|---|
| [웹 프론트엔드 인터뷰] #3. React 상태관리는 어떻게 해야 하나요? (1) | 2021年11月04日 |
| [웹 프론트엔드 인터뷰] #1. 자바스크립트 엔진은 어떻게 동작하나요? (1) | 2021年08月04日 |
| React 18, 달라진 점들 (React 18, breaking points) (1) | 2021年07月28日 |
| [패캠] 프론트엔드 Back to the Basics : 지속가능한 코드 작성과 성능 향상법 강의 내용 정리 (1) | 2021年06月02日 |