프론트 디벨로퍼로 이런 저런 기능을 붙여 나가고 있지만, 기본적인 개념이 요새 많이 부족하다는 생각이 든다. 면접준비를 하며 하나씩 채워 가야겠다.
- 브라우저 렌더원리 (Next js serverside 기준)
특정 페이지 요청해서 받아온 첫 리소스 type은 document
서버 단에서 미리 렌더링 과정을 거쳐 만들어진 Render Tree 정보를 가진 문서이다.
Webkit의 렌더링 동작 과정에 표시한 부분처럼, 브라우저는 이 document만을 가지고 브라우저 화면 내의 엘리먼트 배치와 그리기만 하면 된다.
'document 페이지를 화면에 빠르게 보여주려면 어떻게 해야 할까?'
document를 생성하는 부분, 즉 렌더 트리를 생성하는 과정을 공략해야 함.
Render Tree 최적화
- 화면에 보여줄 렌더링 요소를 줄이자.
'팝업창' '설정메뉴바'와 같이 유저의 특정 액션이 있어야만 보여지는 요소들을 초기 로딩 시에 바로 렌더링 하지 않도록 줄이는 것 중요
-확실하게 초기 로딩 시 필요한 요소들만 받아올 수 있는 방법은?
Code splitting 을 이용해서 코드를 Chunk 형태로 따로 떼어낼 수 있다.
Code splitting은 Webpack 등의 번들러가 지원하는 기술로, 전략적으로 각 코드를 분할할 수 있고, 특정 컴포넌트를 dynamic하게 import를 해서 별도로 요청할 수 있음.
바로 보여줄 필요 없는 요소들을 별도 청크 파일로 분리하여 초기 렌더 속도 개선이 가능하며 document 리소스 크기가 감소하여 통신 속도 증가한다. 이후 아직 요청하지 않은 Chunk Code 들은 실제로 필요한 타이밍에 별도로 호출하여 사용할 수 있다.
- ESI (Edge Side Includes)
웹페이지 조각을 다른 웹 페이지에 포함시키는 마크업 언어 기술
기존에 있는 document 페이지에서 특정 document 페이지 조각을 추가할 수 있는 것이다. React 단에서 쉽게 사용할 수 있는 React-esi 모듈이 있다.
화면에서 감추는 방식은 여러 방법이 있는데, 'display: none' 'opacity:0' 'visibility: hidden' 등
이 중 'display: none' 만 Render Tree에서 제외됨.
Javascript 요소 최적화
Javascript가 HTML 파싱에 많은 영향을 미치는 요소 중 하나이기 때문
렌더 트리를 만들기 이전 단계인 HTML 파싱 중에 Script Code를 만나게 되면 HTML 파싱을 멈추게 된다. HTMl 파싱을 멈춘다는 것은 웹 화면의 렌더링의 지연을 뜻하고 이는 초기 로딩 속도를 늦추는 원인이 되는 것이다.
그래서 초기 렌더링과 무관하게 동작하는 스크립트는 아래로 내려 엘리먼트 요소들이 먼저 렌더링 되도록 할 수 있다.
그러나 React나, Next.js와 같이 프레임워크 내에서는 태그 내 스크립트 코드를 넣을 일이 많이 없다.
또한 초기 로딩에 필요로 한 외부 라이브러리, 또는 웹 폰트 등 사용으로 인해 태그 내에서는 스크립트 선언을 많이 하곤 한다.
