CSR과 SSR

CSR : Client Side Rendering

클라이언트 측의 브라우저가 JS파일을 다운로드하고
직접 실행하여 렌더링을 하는 것을 말함

 

1. 인터넷이 느리거나 사용자가 JS를 비활성한다면 아무것도 나오지 않을 수 있다.
2. 앵귤러, 뷰, 리액트 등
3. 쉽게 말해서 클라이언트 측에서 다하는 것을 말함
4. 서버에서  전체 페이지를 다시 읽어 오고 필요한 부분만 받아오기에 빠른 인터렉션이 가능하다.

문제점

1. 사용자가 첫화면을 보기까지의 시간이 좀 걸린다.
2. 구글 네이버와 같은 검색엔진이 해당 페이지를 빈 페이지로 인식하여 검색엔진이 인식을 못한다.
3. 클라이언트 측에서 사용자의 정보를 쿠키에 저장하기에 보안상의 문제가 발생한다. SSR에서는 서버측에서 세션으로 관리한다.

 

SSR : Server Side Rendering

UI를 서버에서 렌더링하는 것!
모든 컨텐츠가 html에 담겨있기때문에 검색엔진이 검색하기 유용하다.

 

서버사이드 렌더링을 구현하면 사용자가 웹 서비스에 방문했을 때 서버 쪽에서 초기 렌더링을 해준다.

그리고 사용자가 html을 전달 받을 때 그 내부에 렌더링된 결과물이 보인다.

 

맨처음에는 HTML만 있어서 사용자와 인터렉션은 되지 않는다. 그 후에 JS 코드가 다운로드 되고 실행되어 이미 존재하는 HTML과 동기화하여서 인터렉션이 가능해진다.

 

장점

1. 웹 서비스의 검색엔진 최적화를 위해서라면 서버 사이드 렌더링을 구현해주는 것이 좋다.

• 구글,네이버,다음 등의 검색 엔진이 우리가 만든 웹 애플리케이션의 페이지를 원할하게 수집할 수 있다 리액트로 만든 SPA는 검색 엔진 크롤러 봇처럼 JS가 실행되지 않는 환경에서는 페이지가 제대로 나타나지 않는다. 따라서 서버에서 클라이언트 대신 렌더링을 해주면 검색 엔진이 페이지의 내용을 제대로 수집할 수 있다. 구글 검색 엔진은 다른 검색엔진과 다르게 검색엔진에서 JS를 실행하는 기능이 탑재되어 있어서 제대로 페이지를 크롤링해 갈 때도 있지만, 모든 페이지에 대해 JS를 실행해주지는 않는다.

2. 초기 렌더링 성능 개선

• 예를 들어 SSR(서버사이드렌더링)이 구현되지 않는 웹 페이지에 사용자가 방문하면 JS가 로딩되고 실행될 때까지 사용자는 비어있는 페이지를 보며 대기해야한다. 여기에 API까지 호출해야 한다면 사용자의 대기 시간이 더더욱 길어진다.
• 반면에 SSR을 구현한 웹페이지라면 JS파일이 다운로드가 완료되지 않은 시점에서도 html상에 사용자가 볼수 있는 컨텐츠가 있기 때문에 대기 시간이 최소화되고 사용자 경험 또한 향상된다.

단점

1. SSR은 결국 원래 브라우저가 해야할 일을 서버가 대신 처리하는 것이므로 서버 리소스가 사용된다는 단점이 있다.

 

2. 갑자기 수많은 사용자가 동시에 웹 페이지에 접속하면 서버에 과부하가 발생할 수 있다.

따라서 사용자가 많은 서비스라면 캐싱과 로드 밸런싱을 통해 성능을 최적화 해줘야 한다.

사용자가 많을수록!

클릭할수록 서버에게 요청하는데 이요청이 많아지면 과부하 걸림

 

3. SSR을 하면 프로젝트의 구조가 좀더 복잡해 질 수 있다

데이터를 미리 불러오기, 코드 스플리팅과의 호환등 고려해야할 사항이 많다.

 

4. 에러가 발생하면 다시 처음부터 데이터를 받아와야함

 

 

SPA에서 서버사이드 렌더링을 하는이유

리액트로 만든건 검색엔진에 뜨지 않기 때문에 검색엔진으로 우리가 만든 웹 사이트가 검색 되길 바라기 때문에 서버사이드 렌더링을 하며 보안 문제상으로 SSR을 해주는 게 좋다!

 

리액트 프레임워크인 Next.js를 사용하여 SSR를 할 수 있다.