URL 하나 입력하는 순간 생각보다

많은 프로세스와 스레드가 동시에 움직인다

1. Handling Input

브라우저 주소창에 입력하는 순간부터 이미 처리가 시작된다.

예를 들어:

apple

를 입력했다고 하자.

실제 브라우저는 먼저

"이게 URL인가?"
"검색어인가?"

를 판단한다.

검색어로 판단이 되면

https://www.google.com/search?q=apple

같은 형태로 변환한다.

2. Start Navigation

그 다음 실제 페이지 이동이 시작된다.

이 단계에서

로딩 스피너 표시
DNS 조회
네트워크 연결 준비

같은 작업이 진행된다.

DNS 조회도 여기서 발생한다

브라우저는 도메인을 직접 이해하지 못한다.

즉

example.com
↓
93.xxx.xxx.xxx

로 IP를 찾아야 한다.

리다이렉트도 여기서 처리된다

예를 들어 서버가

301 Moved Permanently

를 반환하면 브라우저는 새 URL로 다시 요청한다.

처음엔 리다이렉트를 단순 서버 기능으로만 봤는데, 실제로는 브라우저 네비게이션 흐름 자체에 포함되어 있었다.

3. Read Response

서버 응답을 받은 뒤 브라우저는

"이게 뭐지?"

를 판단한다.

Content-Type이 왜 중요한가

예를 들어

Content-Type: text/html

이면 HTML 렌더링.

Content-Type: image/png

이면 이미지 처리.

application/json

이면 API 데이터.

즉 브라우저는 Header를 보고
“이 데이터를 어떻게 처리할지” 결정한다.

MIME Type Sniffing

브라우저는 서버 헤더가 틀렸을 수도 있다고 가정한다.

그래서 일부 데이터를 직접 읽어서 타입을 재판단하기도 한다.

이 과정이 MIME Type Sniffing이다.

CORB

CORB(Cross-Origin Read Blocking)는
다른 출처의 민감한 데이터를 Renderer Process로 넘기지 않는 정책이다.

예를 들어 JSON API 응답 같은 것들.

4. Find Renderer Process

이후 브라우저는

"이 페이지를 어떤 Renderer Process가 처리할까?"

를 결정한다.

Renderer Process는 실제 페이지를 실행한다

HTML 파싱, CSS 처리, JS 실행, 렌더링.

전부 여기서 수행된다.

즉 우리가 React/Next.js 앱을 실행한다고 생각하지만,
실제로는 브라우저 Renderer Process 안에서 실행되고 있다.

왜 탭마다 프로세스를 나누는지

예전엔 메모리 낭비 아닌가 싶었다.

근데 이유가 있었다.

예를 들어 어떤 탭에서 문제가 생겨도

한 탭 오류
≠ 브라우저 전체 종료

가 가능하다. 그리고 보안 격리도 강화된다.

즉 멀티 프로세스 구조 자체가 안정성과 보안 전략이다.

5. Commit Navigation

여기서 실제 페이지 렌더링이 시작된다.

예를 들어

주소창 업데이트
HTTPS 자물쇠 표시
뒤로가기 히스토리 추가
로딩 상태 변경

전부 여기서 반영된다.

HTML 파싱

그 다음부터

DOM 생성
CSSOM 생성
Render Tree
Layout
Paint
Composite

렌더링 파이프라인이 이어진다.

즉 이전에 공부했던:

Reflow
Repaint
FCP
LCP

전부 이 흐름 위에서 동작하고 있다.

Browser 작동순서