페이지 채우기: 브라우저가 작동하는 방법 - 1

브라우저 작동원리 시리즈 - 1

2020-09-25

2021-09-30

Browser, mdn

본 글은 mdn web docs의 Populating the page: how browsers work를 번역한 글입니다.

현재 작성일자(2020년 9월 25일) 기준으로 아직 한글로 번역되지 않아 본 번역 포스팅을 완료하면 해당 페이지를 한국어로 옮겨놓을 예정입니다. 수정 및 보완사항이 있다면 본 포스팅 하단 댓글에 작성 부탁드립니다.

브라우저 작동 원리 또는 렌더링에 관해 공부하고, 포스팅하고 싶은 마음이 있었는데 mdn에 좋은 게시물이 많이 있었고 그중 몇 가지를 연재로 번역하면서 공부해보는 시간을 가져볼려고 합니다.

연재할 MDN docs

페이지 채우기: 브라우저 작동원리

사용자들은 컨텐츠가 빠르게 로드되고 상호작용이 부드러운 웹 경험을 원합니다. 그러므로 개발자들은 이 두가지 목표를 성취하기 위해서 노력해야만 합니다.

성능과 감지된 성능을 개선하는 방법을 이해하기 위해서는 브라우저가 어떻게 동작하는지 이해하는 것이 도움을 줄 수 있습니다.

개요

빠른 사이트들은 더 나은 사용자 경험을 제공한다. 사용자들은 컨텐츠와 함께 빠르게 로드되고 상호작용이 부드러운 웹 경험을 예상하고 바랍니다.

웹 퍼포먼스에서 두가지 주요한 이슈로는 지연시간(latency)에서 경험하게 될 이슈와 브라우저가 단일 쓰레드로서 갖는 주요한 사실에서 갖는 이슈들입니다.

지연시간은 빠른 로드를 보장하기 위해 극복해야하는 우리의 주요한 위협입니다. 로드을 빠르게 하기 위해 개발자의 목표로는 가능하 한 빠르게 또는 적어도 보기에 매우 빠른 속도로 요청된 정보를 보내는 것을 포함함니다. 네트워크 지연은 바이트(bytes)를 무선에서 컴퓨터로 전송하는 시간을 얘기합니다. 웹 퍼포먼스는 가능한 한 빠르게 페이지 로드가 될 수 있도록 우리가 해야만 하는 가능한 빠르게 되도록 우리가 해야 하는 것입니다.

대부분은 브라우저들은 단일 쓰레드로 간주됩니다. 부드러운 상호작용을 위해 개발자들의 목표는 부드러운 스크롤링에서부터 터치에 반응하는 것까지 효율적인 사이트 상호작용을 보장하는 것입니다. 렌더링 시간의 핵심은 우리가 부여한 모든 작업을 메인 쓰레드가 완료할 수 있도록 보장하는 것과 항상 사용자 상호작용에 대처할 수 있도록 하는것입니다. 웹 퍼포먼스는 브라우저의 단일 쓰레드의 성질을 이해하고, 메인 쓰레드의 업무를 부드러운 렌더링과 상호작용에 즉시 반응할 수 있도록 보장하기 위해 가능한 그리고 적절한 범위내로 최소화함으로써 개선할 수 있습니다.

네비게이션

네비게이션은 웹 페이지 로딩에 있어서 첫번째 단계입니다. 언제든지 사용자가 주소바에 URL을 입력함으로써 페이지를 요청할때, 링크를 클릭할때, 폼을 제출하거나 다른 행동을 취할때마다 발생합니다.

웹 퍼포먼스의 첫번째 목표는 탐색이 완료되는 시간을 최소화 하는 것입니다. 이상적인 조건에서는 이건 보통 오래 걸리지 않지만 지연시간과 인터넷 접속 속도는 지연을 야기할 수 있는 적입니다.

DNS 조회

웹 페이지를 탐색하는 첫번째 단계는 페이지에 배치되어 있는 자산(asset)들이 어디에 있는지 찾는 것입니다. 여러분이 https://example.com 를 탐색한다면, HTML 페이지는 93.184.216.34 라는 IP 주소에 서버를 두고 있을것입니다. 만약 여러분이 이 사이트를 절대로 방문하지 않았었다면, DNS 조회는 반드시 발생해야만 합니다.

여러분의 브라우저는 차례대로 IP 주소에 의해 반응하기 위해 최종적으로 네임서버에 지정된 DNS 조회를 요청할 것입니다. 이러한 초기 요청 이후, IP는 지속적인 요청 속도를 올리기 위해서 네임서버로 다시 접속하는 대신 캐시로부터 IP 주소를 획득함으로써 한동안 캐시될 것입니다.

DNS 조회는 보통 페이지 로드를 위해 호스트네임 당 오직 한번만 수행될 필요가 있습니다. 하지만 DNS 조회는 요청된 페이지 참조의 각각의 유일한 호스트네임을 위해 완료되야만 합니다.

만약 당신의 폰트, 이미지, 스크립트, 광고 그리고 메트릭스 등 모든 것들이 다른 호스트네임을 갖고 있다면, DNS 조회는 각각의 것들을 위해 이루어져야 합니다.

이러한 작업은 특히 모바일 네트워크 환경에서 성능에 있어서 문제를 유발할 수 있습니다. 사용자가 모바일 네트워크 환경에 있다면, 각각의 DNS 조회는 권한이 있는 DNS 서버에 도달하기 위해 휴대전화에서 기지국까지 가야만 합니다. 휴대전화, 기지국 그리고 네임서버 간의 거리는 막대한 지연시간을 추가합니다.

