브라우저 동작 과정
브라우저의 주요 기능
- 사용자가 선택한 자원을 서버에 요청하고 브라우저에 표시하는 것
- 자원은 HTML, PDF, 이미지 혹은 다른 형태이다.
- 자원의 주소는 URI에 의해 정해진다.
브라우저 기본 구조
- 사용자 인터페이스 : 주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등 / 요청한 페이지를 보여주는 창 제외한 나머지 모든 부분
- 브라우저 엔진 : 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어
- 렌더링 엔진 : 요청한 콘텐츠를 표시
- 통신 : HTTP 요청과 같은 네트워크 호출에 사용된다. 플랫폼 독립적인 인터페이스. 각 플랫폼 하부에서 실행
- UI 백엔드 : 콤보 박스와 참 같은 기본적인 장치를 그린다. 플랫폼에서 명시하지 않은 일반적인 인터페이스로서, OS 사용자 인터페이스 체계를 사용
- 자바스크립트 해석기 : 자바스크립트 코드를 해석하고 실행
- 자료 저장소 : 자료를 저장하는 계층. 쿠키를 저장하는 것과 같이 모든 종류의 자원을 하드 디스크에 저장할 필요가 있다.
- 크롬은 대부분의 브라우저와 달리 각 탭마다 별도의 렌더링 엔진 인스턴스를 유지하는 것이 주목. 각 탭은 독립된 프로세르로 처리된다.
렌더링 엔진
- 렌더링 엔진은 요청 받은 내용을 브라우저 화면에 표시
- 주로 HTML, XML, 이미지를 표시하고, 확장 기능을 이용하면 PDF와 같은 다른 유형의 문서도 표시할 수 있다.
- 렌더링 엔진 종류
- 게코 엔진 : 파이어폭스
- 웹킷 엔진 : 사파리, 크롬
렌더링 엔진 동작 과정
- HTML 마크업을 처리하여 DOM 트리를 생성
- HTML 페이지는 바이트를 문자로 변환 -> 토큰화 -> 노드로 변환 -> DOM 트리 생성
- DOM 트리는 렌더링될 때 어떻게 표시할지는 알려주지 않는데, 그 정보는 CSSOM이 알려주게 된다.
- CSS 마크업을 처리하여 CSSOM 트리를 생성
- CSS 또한 바이트를 문자로 변환 -> 토큰화 -> 노드로 변환 -> CSSOM 트리 구축
- DOM 트리와 CSSOM 트리를 결합하여 렌더링 트리 생성
- DOM 트리와 CSSOM 트리를 결합하여 렌더링 트리를 형성
- 렌더링 트리는 페이지에 표시되는 모든 DOM 콘텐츠와 각 노드에 대한 모든 스타일 정보를 갖고 있다.
- 생성 과정
- DOM 트리의 루트에서 시작하여 순회
- 표시된 각 노드에 대해 매팅되는 CSSOM 규칙을 찾고, 적용한다.
- 표시된 노드를 컨텐츠와 스타일과 함께 내보낸다.
- 렌더링 트리 배치 : 각 노드에 대해 화면에서의 정확한 위치와 크리를 계산한다.
- 뷰포트 내에서 노드의 정확한 위치와 크기를 계산
- 페이지 내에서의 각 객체의 정확한 위치와 크기를 계산하기 위해, 브라우저는 렌더링 트리의 루트에서 시작하여 트리를 순회
- 레이아웃 과정의 결과는 Box Model이다. 박스 모델은 뷰포트 내에서 각 노드의 정확한 위치와 크기 정보를 담고있다. 모든 상대적인 특정값은 화면에서의 절대적인 픽셀로 변환된다.
- 렌더 트리 그리기 : UI 백엔드에서 렌더링 트리의 각 노드를 가로지르며 렌더링한다.
- 렌더링 트리의 각 노드를 화면에서의 실제 픽셀로 변환한다.
이 과정들은 점진적으로 진행. 렌더링 엔진은 모든 HTML을 파싱할 때까지 기다리지 않고 배치와 그리기 과정을 시작. 에트워크로부터 나머지 내용이 전송되기를 기다리는 도잇에 받은 내용의 일부를 먼저 화면에 표시한다.
- 렌더링 트리의 각 노드를 화면에서의 실제 픽셀로 변환한다.
- 브라우저 주소차에 www.naver.con 입력
- 네이버 서버를 찾아간다
- DNS가 연결해줄 곳을 찾는다
- 서버에서 index.html 파일을 클라이언트로 보낸다
- 브라우저는 텍스트로 이루어진 index.html 파일을 파싱한다
- 한줄한줄 읽으면서 DOM트리를 만들어간다
- 중간에 css요청이 발생하면 요청과 응답과정을 거치고 css를 파싱한다
- css파싱이 끝나면 중단된 html을 다시읽고 DOM트리를 완성한다
- 완성된 DOM트리와 CSSOM트리를 합쳐 Render Tree를 만들고 그린다
- 중간에 HTML파서는 Script태그를 만나게 되면 javascript 코드를 실행하기 위해 파싱을 중단
- 제어권을 자바스크립트 엔진에게 넘기고, 자바스크립트 코드 또는 파일을 로드해서 파싱하고 실행한다
AJAX (asynchronous JavaScript and XML)
- 자바스크립트를 이용해 서버와 브라우저가 비동기 방식으로 데이터를 교환할 수 있는 통신 기능
- 브라우저가 가지고있는 XMLHttpRequest 객체를 이용해서 전체 페이지를 새로 고치지 않고도 페이지의 일부만을 위한 데이터를 로드하는 기법
- 서버와 주고받는 데이터 형태 : JSON, XML, HTML, 텍스트 파일 등
- 장점
- 웹 페이지 전체를 다시 로딩하지 않고도, 웹 페이지의 일부분만을 갱신할 수 있다(속도 향상)
- 서버의 처리가 완료될 때까지 기다리지 않고 처리가 가능하다.
- 서버에서 Data만 전송하면 되므로 전체적인 코딩의 양이 줄어든다.
- 단점
- 히스토리 관리가 되지 않는다.
- 연속으로 데이터를 요청하면 서버 부하가 증갈할 수 있다.
- 브라우저에서 JavaScript가 비활성화된 경우 작동하지 않는다.
Framework (프레임워크)
- 프로그램의 뼈대가 되는 부분을 미리 구현한 클래스, 인터페이스, 메서드 등의 모음
- 장점
- 미리 구현해 둔 코드를 쓰기 때문에 빨리 만들 수 있다
- 품질이 보장되어 있다
- 추상화 계층을 하나 제공하는 것이 되어 사용하기 쉽다
- 단점
- 프레임워크 사용에 익숙해 지는데 시간이 걸린다.
- 프레임워크 내부를 커스터마이징하기 힘들다. 즉, 유연성이 부족
Library (라이브러리)
- 소프트웨어 개발에 쓰이는 하부 프로그램들의 모임으로 즉, 자주 쓰일 만한 기능들을 모아 놓은 유틸 혹은 클래스의 모음
프레임워크와 라이브러리 차이
- 프로그램을 쉽게 만들 수 있게 하는 공통된 목적
- 프레임워크는 큰 틀을 제공하고 내 코드는 프레임워크의 틀 안에 맞춰서 작성
- 라이브러리는 사용할 수 있는 함수들의 모음으로, 호출해서 사용
DOM
- 문서 객체 모델, XML이나 HTML 문서에 접근하기 위한 일종의 인터페이스
- 문서 내의 모든 요소를 정의하고, 각각의 요소에 접근하는 방법을 제공
가상 DOM
- 기존에는 화면의 변경사항을 돔을 직접 조작하여 브라우저에 반영
- 이 방법의 큰 단점은 돔 트리가 수정될 때마다 렌더 트리가 계속해서 실시간으로 갱신된다는 점
- 가상 돔을 활용하면 화면에 변화가 있을 때 마다 실시간으로 돔 트리를 수정하지 않고 변경사항이 모두 반영된 가상 돔을 만들어낸다.
- 그 후 가상 돔을 이용해 한 번만 돔수정을 하게 되고 이는 한 번만 렌더 트리를 만들어내게 된다.
- 즉, 불필요한 렌더링 횟수를 줄일 수 있게 된다.
SSR (Sever Side Rendering)
- 완전하게 만들어진 HTML파일을 받아오고 렌더링하게 된다.
- 웹서버에 요철할 때마다 브라우저 새로고침이 일어나고 서버에 새로운 페이지에 대한 요청을 하는 방식
- 장점
- 초기 로딩 속도가 빠르기 때문에 사용자가 컨텐츠를 빨리 볼 수 있다.
- 모든 검색엔진에 대한 SEO(검색엔진 최적화)가 가능하다.
- 단점
- 매번 페이지를 요청할 때마다 새로고침 되기 때문에 사용자 UX가 다소 떨어진다.
- 서버에 매번 요청을 하기 때문에 트래픽, 서버 부하가 커진다.
- 고려할 점
- 컨텐츠가 처음으로 페인트되는 시간이 얼만큼 중요한지
- 초기 로드 시간이 중요한 사항이 아니라면 SSR은 과도할 수 있다
- SSR 도구
- 리액트 : renderToString(), Next.js
- 뷰 : SSR 가이드, Nuxt.js
- 앵귤러 : 앵귤러 유니버설
CRS (Client Side Rendering)
- 처음에 웹서버에 요철할 때 데이터가 없는 문서를 반환
- HTML 및 static 파일들이 로드 되면서 데이터가 있다면, 데이터 또한 서버에 요청하고 그것이 화면상에 나타나게 된다.
- 브라우저가 서버에 HTML과 static 파일을 요청한 후 로드되면 사용자의 상호작용에 따라서 javascript를 통해 동적으로 렌더링한다.
- 필요에 따라 데이터를 서버에 요청해서 받아와 렌더링한다.
- 장점
- 첫 로딩에 HTML과 static 파일들만 다 받으면, 동적으로 빠르게 렌더링하기 때문에 사용자 UX가 뛰어나다.
- 서버에 요청하는 횟수가 훨씬 적기 때문에 서버 부담이 덜하다.
- 단점
- 모든 HTML과 static파일이 로드될 때까지 기다려야 한다.
- SEO(검색엔진 최적화) 문제가 발생할 수 있다.
SSR 과 CRS
| SSR | CRS | |
|---|---|---|
| 초기로딩속도 | CRS에 비해 다운 받는 파일이 많지가 않아 속도가 빠르다. | 모든 JS파일을 다운 받아와야 하기 때문에, 초기에는 오래 걸린다 |
| 서버부담 | 서버와 잦은 응답(view 변경 시 마다) 을 하기 때문에 서버에 부담이 된다 | data 요청이 있을 때만 서버에 요청하기 때문에 서버에 부담이 적다 |
| SEO | HTML에 대한 정보가 처음에 포함되어 있어 데이터를 수집할 수 있다. | 맨 처음 HTML 파일이 비어 있어 크롤러가 데이터를 수집할 수 없다(구글제외) |
SPA (Single Page Application)
- 단 하나의 페이지로 이루어진 어플리케이션
- 단 하나의 HTML 파일을 기반으로 javascript를 이용해 동적으로 화면을 바꾸는 방식의 웹 애플리케이션
MPA (Multuple Page Application)
- 화면마다 HTML파일이 존재하고, 사용자가 그 화면을 요청할 떄마다, 웹 서버가 필요한 데이터와 HTML로 파싱해서 보여주는 방식의 웹 애플리케이션
혼자 공부하면서 정리하는 블로그