웹 브라우저 렌더링, 왜 알아야 하나요?
프론트엔드 개발을 하는 입장에서 브라우저가 어떤일을 해서 나에게 보여지는지 알아내는것은 매우 중요한 일입니다. 왜냐하면, 우리가 짠 코드가 실행되는 환경이 브라우저이기 때문이고, 발생하는 오류들에 대해서도 더욱 폭 넓게 문제를 해결할 수 있기 때문입니다. 이러한 과정을 통해서 웹 사이트의 성능을 더욱 좋게 만들수 있고 사용자 경험을 더욱 좋게 만들 수 있습니다.
이 글을 읽으면 얻을 수 있는 정보들이에요
웹 브라우저의 구성요소
웹 브라우저 렌더링 과정
웹 브라우저의 구성요소
출처 코딩하는 누나 유튜브
웹 브라우저는 사용자 인터페이스, 렌더링 엔진, 브라우저 엔진으로 이루어져있습니다.
- 사용자 인터페이스 : 주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등. 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분입니다.
- 브라우저 엔진 : 렌더링 엔진과 사용자 인터페이스 사이에 가교 역할을 하는 부분입니다.
- 렌더링 엔진 : 요청한 콘텐츠를 표시하는 부분입니다. 예를 들어서 HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시합니다.
- 통신 : HTTP 요청과 같은 네트워크 호출에 사용됩니다. 독립적으로 동작합니다.
- 자바 스크립트 해석기 : 자바스크립트 코드를 해석하고 실행합니다.
- UI 백엔드 : 콤보 박스, 창 같은 기본적인 장치를 그립니다. 플랫폼에서 제어하지 않는 일반적인 인터페이스로서 OS 사용자 인터페이스 체계를 사용합니다.
- 자료 저장소 : 로컬 세션 등등 정보를 저장할 수 있는 공간입니다.
웹 브라우저 렌더링 과정
웹 브라우저에서 사용자가 주소입력창(사용자 인터페이스)에 주소를 입력해서 엔터를 누르면 그 사이트가 웹 브라우저에 띄워지게 되는데 그 과정에 대해서 알아보겠습니다.
- DNS(Domain Name System) 서버를 찾아가서 방문하고자 하는 사이트의 아이피를 가져옵니다. (아이피를 알아야 서버와 통신이 가능하기 때문)
- 리소스 요청을 해서 서버에게 내가 보고자 하는 내용을 요청합니다. 이때 바이트스트림 형태로 받게 되는데(0101 <- 이런거) 이런 내용을 요청한 인코딩 방식에 따라 캐릭터화 시켜서 문서로 만들어줍니다.
- 토큰화를 해서 요청한 내용이 어떤 의미단위가 있는지(태그가 열렸니? 닫혔니? 등등) 파악합니다.
- 만들어진 토큰을 가지고 객체로 재정의 해서 노드로 만들게 됩니다.
- 렌더링엔진이 렌더링을 통해서 사용자에게 보여주게 됩니다.
렌더링 엔진
위에서 어떤식으로 웹 페이지의 내용이 보여지는지 알아보았는데, 렌더링 엔진의 동작과정을 추가적으로 알아봄으로써 웹사이트 성능 업그레이드에 대한 인사이트를 얻을 수 있었습니다.
- HTML 파싱 및 DOM 트리 생성
- 의미있는 노드에 관계성을 부여해주면 그것을 모델이라고 하는데요 HTML은 파싱되어서 Document Object Model이 됩니다. (문서 객체 모델)
트리 자료구조와 굉장히 유사한 것을 확인할 수 있습니다.
- CSS 파싱 및 CSSOM 트리 생성:
- 이것도 다 웹사이트 내용 보려고 하는 작업인데 HTML만 딸랑 가지고는 웹사이트를 볼 수 없을겁니다. 문서에서 style 태그를 보고 CSS도 요청하게 되는데 CSS도 바이트 스트림 형태로 받아와서 캐릭터화, 토큰화, 노드화 과정을 거친 후에 CSSOM 형태로 만들어지게 됩니다.
- 렌더 트리 생성:
- 브라우저는 DOM 트리와 CSSOM 트리를 결합하여 렌더 트리를 생성합니다. 렌더 트리는 실제 화면에 표시될 요소들만 포함하며, display: none처럼 보이지 않는 요소들은 제외됩니다.
- 레이아웃:
- 렌더 트리(설계도)가 상성된 다음에 바로 그릴수는 없는데 어디서부터 어디까지 그려야 하는지에 대한 check를 하는 작업을 레이아웃이라고 합니다.
- 페인트, 컴포시팅
- 픽셀 하나하나를 레이아웃이 알려준 방법대로 그리는데 한번에 싹 다 그리는것이 아니라 레이아웃이 알려준 여러 개의 레이어로 나누어서 그리게 됩니다. 그리고 여러개의 레이어를 마지막에 합쳐서(composite)보여주게 됩니다.
- 왜 여러개의 레이어로 그리냐면 한 레이어로 되어있으면 여러번 바뀌는 요소 때문에 전체를 다 바꿔버려야 하는 비효율이 발생하게 됩니다.
Reflow, Repaint
- repaint : 재결합된 렌더 트리를 기반으로 다시 화면에 페인트 하는것을 말합니다.
- reflow : 레이아웃 계산을 다시 해야하는 경우를 말하며 reflow가 발생하면 repaint는 필연적으로 발생합니다. reflow는 Html요소들의 위치와 크기를 다시 계산해야하기 때문에, repaint에 비해서 시간이 오래걸립니다. 변경하려는 특정 요소의 위치와 크기 뿐만 아니라 연관된 다른 요소들의 위치와 크기까지 재계산 해야하기 때문입니다. 따라서 리플로우가 자주 발생하도록 하는 코드는 지양해야합니다.
reflow가 자주 발생하지 않도록 코드를 작성해야 렌더링 성능을 높이고 사용자 경험을 더욱 좋게 만들어줄 수 있스비다. 그렇다면 reflow가 자주 발생하는 경우를 알아보고 피하기 위한 대안책을 알아봅시다.
reflow가 발생하는 경우
- 요소의 크기, 위치 변경
- 브라우저 창의 크기 변경
- font-size 변경
- scroll
- DOM API를 통한 노드 요소의 추가, 삭제
reflow를 발생시키는 css요소들
reflow 최소화하기.
리플로우를 발생시키지 않겠다!! <- 이건 불가능합니다. 대신 최소화 할 수는 있습니다.
1. 가급적 레이아웃 피하기 : 기하학적인 속성의 변경을 피함으로서 리플로우를 줄일 수 있습니다.transform같은 것을 사용해서 리플로우를 줄일 수 있습니다.
2. 이전 레이아웃 모델 대신 Flexbox사용하기
3. 애니메이션은 흐름 밖에서 변경 : HTML 요소들의 흐름 밖에서 애니메이션을 사용해야합니다.position: absolute;혹은position: fixed를사용해서 주변 요소에게 영향을 주지 않는 요소로 설정해야합니다.
웹 사이트의 성능을 좋게 만드는 방법
사용자가 더 좋은 사이트를 방문했으면 좋겠다는 생각에 이러한 요소들을 공부하는 것 같습니다. 어떤식으로 렌더링 되는지 알아야 더 빠르게 구동되도록 만들 수 있는 것 같습니다.
참고문헌
브라우저 렌더링 파이프라인
How browser rendering works
면접에서 브라우저 렌더링 과정을 묻는 이유.
코딩알려주는 누나 웹브라우저 작동방식
브라우저는 어떻게 동작하는가?
reflow repaint
