SSR(Server Side Rendering)
- Javascript 가 웹 페이지를 브라우저에서 렌더링하는 대신에, 서버에서 렌더링
- 데이터베이스의 데이터가 필요한 경우, 서버는 데이터베이스의 데이터를 불러온 다음 웹 페이지를 완전히 렌더링 된 페이지로 변환한 후에 브라우저에 응답으로 보냄
- 브라우저가 다른 경로로 이동할 때마다 서버는 이 작업을 다시 수행
- USE
- SEO(Search Engine Optimization, 검색 엔진 최적화)가 우선순위인 경우, 일반적으로 SSR 을 사용
- 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우에도, 단일 파일의 용량이 작은 SSR 이 적합
- 웹 페이지가 사용자와 상호작용이 적은 경우, SSR 을 활용
- Risk
- 자원이용이 서버에 집중되기 때문에 애플리케이션 유지비용이 높음
- 일부 서드파티 자바스크립트 라이브러리의 경우 서버사이드 렌더링이 불가능할 수 있음
- 예시
- 네이버 블로그
: 검색엔진 최대한 노출되는 게 유리
: 다른 웹사이트에 비해 사용자와 상호작용이 많지 않음
- The NewYork Times
: 많은 사용자가 클릭할 때마다 전체 웹사이트를 다시 서버에서 받아오기 때문에 발생하는 서버 과부하 이슈가 있음에도 불구하고, CSR에 비해 초기 로딩 속도가 빠르기 때문에 구독자가 신문기사를 빠르게 읽을 수 있다는 장점
: 해당 신문사의 기사가 검색엔진에 노출되는 것이 중요하기 때문에 SEO(Search Engine Optimization)에 유리한 SSR을 이용
CSR(Client Side Rendering)
- 클라이언트에서 Javascript 가 페이지를 렌더링
- 웹 페이지를 렌더링하는 데에 필요한 데이터를 API 요청으로 데이터베이스에 저장된 데이터를 가져와서 웹 페이지에 렌더링
- CSR에서는 SSR과 다르게, 서버가 웹 페이지를 다시 보내지 않음, 브라우저는 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링함. 이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일임
- USE
- SEO가 우선순위가 아닌 경우, CSR을 이용
- 사이트에 풍부한 상호 작용이 있는 경우, CSR 은 빠른 라우팅으로 강력한 사용자 경험을 제공
- 웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공
- Risk
- 느린 렌더링 속도로 사용자 경험이 안 좋아 질 수 있음. 모든 렌더링의 부하가 클라이언트 쪽에 집중되기 때문에 사용자에 따라서 경험이 달라짐.
- search engine bots 와 상성이 안좋음. Javascript가 렌더링해야 하는 정보들은 Google 과 같은 search engine index에 포함이 안될 가능성이 매우 높음.
- 예시
- 아고다 등 (예약 사이트에 유리)
: SSR에서는 서버에서 렌더링을 해야 하기 때문에 상호작용(interaction)이 많아질수록 서버에 부담이 많은 반면에, CSR에서는 서버가 클라이언트에 필요한 데이터만 넘겨주기 때문에 부담이 적음
: SPA(Single Page Application)를 기반으로 화면의 일부만 받아온 데이터로 변경해 주기 때문에 빠른 렌더링으로 User Experience(사용자 경험)에 유리
