용어 사전

링크

Client, Server Side Rendering

1. Client Side Rendering (CSR)

• 기술이 발전하면서 웹 페이지에서 제공하는 서비스가 복잡해짐으로서, AJAX만으로는 모든 로직을 처리하기가 어려워짐.
• 이를 위해 React, Vue, Angular 와 같은 프레임워크가 등장하면서, 클라이언트에서 렌더링을 진행하는 경우가 많아짐.
• 이제는 서버에서 최소한의 HTML을 받고, 내부에 위치한 script 태그로 JS 파일을 받아 클라이언트에서 페이지를 렌더링하는 형식으로 변화.
• 초기에 애플리케이션 가동에 필요한 JS 파일의 크기가 크기에, 적극적인 코드 분할 (Code Splitting) 을 고려해야 함.

1-1. CSR의 동작 방식

1. 사용자가 웹 페이지를 방문할 경우, 브라우저는 최소한의 HTML 파일을 다운로드한다.
2. 브라우저는 script 태그를 통해 JS 번들 파일을 다운로드 하고, Ajax를 통해 동적으로 컨텐츠를 가져오며 화면을 렌더링한다.
3. 이후 사용자가 페이지를 이동할 경우, 별도의 HTML을 받지 않고 사전에 받은 JS 파일만을 활용하여 렌더링을 진행한다.

1-2 CSR의 장단점

1. 장점

• 초기 렌더링 이후에 진행되는 렌더링의 경우 로딩 속도가 훨씬 빠르다. 이미 페이지 로딩에 필요한 모든 자원을 받은 상태이기 때문
• 서버와의 통신 과정에서 페이지의 UI를 다시 그릴 필요 없이, 동적으로 일부분만 변경시킬 수 있다.

2. 단점

• 초기 구동에 필요한 파일을 전부 받아야 하기에, 그만큼의 초기 페이지 구동 속도가 느리다. (FP,FCP 느림)
• 페이지가 완전히 로딩되기 전까지는 하얀 화면만을 봐야 하기에 UX가 구림
• SEO (Search Engine Optimization) 검색 엔진 최적화가 어렵다. 검색 엔진이 처음 페이지를 방문할경우 HTML이 빈 경우가 많기 때문
• 페이지 메타 데이터의 변경을 위한 추가 작업이 필요함. 다른 페이지로의 이전을 진행할 경우 이를 인지시키기 위해 각 페이지에 대한 메타 데이터를 동적으로 렌더링 해야 함
• 사용자의 PC 성능에 따라 렌더링 속도가 좌우됨

2. Server Side Rendering(SSR)

• 서버에서 사전에 렌더링된 파일을 클라이언트에게 전송하고, 클라이언트는 이를 즉시 렌더링하는 방식
• 단, Js의 경우 정적 리소스 (HTML, CSS)가 렌더링 된 이후 적용되기에 Js가 모두 적용되기 전에는 조작이 불가능하다.
  

2-1 SSR의 동작 방식

1. 사용자가 웹 페이지를 방문할 경우, 서버는 이를 확인하고 브라우저에게 제공할 HTML 컨텐츠를 컴파일한다.
2. 컴파일된 HTML은 브라우저에 제공되며, 브라우저는 이를 다운로드하고 렌더링하여 사용자가 이를 볼 수 있도록 한다.
3. 이후 Js파일을 다운로드 받은 후 실행하여 사용자와 페이지 간의 인터렉션을 가능하게끔 한다.
4. 사용자가 다른 페이지로 이동할 경우, 1~3번의 과정을 반복한다.
   

2-2 SSR의 장단점

1. 장점

• 초기 페이지 로딩 속도가 빠르다.(FP,FCP가 빠름) 서버에서 사전에 렌더링 된 HTML 파일을 브라우저에서 로딩하기 때문.
• 서버에서 페이지 로직 및 렌더링을 사전에 실행할 경우, Js 파일을 많이 보낼 필요가 없어지므로 TTI 또한 상대적으로 빠르게 수행
• 이미 사전에 렌더링 된 HTML을 크롤링 봇이 방문하므로, SEO 또한 효율적으로 적용할 수 있다.
• 서버에서 완성된 페이지를 브라우저에서 보여주기만 하면 되므로, 클라이언트의 PC 성능에 크게 영향을 받지 않는다.

2. 단점

• 페이지를 이동할 때마다 매번 새로운 HTML을 받아야 하므로 TTFB가 느리다.
• 서버에서 각 페이지에 대한 정적 리소스를 보내야 하기 때문에 이를 위한 서버 호스팅이 필수적
• 각 페이지를 로드하는 과정이 오래 걸린다면, 오히려 사용자 경험을 해친다.
• 각 요청에 대한 HTML 파일을 그때 그때 렌더링 해야하기 때문에, CDN을 활용한 캐싱 전략을 사용할 수 없다.