브라우저 렌더링 원리

🚀 브라우저(browser) 기본 사용 흐름

웹 브라우저 정의

웹 서버에 이동하며 쌍방향으로 통신하고 HTML문서나 파일을 출력하는 그래픽 사용자 인터페이스 기반의 응용 소프트 웨어이다.

1. 사용자가 브라우저를 실행 (접속하고 싶은 사이트의 url를 주소창에 입력).
2. 브라우저는 입력된 url의 서버에게 사이트 정보를 받아와 이를 화면에 표현.
3. 표현된 정보를 사용자가 활용.

즉, 사용자가 원하는 페이지를 서버에 요청하고 서버로 부터 받은 응답(HTML,CSS,JavaScript, 이미지 등) 을 브라우저에 표시하는 것이다.

---

🚀 웹 브라우저(Web browser) 종류 및 구조

웹 브라우저로는 파이어폭스, (구글)크롬, 인터넷 익스플로러, (애플)사파리 등이 있다.

🍄 브라우저의 기본 구조

1. 사용자 인터페이스
   URI(Uniform Resource Identifier)를 입력할 수 있는 주소 표시줄, 이전&다음 버튼, 북마크 메뉴 등 요쳥한 페이지를 보여주는 창을 제외한 나머 지 모든 부분.

2. 브라우저 엔진
   사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어

3. 렌더링 엔진
   요청한 콘테츠를 표시.
   ex) HTML을 요청하면 HTML과 CSS를 파싱 하여 화면에 표시한다.

4. 통신
   HTTP요청과 같은 네트워크 호출에 사용된다. 이것은 플랫폼 독립적인 인터페이스이고 각 플랫폼 하부에서 실행된다.

5. UI 백엔드
   select / input 등 기본적인 위젯을 그리는 인터페이스. 플랫폼에서 명시하지 않은 일반적인 인터페이스로, OS사용자 인터페이스 체계를 사용.

6. 자바스크립트 해석기
   자바스크립트 코드를 해석하고 실행.

7. 자료 저장소
   자료를 저장한다. Cookie, Local storage등 모든 자료를 저장하는 영역으로, 모든 종류의 자원을 하드 디스크에 저장할 필요가 있다. HTML5명세에는 브라우저가 지원하는 웹데이터 베이스가 정의되어 있다.

---

🚀 렌더링 엔진

렌더링 엔진의 역할은 요청 받은 내용을 브라우저 화면에 표시하는 일이다.

렌더링 엔진은 HTML및 XML 문서와 이미지를 표시 할수 있다. 물론 플러그인이나 브라우저 확장 기능을 이용해 PDF와 같은 다른 유형도 표시할 수 있다.

각 브라우저 마다 사용하는 렌더링 엔진은 다르다.

• 파이어 폭스 : 게코(Gecko) 엔진
  

• 사파리, 크롬 : 웹킷(Webkit)
  

🍄 브라우저의 렌더링 과정

1. 불러오기(Loading)
   HTTP 모듈 또는 파일 시스템으로 전달 받은 리소스 스트림을 읽는 과정으로, 로더가 이 역할을 맡고 있다. 로더는 단순히 읽는 것이 아니라 이미 데이터를 읽었는지도 확인하고, 팝업창을 열지 말지 또는 파일 다운로드 받을지를 결정한다.

2. 다운받은 HTML, CSS를 Object Model로 만든다.

❓ DOM(Document Object Model) 이란?

HTML태그를 JS에서 이용할수 있는 객체로 만드는 것이다. 즉 HTML문서의 객체 기반 표현 방식이다.

◾ HTML -> DOM
HTML파일은 HTML파서에 의해 파싱 되어 DOM트리로 변환된다.

◾ CSS -> CSSOM (<link> ,<style> 를 통하여 생성)
CSS파일은 CSS파서에 의해 파싱 되어 CSSOM트리로 변환된다.

❓ 파싱(parse or parsing)?
문서를 파싱한다는 것은 브라우저가 코드를 이해하고 사용할 수 있는 구조로 변환하는 것이다.
파싱 결과는 보통 문서 구조를 나타내는 노드 트리인데 파싱 트리 또는 문법 트리 라고 부른다.

3. DOM과 CSSOM을 합쳐서 렌더트리를 만든다.

◾Render Tree

