웹 브라우저의 동작
브라우저 ⇒ 도메인서버와 통신하여 호스트의 IP를 찾음.
이후 브라우저는 해당 호스트IP서버와의 TCP 연결을 생성, 이제 브라우저는 IP서버와의 리소스 요청및 다운로드를 진행한다.
리소스에는 HTML,CSS,IMAGE,JS,Font 등.. 리소스를 다운로드하면서 페이지를 그리는 과정을 렌더링 이라고한다.
렌더링 과정
- HTML구문 분석을 진행하면서 DOM트리 생성
- HTML구문 분석 중 CSS링크가 발견되면 CSS구문 분석을 진행하여 CSSOM 트리생성 (HTML과 별도의 스레드로 동작함)
- DOM+CSSOM ⇒ 렌더 트리 생성
- 렌더트리를 통해 노드들의 위치 정보가 계산됨. 브라우저의 왼쪽위부터 오른쪽 아래 순으로 진행
- 브라우저창에 표현하는 페인트 단계
JS의 경우 DOM,CSSOM을 동적으로 변경 가능해서 렌더링 도중 JS에 의해 변경이 발생하면 3~5번 과정을 재수행한다. 따라서, 렌더링 과정에서 최대한 JS의 개입 없이 최적화가 필요하다. 그러나 대다수의 JS는 렌더링에 관여하여 이를 잘 구분하여 분리해야 한다..
DOM 최적화
HTML의 구문분석은 관대하다.
HTML 구문분석 과정에 작은 오류가 발생하면 브라우저가 알아서 처리하는 경우가 있다. ( ex:일부 태그를 닫지 않는 케이스 ) 그러나 이런 케이스가 많아질 경우 브라우저가 처리하면서 많은 메모리와 CPU를 소모할 수 있고 이는 렌더링 시간에 어느 정도 관여할 수 있다는 점이다. 오류 최소화가 필요한 부분이다.
과도한 HTML 태그 중첩 사용은 피하자.
위의 렌더링 과정에서 JS가 동적 변경을 발생시키면 3~5번 과정을 되풀이한다고 언급한 내용이 있다. 3~5번 과정을 되풀이 할때 HTML태그가 많다면 이것 또한 렌더링 지연의 원인이 될 것이다.
Atomic 디자인패턴으로 퍼블리싱 한 경험이 있는데 atom단위, module단위로 분리하는 과정에서 지나치게 태그를 많이 감싸서 활용하다보니 결과물을 보았을 때 생각보다 많고 불필요한 태그 중첩을 사용한 경험이 있다. 나중에 개발 데이터가 입혀진 후에는 수정이 많이 어려울 것으로 생각된다.
CSS 최적화
CSS를 분리하자
CSS를 통으로 말아서 사용하면 브라우저의 첫 화면과 관련없는 (뒤에 숨어있는 페이지 등) 리소스가 있을 수 있어, 렌더링 속도 지연에 영향을 준다. 해당 페이지에 필요한 CSS를 분리하면 좋다는 말이다. 그러나 이게 맘처럼 쉽지는 않을 것 같다. 어떻게 분리해야 좋을지는 좀 더 고민이 필요해보인다.
또 다른 방법으로는 당장 필요하지 않는 CSS를 지연 로드 시키는것이다. 예를 들면 <link data-href="css파일"/> 로 태그 작성 후 js onload이벤트를 통해 페이지가 로드되면 "data-href " 값 이용해 파일을 연결한다. 이 또한 CSS 파일 분리를 잘 해 두어야 할 수 있는 방법이다.
어떻게 CSS를 효율적으로 분리할 수 있을지가 중요한 것 같다.
JS 최적화
async, defer 속성을 이용
위에 언급한 듯이 JS는 렌더링 지연에 영향을 주는 부분이 있다. 따라서 HTML 구문 분석 과정에 꼭 필요한 JS와 그렇지 않은 JS를 구분할 필요가 있다.
async, defer 속성이 이를 도와줄 수 있다. async 속성은 HTML 구문 분석과 동시에 실행하고, defer 는 JS를 미리 다운 받아 놓은 뒤 HTML 구문 분석이 완료된 후 실행한다.
그 외에 onload event를 활용하는 방법이 있다.
CSS와 마찬가지로 JS 분리가 관건이다.
