🌐 웹페이지를 표시한다는 것: 브라우저는 어떻게 동작하는가

• 사용자에게 빠른 로딩과 원활한 상호작용을 제공하기 위한 MDN 가이드를 읽으면서 작성한 글입니다.
  https://developer.mozilla.org/ko/docs/Web/Performance/Guides/How_browsers_work

• (원문)🌐 Populating the page: how browsers work
  https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/How_browsers_work#paint

🐶 개요

브라우저는 싱글 스레드!

• UI 렌더링, 이벤트 처리, JS 실행 등이 모두 메인 스레드에서 처리됨.
• 무거운 작업이 메인 스레드를 점유하면 사용자 상호작용이 지연됨. (지연 Latency 발생)

💡 개선 아이디어

• 상호작용 보장: 큰 요청은 나눠서, 필수 리소스를 먼저 패칭하고 나머지는 로딩 UI와 함께 보여줄 수 있다.
• 메인 스레드의 책임 줄이기: 랜더링이 지연되는 현상이 발생한다면? 브라우저가 싱글 쓰레드인 점을 생각하여 프로파일러에서 점유하고 있는 특정 스크립트의 이름을 확인하고 이를 디버깅할 수 있다.

빠르게 로딩하기 위한 전략

1. 빠르게 요청하기

• HTML 파싱 중 <link>, <script>(defer와 async가 있는 경우) 와 같은 리소스를 만나면 파싱 도중에 요청됨
• 중요한 리소스는 우선순위(priority) 또는 프리페치(prefetch)를 활용

2. 중요한 리소스는 미리/먼저 요청

• rel="preload": 명시적으로 우선 로딩할 리소스를 지정
• rel="prefetch": 나중에 필요할 리소스를 미리 받아두기
• 화면을 그리는 데 필요한 CSS/JS는 가능한 초기 14KB에 포함해 TTFB 이후 빠르게 파싱할 것

---

📡 탐색(Navigation)

DNS 조회(DNS Lookup)

1. URL 입력 / 링크 클릭 / 폼 제출 이 발생했을 때
2. DNS 조회 (최초 방문 시)
   • 클라이언트 → DNS 서버 → IP 주소 반환
   • 만약 최초 방문이 아니라면 캐싱된 IP 검색

TCP Handshake

• SYN → SYN-ACK → ACK
• TCP 소켓 연결을 맺기 위한 3-way handshake

TLS Handshake (HTTPS)

• ClientHello → ServerHello + 인증서 → clientKey → 암호화 설정 완료
• TLS 세션 재사용 시 Session ID or Ticket로 빠르게 재연결(ClientHello에 Session Ticket을 확장 필드에 포함하여 보냄)

---

📬 응답(Response)

TTFB (Time to First Byte)

• TCP가 연결되고 나면, HTTP GET 요청을 보냄. 이 요청의 첫 응답 바이트가 도달하기까지의 시간

TCP 세그먼트:

• TCP는 데이터를 포트 번호, 시퀀스 번호, 플래그 등 TCP 헤더를 붙여서 함께 세그먼트로 나누어 전송.
• 세그먼트는 IP 계층으로 전달되어 패킷으로 변환된 후, 라우팅을 통해 목적지로 전송.

데이터의 형태는?

• HTTP: 헤더 + 바디로 구성된 텍스트 데이터.
• WebSocket: 초기 핸드셰이크는 HTTP, 이후 바이너리 데이터 전송.
• HTTPS: TLS로 암호화된 바이너리 데이터.
• TLS 핸드셰이크: 암호화 협상을 위한 바이너리 데이터 (Wireshark 툴로 해석)

ACK

• TCP는 일정 수의 세그먼트를 전송한 뒤 ACK 패킷으로 순서를 확인하고 승인받음
  • 예: ACK 1001 → "다음에 1001번부터 보내줘"
• 클라이언트가 세그먼트를 과도하게 수신하면 처리 불가 → ACK 지연 또는 누락 발생
• 서버는 계속 데이터 전송하지만, 클라이언트는 수신하지 못해 혼잡 발생
  • 이러한 상황을 방지하기 위해 혼잡 제어(Congestion Control)가 필요

슬로우 스타트

• TCP는 처음엔 전송 속도를 혼잡 윈도우(CWND)를 사용하여 점진적으로 증가
  • ACK 수신 시, 2배 증가
  • 패킷 손실 발생 시, 절반 감소
• 예시: 1 → 2 → 4 → 8 MSS (MSS는 1460바이트)

---

📖 구문 분석(Parsing)

HTML 파싱 흐름

• HTML → 토크나이징 → DOM 생성
• <script> 태그는 기본적으로 파싱 중단
  • async: 다운로드 병렬, 실행 즉시
  • defer: 다운로드 병렬, 파싱 완료 후 실행

