💚 SSR이란?
Server Side Rendering의 약자
말 그대로 서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식이다.
SSR의 단계
1. User가 Website 요청을 보냄
2. Server는 즉시 렌더링 가능한 html 파일을 만든다.
3. 클라이언트에 전달되는 순간, 이미 렌더링 준비가 되어있기 때문에
html은 즉시 렌더링 된다. 그러나 사이트 자체는 조작 불가능하다.
4. 클라이언트가 자바스크립트를 다운 받는다.
5. 다운 받아지고 있는 사이에 유저는 컨텐츠는 볼 수 있지만 사이트를 조작할 수는 없다.
이때의 사용자 조작을 기억하고 있는다.
6. 브라우저가 javascript 프레임워크를 실행한다.
7. JS까지 성공적으로 컴파일 되었기 때문에 기억하고 있던 사용자 조작이 실행되고,
이제 웹페이지는 상호작용이 가능해진다. SSR의 핵심은 백엔드에게 데이터를 받아오기 때문에 첫 페이지도 빈 화면이 아닌 채워진 화면이 나온다.
서버에서 완성된 페이지를 전달하기 때문에 검색 엔진이 수집하기 용이하다는 장점을 갖고 있다. 또한 서버에서 렌더링을 부담하기 때문에 사용자 하드웨어에 의존하지 않는다는 장점을 갖고 있다.
그러나, 서버에서 부담하기 때문에 생산 비용이 증가할 수 있고, SSR을 위한 코드 작성이 필요하다는 단점이 있다. 무거운 페이지라고 한다면 초기 로딩이 오히려 CSR보다 오래 걸릴 수 있다는 것 또한 SSR의 단점이다.
💛 CSR이란?
Client Side Rendering의 약자 말 그대로 SSR과 달리 렌더링이 클라이언트(브라우저) 쪽에 일어난다.
즉, 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내준다. 클라이언트는 그것을 받아 렌더링을 시작한다.
CSR의 단계
1. User가 Website 요청을 보냄
2. CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 클라이언트로 보낸다.
3. 클라이언트는 HTML과 JS를 다운로드 받는다.
5. 다운이 완료된 JS가 실행된다.
6. 서버가 API로부터의 요청에 응답한다.
7. API로부터 받아온 data를 placeholder 자리에 넣어준다. 이제 페이지는
상호작용이 가능해진다. CSR은 처음 요청할 때는 모든 리소스를 프론트에 요청하고, 프론트가 그 정보를 캐싱하고 있기까지의 과정이 있기 때문에 첫 화면을 로딩할 때는 느리다.
그러나 프론트가 모든 리소스를 캐싱하는 덕분에 클라이언트는 그때 그때 필요한 정보만 프론트에게 빼와서 만들면 된다.
CSR은 페이지에 필요한 리소스를 사전에 불러와 데이터를 캐싱하고 있다가 현재 URL에 맞는 페이지를 보여주기 때문에 초기 랜더링 이후 속도는 빠르다는 장점을 갖고 있다.
그러나 초기 페이지 로딩은 SSR보다 느리고, SEO에 불리하다. 빈화면을 보여주기 때문. 사용자는 빈 리소스를 보게될 가능성이 크다는 단점이 있다.
🤔 SSR과 CSR의 차이
-
페이지를 완성하는 주체
CSR : 클라이언트
SSR : 서버
-
웹페이지 로딩 시간
CSR : HTML, CSS와 모든 스크립트들을 한 번에 불러오기 때문에 SSR보다 느림
SSR : 필요한 부분의 HTML과 스크립트만을 불러와 평균적으로 속도가 더 빠르다.
-
SEO 대응
검색 엔진은 자동화된 로봇인 ‘크롤러’의 웹 사이트들을 읽는다. CSR은 자바스크립트를 실행시켜 동적으로 컨텐츠가 생성되기 때문에 자바스크립트가 실행 되어야 metadata가 바뀌었다.
SSR은 애초에 서버 사이드에서 컴파일 되어 클라이언트로 넘어오기 때문에 크롤러가 대응하기 용이하다.
레퍼런스 :
https://velog.io/@ka0son/렌더링-삼형제-CSR-SSR-SSG-이해하기#csrclient-side-rendering이란
