• 파싱(해석, 구문분석) : 프로그래밍 언어의 문법에 맞게 작성된 텍스트 문서를 읽어 들여 실행하기 위해 텍스트 문자의 문자열을 토큰으로 분해(어휘 분석)하고, 토큰의 문법적 의미와 수조를 반영하여 트리 구조의 자료구조인 파스 트리를 생성하는 일련의 과정

• 랜더링 : HTML, CSS, 자바스크립트로 작성된 문서를 파싱하여 브라우저에 시각적으로 출력하는것

브라우저의 렌더링 과정 요약

1. HTML, CSS, js, 이미지, 폰트파일등 렌더링에 필요한 리소스 요청 -> 서버로부터 응답 받음
2. 렌더링 엔진은 응답된 HTML과 CSS를 파싱 -> DOM과 CSSOM을 생성 -> 결합후 렌더트리를 생성
3. 자스 엔진은 응답된 자스를 파싱 -> AST를 생성 -> 바이트코드로 변환 -> 자스는 DOM API를 통해 DOM이나 CSSOM 변경 ㄱㄴ -> 렌더트리로 결합
4. 렌더 트리를 기반으로 HTML 요소의 레이아웃(위치,크기)을 계산 -> 브라우저 화면에 HTML 요소를 페인팅

요청과 응답

• 브라우저의 핵심기능 : 필요한 리소스(HTML, CSS, 자스, 이미지, 폰트 등의 정적파일, 동적생성데이터)를 서버에 요청 -> 응답 -> 브라우저 시각적 렌더링

• 요청 - 응답 - 렌더링

• 서버는 URL 에 암묵적으로 index.html 요청을 한다.

  • http://honyelim.com = http://honyelim.com/index.html

• 정적파일 요청시 주소 정확히 기재

  • http: hongyelim.com/img/logo.png

• 실질적으로 html을 요청시 요청하지 않은 CSS, 자스, 이미지, 폰트 파일도 응답됨 WHY? 브라우저 렌더링 엔진이 HTML을 파싱하는 도중에 외부 리소스를 로드하는 태그 (link, img, script 등)를 만나면 HTML의 파싱을 일시 중단 -> 해당 리소스의 파일을 서버로 요청

HTTP 1.1 과 HTTP 2.0

• HTTP(Hyper Text Transfer Protocol) : 웹에서 브라우저와 서버가 통신하기 위한 프로토콜(규약)이다.

• HTTP/1.1 : 커넥션당 하나의 요청과 응답만 처리함, 여러개의 요청을 한번에 전송할 수 없고 응답 또한 마찬가지 -> 요청도 개별적 ~ 응답도 개별적 ~ -> 동시전송이 불가능한 구조 -> 리소스 개수에 따라 응답시간 증가 불가피

• HTTP/2 : 다중요청/ 응답이 ㄱㄴ, 동시전송가능 -> HTTP/1.1 에 비해 로드 속도가 50% 정도 빠름

HTML 파싱과 DOM 생성

• HTML 문서 -> 문자열로 이루어진 순수 텍스트 -> 시각적인 픽셀로 렌더링하기 위헤? 브라우저가 이해할수 있는 자료구조(객체)(DOM) 로 변환 -> 메모리 저장

• (HTML 파싱과 DOM 생성)

  1. HTML 파일이 브라우저 요청으로 응답 -> (파일읽고 > 메모리저장)2진수를 인터넷을 경유하여 응답
  2. HTML 문서를 바이트(2진수)형태로 응답 -> meta태그의 charset 어트리뷰트에 의해 지정된 인코딩 방식(UTF-8)에 담겨 응답됨 -> 문자열로 변환
  3. 문자열된 HTML -> (문법적 의미를 갖는 최소단위)토큰들로 분해
  4. 토큰 -> 객체 -> 노드(DOM을 구성하는 기본요소)생성
  5. HTML문서는 HTML 집합으로 이루어짐 -> 중첩관계를 갖는다.(부자관계 형성)-> '트리 자료구조'로 구성

• 결론 : DOM은 HTML 문서를 파싱한 결과물

CSS 파싱과 CSSOM 생성

