렌더링 - CSR과 SSR (w/TTV, TTI)

ㅁ렌더링(Rendering): 컴퓨터가 데이터를 시각적으로 변환하여 사용자에게 보여주는 과정

웹 개발에서 렌더링은 주로 브라우저가 웹 페이지를 구성하는 데이터(HTML, CSS, JavaScript 등)를 받아서, 이를 사용자 화면에 표시하는 과정을 의미한다

 

렌더링의 종류 2가지

1. 클라이언트 사이드 렌더링 (CSR, Client-Side Rendering): 클라이언트(보통 브라우저)에서 페이지를 렌더링하는 방식

서버에서 HTML 파일을 기본적으로 빈 상태로 보내고, 클라이언트(브라우저)가 JavaScript를 통해 동적으로 HTML을 구성하는 방식이다. JavaScript가 실행되어 필요한 데이터를 가져오고, 브라우저에서 이를 해석하여 화면을 구성하게 된다.

 

작동 방식:

1. 사용자가 웹 페이지에 접속하면, 서버는 빈 HTML 파일과 JavaScript 파일을 클라이언트로 보냄.
2. 클라이언트는 JavaScript 파일을 실행하고, 그 결과로 동적으로 페이지를 생성함.
3. 이후 클라이언트는 필요할 때마다 서버로 API 요청을 보내 필요한 데이터를 받아와 화면에 표시함.

• 장점:
  • 빠른 사용자 경험: 페이지 전체를 새로고침할 필요 없이, 필요한 부분만 동적으로 업데이트할 수 있어서 더 빠르고 부드러운 사용자 경험을 제공함.
  • SPA(Single Page Application) 구현: 페이지 간 이동 없이, 클라이언트에서만 처리할 수 있는 웹 앱을 만들 수 있음. 예를 들어, React, Vue.js, Angular 같은 프레임워크들은 CSR 방식을 채택하고 있음.
• 단점:
  • SEO 문제: 초기에는 HTML이 비어 있어서, 검색 엔진 크롤러가 콘텐츠를 제대로 인식하지 못할 수 있음. 또한 일부 검색 엔진은 JavaScript를 제대로 해석하지 못해, SEO에 불리할 수 있음.
  • 첫 로딩이 느림: 페이지 처음 로딩 시 JavaScript 파일이 클라이언트에서 처리되기 때문에, 로딩 시간이 오래 걸릴 수 있음. 특히 사용자 네트워크가 느리면 그 차이가 더 커짐.

 

2. 서버 사이드 렌더링 (SSR, Server-Side Rendering): 서버에서 페이지를 렌더링하는 방식

서버에서 HTML을 미리 렌더링한 후, 완성된 HTML 파일을 클라이언트에게 보내는 방식이다. 브라우저는 서버에서 이미 완성된 HTML 파일을 받아서 이를 바로 사용자에게 보여준다. 이 과정에서 브라우저는 추가적인 데이터를 처리할 필요 없이 바로 화면을 구성하게 된다.

 

작동 방식:

1. 사용자가 웹 페이지에 접속하면, 서버에서 요청을 받아 페이지를 미리 HTML로 렌더링함.
2. 완성된 HTML 파일을 클라이언트로 보냄.
3. 브라우저는 그 HTML을 바로 렌더링하여 화면에 보여줌.

• 장점:
  • 빠른 초기 렌더링: 서버에서 이미 완성된 HTML을 보내기 때문에, 사용자가 콘텐츠를 더 빨리 볼 수 있음. 첫 로딩 속도가 빠르다는 장점
  • SEO 친화적: 서버에서 완성된 HTML이 제공되므로, 검색 엔진 크롤러가 페이지를 쉽게 인식하고 색인할 수 있어서 SEO에 유리
• 단점:
  • 서버 부하 증가: 클라이언트의 요청마다 서버가 페이지를 렌더링해서 보내기 때문에, 서버에 더 많은 부하가 걸릴 수 있음. 사용자 수가 많아지면 서버 리소스가 부족해짐.
  • 동적 업데이트가 어려움: CSR처럼 사용자와의 상호작용에 따라 동적으로 페이지를 업데이트하는 기능을 구현하기 위해서는 추가적인 작업이 필요

 

CSR vs SSR

 