TCP 핸드쉐이크 (TCP Handshake)

일단 IP 주소를 알고 있다면, 브라우저는 TCP three-way handshake 를 통해 서버 연결을 설정합니다. 이러한 메커니즘은 두개의 엔터티가 소통하기 위한 설계입니다–브라우저와 서버의 경우에– 종종 HTTPS 를 거쳐 네트워크 TCP 소켓 연결의 매개변수(parameter)를 협상할 수 있습니다.

TCP’s three way handshaking 기술은 종종 “SYN-SYN-ACK”(또는 더 정확하게는 SYN, SYN-ACK, ACK)이라고 부릅니다. 왜냐하면 그리고 시작하기 위해 두 컴퓨터 사이에서 TCP 세션을 시작하고 협상하기 위해 TCP에 의해 전송된 세가지 메시지가 있기 때문입니다. 즉, 세가지 이상의 메시지들이 각각의 서버 사이에서 오고 간다는 것을 의미하며 해당 요청은 아직 완료되지 않았다는 것입니다.

TLS 협상

HTTPS를 통해 설정된 안전한 연결을 위해서 또 다른 “Handshake”이 필요합니다. 이 Handshake 또는 TLS Negotiation은 통신을 암호화하고, 서버를 식별하며 데이터의 전송이 실질적으로 이루어지기 전에 제때 안전한 연결(secure connection)이 설정되도록 사용할 암호(cipher)를 결정합니다. 이러한 작업들은 요청된 콘텐츠가 실제로 전송되기 전에 서버에 3회 이상의 왕복을 요구합니다.

통신을 보안화하는것이 페이지 로드에 시간을 추가하는 반면에, 브라우저와 웹 서버 사이에 전송된 데이터가 서드 파티(third party)에 의해 암호 해독이 될수 없으므로 보안화된 연결(secure connection)의 시간지연 비용은 가치있다.

8번의 왕복 이후에 브라우저는 최종적으로 요청을 완료할 수 있다.

응답

일단 우리가 웹 서버와 접근을 설정하고 있다면 , 브라우저는 유저를 대신해 초기 HTTP GET request 를 전송합니다. 웹사이트의 경우 HTML 파일이 대부분 입니다. 일단 웹 서버가 요청을 받으면, 관련 응답(response) 헤더와 HTML 콘텐츠를 응답할 것입니다.

<!doctype HTML>
<html>
 <head>
  <meta charset="UTF-8"/>
  <title>My simple page</title>
  <link rel="stylesheet" src="styles.css"/>
  <script src="myscript.js"></script>
</head>
<body>
  <h1 class="heading">My Page</h1>
  <p>A paragraph with a <a href="https://example.com/about">link</a></p>
  <div>
    <img src="myimage.jpg" alt="image description"/>
  </div>
  <script src="anotherscript.js"></script>
</body>
</html>

초기 요청에 대한 응답은 획득한 데이터의 첫번째 바이트를 포함하고 있습니다. Time to First Byte (TTFB)는 사용자가 요청한 시간(링크를 클릭함으로써)과 HTML의 첫번째 패킷의 수신 사이의 시간입니다. 첫번째 콘텐츠의 청크는 보통 데이터의 14kb 입니다.

위 예제에서, 요청은 확실히 14Kb 미만이지만 다음에서 언급할 분석(parsing) 중에는 브라우저가 링크를 찾을때까지 연결된 리소스는 요청되지 않습니다.

TCP Slow Start / 14kb rule

첫번째 응답 패킷은 14kb 일것입니다. 이건 네트워크 연결 속도의 균형을 잡기위한 알고리즘인 TCP slow start 의 일부분입니다. Slow Start는 네트워크의 최대 대역폭이 결정될때까지 전송되는 데이터의 양을 점진적으로 증가시킵니다.

초기 패킷의 수신 이후에 TCP slow start 에서, 서버는 다음 패킷를 약 28kb 까지 두배로 키웁니다. 미리 지정된 스레드홀드에 도달하거나 정체가 발생할때까지 후속 패킷의 크기는 증가할 것입니다.

만약 여러분이 초기 페이지 로드에 대한 14kb 규칙을 들은적이 있다면, TCP Slow Start는 초기 응답이 14kb인 이유이기도 하며 웹 퍼포먼스 최적화가 이러한 초기 14kb 응답을 염두에 두고 최적화에 초점을 맞춰야하는 이유이기도 합니다. TCP slow start는 혼잡을 피하기 위한 네트워크 수용능력을 위해 점진적으로 전송 속도를 알맞게 구성합니다.

혼잡 관리

서버가 TCP 패킷에 데이터를 보낼때, 사용자의 클라이언트는 승인 또는 ACK를 반환하여 전달을 확인합니다. 이 연결은 하드웨어와 네트워크 조건에 따라 제한된 수용력을 가지고 있다. 만약 서버가 매우 빠르게 매우 많은 패킷을 보낸다면, 그들은 멈출것입니다. 즉, 인식하지 못할것입니다. 서버는 이것을 분실된 ACK(missing ACKs)로 등록합니다. 혼잡 관리 알고리즘(Congestion control algorithms)은 전송된 패킷과 ACK의 흐름을 사용하여 전송 속도를 결정합니다.

mdn 원본 페이지의 콘텐츠가 너무 길다고 판단되어 DOM과 CSSSOM에 대한 내용을 다룰 Parsing 부분은 ‘페이지 채우기: 브라우저가 작동하는 방법 - 2’ 에서 다루겠습니다.

StudyBrowser