[Next.js] CSR(Client Side Rendering), SSR(Server Side Rendering)

클라이언트사이드렌더링_CSR(Client Side Rendering), 서버사이드렌더링_SSR(Server Side Rendering)

 

CSR

Client Side Rendering의 약자이다.
렌더링이 클라이언트 사이드에서 일어난다.

 1. 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내준다. 
 2. 클라이언트는 그것을 받아 렌더링을 시작한다.

 

CSR 순서
1. User가 Website에 페이지에 대한 요청을 보낸다.
2. CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 클라이언트 사이드로 보낸다.
    CDN : aws의 cloudflare와 같이 엔드 유저의 요청에 '물리적'으로 가까운 서버에서 요청에 응답하는 방식이다.
3. 클라이언트는 HTML과 JavaScript를 다운로드 받는다. (이때 SSR과 달리 유저는 아무것도 볼 수 없다)
4. 다운로드가 완료된 JavaScript가 실행되고 데이터를 위한 API가 호출된다. (이때 placeholder 및 datafetching전 데이터를 본다)
5. 서버가 API로부터의 요청에 응답한다.
6. API로부터 받아온 data를 placeholder 및 datafetching 전 자리에 넣어준다. 이제 페이지는 상호작용이 가능해진다.


즉, 서버에서 처리 없이 클라이언트로 보내주기 때문에 자바스립트가 모두 다운로드 되고 실행이 끝나기 전까지 사용자는 볼 수 있는게 없다. 

 

 

---

 

SSR

Server Side Rendering의 약자이다.

서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식이다.

 

SSR 순서

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


즉. 서버에서 이미 '렌더 가능한' 상태로 클라이언트에 전달되기 때문에, JavaScript가 다운로드 되는 동안 사용자는 무언가를 보고 있을 수 있다.

 

 

---

 

CSR vs SSR

1. 웹페이지를 로딩하는 시간

웹 페이지 로딩의 종류는 두 가지로 나눌 수 있다.
 1) 하나는 웹 사이트의 가장 첫 페이지를 로딩하는 것.
 2) 다른 하나는 나머지를 로딩하는 것

1) 첫 페이지 로딩시간
- CSR의 경우 HTML, CSS와 모든 스크립트들을 한 번에 불러온다. 반면 SSR은 필요한 부분의 HTML과 스크립트만 불러오게 된다.

- 따라서 평균적으로 SSR이 더 빠르다.

2) 나머지 로딩 시간
- 첫 페이지를 로딩한 후, 사이트의 다른 곳으로 이동하는 식의 동작을 가정하자. CSR은 이미 첫 페이지 로딩할 때 나머지 부분을 구성하는 코드를 받아왔기 때문에 빠르다.
- 반면, 첫 페이지를 로딩한 과정을 정확하게 다시 실행하는 SSR이 더 느리다.

 

 

2. SEO 대응

 1. 검색 엔진은 자동화된 로봇인 '크롤러'로 웹 사이트들을 읽는다

 2. CSR은 자바스크립트를 실행시켜 동적으로 컨텐츠가 생성되기 때문에 자바스크립트가 실행 되어야 meatadata가 바뀌었다.
 3. 이전 크롤러들은 자바스크립트를 실행시키지 않았었기에 SEO 최적화가 필수적이었지만 구글이 그 트렌드를 바꾸고 있다고 하지만 아직 SEO 최적화를 해야 크롤러에 더 빨리 크롤링될 수 있다.
4. 애초에 서버 사이드에서 컴파일되어 클라이언트로 넘어오기 때문는 SSR이 크롤러에 대응하기 용이하다.

 

 

3. 서버 자원 사용

1. 매번 서버에 요청을 하기 때문에 SSR이 서버 자원을 더 많이 사용한다.
 2. 반면 클라이언트에서 모든 작업을 처리하는 CSR이 서버에 부하가 적다.

 

 

---

 

정리

클라이언트 사이드 렌더링(Client Side Rendering)

 - 클라이언트 사이드 렌더링은 클라이언트인 브라우저가 렌더링을 처리하는 방식이다.

 - 서버에서 받은 데이터를 통해 클라이언트인 브라우저가 화면을 그리는 주체이다.

장점
 - 네이티브 앱과 비슷한 빠른 인터렉션을 구현할 수 있다.
 - 렌더링을 브라우저에게 담당시킴으로서 서버 트래픽을 감소시키고, 사용자에게 더 빠른 인터렉션을 제공해 준다.
 - 새로고침이 발생하지 않아 사용자가 네이티브 앱과 비슷한 경험을 할 수 있다.

단점
 - 첫 페이지 로딩 속도가 서버 사이드 렌더링에 비해 다소 느리다.
 - 서버에 첫 요청 시 전체 페이지에 대한 모든 문서 파일을 받다 보니 서버 사이드 렌더링보다 로딩 속도가 느리다.
 - 검색엔진최적화(SEO)에 대한 추가 보완 작업이 필요하다.
 - 포털사이트 검색엔진 크롤러가 웹사이트에 대한 데이터를 제대로 수집하지 못하는 경우가 발생할 수 있다.

 - 구글의 검색엔진의 경우 자바스크립트 엔진이 내장되어 있어 크롤링이 되지만, 네이버, 다음의 경우 검색엔진이 제대로 크롤링하지 못하기 때문에 별도의 보완작업이 필요하다. (예, sitemap 문서 작성)

 

 

서버 사이드 렌더링(Server Side Rendering)
 - 서버 사이드 렌더링은 클라이언트(브라우저)가 서버에 매번 데이터를 요청하여 서버에서 처리하는 방식이다.

 - 클라이언트에서 요청이 들어올 때마다 매번 서버에서 새로운 화면을 만들어 제공한다.

 - 서버가 화면을 그리는 주체이다.

장점
 - 첫 페이지 로딩 속도가 클라이언트 사이드 렌더링에 비해 더 빠르다.
 - 해당 첫 페이지에 해당하는 문서만 브라우저에게 전달하여 브라우저가 렌더링하기 때문에 초기 로딩 속도가 클라이언트 사이드 렌더링에 비해 더 빠르다.
 - 검색엔진최적화(SEO)가 가능하다.

 

단점
 - 초기 로딩 이후 페이지 이동 시 속도가 느리다.
 - 페이지 이동 시마다 클라이언트가 서버에게 필요한 데이터를 요청하고 응답해주는 방식이다 보니 속도가 느리다.