🌱 CSR
-
정의 : Client Side Rendering의 약자로 클라이언트 측에서 렌더링이 일어나는 방식.
-
특징 :
- SPA에서 사용
- 처음에 모든 JS 파일을 다운 받아 와서 초기 로딩 속도가 느리지만, 이후 페이지 전환 시 로딩 속도는 빠르다. (일부만 요청하면 되기 때문)
- 서버에 부담이 적다.
- 반응 속도가 빨라 UX 측면에서 좋다.
- SEO(검색 엔진 최적화)에 불리함 (구글의 크롤러 봇은 JS를 실행할 줄 알아서 CSR 크롤링도 가능하지만, 개선해나가는 단계)
🌱 SSR
-
정의 : Server Side Rendering의 약자로 서버 측에서 렌더링이 일어나는 방식.
-
특징 :
- MPA에서 사용
- 서버 요청 시 즉시 HTML을 만듦
- 데이터가 달라져서 미리 만들어두기 어려운 페이지에 적합하다.
- 첫 로딩 속도는 빠르나, 이후 페이지 전환 시 마다 서버 요청으로 인해 로딩 속도가 느리다.
- 서버에 부담이 간다.
- TTV(Time To View)와 TTI(Time To Interact) 사이 간극이 있어 UX 측면에서 좋지 않다.
- 모든 데이터가 HTML에 담긴 채로 전달되기 때문에 SEO에 유리하다.
SPA !== CSR, MPA !== SSR임을 인지하자.
페이지가 몇 개인지, 렌더링을 어디서 하는지에 따라 다른 개념!
🌱 SSG
-
정의 : Static Site Generation의 약자로 서버에서 요청 시 HTML을 미리 다 만들어 놓는 정적 렌더링 방식.
-
특징 :
- 바뀔 일이 거의 없는 정적 페이지에 적합하다. (캐싱에 용이)
🌱 CSR과 SSR의 동작 과정
🌿 CSR
- User가 웹사이트에 요청을 보낸다.
- CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 클라이언트로 보낸다.
- 클라이언트는 HTML, JS를 다운받는다. (이때, SSR과 달리 유저는 아무것도 볼 수 없음.)
- 다운이 완료된 JS가 실행되고 데이터를 위한 API가 실행된다.
- 서버가 API 요청에 응답한다.
- API로 받아온 데이터를 보여주고 인터랙션이 가능해진다.
🌿 SSR
- User가 웹사이트에 요청을 보낸다.
- 서버는 즉시 렌더링 가능한 HTML을 만든다.
- 클라이언트에 전달되는 순간 즉시 렌더링된다. (JavaScript가 읽히기 전이므로 인터랙션은 불가능)
- 클라이언트가 JS를 다운받는다.
- 다운받는 사이 User는 컨텐츠를 볼 수 있지만, 인터랙션은 할 수 없다. (사용자 조작을 기억하고 있는다.)
- 브라우저가 JS 프레임워크를 실행한다.
- 기억하고 있던 사용자 조작을 실행한다.
🌱 CSR 보완 방법
- 초기 로딩 속도 보완 방법
- 코드 스플리팅
- 트리 쉐이킹
- chunk 분리
- SSR이나 SSG 도입
번들 사이즈를 줄여 초기 로딩 속도 보완
- SEO 보완 방법
- pre-rendering (라이브러리, 웹팩 플러그인 등을 통해 크롤러가 요청 시 미리 만들어둔 HTML을 줌)
- SSR이나 SSG 도입
🌱 CSR + SSR/SSG 도입 방법
-
프레임워크 없이 도입하는 방법 (다소 복잡함)
- node, express (별도 서버 직접 운영)
- nest
-
프레임워크 사용
- React
- Next.js (SSR, SSG 선택 가능)
- Gatsby (SSG에 최적화, 다양한 플러그인)
- Angular
- Universal (원래 프레임워크였으나 4부터 모듈에 포함됨)
- Vue.js
- Nuxt.js
- React
🌱 느낀 점
- 검색 노출이 중요한지, 인터랙션이 중요한지, 사이트가 정적인지 등 서비스 성격에 따라서 CSR, SSR, CSR + SSR 중에서 잘 선택하자!
| 참고자료 |
FE developer