이전에는 SSR(Server-Side Rendering) 방식이 주를 이루었고, 웹 페이지는 주로 서버에서 미리 만들어진 HTML을 클라이언트에게 전달하는 방식으로 동작했다. 이 당시 웹 페이지는 정적인 콘텐츠가 대부분이었고, JavaScript는 주로 간단한 인터랙션(예: 버튼 클릭, 폼 검증 등)을 처리하는 용도로만 사용됐다.

그러나 시간이 지나면서 웹 애플리케이션이 더 복잡해지고, 사용자 경험을 극대화하기 위해 동적인 데이터와 즉각적인 화면 업데이트가 중요한 요소가 되어갔다. 특히, SPA(Single Page Application)의 등장으로 인해 클라이언트 측에서 페이지를 렌더링하고 업데이트하는 CSR(Client-Side Rendering) 방식이 필요해졌다.

이때 AJAX(Asynchronous JavaScript and XML) 기술의 발전으로 웹 페이지 일부를 비동기적으로 갱신할 수 있게 되면서, 클라이언트 측에서 데이터를 받아와서 화면을 동적으로 업데이트하는 방식이 가능해졌다. 더불어 React, Vue.js, Angular와 같은 프레임워크들이 CSR을 기반으로 하여 등장했고, 이를 통해 더욱 빠르고 유연한 사용자 경험을 제공할 수 있게 되었다.

따라서 이전에는 웹 개발자가 주로 서버 측에서 모든 것을 처리했지만, CSR 기술이 발전하면서 JavaScript를 중심으로 한 프론트엔드 기술이 중요해졌고, 프론트엔드 개발자라는 역할이 명확하게 구분되기 시작했다.

- 프론트엔드 개발자: 클라이언트 측에서의 렌더링, 사용자 인터랙션, 성능 최적화 등을 주로 담당

- 백엔드 개발자: 서버 측의 비즈니스 로직과 데이터 관리를 처리

 

 

 

 

[웹 성능을 측정하는 중요한 지표]

ㅇTTV(Time To View): 사용자가 웹 페이지에 접속한 후, 첫 화면이 보이는 시간

즉, 브라우저가 HTML, CSS, JavaScript 등을 처리하여 사용자에게 처음으로 유의미한 콘텐츠를 보여줄 때까지 걸리는 시간을 측정

 

왜 중요한가? TTV는 사용자가 페이지를 얼마나 빨리 인식할 수 있는지를 나타내는 중요한 지표이다. 사용자들이 페이지를 로딩하는 동안 아무것도 보이지 않으면, 그들은 페이지가 느리다고 느낄 가능성이 크다. TTV가 짧을수록 사용자는 페이지가 빠르게 로드되었다고 느낀다.

 

 

ㅇTTI(Time To Interact): 사용자가 페이지에서 상호작용을 할 수 있을 때까지의 시간

즉, 버튼을 클릭하거나 스크롤하는 등의 상호작용이 가능해지는 시점을 기준으로 측정

 

왜 중요한가? TTI는 사용자 경험에 큰 영향을 미치는 지표이다. 사용자가 페이지를 보고 있지만 아직 상호작용할 수 없다면, 그들은 페이지가 느리게 작동한다고 느낄 수가 있다. TTI가 짧으면 사용자는 페이지를 더 빠르고 직관적으로 사용할 수 있게 된다.

 

 

 

 

(추가)

하이브리드 방식: CSR + SSR

CSR과 SSR의 장점을 결합한 방식도 많이 사용된다. 예를 들어, Next.js(React 기반)이나 Nuxt.js(Vue.js 기반) 같은 프레임워크들은 초기 페이지 로딩은 SSR로 처리하고, 이후 사용자와의 상호작용은 CSR 방식으로 처리하는 하이브리드 방식을 사용한다. 이렇게 하면 SEO와 초기 로딩 성능도 챙기면서, 사용자 경험도 향상시킬 수가 있다.

 

 

 

 

 

참고 및 출처: 서버사이드 렌더링(드림코딩 유튜브)

https://www.youtube.com/watch?v=iZ9csAfU5Os&t=262s

아주 좋은 영상이다 :) 참고로 영상에서는 CSR을 설명한 다음에 SSR을 설명하지만, 역사적으로는 SSR이 먼저 있었고 그 후에 CSR이 탄생했다