[JS] 브라우저 렌더링 과정 (캐싱/SSR)

1. 이유 

[브라우저 렌더링]

- 프로젝트에서 gnb 에 데이터는 Tiles 를 호출하여 model 객체에 담아서 보내주고 있음 

- Tiles 호출 시기가 궁금하였고, 결국 SSR이 어떻게 화면을 응답받는지가 궁금하였음 

 

[렌더링 과정에서 외부자원 호출 부분 - img]

- 또한 상품 상세에 이미지에 lazyloading 이 적용되었는데, 해당 스크립트가 "언제" 실행되는지 

- 또 이미지가 "언제" 호출되어 나타나는지 알아야 했음 

 

=> 그렇기 위해선 기본적으로 브라우저의 렌더링 과정을 완벽히 이해하고 있어야 함 

 

2. 브라우저 렌더링 과정 

- 파싱 : 텍스트 문서를 -> 토큰으로 분해 -> 토큰에 문법적인 의미와 구조를 반영 -> 파스 트리

- 렌더링 : HTML, CSS, JS 로 작성된 문서를 파싱하여 브라우저에 시각적으로 출력하는 것 

 

[큰 흐름]

브라우저 요청 렌더링에 필요한 정보 (HTML, CSS, JS) 요청 응답

-> 브라우저 렌더링 엔진은 HTML, CSS 파싱하여 DOM, CSSOM 생성하여 "렌더트리" 

-> 브라우저 자바스크립트 엔진은 JS 파싱하여 실행 

-> "렌더트리" 기반으로 HTML 요소의 레이아웃 개선, 화면에 페인팅 

브라우저 렌더링 과정

 

1) HTTP 2.0

• HTML 내에 존재하는 css, js, img, link 등이 동시 전송이 가능함 

 

2-1) HTML 파싱과 DOM 생성

• HTML 문서는 문자열로 이루어진 "순수한 텍스트"
• "DOM" 객체 (자료구조)  : HTML 문서를 파싱한 결과물 
  • 파싱 과정 : 바이트 -> 문자 -> 토큰 -> 노드 -> DOM 트리 

 

2-2) CSS 생성과 CSSOM 생성 

• 렌더링 엔진은 HTML을 한줄씩 읽어가면서 DOM 을 생성함 
• css 나 link, style 태그가 있으면 DOM 생성을 중단함  ( 🤔 여기서 img 태그는? => 태그 만나면 중단) 
• 지정된 CSS 파일을 서버에 요청하고 CSS를 파싱하여 
  • 바이트 -> 문자 -> 토큰 -> 노트 -> CSSOM 생성 

 

3) 렌더 트리 생성 

• 브라우저 화면에 렌더링 되지 않는 노드 (script, display none)들은 포함하지 않음 

 

4) 자바스크립트 파싱과 실행 

• DOM API : DOM은 HTML 문서 정보 뿐 아니라 HTML 요소와 스타일은 변경할 수 있는 인터페이스 
• script 태그를 만나면 주도권은 js engine으로 넘기게 됨 
• cpu가 이해할 수 있는 저수준 언어로 변환하고 실행함 
  • 자바스크립트 소스 코드 -> 토큰 -> AST -> 바이트코드 -> "인터프리터" 

🤔 의문점
- Render Tree 이후에 자바스크립트 엔진이 실행되는 것인지 
- img는 언제 서버에 요청을 하는 것인지
- html이 한줄씩 읽어가면서 dom을 생성한다면 img 태그에서 src 로 서버에서 이미지를 호출하는 부분도 그때 html파싱을 블로킹 시켜서 호출하는 것인지? 


  => img 태그 만나면 dom 그리기 중단 후 서버와 요청함

 

 

3. BOM과 DOM 객체 

• window : HTML 로딩이 완료된 시점에 가장 먼저 만들어지는 객체, DOM이 들어올 창 
• document : window의 프로퍼티 중 하나로써 window가 생성되고 만들어짐 

https://sushmithavootukuri.medium.com/difference-between-window-document-and-screen-in-javascript-757a65b25e9a

 

• window / document의 내장 메서드 실행 시점
  • DOM TREE 완성 후 : document.ready /  DOMContentLoaded
  • CSS, JS, IMG 와 같은 외부 리소스 로딩 완료 후 : load 

 

 

 

4. 브라우저 캐싱 

- HTTP 요청을 할 떄마다, HTML, CSS, JS, img 등을 불러옴 

- 매번 요청을 할 때마다 다시 불러오는 것은 성능상 부담

 

• 브라우저 캐시 적용
  • HTTP 요청을 하는 클라이언트 에플리케이션 "내부 디스크" 에서 이루어지는 캐시 
  • HTTP 캐시라고 불리기도 함 
  • Etag를 적용하여 특정 버전의 리소스를 표시함, 요청에 리소스가 그대로이면 캐시에 저장된 정보를 보여줌 

 

 

 

5. 서버사이드 렌더링과 클라이언트사이드 렌더링 

- 현재 사이트는 JSP를 통해서 HTML 파일을 반환한다 -> SSR 방식을 취함 

• controller의 결과로 해당 경로를 반환함 
• dispatcher servlet에서 해당 경로에 있는 jsp 파일을 view resolver에게 반환함 
• • Jasper : 실제 JSP 페이지의 요청을 처리하는 서블릿,
  • JSP 코드 -> 서블릿 코드 .java 로 변환됨 -> 서블릿 코드를 컴파일링 하여 bytecode(.class) 
• modelAndView 로 바꾸어서 다시 dispatcherServlet으로 전달하면 view 에서 HTML 으로 응답  

ViewResolver에서 Model 값을 담은 JSP 파일을 찾은 View 객체를 View 로 넘김

• Rest Controller와 같이 api 통신의 경우엔 dispatcherservlet에서 reolsver가 아니라 바로 데이터 값을 받아서 전달함

 

 

- React 와 같은 프레임워크는 API로만 데이터를 호출하고 화면은 클라이언트에서 그리는 -> CSR 방식

 

 

6. 질문에 대한 답

• lazyloading
  • 서버에서 복수의 img에 대한 url 을 반환 받을 것 
  • 각 img 태그에는 src가 할당되어있지 않은 상태 (default 이미지는 지정해줌)
  • observe를 통해서 노드 element 의 위치를 파악하고 scroll을 내릴 때마다 
  • 그때에 위치에 해당하는 태그에 맞는 url을 src에 담아주면서 서버(또는 클라우드)에서 이미지를 가져옴 

 

 

---

* window와 document 

https://sushmithavootukuri.medium.com/difference-between-window-document-and-screen-in-javascript-757a65b25e9a

Difference between Window, Document and Screen in JavaScript

 

* 브라우저 캐싱

https://yozm.wishket.com/magazine/detail/2341/

프론트엔드 개발자가 알아야 할 ‘캐싱’ 개념 정리 | 요즘IT

*jsp 렌더링

https://medium.com/@js230023/jasper%EC%99%80-catalina-ea11a337945f

Jasper와 Catalina