• 랜더링엔진 HTML 한줄씩 파싱 -> DOM 생성 -> CSS로드하는 link태그나 style 태그 만날시 DOM생성 일시 중단
• CSSOM(CSS Object Model) : CSS를 HTML과 동일한 파싱과정(바이트 -> 문자 -> 토큰 -> 노드 -> CSSOM)을 거치며 해석하여 생성

렌더 트리 생성

• 렌더링 엔진 HTML 과 CSS 파싱 -> DOM, CSSOM을 생성 -> 렌더링을 위해 렌더트리로 결합
• 랜더 트리 : 렌더링을 위한 트리구조의 자료구조 -> 브라우저 화면에 렌더링되는 노드만으로
• 브라우저 렌더링 과정은 반복해서 실행
  • 자스에 의한 노드 추가 또는 삭제
  • 브라우저 창의 리사이징에 의한 뷰포트 크기 변경
  • HTML 요소의 레이아웃의 (위치, 크기영향주는)스타일 변경
• 리렌더링은 비용이 많이듬, 성능에 악영향, 발생빈도 줄여야함

자바스크립트 파싱과 실행

• 자스코드에서 DOM API를 사용시 -> 이미생성된 DOM 동적조작이 가능하다..
• 파싱과정 CSS와 마찬가지 -> script 코드 만나면 DOM 생성 일시 중단
• 자스 파싱과 실행은 자스엔진이 처리함
• 자스코드 파싱 -> CPU가 이해할수 있는 저수준언어로 변환 -> 실행
• AST 기반으로 인터프리터가 실행할수 있는 중간코드인 바이트코드를 생성하여 실행
• AST(추상적 구문 트리) : 프로그래밍 언어로 작성된 소스 코드의 추상 구문 구조의 트리이다.(실제 구문에서 나타나는 모든 세세한 정보를 나타내지는 않는다는 것)
• 토크나이징 : 자스 소스코드를 어휘분석 -> 토큰들로 분해 ≈ 렉싱
• 파싱 : 토큰들의 집합을 구문분석하여 AST(추상적 구문 트리)를 생성
• 바이트코드 생성과 실행 : AST -> 바이트코드로 변환 -> 인터프리터에 의해 실행
• 디옵티마이징(deoptimizing): 최적 레벨 이하로 만들다.

리플로우와 리페인트

• 리플로우/ 리페인트 : DOM과 CSSOM은 다시 렌더 트리로 결합 -> 변경된 렌더트리를 기반으로 레이아웃과 페인트 과정을 거쳐 브라우저 화면에 다시 렌더링
• 리플로우 : 레이아웃 계산을 다시하는것
• 리페인트 : 재결합된 렌더트리를 기반으로 다시 페인드

자바스크립트 파싱에 의한 HTML파싱 중단

• (지금까지 본바)렌더링 엔진과, 자스 엔진은 직렬적으로 파싱수행
• script 태그 위히에 따라 HTML파싱이 블로킹되어 DOM생성이 지연될수 있음 -> 중요
• 자스코드에서 DOM 이나 CSSOM을 변경하는 DOM API를 사용할경우 DOM이나 CSSOM이 이미 생성되어 있어야함
• body 요소 가장아래에 자스를 위치시켜야함 -> 블로킹(방해, 막기) 방지
• 아래위치시 -> 자스 실행전 DOM생성 완료-> 렌더링 -> 페이지 로딩시간 단축

script 태그의 async/defer 어트리뷰트(IE10 이상 지원)

• async 와 defer 어트리뷰트는 src 어트리뷰트를 통해 외부 자스파일을 로드하는 경우에만 사용 -> src 어트리뷰트가 없는 인라인 자스에는 사용 x

<script async src="app.js"></script>
<script defer src="app.js"></script>

• async 와 defer 사용시 HTML 파싱과 자스파일의 로드가 비동기적으로 동시진행 -> 실행시점 차이 O

• async : 자스 파싱과 실행은 자스 파일의 로드가 완료된 직후 진행 -> HTML 파싱이 중단

• defer : 자스 파싱과 실행은 HTML 파싱이 완료된 직후(DOM 생성이 완료된 직후) 진행