브라우저 렌더링 원리를 알아야 하는 이유
C는 직접 운영 체제에서 실행되고, Java는 가상 머신 위에서 실행된다.
C는 컴파일 언어로, 소스코드가 기계어로 변환된 후 실행된다. Java는 소스코드가 바이트코드로 컴파일되어 JVM에서 해석 및 실행된다. 반면 JavaScript는 웹 브라우저에서 실행된다. (물론 Node.js를 통해 서버 사이드에서도 실행될 수 있다.)
JavaScript를 클라이언트 사이드에서 사용할 경우 웹 브라우저에서 HTML, CSS, JavaScript가 실행되므로 브라우저 렌더링 원리를 이해하는 것은 중요하다.
-(JVM이란?) JVM은 하드웨어와 운영 체제 사이의 추상화 레이어로 작동하는 소프트웨어이다. 보통 자바 개발 키트(JDK)에 포함되어 컴퓨터에 설치된다.
-(클라이언트 사이드) 웹 브라우저에서 사용자의 상호작용에 응답하여 작동하는 코드 (주로 HTML, CSS, JavaScript)
-(서버 사이드)서버에서 데이터 처리 및 저장, 클라이언트에게 웹 페이지를 제공하는 코드가 실행되는 곳 (Node.js, Python, php등 서버 사이드 언어 사용)
주소창에 google.com을 검색하면 일어나는 일?
사용자가 브라우저에 google.com을 검색했을 때 일어나는 일을 순서대로 도식화한 것이다.
순서대로 자세히 설명하면 다음과 같다.
1.사용자가 웹 브라우저를 통해 google.com 을 입력하면 URL 주소 중 도메인 네임(=www.google.com) 부분을 DNS 서버에서 검색
2.DNS 서버에서 해당 도메인 네임에 해당하는 IP 주소를 찾아 사용자가 입력한 URL 정보와 함께 전달
3.브라우저는 HTTP 프로토콜을 사용하여 요청 메시지를 생성하고 HTTP 요청 메시지는 TCP/IP 프로토콜을 사용하여 웹 서버로 전송
4.서버는 response 메시지를 생성하여 다시 브라우저에게 데이터를 전송
5.브라우저는 response를 받아 파싱하여 화면에 렌더링
-(DNS)도메인 이름 시스템(DNS)은 사람이 읽을 수 있는 도메인 이름(예: www.amazon.com)을 머신이 읽을 수 있는 IP 주소(예: 192.0.2.44)로 변환해주거나 반대의 역할을 수행
마치 전화번호부같음 (IP주소와 도메인을 저장하고 매핑하는 일종의 데이터베이스이므로)
-(HTTP) HTTP(HyperText Transfer Protocol)은 TCP 기반의 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜
-(프로토콜) 프로토콜은 통신하기 위한 약속들을 기술적으로 잘 정의해 둔 것. 데이터를 송수신하는 순서와 내용을 결정. HTTP, TCP/IP, UDP 모두 프로토콜.
잠깐, 그런데 여기서 TCP/IP가 뭘까?
즉 TCP란 호스트 간 데이터 전송을 제어하고 안정적이고 순서대로 전달하기 위한 규칙이고, IP는 인터넷 상의 컴퓨터들이 서로를 식별할 수 있도록 컴퓨터에 고유한 주소를 부여하는 규칙이다.
-(패킷) 패킷 또는 네트워크 패킷은 네트워크를 통해 전송되는 형식화된 데이터 덩어리이다.
브라우저 렌더링 단계
위의 단계에서 Web서버가 응답과 함께 HTML, CSS, JavaScript 파일이 포함된 데이터를 브라우저에게 전달한 이후 브라우저 렌더링이 어떻게 일어나는지 살펴보자.
Web서버가 브라우저에게 HTML문서를 전달할 때, 브라우저가 이를 이해할 수 있도록 파싱(parsing)하는 과정이 필요하다.
파싱(parsing)은 일정한 규칙을 가진 문자열(코드, 마크업 등)을 의미 있는 토큰(token)으로 분해하고 구조를 이해하는 과정이다.
사진에서는 XML 문서를 Parser가 파싱하는 과정을 트리 구조로 변환하였는데,
루트 요소에는 gallery, 루트 요소 아래 세 개의 자식 요소에는 photographer, email, photos, 그 아래 자식 요소로 구성되어 있다.
이를 통해 프로그램이 데이터 구조를 이해하고 접근할 수 있게 만들어주었다.
브라우저도 HTML문서를 파싱하여 파싱 트리를 생성하는데, 이를 기반으로 DOM트리를 만들어낸다.
*DOM : 브라우저가 서버에게 요청해 응답으로 받은 웹 문서 (HTML, XML 등)를 브라우저의 렌더링 엔진이 로드하고 파싱하여 브라우저가 이해할 수 있는 형태로 구성된 것
DOM 트리는 구체적으로는 바이트 -> 문자 -> 토큰 -> 노드 -> DOM의 순서를 거쳐 만들어진다
DOM 트리의 노드는 부모와 자식관계로 묶여있으며, id나 class등의 선택자를 통해 접근이 가능하다.
렌더링 엔진이 HTML 문서를 파싱하다가 CSS를 로드하는 <link>태그나 <style>태그를 만나면 CSS를 또한 파싱한다.
HTML을 파싱해 DOM 트리를 만든 것처럼, CSS를 파싱하면 CSSOM 트리라는 것을 만들게 되는데,
이는 CSS내용을 파싱하고 노드를 만들어 DOM트리처럼 트리 형태로 구조화한 것이다.
참고로, CSSOM은 DOM과 다르게 부모의 속성을 덮어쓸 수 있다. (자손 노드가 부모의 속성을 덮어 씌울 수 있다.)
웹 브라우저를 HTML 문서를 순차적으로 파싱하다가 JavaScript코드를 만나면 파싱을 일시 중단한다. (= <script>태그를 만나면)
이는 매우 중요한데, <script>태그가 문서 내에서 '동기적으로' 처리되어야 하기 때문이다.
스크립트가 실행되는 동안 브라우저는 HTML문서의 나머지 부분을 파싱하지 않는다. 이는 스크립트가 DOM을 조작할 수 있기 때문인데, 스크립트 실행으로 인해 DOM이 변경될 수 있으므로 변경된 DOM에 맞추어 파싱을 계속해야 한다.
스크립트 처리가 완료된 후 브라우저는 중단했던 지점부터 HTML문서 파싱을 재개한다.
이러한 동작방식 때문에 웹개발자들은 종종 스크립트를 문서의 맨 아래에 배치하거나 async, defer 속성을 사용해 파싱 중단으로 인한 페이지 로딩 지연을 최소화한다.
DOM트리와 CSSOM트리를 다 그리고 나면, 이들을 결합하여 Render 트리를 구축하게 된다.
브라우저는 렌더 트리의 노드에 대해서 뷰포트 내에서의 정확한 위치와 크기를 계산하는데, 이때 화면에 표시되지 않은 요소들은 렌더 트리에서 제외시킨다.
이 과정을 Layout 단계라고 부른다.
이후 Layout 단계가 끝나면 Layout 단계에서 계산된 위치와 크기를 기반으로 실제로 화면에 픽셀을 그리는 단계인 Paint 단계가 진행된다.
이 때 처리해야 하는 스타일이 복잡할수록 이 단계에서 소요되는 시간이 길어진다.
마지막으로 Paint 단계의 레이어들을 전부 합성해 화면에 출력하게 된다.
이후 특정 액션 등으로 Layout수치가 변하게 되면 해당 요소의 영향을 받는 노드를 다시 Layout하는데, 이 과정을 Reflow라고 한다.
노드의 크기와 위치를 다시 계산한 후 (Reflow), 계산된 렌더 트리를 다시 화면에 렌더링하는 과정(Repaint)을 거쳐 리렌더링이 발생한다.
만약 Reflow가 발생하지 않아도 background-color나 opacity같이 레이아웃에 영향을 주지 않는 스타일 속성이 변했을 때는 Reflow없이 Repaint만 발생하기도 한다.
즉 브라우저 렌더링 과정을 한 눈에 요약하면 다음과 같다.
구체적인 '브라우저 렌더링' 과정은 초록색 박스에 있는 내용이 된다.
출처
'CS > 브라우저' 카테고리의 다른 글
| 브라우저 살펴보기 - 내비게이션 과정에서 일어나는 일(1) (0) | 2024.06.08 |
|---|---|
| INP란 무엇인가? (0) | 2024.05.01 |
| 게이트웨이와 프록시 (0) | 2023.11.25 |
| DOM과 가상 DOM (4) | 2023.11.21 |
| 크로스 브라우징 (0) | 2023.07.16 |