브라우저의 웹 페이지 동작 이해

https://developer.mozilla.org/ko/docs/Web/Performance/Guides/How_browsers_work

웹페이지를 표시한다는 것: 브라우저는 어떻게 동작하는가 - 웹 성능 | MDN

 

상단의 포스팅을 읽고 단순히 정리해놓은 글입니다.

자세한 내용은 해당 포스팅을 참고 부탁드립니다.

 

---

웹 성능의 주요 포인트

- 지연시간 단축
    - 네트워크 지연시간 & 웹 최적화 (페이지 로드시간 단축)
- 브라우저의 싱글 스레드 동작
    - 렌더링 시간 단축
    - 메인 쓰레드의 책임 감소

웹 최적화의 목표

탐색이 완료될 떄까지의 시간 최소화

 

브라우저 웹 페이지 동작 순서(단계)

1. 탐색 (Navigation)

1. DNS 조회 (DNS Lookup)
   • 입력받은 도메인 주소 조회 (DNS 서버에서 IP 주소 응답) : 최초 요청 이후 일정 기간 IP 캐싱
   • DNS 조회는 호스트 이름 하나당 한 번 수행됨 (따라서 사용하는 자원이 서로 다른 호스트 이름을 가지고 있다면 DNS조회는 각각 모두 수행됨)
   • 모바일 네트워크 환경의 경우, DNS 서버 접근 이전 Cell Tower 접근이 선행되어야 하므로 추가적 지연시간이 발생함.
2. TCP 핸드셰이크(TCP Handshake) 를 통한 서버와 연결 설정
   • 데이터 전송 전 통신하려는 두 주체가 TCP 소켓 연결을 위한 매개변수를 주고받기 위하여 생긴 방식
   • TCP 3방향 핸드셰이크 (SYN-SYN-ACK) 기술을 주로 사용하나 봄 : 두 컴퓨터 간 TCP 세션을 협상하고 시작하기 위해서 TCP 가 3번의 메시지를 전달함
3. TLS 협상 (TLS Negotiation)
   • 보안성 있는 연결을 위한 핸드셰이크로 HTTPS 통신 시 추가되는 절차
   • 통신 암호화에 쓰일 암호를 결정, 서버 확인, 실제 데이터 전송 전 안전한 연결이 이루어지도록 함

2. 응답 (Response)

• 유저 대신 초기 HTTP GET Request 를 보냄 (주로 HTML 파일을 요청함)
• 혼잡제어 (Congestion control) / TCP 슬로우 스타트 (TCP Slow Start)
  • TCP 패킷은 전송 중 세그먼트로 분할되며 순서 보장을 위해 서버는 일정 개수의 세그먼트를 전송한 후 클라이언트로부터 ACK 패킷 형태의 승인을 받아야 함
       -> 빈번한 ACK는 전송 시간 증가를 유발하므로 TCP 슬로우 스타트 알고리즘을 사용함
            => 최대 네트워크 대역폭이 결정될 때까지 전송되는 데이터의 양을 점차적으로 늘리고 네트워크 부하가 높은 경우엔 전송되는 데이터의 양을 줄임

3. 구문 분석 (Parsing)

- 브라우저가 네트워크를 통해 받은 데이터를 DOM 이나 CSSOM으로 바꾸는 단계

- 마크업을 내부적으로 DOM으로 표현

요청된 HTML 페이지의 크기가 초기 패킷의 크기인 14kb 보다 크더라도 브라우저는 구문 분석을 시작하며 가지고 있는 데이터 수준에서 렌더링을 시도함
      => 웹 성능 최적화에서 첫 14kb에 페이지 렌더링에 필요한 모든 것(최소한 페이지의 템플릿)이 포함되어야 하는 이유

 

1. DOM 트리 구축 (Building the DOM tree)
   • 브라우저가 DOM 트리를 만드는 프로세스는 메인 쓰레드를 차지함
   • 프리로드 스캐너(Preload Scanner)
     • 사용 가능한 컨텐츠를 분석하고 우선순위가 높은 자원(CSS, Javascript, 웹 폰트 등)을 미리 요청함 -> 블록킹 감소
     • javascript의 분석 및 실행순서가 중요하지 않다면 async / defer 속성 이용 (CSS 다운은 HTML 분석 및 다운을 막지 않지만 javascript의 실행을 막음)
2. CSSOM 구축 (Building the CSSOM)
   • HTML DOM 트리를 구축하는 프로세스를 CSS 에 대해 한번 더 진행.
   • CSSOM을 만드는데 드는 시간은 일반적으로 한 번의 DNS 조회를 하는 시간보다 짧기 때문에 웹 성는 최적화 관점에서 큰 기여를 할 수 있는 영역은 아님
   • Javascript 컴파일 : javascript는 구문 분석 시 추상 구문 트리로 분석됨
   • 접근성 트리 구축 : 브라우저는 접근성 트리를 만들며 보조장치는 이 트리를 이용해 내용을 분석하고 해석함 (DOM 이 업데이트 될 때, 접근성 트리도 업데이트함.
3. 스타일 (Style)
   • DOM 트리의 루트부터 시작하여 눈에 보이는 노드를 순회하며 렌더 트리를 만듬
     예시) display : none 의 경우 화면에 나타나지 않으므로 렌더 트리에 포함되지 않지만 hidden 의 경우 자리를 차지하기 때문에 렌더 트리에 포함됨
4. 레이아웃 (Layout)
   • 렌더 트리가 한 번 만들어지고 난 후, 렌더 트리를 기반으로 레이아웃이 시작됨
   • 처음 노드의 사이즈와 위치가 결정되는 것을 '레이아웃'이라고 부름
   • 이후 노드의 크기와 위치를 다시 계산하는 것을 '리플로우' 라고 부름
5. 페인트 (Paint)
   • 계산된 각 박스를 실제 화면의 픽셀로 변환하여 화면에 페인팅 하는 것.
   • 페인팅은 레이아웃 트리의 요소를 레이어로 분리할 수 있는데, 컨텐츠를 CPU 의 메인스레드에서 GPU 레이어로 격상하는 것은 (리)페인트 성능을 높임
     (<video>, <canvas>, opacity, 3D transform, will-change 등의 요소 및 속성으로 레이어 가동)
   • 레이어는 성능을 향상시키나 메모리 관리 측면에서 비싼 비용을 차지함 -> 웹 성능 최적화 전략으로 과도하게 사용 금물
   • 합성 (Compositing)
     • 다른 레이어에서 그려진 문서의 각 섹션을 올바른 순서로 화면에 그리며 정확한 렌더링을 보장하기 위해 합성이 이루어짐
     • 합성에서 고려해야할 사항
       1. 반복적 리플로우 (페이지가 계속해서 자원을 로드하는 경우, 소스가 도착이 늦어져 리플로우 유발)
       2. 리페인트 / 재합성 유발 (경우에 따라 레이아웃 단계로 다시 돌아갈 수도 있음(예를 들어 이미지 크기가 정해지지 않았던 경우))

 

4. 상호작용 (Interactivity)

페이지 그리기에 완성했다 하더라도 javascript 를 지연다운 했다면 메인 스레드는 여전히 작업 중이기 때문에 클릭 이벤트 등이 발생했을 시 버벅임이 발생할 수 있음.