서버 사이드 렌더링의 이해
서버 사이드 렌더링은 UI를 서버에서 렌더링하는 것을 의미한다.
일반적으로 초기의 학습하는 리액트 프로젝트는 기본적으로 클라이언트 사이드 렌더링을
하고 있다. 클라이언트 사이드 렌더링은 UI렌더링을 브라우저에서 모두 처리하는 것이다.
즉, 자바스크립트를 실행해야 우리가 만든 화면이 사용자에게 보인다.
한 번 CRA로 프로젝트를 생성하고 개발 서버를 실행해보고, 크롬 개발자 도구의 네트워크 탭을 열고 새로고침을 해보길 바란다. 맨 위에 있는 localhost를 선택하고 Response를 보면
root 엘리먼트가 비어있는 것을 확인할 수 있다. 즉 이 페이지는 처음에 빈 페이지라는 뜻이다.
<div id="root"></div>그 이후에 자바스크립트가 실행되고 리액트 컴포넌트가 렌더링되면서 우리에게 보이는 것이다.
서버 사이드 렌더링을 구현하면 사용자가 웹 서비스에 방문했을 때 서버 쪽에서 초기 렌더링을
대신해준다. 그리고 사용자가 html을 전달받을 때 그 내부에 렌더링된 결과물이 보인다.
서버 사이드 렌더링의 장점
- 구글, 네이버, 다음 등의 검색 엔진이 우리가 만든 웹 어플리케이션의 페이지를
원할하게 수집할 수 있다. 리액트로 만든 SPA는 검색 엔진 크롤러 봇처럼
자바스크립트가 실행되지 않는 환경에서는 페이지가 제대로 나타나지 않는다.
따라서 서버에서 클라이언트 대신 렌더링을 해 주면 검색 엔진이 페이지의 내용을 제대로 수집해갈 수 있다. 구글 검색 엔진은 다른 검색 엔진과 달리 검색 엔진에서
자바스크립트를 실행하는 기능이 탑재되어 있으므로 제대로 페이지를 크롤링해 갈 때도 있지만, 모든 페이지에 대해 자바스크립트를 실행해 주지는 않는다.
따라서 웹 서비스의 검색 엔진 최적화를 위해서라면 서버 사이드 렌더링을 구현해주는 것이 좋다. - 서버사이드 렌더링을 통해 초기 렌더링 성능을 개선할 수 있다. 예를 들어 서버사이드
렌더링이 구현되지 않은 웹 페이지에 사용자가 방문하면, 자바스크립트가 로딩되고 실행될 때까지 사용자는 비어 있는 페이지를 보며 대기해야한다. 여기에 API까지 호출해야한다면 사용자의 대기 시간이 더더욱 길어진다. 반면 서버사이드 렌더링을 구현한 웹 페이지라면 자바스크립트 파일 다운로드가 완료되지 않은 시점에서도 html상에 사용자가 볼 수 있는 콘텐츠가 있기 때문에 대기 시간이 최소화되고 이로 인해 사용자 경험이 향상된다.
서버 사이드 렌더링의 단점
서버사이드 렌더링은 결국 원래 브라우저가 해야할 일을 서버가 대신 처리하는 것이므로 서버 리소스가 사용된다는 단점이 있다. 갑자기 수많은 사용자가 동시에 웹 페이지에 접속하면 서버에 과부하가 발생할 수 있다. 따라서 사용자가 많은 서비스라면 캐싱과 로드 밸런싱을 통해 성능을 최적화해 주어야 한다.
또한 서버 사이드 렌더링을 하면 프로젝트의 구조가 좀 더 복잡해질 수 있고, 데이터 미리 불러오기, 코드 스플리팅과의 호환 등 고려해야 할 사항이 더 많아져서 개발이 어려워질 수도 있다.
서버 사이드 렌더링과 코드 스플리팅 충돌
서버 사이드 렌더링과 코드 스플리팅을 함께 적용하면 작업이 꽤나 까다롭다.
별도의 호환 작업 없이 두 기술을 함께 적용하면 다음과 같은 흐름으로 작동하면서 페이지에 깜박임이 발생한다.
1. 서버사이드 렌더링된 결과물이 브라우저에 나타남
2. 자바스크립트 파일 로딩 시작
3. 자바스크립트가 실행되면서 아직 불러오지 않은 컴포넌트를 null로 렌더링함
4. 페이지에서 코드 스플리팅된 컴포넌트들이 사라짐
5. 코드 스플리팅된 컴포넌트들이 로딩된 이후 제대로 나타남.
이러한 이슈를 해결하려면 라우트 경로마다 코드 스플리팅된 파일 중에서 필요한 모든 파일을 브라우저에서 렌더링하기 전에 미리 불러와야한다.
지금 공부하는 리액트 네이티브를 다루는 기술책에서는 이 문제를 해결하기 위해
Loadable Components라는 라이브러리에서 제공하는 기능을 써서 서버 사이드 렌더링 후 필요한 파일의 경로를 추출하여 렌더링 결과에 스크립트/스타일 태그를 삽입해주는 방법을 써서 해결한다.
내일은 실습을 해봐야겠다.
출처 및 참고 : 리액트를 다루는 기술
