CSR vs. SSR

CSR(Client-Side-Rendering)

서버가 요청을 받으면 클라이언트에 HTML, JS를 보냅니다. 클라이언트는 이 파일을 받아 렌더링을 시작합니다.
js파일이 다운 완료되고 실행이 끝나기 전까지 사용자는 페이지를 볼 수 없습니다.

세부 동작

1. 유저가 웹사이트에 요청을 보냄
2. CDN이 HTML 파일과 js파일로 접근할 수 있는 링크를 클라이언트로 보냄
cf) CDN: aws의 cloudflare를 생각하면 됨. 엔드 유저 요청에 '물리적'으로 가까운 서버에서 요청에 응답하는 방식
3. 클라이언트는 HTML과 JS를 다운로드 받는다.(이때 SSR과 달리 유저는 아무것도 볼 수 없다.😡)
4. 클라이언트가 자바스크립트를 다운 받음.
5. 다운이 완료된 JS가 실행된다. 데이터를 위한 API가 호출된다.(이때 유저들은 placeholder를 보게된다.)
6. 서버가 API로부터의 요청에 응답한다.
7. API로부터 받아온 data를 placeholder 자리에 넣어준다. 이제 페이지는 상호작용이 가능해진다.

SSR(Server-Side-Rendering)

서버에서 이미 '렌더 가능한' 상태로 클라이언트에 전달되기 때문에, 자바스크립트가 다운되는 동안 사용자는 뭔가를 보고 있을 수 있습니다.

세부 동작

1. 유저가 웹사이트에 요청을 보냄
2. 서버는 즉시 렌더링 가능한 html파일을 만든다. (리소스 체크, 컴파일 후 완성된 HTML 컨텐츠로 만든다.)
3. 클라이언트에 전달되는 순간, 이미 렌더링 준비가 되어있기 때문에 HTML은 즉시 렌더링 된다. 그러나 사이트 자체는 조작 불가능. (Javascript가 읽히기 전임.)
4. 클라이언트가 자바스크립트를 다운 받음.
5. 다운 받아지고 있는 사이에 유저는 컨텐츠는 볼 수 있지만 사이트를 조작 할 수는 없다. 이때의 사용자 조작을 기억하고 있는다.
6. 브라우저가 Javascript 프레임워크를 실행한다.
7. JS까지 성공적으로 컴파일 되었기 때문에 기억하고 있던 사용자 조작이 실행되고 이제 웹 페이지는 상호작용 가능해진다.

차이점

1. 웹페이지 로딩 시간

• 첫 페이지 로딩 시간
  • SSR > CSR
    • CSR은 HTML, CSS, 모든 js파일을 일단 한번에 불러옴. SSR은 필요한 부분의 HTML, CSS, js파일만 불러옴.
• 나머지 로딩 시간
  • CSR > SSR
    • 첫 페이지 로딩 후 다른 페이지로 이동시 CSR은 이미 모든 코드를 갖고 왔기 때문에 클라이언트 단에서 화면을 그리는데 파일이 많아 무거워 시간이 더 오래 걸린다.

2. SEO 대응

• CSR은 자바스크립트가 실행돼야 metadata가 바뀜.
• SSR은 애초에 서버 사이드에서 컴파일 되어 클라이언트로 넘어오기 때문에 크롤러 대응에 더 좋음.

3. 서버 자원 사용

• SSR이 서버 자원을 더 사용함. 매번 서버에 요청하기 때문.

사용 권장 예시

1) SSR 권장 예시

• 네트워크가 느릴 때
  • SSR은 각 페이지마다 파일을 나눠 불러오기 때문. CSR은 한번에 모든 것을 불러옴.
• SEO(Search Engine Optimization: 검색 엔진 최적화)가 필요할 때.
• 최초 로딩이 빨라야 하는 사이트를 개발할 때
• 메인 스크립트가 크고 로딩이 매우 느릴 때 CSR은 메인스크립트가 로딩이 끝나면 API로 데이터 요청을 한다. 하지만 SSR은 한번의 요청으로 바로 렌더가 가능한 페이지 파일이 넘어온다.
• 웹 사이트가 상호 작용이 별로 없을 때.

2) CSR 권장 예시

• 네트워크가 빠를 때
• 서버의 성능이 좋지 않을 때
• 사용자에게 보여줘야 하는 데이터의 양이 많을 때.
  • 로딩 창을 띄울 수 있는 장점이 있음.
• 메인 스크립트가 가벼울 때
• SEO 최적화 안 해도 될 때
• 웹 어플리케이션에 사용자와 상호 작용할 것들이 많을 때
  • 아예 렌더링 되지 않아 사용자의 행동을 막는 것이 사용 경험에 오히려 유리함.