브라우저가 렌더링을 준비하는 과정
브라우저 주소창에 주소를 입력한 후에, 브라우저에 초점을 맞춰 렌더링이 되기 전까지의 과정을 상세히 기록한 것이다.
우리가 알고, 칭하는 '렌더링' 까지 오기까지 '브라우저는 어떤 과정을 거치며, 대체 누가 언제 이런 일을 하는것이가' 의 막연한 궁금증으로 아래처럼 정리하게 됐다.
1. Handling inputs (주소창에 URL 입력)
: 브라우저 프로세스 안의 UI 프로세스가 주소값을 URL인지 search query 인지 판단한다.
- search query라면 검색 엔진으로 보내서 검색 준비
- URL이라면 네트워크 프로세스로 URL 값을 전달 준비
2. Start Navigation (엔터키 입력)
- UI 프로세스가 network call initiates과 URL을 전달하며, 렌더러 프로세스를 대기시킨다.
여기서 network 관련 행동을 왜 UI 프로세스가 하는걸까?
그 이유는 브라우저의 UI 에 있다. 주소창에 enter를 입력하면 보통 탭 앞에 로딩되는 UI 를 경험할 수 있을 것이다.
이것을 UI 프로세스가 알고 있어야 Loading spinner (로딩되는 아이콘) 을 생성할 수 있기때문에 UI 프로세스가 관여한다.
- 네트워크 프로세스가 DNS 연결, TLS 연결 생성
- HTTP response code가 301일 경우, UI 프로세스로 redirect 전달한다. 아닐 경우 3번 과정으로 넘어간다.
3. Read reponse (response body가 네트워크 프로세스로 들어올 때)
: 네트워크 프로세스가 response body의 데이터 타입을 확인한다. (content-type, MIME type sniffing)
- HTML 형식은 렌더러 프로세스에게 파일 전달 준비 (HTML 형식이 아닐 경우, 다운로드 매니저에게 파일 전달 준비)
- SafeBrowsin과 CORB 과정을 통해 안정성을 검증한다.
4. Find Renderer process (네트워크 프로세스의 값을 본 후에 브라우저가 사이트를 이동할 때)
- 네트워크 프로세스가 UI 프로세스에게 준비 신호
- UI 프로세스가 2번과정에서 미리 대기시킨 렌더러 프로세스에게 네트워크 프로세스의 결과값을 전달
5. Commit Navigation (렌더링 과정 직전에 발생하는 과정)
- 렌더러 프로세스에게 commit navigation 이라는 확인이 전달되면 document loading phase가 시작된다. ( 이로 인해, 페이지가 전부 로딩되지 않았음에도 브라우저에서 뒤로가기 혹은 중지하기 등의 기능을 실행할 수 있다.)
주소창 업데이트
security indicator(주소창 왼쪽에 자물쇠 모양)
session history 업데이트 (앞/뒤로 페이지 이동, 창닫기 시 복원 기능)
