Client-Side Rendering & Server-Side Rendering
1. Server Side Rendering (SSR)
SSR
- 전통적인 웹 애플리케이션 렌더링 방식
- 사용자가 웹페이지에 접근할 때, 서버에 페이지에 대한 요청을 함
- 서버에서 HTML, View와 같은 자원들을 어떻게 보여줄지 해석하고 렌더링하여 사용자에게 반환함
- 웹 서버에 요청할 때마다 브라우저에서 새로고침이 일어나고, 서버에 새로운 페이지에 대한 요청을 하는 방식
SSR의 장단점
- SSR의 장점
- 검색엔진최적화(SEO) 가능
- SEO : 웹페이지 검색엔진이 자료를 수집하고 순위를 매기는 방식에 받게 페이지를 구성하여 검색 결과의 상위에 나올 수 있도록 하는 작업
- 초기 로딩 속도 빠름
- 처음 렌더링된 HTML을 클라이언트에게 전달해주기 때문에 초기 로딩 속도를 줄일 수 있음
- SSR의 단점
- 프로젝트 구조가 복잡해짐
- Redux, React Router 등 여러 라이브러리와 함께 연동하여 서버에서 데이터를 가져와서 렌더링하는 상황이 발생하면, 프로젝트가 복잡해질 수 있음
- 매번 새로고침이 발생함
- 서버에 요청할 때마다 새로고침이 발생하므로, 서버와의 잦은 응답으로 인해 서버에 부담을 주게 됨
2. Client Side Rendering (CSR)
SPA : Single Page Application
- 컴퓨터에 비해 성능 낮은 모바일을 최적화시키기 위해 등장한 개념
- 최초 한 번 전체 페이지를 로딩한 이후 데이터만 변경하여 사용하는 단일 페이지로 구성된 웹 애플리케이션
- 화면 구성에 필요한 모든 HTML을 클라이언트가 갖고 있고, 서버에 필요한 데이터를 요청하여 JSON 형식으로 받기 때문에 기존 애플리케이션에 비해 화면을 구성하는 속도가 빠름
- 서버에서는 JSON 파일을 보내는 역할만 하고, 클리이언트에서 JavaScript가 HTML을 그리는 역할을 함 => CSR
CSR
- 클라이언트에서 최초 한번 서버에 전체 페이지를 로딩하여 보여줌
- 그 이후 사용자의 요청이 올 때 마다, 서버에 자원을 요청하고 클라이언트가 해석해서 렌더링함
- CSR 과정
- 처음 웹 서버에 요청할 때 데이터가 없는 문서(HTML, static 파일)를 반환함
- HTML 및 static 파일이 로드됨
- 데이터가 있다면, 데이터도 서버에 요청하여 화면에 나타냄
- 사용자의 상호작용에 따라 JavaScript를 통해 동적으로 렌더링함
- 필요에 따라 서버에 데이터를 요청하여 받아와서 렌더링함
CSR의 장단점
- CSR의 장점
- 트래픽 감소와 빠른 상호작용
- CSR은 사용자 행동에 따라 필요하고 변경된 데이터만 받아올 수 있기 때문에 빠른 상요작용이 가능하고 서버의 부담이 덜함
- CSR의 단점
- 초기 구동 속도가 느림
- CSR은 서버에서 View를 렌더링하는 것이 아니라 HTML, JavaScript 파일, 각 종 데이터를 로딩한 후 브라우저에서 렌더링하기 때문에 초기 구동속도가 느림
- 검색엔진 최적화(SEO)가 어려움
- CSR 방식으로 이루어진 웹 페이지에서 View를 생성하기 위해서는 반드시 JavaScript를 실행시켜야 함
- 대부분 웹 크롤러 봇들은 JavaScript 파일을 실행시키지 못하기 때문에 HTML에서만 내용을 수집하여 빈 페이지로 인식하게 됨
- + 최근에 Crome 크롤러 봇은 JavaScript 파일을 실행시킬 수 있다고 함
- 보안 문제가 있음
- SSR은 사용자 정보를 서버 측에서 세션으로 관리하지만, CSR은 쿠기 말고 사용자 정보를 저장할 공간이 마땅치 않음
