브라우저 렌더링이란 브라우저가 서버로부터 요청해 받은 내용을 브라우저 화면(view)에 표시해주는 작업을 말합니다. 즉, 브라우저가 서버로부터 HTML, CSS, JavaScript 문서를 전달받아 브라우저 엔진이 각 문서를 해석해 브라우저 화면을 그려주는 것이죠.
예를 들어, 크롬 브라우저에 접속해 주소창에 www.google.com 을 입력한다면 브라우저는 google서버로부터 google웹사이트에 대한 정보를 받아 브라우저 화면에 google홈페이지를 그려주게 되는 것입니다. (이 과정은 브라우저 동작과정 참고)
브라우저 렌더링은 크게 ‘클라이언트 사이드 렌더링’과 ‘서버 사이드 렌더링’ 방식으로 나누어집니다.
클라이언트 사이드 렌더링(CRS)
클라이언트 사이드 렌더링은 클라이언트인 브라우저가 렌더링을 처리하는 방식입니다. 리액트로 할 수 있는 가장 기본적인 방식의 렌더링입니다. 즉, 서버에서 받은 데이터를 통해 클라이언트인 브라우저가 화면(View)을 그리는 주체가 되는 것입니다. 리액트로 설명하자면 자바스크립트로 변환된 리액트 코드를 웹 브라우저에서 실행해서 HTML을 만드는 걸 말합니다.
SPA 트렌드와 CPU 성능 상승 + JS 표준화(리액트, 뷰, 앵귤러 등의 framework 발전)와 함께 본격적으로 시작되었다고 합니다.
- SPA - Single Page Application
서버에서 전체 페이지를 한번 렌더링해서 보여주고, 사용자가 요청할 때마다 리소스를 서버에서 제공받아 클라이언트가 해석하고 렌더링하는 방식이라고 할 수 있습니다. SSR과 달리 서버에 HTML문서를 요청하는 것아 아니라JS로 콘텐츠를 렌더링 하는 것!
- 참고로 우리가 리액트를 사용하기 전에 만들었던 Weekly Mission이 우리 컴에 있는 html과 css, 약간의 동적 기능을 담당하는 JS를 브라우저로 전달하기 때문에 SSR이라고볼 수 있습니다.
- 요즘에는 CSR과 SSR 말고도 Static Site Generationg이라고 SSG도 있다고 합니다.
- 리액트 18에서 SSR이 가능해질 거라는 말이 나온다고 합니다! (지금은 Next.js 사용)
장점
네이티브 앱과 비슷한 빠른 인터렉션을 구현할 수 있습니다. View 렌더링을 브라우저에게 담당시킴으로서 서버 트래픽을 감소시키고 사용자에게 더 빠른 인터랙션을 제공해줍니다. 새로고침이 발생하지 않아 사용자가 네이티브앱과 비슷한 경험을 할 수 있습니다
따라서 초기 페이지 로드는 약간 느리지만 후속 페이지의 로드 시간이 빠릅니다. CSR은 서버 호출 시마다 전체 UI를 다시 불러올 필요가 없습니다.
단점
- 첫 페이지 로딩 속도가 서버 사이드 렌더링에 비해 다소 느립니다.
서버에 첫 요청 시 전체 페이지에 대한 모든 문서 파일을 받다 보니 서버 사이드 렌더링보다 로딩 속도가 느립니다.
-
페이지 캐싱이 잘 안됩니다.
- 웹 페이지의 정적 콘텐츠를 여러 지역의 서버에 저장해놓고, 사용자가 해당 콘텐츠를 요청할 때 가장 가까운 서버에서 즉시 제공하는 기술
- 서버 리전을 한곳에만 두고 전세계에서 페이지 캐싱을 사용해 빠르게 웹페이지 로드가 가능하도록 하는 기술!
- CSR에서는 초기 페이지 로드 이후에 JavaScript 코드가 실행되어 웹 페이지의 콘텐츠를 동적으로 생성하기 때문에(즉 처음엔 빈깡통 HTML임) 페이지의 콘텐츠가 일관된 형태로 유지되지 않으며, 이를 캐싱하는 것이 어렵습니다.
-
검색엔진최적화(SEO)에 대한 추가 보완 작업이 필요합니다.
포털사이트 검색엔진 크롤러가 웹사이트에 대한 데이터를 제대로 수집하지 못하는 경우가 발생할 수 있습니다.
구글의 검색엔진의 경우 자바스크립트 엔진이 내장되어 있어 크롤링이 되지만, 네이버, 다음의 경우 검색엔진이 제대로 크롤링하지 못하기 때문에 별도의 보완작업이 필요합니다.
