SSR과 CSR, 좀 멋있는 이름인걸?

Keun·2022년 6월 17일
0

이름이 멋있는 친구들: SSR & CSR

이상하게 이름 볼때마다 특수부대 느낌난다. 나만그렇지 그치?

아무튼 항상 여기에 정리할땐 이상한 이야기로 시작해야 뭔가 워밍업하고 쓰는 기분이야.

이건 특수용어가 절대 아니야. 쫄지마. 알았지?

별거없어.

저 이름을 보면서, 리액트 생각해주면서, 뭔가 뒤엉켜있을거같은 보이지않는 서버쪽 생각하면서, 마음을 가다듬고 저 용어들을 지긋이 바라봐.

SSR...흠 뭔가 S 둘중 하나는 Server...흠...R뭔가..음...랜더링? Rendering? ok...

역시 SSR -> Server Side Rendering.

한국어 그대로 말하면~ 서버 쪽 렌더링. 서버 렌더링? 자, 다음 드루와.

CSR...흠 C..C...라 내 대학교때 학점이 왜 생각나지 아무튼 조용히하고...음...C...Computer? 오 Client! (사실 구글링해서 뭔지 보긴했음)..
R도 뭐 마찬가지겠지. 짝궁으로 둘이 설명 나오는거보니까.
그렇지. CSR -> Client Side Rendering!

그럼 한국어로 뭐겠어? 클라이언트 쪽 렌더링! 꼬불꼬불 뒤얽혀있을 것 같은 서버쪽이 아니라 우리쪽! 클라이언트 바깥쪽! 이느낌에서 렌더링을 뙇!

렌더링이 뭐야?
렌더링은 서버로부터 요청해서 받은 내용을 브라우저 화면에 표시해주는것!

ㅇㅋㅇㅋ.. 느낌옴 대충 뭔지는 알겠음. 누군가 물어보면 대답할 것 같아. 하지만!

내 스타일상 정확히 느낌 빡 안오면 잠이 안온다.

CSR

SPA, Single Page Application (기억나지? 나 저번에 정리해놨음. 다시봐야징~) 와 CPU 성능 + JS 표준화 (리액트, 앵귤러 라이브러리 및 프레임워크) 발전과 함께 시작되었다고한다.

SPA-> 한번 페이지를 서버에서 가져와서 로딩한다음에, 사용자가 원하는 데이터만 보고싶으면 그것만 불러와서 로딩.

서버에서 HTML을 다 요청하는게 아닌 (SSR이랑 다르게), 브라우저에서 자바스크립트로 콘텐츠를 렌더링 한다고 한다.

예를 들면, body에 id= "root"만 있는데, 자바스크립트 링크만 들어있다.


https://ctdlog.tistory.com/46

블로거님께 감사드립니다..정리 잘하겠습니다.
아무튼, 최초로 서버에서 클라이언트 쪽으로 끌고올때, 텅텅 빈것을 볼 수 있다. 위에 위에 맨처음 그림에서 볼 수 있듯이, 자바스크립트 다운로드 할 동안, html은 로딩상태이고 다 완료 되었을때, 자바스크립트로 프레임워크 및 라이브러리 작동시키고, 사용자가 원할때마다 원하는 부분만 서버에서 딱딱 가져온다.

단점:
1. 사용자가 첫 화면을 보기까지 시간이 오래걸릴 수 있다. (진짜다. 이건 내가 프로젝트때 겪었고, 마음아팠다. 분명 코드 가지런하게 다하고, 구글링하면서 했는데 왜케 느리지?)
2. SEO 가 잘 안된다...걍 안된다..

SEO -> SEARCH ENGINE OPTIMIZATION