4. Layout
   렌더트리가 만들어 졌으면 이것을 토대로 그려질 노드와 그의 스타일값 그리고 치수까지 계산한다.

❓ Viewport

그래픽이 표시되는 브라우저 영역, 크기.
뷰포트는 모바일의 경우 디스플레이의 크기, pc의 경우 브라우저 창의 크기에 따라 달라진다.

5. Paint
   이 정보들을 페인팅 단계로 전달해서 렌더트리의 각 노드를 화면상의 실제 픽셀로 변환한다.

요약
브라우저는 HTML, CSS, 자바스크립트, 이미지, 폰트 파일 등 렌더링에 필요한 리소스를 요청하고 서버로부터 응답을 받는다.

브라우저의 렌더링 엔진은 서버로부터 응답된 HTML과 CSS를 파싱하여 DOM과 CSSOM을 생성하고 이들을 결합하여 렌더 트리를 생성한다.

브라우저의 자바스크립트 엔진은 서버로부터 응답된 자바스크립트를 파싱하여 AST를 생성하고 바이트코드로 변환하여 실행한다.
이때 자바스크립트는 DOM API를 통해 DOM이나 CSSOM을 변경할 수 있다. 변경된 DOM과 CSSOM은 다시 렌더 트리로 결합된다.

렌더 트리를 기반으로 HTML 요소의 레이아웃(위치와 크기)을 계산하고 브라우저 화면에 HTML 요소를 페인팅한다.

---

❓❓❓ CSR & SSR
CRS(Client Side Rendering) 와 SSR(Server Side Rendering)은 렌더링 하는 지점만 다를 뿐, html파일을 렌더링 하는 역할은 동일하다.
흔히 렌더링이라고 하면, html 파일로부터 DOM tree를 만드는 이 과정을 말하지만, CSR/SSR에서 말하는 렌더링은 이를 넘어서 template 언어, javascript 로 작성된 component(react)등 html이 아닌 것을 html로 변환하는 과정을 포함한다.

CRS 은 서버로부터 html파일을 전달받아서 렌더링을 시작하면, html태그 내에는 id가 root인 div 하나만 달랑 있을 뿐이다(처음 html파일은 비어있고, 웹브라우저 화면에 처음 접속하면 빈화면이 보이는 이유이다).
이후 어플리케이션에서 필요한 js파일(어플리케이션에서 필요한 로직 뿐만 아니라 프레임워크, 라이브러리를 구동하는 소스까지 포함)을 전달 받은 후에, 화면에 view가 보여질 수 있다.

이로써 CSR의 단점은, 초기 로딩 속도가 느려서 화면에 빈 화면이 비춰지는 점과, SEO가 안좋다는 점을 뽑을 수 있다. (웹크롤링 할 때, html파일이 비어있어서 웹사이트의 어떤 정보도 읽을 수 없기 때문)

SSR 은 서버에서 렌더링하여 (즉, 서버에서 필요한 데이터를 모두 가져와서) html파일을 만든다. 잘 만들어진 html파일을 동적으로 생성하여 js파일(소스코드를 제어할 수 있는 정도)과 함께 클라이언트에 보내준다.
이렇게 되면 클라이언트 측에서는 동적인 화면을 바로 보여줄 수 있는 것이다. CSR에 비해 초기 로딩속도가 빠르고, 많은 정보가 html내에 담겨있기 때문에 SEO효과가 좋다는 장점이 있다.

하지만, 처음 로딩속도만 빠를 뿐, 사용자가 웹브라우저에서 동적인 요청을 할 때마다 서버에 요청을 보내서 데이터를 받아오기 때문에 전체적인 웹사이트를 서버에서 매번 다시 받아오는 것과 같아서 서버에 과부하가 걸리기 쉽다.

• Time line으로 보는 CSR SSR 차이점

1) html파일만 받아온다(빈화면)
2) js파일을 불러온다(각종 소스코드 등 해제)
3) 초기 로딩속도가 걸리지만, 파일이 다 받아와진 이후에는 빠른속도로 인터랙션 가능

1) html파일과 이를 작동시킬 js일부를 함께 받아온다(일부 소스코드 등 해제)
2) 나머지 js파일을 불러온다 (❗ 2번이 작동하기 전의 인터랙션은 보장하지 못한다는 단점)
3) 초기 로딩속도가 빠르지만, js파일이 다 받아와지기 전의 인터랙션 불가능