다음의 문제에 대한 해결을 위해 해당 글을 포스팅한다.

1. 왜 server-side rendering과 client-side rendering 중 하나를 선택해야 할까?
2. server-side rendering과 client-side rendering의 차이는 무엇인가?
3. pre-rendering은 무엇인가?
4. server-side rendering과 client-side rendering 방식 각각의 장단점은 무엇인가?
5. 어떠한 프로젝트에 어떠한 rendering 방법을 적용하여야 할까?

Rendering

사용자가 사이트에 접속하면 브라우저는 화면을 출력하기 위해 서버에 html, js 파일을 요청하여 브라우저 DOM에 그려주는데 이러한 전 과정을 렌더링이라고 한다.
즉, 렌더링 과정은 작성한 html, css, javascript 파일을 브라우저 화면으로 출력하는 과정이다.
개발자 측면에서는 웹/앱의 코드를 사용자와 상호작용할 수 있는 인터페이스인 브라우저와 사용자의 화면에 보여주게끔하는 과정이다.

여기에는 대표적으로 js 언어가 사용되고, 새로운 라이브러리나 프레임워크가 만들어지며 다양화된 웹사이트를 좀 더 효율적으로 보여주고자 만들어진 Client-side rendering, 그리고 WWW(World Wide Web)이 처음 출범했을 때 브라우저에 사용되었던 Server-side rendering의 2가지 종류가 있다.
실제로 Client-side rendering은 React에서 주로 사용되고 있고, Server-side rendering은 새로 떠오르고 있는 Next.js에서 주로 사용되고 있는 방식이다.

Rendering 방식 선택의 중요성

웹 개발자는 화면을 개발할 때 어떠한 웹 서비스를 개발할지에 따라 적절한 웹 앱 아키텍처를 설계하고 적절한 tool과 기술을 사용해야 하는데, 렌더링 종류도 그 중 하나의 결정사안이 될 수 있다.
렌더링 종류를 개발할 웹 서비스에 맞게 잘 선택해야지만, SEO 결과, 앱 성능, 사용자 경험 등의 측면에서 나쁜 결과를 초래하지 않는, 그래서 이후 추가 개발 비용이 들지 않을 수 있는 서비스를 완성할 수 있다고 생각한다.

Server-side rendering (SSR) VS Client-side rendering (CSR)

SSR

app의 코드가 server에서 process(render)되는 것이 특징이고 다음의 렌더링 과정을 거친다.

1. 유저가 브라우저의 주소창에 원하는 URL을 입력한다.
2. 해당 URL에 대한 요청 데이터가 server에 전달된다.
3. server는 front-end/브라우저에서 필요한 데이터와 css 파일과 함께 html 파일을 생성한다.
4. server는 생성한 html 파일을 브라우저의 요청에 대한 응답으로 전송한다.
5. 브라우저는 받은 html 파일을 실행하고 페이지에 표시한다.
   

장점

• 처음 load하는 시간이 빠르다.
  • server의 브라우저의 요청에 대한 page 응답이 rendered html 파일이기 때문에, 브라우저에서는 javascript 파일을 실행시킬 필요가 없이 바로 결과를 화면에 보여줄 수 있다.
• 검색환경최적화(SEO)에 유리하다.
  • search engine 상위 결과에 노출되려면 웹사이트는 검색엔진 웹 크롤러에 의해 readable해야 한다. 그러기 위해서 웹 사이트의 모든 정보를 텍스트 형태로 표시되어야 한다.
  • 또한 웹사이트의 response time도 랭킹에 영향을 미친다. 그러한 측면에서 client-rendered 웹사이트에 비해 server-rendered 웹사이트에 걸리는 웹크롤러의 response time이 더 빠르다.

단점

• server의 부하가 크다.
  • SSR의 특성상 server의 자원을 사용하기 때문에 많은 요청이 들어오면 느려질 수 있다.
  • 이러한 문제를 피하기 위해, 유저 수와 웹사이트 load capacity에 따라 적절한 조건의 hosting server를 선택하여야 한다.
• page의 데이터가 변하는 경우(페이지 전환)에는 그 속도가 느리다.
  • 유저가 server-rendered 페이지를 바꾸어야 하는 경우, 그 변화의 크고 작은 정도와 관련 없이 server가 다시 render하는 과정이 필요하다.

CSR

app의 코드가 사용자의 browser에 전송되어 process(render)되는 것이 특징이고 다음의 렌더링 과정을 거친다.

1. 유저가 브라우저의 주소창에 원하는 URL을 입력한다.
2. 해당 URL에 대한 요청 데이터가 server에 전달된다.
3. server는 database로부터 정보를 끌어와 JSON 등의 요청된 형태로 응답을 생성한다.
4. server는 client에 요청된 데이터를 전송한다.
5. 브라우저는 html 코드에 server로부터 얻은 데이터를 넣어 화면을 보여주고, client에 저장되어 있던 javascript를 실행하여 유저에게 페이지를 보여줄 수 있게 된다.
   

장점

• server의 부하가 적다.

• 처음 load 이후에는 웹사이트 rendering 속도가 빠르다.

  • 새로 변경된 부분만 client-side에서 re-render되므로 속도가 빠르다.

단점

• 초기 loading 시간이 길다.

• SEO에 불리하다.

Use Case

SSR

SEO가 중요하고 변경이 잘 없는 웹사이트의 경우에는 서버 사이드 렌더링이 가장 좋은 선택이 될 수 있다.

ex. 온라인 마켓, e-learning

CSR

변경이 잦은 dynamic 웹사이트의 경우 클라이언트 사이드 렌더링이 더 좋은 선택지가 될 수 있다.

ex. 온라인 메신저, 소셜 네트워크

SSR + CSR (함께 사용하기)

Pre-rendering

렌더링 과정을 빠르게 진행하기 위해, 브라우저에 rendering되기 전 먼저 rendering 과정을 진행하여 빠르게 화면을 보여주는 Pre-render이 있다.

해당 과정을 통해서 다음의 두 가지 이점을 얻을 수 있다.

• server response 시간이 빨라진다.

  • server에서 client로부터 요청을 받으면 바로 응답(ex. static webpage skeleton; 기본 페이지 레이아웃)을 주고 나머지 데이터를 생성하고 전송하는 동안 유저는 로딩 페이지를 보게 된다.

• SEO 랭킹을 올릴 수 있다.

  • static website element(ex. meta-data, meta-descriptions, web page structure)가 먼저 렌더링되면서 웹 크롤러가 먼저 렌더링된 데이터를 분석하고 더 높은 SEO 랭크에 올릴 수 있다.

Use Case

ex. facebook

Ref

• https://clockwise.software/blog/client-side-vs-server-side-vs-pre-rendering/