CSR(Client-Side Rendering)과 SSR(Server-Side Rendering)

❓ 클라이언트 사이드 렌더링(CSR)

CSR은 웹 페이지가 사용자의 브라우저에서 직접 그려지는 방식이다.

여기서 중요한 점은, 서버가 사용자에게 완성된 페이지를 보내는 것이 아니라 기본적인 HTML 뼈대만 전달한다는 것이다.

 

이 기본 HTML 은 말 그대로 페이지의 틀만 가지고 있을 뿐, 실제로 화면에 표시될 내용(텍스트, 이미지, 버튼 등...)은 없는 상태이다. 즉, 브라우저는 처음에 빈 화면을 받게 된다.

그래서 페이지가 처음 로드될 때, 화면에 거의 아무것도 보이지 않거나 간단한 로딩 화면만 나타날 수 있다.

 

브라우저는 이 HTML 파일을 받은 후, HTML 안에 포함된 자바스크립트 파일을 불러와서 실행한다.

자바스크립트는 서버로부터 필요한 데이터를 다시 요청하고, 그 데이터를 이용해 페이지의 나머지 부분을 채워나간다.

이렇게 해서 사용자가 실제로 보는 화면이 점점 완성되는데, 이 과정이 모두 브라우저 안에서 이루어진다.

 

요약하자면, 서버는 페이지를 완성된 상태로 그려서 보내는 것이 아니라, "HTML 뼈대와 자바스크립트"를 보내서, 브라우저가 직접 페이지를 완성하게 하는 것이다.

 

---

⚙️ CSR 동작방식

1. 사용자가 웹 페이지에 접속하면, 브라우저는 서버에 요청을 보내서 페이지를 받아온다.
2. 서버는 기본적인 HTML 파일을 브라우저에 전달하는데, 이 HTML 파일에는 페이지의 기본 틀만 들어있다.
3. 브라우저는 HTML 파일을 받아와 자바스크립트를 실행한다. 이 자바스크립트는 다시 서버에 데이터를 요청해서, 화면에 필요한 정보를 받아온다.
4. 받아온 데이터를 기반으로 브라우저가 화면을 완성한다.

 

🌟 CSR 장점

1. 동적인 페이지 전환: CSR 은 사용자가 페이지 내에서 상호작용할 때(예: 버튼 클릭, 메뉴 선택 등), 페이지 전체를 다시 로드하지 않고, 필요한 부분 업데이트할 수 있다. 이 덕분에 화면 전환이 부드럽고 빠르게 느껴진다.
2. 더 나은 사용자 경험(UX): CSR 에서는 한 번 페이지가 로드되면, 이후에는 페이지 이동이 빠르다. 왜냐하면 필요한 자바스크립트와 데이터를 이미 한 번 받았기 때문이다. 사용자가 여러 페이지를 이동할 때, 전체를 다시 로드하지 않고 필요한 데이터만 요청하기 때문에 웹사이트가 더욱 반응성이 좋게 느껴진다.

 

⛔️ CSR 단점

1. 초기 로딩 속도가 느림: CSR 에서는 페이지를 처음 불러올 때 서버에서 HTML 뼈대만 받고, 나머지 자바스크립트와 데이터를 따로 요청해서 화면을 구성한다. 이 때문에 자바스크립트 파일이 모두 로드되고 실행될 때까지는 화면이 빈 상태로 보일 수 있다. 즉, 초기 로딩 속도가 상대적으로 길어질 수 있다.
2. SEO(검색 엔진 최적화)에 불리: 검색 엔진(구글 등)은 웹 페이지를 읽을 때, HTML 의 내용을 바탕으로 페이지를 분석한다. CSR 은 초기 HTML 이 거의 비어 있는 상태이기 때문에, 검색 엔진이 제대로 페이지 내용을 분석하기 어렵다. 이는 사이트가 검색 결과에서 불리해질 수 있음을 의미한다.

 

---

❓ 서버 사이드 렌더링(SSR)

CSR 은 웹 페이지를 사용자가 요청할 때, 서버에서 HTML 을 미리 생성하여 사용자에게 전달하는 렌더링 방식이다.

이 방법은 서버가 웹 페이지의 내용을 미리 준비하고, 사용자가 페이지에 접속하면 즉시 완성된 HTML 파일을 브라우저로 전송한다.

 

SSR 의 가장 큰 특징은 서버가 페이지를 사전에 렌더링 한다는 점이다.

