[Web] 웹 동작원리, 브라우저 렌더링 원리

🥺 서론

확인해보니 이전에 웹 동작원리를 한번 포스팅했었는데, 이를 면접전에 다시 복습하거나 신경쓰지 않았다는게 참 후회스러웠다.

그런 한편으로, 이 포스팅이 상당히 간략하기도 하며, 브라우저 렌더링 같은 경우엔 프론트로서 자세히 정리해보아야겠다고 생각했다.

 

이번 포스팅을 계기로 웹 브라우저 원리를 한번 정리하면서, 면접 전 제대로 대비하지 못한 CS지식의 중요성을 다시금 곱씹어야겠다.

* 이전 포스팅(Web 동작원리) : abangpa1ace.tistory.com/43?category=913067

[Web] Web 동작원리

---

🌐 Web 동작원리 (웹페이지 로드과정)

우선, 웹페이지를 다운로드하고, 파싱하고, 렌더링하는 일련의 과정(이벤트)을 전체적으로 정리하려고 한다.

그리고, 브라우저 렌더링에 관한 부분을 아래에서 좀 더 구체적으로 작성하겠다!

노란색 단계들은 Javascript로 컨트롤이 불가한 Network Level 이다. 웹 리소스를 서버로부터 문서를 읽어들이는 일련의 과정이 포함된다.

* 현재 페이지(www.a.com)에서, 브라우저 주소창에 주소를 입력해 다른 페이지(www.b.com)로 이동하는 상황을 가정하자.

 

1. Prompt for unload

• beforunload => unloadEventStart => unloadEventEnd
• 현재 페이지에서 다른 페이지로 이동하고자 할 때 발생. 현제 페이지를 unload 한다.
• 통상 "현재 보고 있는 페이지를 나가시겠습니까?"와 같은 알림창이, window.unload 이벤트에 등록된 핸들러이다.

 

2. Redirect

• redirectStart => redirectEnd
• 서버에서 명시적인 res.Redirect 신호를 보내면 발생한다.(HTTP status code 3XX) Optional 하므로 발생하지 않을 수도 있음.

3. AppCache

• fetchStart
• 실제로 서버에서 리소스 요청을 보내기 전에, 브라우저 캐시에 해당 요청에 대한 유효한 응답이 있는지 확인
• 이미 캐싱된 리소스가 있다면, 이는 네트워크 통신을 거치지 않기 때문에 퍼포먼스 효율성이 증가한다.

4. DNS(Domain Name Server)

• domainLookupStart => domainLookupEnd
• HTTP 요청을 통해 보낸 도메인(www.a.com)을 실제 HTML 파일 등 리소스를 가지는 서버 주소인 IP주소(12.3.4.55)로 변환
• DNS에 보내기 전에, 브라우저에 cache 되어있는지 확인. 없다면, local의 hosts 파일에서 참조할 수 있는 도메인이 있는지 확인.
• 없다면, 마지막으로 DNS를 조회해서 서버의 실제 IP주소를 확인.

5. TCP(Transmission Control Protocol)

• DNS 단계에서 알아낸 IP를 통해 TCP로 서버에 연결(socket을 연다)
• Client부터 SYN, SYN+ACK, ACK의 3-way-handshake 방식으로 서로의 안정성을 확인하고, 연결형 서비스를 지향한다.

6. Request/Response

• requestStart => requestEnd
• HTML 문서에 대한 요청. 모든 Response(응답시간)가 종료되면 웹페이지에서 사용할 HTML 리소스를 받은 상태이다.
• Response의 첫 바이트가 수신한 직후 응답시간을 체크한다(start) => 마지막 바이트를 받은 직후 응답시간 완료를 체크한다(end)

7. Processing

• domInteractive => domContentLoaded(start, end) => domComplete
• 리소스(HTML, CSS, JS, img 파일 등)를 파싱하고 렌더링 단계까지 포함된다.
• domInteractive : 모든 HTML, DOM 생성 작업 완료
• domContentLoaded : DOM, CSSOM이 준비된 시점(Render Tree 생성전). JS 기능 추가(즉, JS 프레임워크 트리거가 DOMContentLoaded)
• domComplete : 페이지 및 해당 하위 리소스가 모두 준비된 시점. Render Tree를 Painting하여 최종적으로 렌더링한다.

8. Load

• loadEventStart => loadEventEnd
• 서브 리소스(이미지, 동영상)까지 모두 다운로드받고 읽은 단계. 최종적으로 모든 웹페이지가 브라우저에 제공되는 상태.

---

🌐 브라우저 렌더링 원리

- 브라우저 주요 기능

브라우저의 주요 기능은 사용자가 선택한 리소스를 서버에 요청하고 브라우저에 표시하는 것이다.

리소스는 통상 HTML 문서지만, PDF, 이미지 또는 다른 형태일 수 있다. 이 자원의 주소는 URI에 의해 정해진다.

 

브라우저는 HTML, CSS 명세에 따라 HTML 파일을 해석하여 표시하는데 이 명세는 웹 표준화 기구인 W3C(World Wide Web Consortium) 에서 정한다.

과거의 브라우저는 일부만 이 명세를 따르고 독자적으로 확장하여 호환성 문제가 심하였으나 최근에는 대부분 브라우저가 표준을 따른다.

 

브라우저의 사용자 인터페이스는 표준 명세가 없음에도 불구하고, 수년간 서로의 장점을 모방하여 현재에 이르게 되었다.