Search Engine Optimization
웹 어플리케이션을 만드는 이유는 뭘까? 일반적으로 내 제품을 홍보하는것 이것 자체가 서비스 비즈니스.
효과적인 서비스 홍보를 위해서는 내가 만든 웹페이지가 상위에 노출되어야한다.
SEO가 그래서 필요하다. 검색엔진 최적화.
검색엔진에서 더 찾기 쉽도록 사이트를 개선하는 프로세스. 즉, 구글의 검색엔진이 찾을 수 있고, 이해할 수 있는 사이트를 만들어야 검색결과가 최상위에 보인다.
React는 기본적으로 잘 안되어있다. https://rbals0445.tistory.com/65
구글봇은 html/css로 되어있는 웹사이트는 잘 크롤링한다 왜냐하면 렌더링 하기에 좋은 형태니까. 하지만 js로 되어있으면 리액트는 리액트컴포넌트를 html css 로 변환해야하기때문에 잘 안된다.
SPA는 부분적으로 랜더링해서 보여주기때문에 키워드를 통해서 검색엔진 상위랭크에 넣게 하는것이 힘들다.
방법으로는 REACT는 NEXT.JS쓰면 된다고한다. React helmet등등.
두번째는 프리렌더링-> 프로젝트 배포전에 렌더링이 일어나는 것. 미리 html 만들어 두고, 서버에서 요청할때 그에맞는 html로 바꿔주는 것.

그렇기 때문에, SSR, 특수부대이름같은 아이가 등장!

SSR

얼마나 답답하면, 그냥 일단 서버에서 다 가져올 생각을 할까. 찔끔찔끔 사용자 생각해서 원할때마다 서버에서 가져오는 것으로 하려고 했는데? 얼마나 답답하면 그냥 다 끌고왔을까. 말그대로 일단 웹사이트 접속하면 서버에서 필요한 데이터 삭다 HTML 파일 만들고, 만들어진 HTML을 동적으로 조금 제어가능한 소스코드와 함께 클라이언트에 슝 보낸다. 그러면 사용자는 모든 것을 다 한번에 마지막에 보게되는 것이다. 위에 위에 그림에 참고~
로딩이 훨씬 빠르고, SEO가 훨씬 효율적이다. html요소들을 한꺼번에 가져오니까! 그것으로 딱 구글 봇이 키워드 잘 찾아내고, 등등 해서 검색창 우리가 딱 치면 잘 나오겠지?

단점 물론 있죠:
1. 사용자가 '아 새로고침 해야지.' 이러고 딱 새로고침 누르는 순간, 다시 서버에서 처음부터 끝까지 다 불러와야한다. 그래서, 이게 BLINKING ISSUE라고 한다. 깜빡거리는 이슈. 보기 좋지않다. 다시 깜빡이니까.
2. html요소들이 많거나, 사용자가 엄청 많다. 그러면 서버에서 계속 끌고오겠지? 그러면 서버 과부하 걸리지...
3. 마지막으로 TTV(time to view) 와 TTI(time to interactive) 위에 위에 그림 보면 알것이다. CSR은 html만 받아왔을때는 비어있지만, 점점 로직을 처리하는 자바스크립트 파일을 가져오면서 웹사이트가 보여지기때문에 동시에 인터랙션 즉 사용자가 누르고 뭐 이것저것 가능하다. 반면에 SSR은 그 전까지 불가능..다 가져올때까진..

리액트 개발자로서, 그럼 CSR단점 어떻게 해결해야함?

요즘 SSG(STATIC SITE GENERATION)이런게 나왔다. 말그대로 정적 사이트 발생. 우리가 코딩짜면 만든 웹 어플리케이션을 정적으로 웹페이지를 미리 생성해두고 서버에 배포하게 만드는 그런것이다. 그리하여 라이브러리 이름은 GATSBY. 이거 왁스이름아닌가...아무튼..조용히하고 집중해. 그리고 동적인 요소들도 충분히 가져올 수 있으니까 좋지. 아주좋아.

그다음에 NEXT.JS. 이건 리액트 검색하면 맨날 뜨는것이다. 이게 도대체 뭐지. 그리고 왜 리액트 할줄알면 저거 많이 쓴다는데 왜지? 라는 의문이 생겼는데 이것을 쓰면 SSR을 지원한다고 한다. 리액트가 CSR인데 리엑트에서 SSR가능하게 해주는 프레임 워크라고 한다.

이상!

0개의 댓글