CSR
Client Side Rendering
서버에서 처리 없이 클라이언트에서 렌더해야 하기 때문에 자바스크립트가 모두 다운되고 실행이 끝나기 전까지 사용자는 볼 수 있는게 없다.
단계
- 웹사이트 요청
- 서버에서 요청에 응답
- 클라이언트는 HTML과 JS를 다운로드 받음(유저는 아무것도 볼 수 없음)
- 다운이 완료된 JS가 실행, 데이터를 위한 API 호출 (유저들은 placeholder를 봄)
- 서버가 API로부터의 요청에 응답
- API로부터 받아온 data를 placeholder 자리에 넣어줌
- 상호작용이 가능해짐
SSR
Server Side Rendering
서버에서 렌더링 준비를 마치고 클라이언트에 전달
단계
- 웹사이트 요청
- 서버는 즉시 렌더링 가능한 html파일을 만든다.
- 클라이언트에 전달되는 순간, 이미 렌더링 준비가 되어있기 때문에 HTML은 즉시 렌더링 됨. (Javascript는 읽히기 전이라 사이트 조작 불가능)
- 클라이언트에서 자바스크립트를 다운받음
- 다운 받아지고 있는 사이에 유저는 컨텐츠를 볼 수는 있지만 사이트 조작은 할 수 없다. (대신 조작을 기억하고 있음)
- 브라우저가 Javascript 실행되면 기억하고있던 사용자 조작이 실행되고 웹 상호작용이 가능해짐
둘의 차이점은?
1. 웹페이지 로딩 시간
처음 로딩되는 시간은 SSR이 빠르다.
CSR은 전체 페이지 구성을 다운로드 한 후에 보여주고, SSR은 첫 로딩시 필요한 HTML과 스크립트만 불러오기 때문이다.
하지만 이후 페이지 이동은 CSR이 빠르다.
이미 다른 페이지의 구성요소들도 다운받아놓은 상태이기 때문이며, SSR은 페이지를 로딩 할 때마다 불러오기를 다시 하기때문에 느리다.
2. SEO 대응
다른 글들을 찾아 보았을 때 CSR의 경우 빈 HTML이라 크롤링이 되지 않는다는 글들이 많아서 이 부분은 나도 많이 헷갈렸었다.
2019년도 부터 구글은 JS까지 렌더링 하여 크롤링할 수 있다는 글도 있고....
또한 CSR에서 Pre-rendering(미리 준비된 정적 페이지를 만든다)을 가능하게 해주는 라이브러리가 존재하여 SEO에 대응할 수 있으며, header의 meta 태그를 이용하여 설정해주는 방법도 있다.
header에 meta태그가 포함되면 SEO도 가능하며 링크를 공유할 때 썸네일, 텍스트 등을 노출할 수 있다. 이또한 라이브러리로 해결은 가능하다.
3. 서버 자원 사용
SSR이 페이지 이동 시 매번 서버에 요청을 하기 때문에 자원이 더 많이 사용된다.
🧐 내 생각 ?
장점과 단점이 공존하니 프로젝트마다 성격이 다를테니 어떤걸 사용할 지는 그때 맞춰서 골라야 할 것 같다.
공부하며 정리&기록하는 ._. 씅로그