그래서, 브라우저의 사용자 인터페이스는 서로가 유사하며, 이러한 일반적인 요소 외 필수 UI가 정의되어있진 않다.

• URI를 입력할 수 있는 주소 표시줄
• 이전 버튼과 다음 버튼
• 북마크
• 새로고침 버튼과 현재 문서의 로드를 중단할 수 있는 정지 버튼
• 홈 버튼

 

- 브라우저 기본 구조

1. 사용자 인터페이스 : 위에서 언급한 주소 표시줄, 다양한 버튼 등. 페이지를 보여주는 창을 제외한 나머지 모든 부분이다.
2. 브라우저 엔진 : 사용자 인터페이스와 렌더링 엔진 사이 동작을 제어
3. 렌더링 엔진 : 요청한 컨텐츠를 표시. HTML을 요청하면 HTML, CSS 파싱을 담당하는 영역.
4. 통신 : HTTP 요청과 같이 네트워크 호출에 사용됨. 플랫폼과 독립적인 인터페이스로 각 플랫폼 하부에서 실행된다.
5. UI 백엔드 : 콤보박스와 창 등 기본적인 장치를 그림. 플랫폼에서 명시하지 않은 일반적인 인터페이스로, OS 인터페이스 체계를 사용.
6. 자바스크립트 해석기 : 자바스크립트 코드를 해석하고 실행.
7. 자료 저장소 : 자료저장 계층. 쿠키 등의 자원을 저장하며, HTML5 명세에는 브라우저가 지원하는 '웹 데이터베이스' 도 정의됨

 

- 렌더링 엔진

사용자가 요청한 내용을 서버로부터 받아 브라우저 화면에 표시하는 역할을 하는 브라우저 엔진.

렌더링 엔진은 HTML, XML 문서와 이미지를 표시할 수 있다. 물론, 플러그인이나 확장기능으로 PDF 등도 표현할 수 있음.

 

* 종류 : 크롬, 사파리는 웹킷(Webkit), Blink(크롬 28버전부터) / 파이어폭스는 모질라의 게코(Gecko) 엔진 사용

 

* 동작과정

1. 렌더링 엔진은 HTML 문서를 파싱하고 "컨텐츠 트리" 내부에서 태그를 DOM 노드로 변환한다.
2. 그리고, 외부 CSS 파일과 함께 포함된 스타일 요소도 파싱하여 CSSOM 노드로 변환한다.
3. HTML 표시규칙과 스타일 정보는 "렌더 트리" 라고 불리는 새로운 트리로 생성된다.
4. 렌더 트리를 기반으로 노드들의 배치(레이아웃) 작업이 진행된다. 이를, 디바이스(뷰포트) 기준으로 그려준다.
5. 다른 파싱과 배치를 병행해서 처리하기도 하며, 일부를 먼저 화면에 표시하는 등 최적화 작업들이 존재한다.

 

웹킷 동작 과정

게코 동작 과정

두 엔진의 용어가 조금 상이하나, 기본적인 동작 프로세스는 결국 동일함을 알 수 있다.

 

- 조금 더 이해하기

1) 파싱과 DOM 트리 구축

 

문서 파싱은 브라우저가 코드를 이해하고 사용할 수 있는 구조로 변환하는 것이다.

이렇게 파싱된 결과는 보통 문서 구조를 나타내는 노드 트리로, 파싱 트리(parse tree) 또는 문법 트리(syntax tree) 라고 부른다.

• HTML 파싱 : HTML 마크업을 파싱 트리로 변환. DOM(Document Object Model)은 마크업과 1:1 관계를 맺는다.
• CSS 파싱 : 스타일시트 객체로 파싱되며, 각 개체는 CSS Rule의 selector, declaration 으로 구성되어있다.

 

2) 스크립트와 스타일 시트의 진행 순서

 

• 스크립트가 실행되면 파싱은 중단된다.(외부에 있으면 받기 전까지 파싱중단). async, defer 등 키워드로 비동기 처리하며, HTML5는 자동으로 비동기 처리하는 속성이 있어 별도 맥락으로 파싱, 실행된다.
• 예측 파싱 : 웹킷, 파이어폭스는 최적화(예측 파싱)를 지원. 스크립트 실행중 다른 스레드는 다른 리소스를 내려받고 파싱하여 전체 속도를 개선한다.
• 스타일 시트 : DOM 트리를 변경하지 않으므로 파싱을 중단하지 않는다. 하지만, 스크립트가 스타일 정보를 요구할 때 문제될 수 있다. (웹킷은 로드되지 않은 스타일이 요구될 시 스크립트 중단, 게코는 아직 파싱/로드중인 스타일 시트가 있는 경우 스크립트 실행 중단) 

---

웹페이지 로드와 렌더도 생각보다 많은 절차가 얽혀있으며, 특히 브라우저의 구성과 개념을 알게 된 유익한 기회였다.

 

특히, Naver D2 소스에는 브라우저 동작의 주요 개념들을 심층적으로 설명하고 있다. (파싱, DOM, 렌더 트리 등등)

이 글은 출처 안내의 목적도 있지만, 다시 한 번 전체적으로 읽어보면서 주요 개념들을 완벽하게 이해하기 위한 리소스로 사용해야겠다!

 

 

[출처]

- jooonho 님의 블로그(웹페이지 로드) : jooonho.com/js/2021-01-24-timing-api/  

- Naver D2(브라우저 동작, 심화) : d2.naver.com/helloworld/59361

- jaddong 님의 블로그(브라우저 렌더) : jaddong.tistory.com/entry/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0