사용자가 웹 사이트를 방문하면, 브라우저는 서버에 페이지 요청을 보낸다.

서버는 이 요청을 처리하고 필요한 데이터를 수집하여 완성된 HTML 문서를 만든다.

이 HTML 문서에는 웹 페이지의 모든 내용(텍스트, 이미지, 링크, 버튼 등...)이 포함되어 있다.

 

사용자가 브라우저에서 이 HTML 을 받아보면, 브라우저는 이 문서를 즉시 해석하여 사용자에게 보여준다.

결과적으로, 사용자는 페이지를 요청한 즉시 콘텐츠를 확인할 수 있다.

 

---

⚙️ SSR 동작방식

1. 사용자가 웹 페이지를 요청하면, 브라우저는 해당 요청을 서버에 보낸다.
2. 서버는 요청을 받고, 필요한 데이터를 데이터베이스에서 가져오거나 다른 API 와 통신하여 필요한 정보를 수집한다.
3. 서버는 수집한 데이터를 바탕으로 완성된 HTML 파일을 만든다. 이 파일을 모든 콘텐츠와 구조를 포함하고 있으며, 사용자가 요청한 페이지를 즉시 렌더링 할 수 있도록 준비된다.
4. 완성된 HTML 파일은 브라우저로 전송된다. 이 과정에서 서버는 브라우저가 요청한 모든 요소를 포함한 HTML 파일을 전달하여, 브라우저가 페이지를 그리는 데 필요한 모든 정보를 갖추게 한다.
5. 브라우저는 받은 HTML 을 즉시 화면에 렌더링 한다.

 

🌟 SSR 장점

1. 빠른 초기 로딩 속도: SSR 에서는 서버에서 미리 생성된 HTML 파일을 제공하기 때문에, 사용자는 즉시 콘텐츠를 확인할 수 있다. 초기 로딩 속도가 빨라서 사용자가 페이지를 기다리는 시간을 최소화할 수 있다.
2. SEO 최적화에 유리: SSR 은 검색 엔진 최적화에 유리하다. SSR 에서는 초기 페이지 로드 시 모든 콘텐츠가 포함되어 있기 때문에, 웹사이트가 검색 결과에서 더 잘 노출 될 수 있다.

 

⛔️ SSR 단점

1. 서버 부하 증가: SSR 에서는 사용자의 요청마다 서버가 새로운 HTML 을 생성해야 한다. 이는 서버에 추가적인 부하를 발생시키며, 특히 트래픽이 많은 웹사이트에서는 성능 저하를 초래할 수 있다. 따라서 서버의 용량과 성능이 중요하다.
2. 전체 페이지 새로고침: SSR 방식에서는 사용자가 페이지의 일부만 변경하더라도, 전체 페이지를 다시 로드해야 한다. 예를 들어, 사용자가 메뉴를 클릭하여 다른 페이지로 이동할 경우, 서버에서 새로운 HTML 파일을 요청하고 이를 다시 렌더링해야 하므로, 사용자는 매번 새로고침되는 페이지를 경험하게 된다. 이로 인해 사용자 경험이 저하될 수 있다.

 

---

📌 CSR vs SSR

구분	클라이언트 사이드 렌더링(CSR)	서버 사이드 렌더링(SSR)
렌더링 위치	브라우저에서 수행	서버에서 수행
초기 로딩 속도	상대적으로 느림 (빈 HTML 뼈대 제공)	빠름 (완성된 HTML 제공)
SEO 최적화	불리 (페이지 내용이 자바스크립트로 로드됨)	유리 (모든 콘텐츠가 초기 로드 시 포함됨)
서버 부하	낮음 (주로 API 요청 및 데이터 처리)	높음 (모든 요청에 대해 HTML 생성 필요)
사용자 경험	동적이고 빠른 상호작용 가능	초기 로딩 후 페이지 새로 고침 필요
상태 관리	클라이언트에서 상태를 유지하고 관리	서버에서 상태를 관리하고, 클라이언트에 전송

 

---

💡 참고 자료

https://prismic.io/blog/client-side-rendering

What is Client-side Rendering (CSR)?

https://prismic.io/blog/client-side-vs-server-side-rendering

Client-side Rendering (CSR) vs. Server-side Rendering (SSR)

https://strapi.io/blog/server-side-rendering-vs-client-side-rendering

Server-Side Rendering vs Client-Side Rendering