프리로드 스캐너(Preload scanner)

• 파싱과 병렬로 실행되어 CSS, JS, 웹 폰트 등 우선순위 높은 리소스를 미리 요청 (브라우저가 처리)
• 리소스 로딩 지연 방지, 렌더링 시간 단축

CSSOM 구축(Building the CSSOM)

• CSS도 파싱되어 스타일 규칙 트리(CSSOM) 생성
• DOM + CSSOM → 렌더 트리 생성
  - 렌더 트리에는 화면에 직접 표시되는 노드만 포함됨
  

💡 CSSOM 빌드는 병목 구간인가?

개발자 도구에서 찾아볼 수 있는 Recalculate Style은 (CSS 구문 분석 + 스타일 트리 생성 + 재귀 계산)을 포함한 전체 시간을 표시합니다.

이는 전체 단계가 빠르게 처리되며, DNS 조회 1번보다 짧은 시간에 계산되기 때문입니다.

🤔 CSS가 실제 성능에 영향을 주는 구간

• 리플로우(Reflow): 나중에 발생하는 레이아웃 재계산
• 레이아웃 쉬프트(Layout Shift): 요소 위치 변경으로 인한 프레임 드롭 유발

Javascript 컴파일(JavaScript Compilation)

실행 흐름

• JavaScript는 파싱 → AST(Abstract Syntax Tree) 생성
• 인터프리터가 AST를 읽어 바이트 코드(기계가 해석할 수있는 중간 코드)로 변환
• JIT(Just-In-Time) 컴파일러가 반복되는 핫스팟 코드를 감지해 네이티브 머신 코드(어셈블리어 수준)로 최적화
• 웹 워커 등을 통해 멀티 스레드로도 처리 가능

🧵 Web Worker vs Promise

Promise

• 비동기 작업을 메인 스레드에서 예약
• 백그라운드에서 실행되지만, 콜백이 실행되는 시점엔 메인 스레드 사용
• 즉, CPU 집약적인 작업이 promise 콜백 안에 있다면 → 메인 스레드 점유 → 렌더링 지연 발생 가능

Web Worker

• 메인 스레드와 완전히 분리된 실행 환경
• 별도 스레드에서 실행 → 렌더링 차단 없이 무거운 작업 가능
  • 단, 메모리 소비 증가
• 메인과 워커 간 직접 DOM 접근 불가, 오직 메시지 큐로 통신 ✨

접근성 트리 구축(Building the Accessibility Tree)

• 브라우저가 DOM/CSSOM에서 파생해 생성
• 내용(name), 역할(role), 상태(state), 설명(description) 포함
• 스크린 리더는 접근성 트리를 통해 웹 콘텐츠에 접근

AOM이란?

https://wicg.github.io/aom/explainer.html

• AOM(Accessibility Object Model)은
  웹 개발자가 접근성 트리를 직접 제어할 수 있도록 하는 API
• 기존에는 aria-* 속성으로만 제한된 접근성 제어가 가능했지만,
  AOM을 사용하면 JS에서 보다 동적으로 접근성과 관련된 속성을 관리할 수 있게 됨

---

🎨 렌더(Render)

1. 스타일(Style)

• 랜더 트리 만들기 (CSSOM + DOM 매칭, 상속/캐스케이딩 계산)
• 화면에 그려지지 않는 요소는 렌더 트리 합성에서 빠짐

2. 레이아웃(Layout)

• 각 요소의 위치와 크기 계산: 뷰포트를 고려하고 박스 모델의 속성으로 계산
• 이미지 등 비동기 요소는 공간을 확보해두고 나중에 채움

3. 페인트(Paint)

• 페인트 과정에서 그려지는 첫 페인트를 FMP라 함(First Meaningful Paint)
• 요소들을 픽셀로 변환(레스터화)
• 리페인팅을 빠르게 하기 위한 GPU 레이어
  • GPU 레이어 유도: video, canvas, 특정 CSS 속성을 가진 요소(opacity, transform, will-change)
  • 과도한 레이어 생성은 메모리 낭비 주의

4. 합성(Compositing)

• 레이어를 병합하여 최종 화면 출력
• 페이지가 계속해서 자원을 로드하면 리플로우가 발생할 수 있음(이미지 로드)

---

상호작용(Interactivity)

• 브라우저가 페이지를 로드한 후, onLoad 이벤트가 발생하고 코드 실행이 시작되면 메인 스레드가 작업을 처리하고 있으므로 상호작용(인터랙션)이 지연될 수 있음
• TTI(Time to Interactive): 사용자가 페이지와 상호작용할 준비가 완료될 때까지의 시간을 측정하는 지표