2019년 리액트 서버사이드 렌더링 + 코드 스플리팅 + 데이터 로딩 레시피
이번 튜토리얼에서는 리액트 프로젝트에 서버사이드 렌더링과 코드 스플리팅을 구현하는 방법에 대하여 알아보겠습니다.
이 튜토리얼의 최종 결과물 Github Repo: https://github.com/velopert/react-ssr-and-splitting
배경지식
서버사이드 렌더링의 단점
서버 사이드 렌더링을 구현하면 구글, 네이버, 다음 등의 검색엔진이 우리가 만든 웹 애플리케이션의 페이지들을 원활하게 수집 할 수 있습니다. 리액트로 만든 SPA 는 자바스크립트가 실행이 되지 않는 검색엔진 크롤러 봇과 같은 환경에서는 페이지가 제대로 나타나지 않습니다. 따라서, 서버측에서 대신 리액트 컴포넌트 렌더링을 해주는 서버 사이드 렌더링을 구현하고 나면 검색엔진이 페이지들을 제대로 수집해갈 수 있습니다. 구글 검색엔진은 다른 검색엔진들과는 다르게 검색엔진에서 자바스크립트를 구동해주기 때문에 페이지를 제대로 크롤링해갈 때도 있습니다. 하지만, 모든 페이지에 대하여 자바스크립트를 실행하는 것이 아니기 때문에 웹서비스를 위한 검색엔진최적화 (SEO)를 신경 쓰신다면 서버사이드 렌더링을 구현해주셔야 합니다.
추가적으로, 서버사이드 렌더링을 통하여 초기 렌더링 성능을 개선시킬 수 있습니다. 예를 들어서 서버 사이드 렌더링이 구현되지 않은 웹페이지에 사용자가 방문을 하게 된다면, 자바스크립트를 로딩하고, 실행할 때 까지 사용자에게는 흰 페이지만 보여지기 때문에 대기 시간이 길어집니다. 추가적으로 페이지 로딩 후에 API 도 호출해야 하는 상황에는 사용자의 대기시간이 더더욱 길어지겠지요? 반면 서버사이드 렌더링을 구현한 웹페이지에 사용자가 방문을 하게 된다면 자바스크립트 파일 다운로드가 아직 완료되지 않은 시점에서도 사용자가 컨텐츠를 읽을 수 있기 때문에 대기시간이 최소화됩니다.
서버사이드 렌더링의 단점
서버사이드 렌더링의 단점은 원래 브라우저가 해야 할 일을 서버가 대신 처리하는 것 이기 때문에 서버쪽 리소스가 사용된다는 점 입니다. 만약에 갑자기 수많은 사용자들이 동시에 웹페이지에 방문하게 된다면 서버쪽에서 과부하가 발생 할 수 있기 때문에 사용자가 많은 서비스에서는 캐싱 및 로드밸런싱을 통하여 성능을 최적화 시켜주어야 합니다.
서버사이드 렌더링과 코드 스플리팅
서버사이드 렌더링과 코드 스플리팅을 함께 적용한다면 작업이 꽤나 까다롭습니다. 별도의 설정없이 이 두 기술을 함께 적용하게 된다면 다음과 같은 흐름으로 작동하게 되면서 페이지에 깜박임이 발생합니다.
- 서버사이드 렌더링된 결과물을 브라우저에게 전달
- 서버사이드 렌더링된 결과물이 브라우저에서 보여짐
- 자바스크립트 파일 로딩 시작 (main.js)
- main.js 에 있는 자바스크립트가 호출 되면서 아직 불러오지 않은 컴포넌트들을 null 로 보여줌
- 페이지에서 코드 스플리팅된 컴포넌트들이 잠시동안 사라짐
- 코드 스플리팅된 컴포넌트들을 모두 불러오고 나서 페이지가 제대로 나타남
이러한 이슈를 해결하기 위해선 각 라우트 경로마다 초기 렌더링을 하기 전에 어떤 컴포넌트들을 불러와야 할지 사전에 설정을 해주거나, 서버사이드 렌더링을 하는 과정에서 어떤 컴포넌트들이 사용되었는지 파악을 해서 html 내부에 스플리팅된 파일들을 불러오는 태그를 삽입해주어야 합니다.
이 튜토리얼에서는 loadable-components 라는 라이브러리를 사용하여 위에서 언급한 해결법들 중에서 후자의 방법을 사용하여 이 문제를 해결합니다.
또 다른 대안, Next.js
미리 말씀드리자면 코드 스플리팅과 서버사이드 렌더링을 함께 적용하는 것은 꽤나 까다로운 작업입니다. Next.js 라는 리액트 프레임워크를 사용하면 이 작업을 최소한의 설정으로 간단하게 처리 할 수 있습니다. 그 대신에, 몇가지 제한들이 존재합니다. 가장 대표적으로는 react-router 와 호환이 되지 않습니다. 리액트 관련 라우터 라이브러리 중에서는 라액트 라우터 (react-router) 가 점유율이 가장 높은데 이와 호환되지 않은건 꽤나 치명적인 단점입니다. 호환이 되지 않기 때문에 기존에 이미 존재하는 프로젝트에는 적용하기가 매우 까다롭습니다. 그리고, 리액트 라우터는 컴포넌트 기반으로 라우트를 설정하는 반면에 Next.js 는 파일 시스템에 기반하여 라우트를 설정합니다. 컴포넌트 파일의 경로와 파일명을 사용해서 라우트를 설정하는 것이죠. 그 외에도, 모든 복잡한 작업들을 Next.js 가 대신 해주기 때문에 실제 작동원리를 파악하기 힘들어질 수 도 있습니다. 흔히 이런걸 "마법" 이라고 부르기도 하지요.
만약 코드 스플리팅과 서버사이드 렌더링을 가장 쉽게 적용하고 싶다면 Next.js 를 사용하는 것을 추천드립니다. 하지만, Next.js 의 라우팅 방식보다 리액트 라우터 의 라우팅 방식을 더 좋아하거나, 기존의 프로젝트에 적용을 해야 된다거나, 혹은 작동 원리를 제대로 파악해가면서 구현을 하고 싶다면 직접 구현을 하는 것도 나쁘지 않은 방법입니다.