일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Technical Writing
- 자바파이썬
- khaiii
- 카우치코딩 #couchcoding #6주포트폴리오 #6주협업프로젝트v
- 출처: 자바의 신 8장
- 코딩온라인
- Kakao
- SSR
- Machine Learning
- github markdown
- 모바일웹스킨
- taskkill
- 마크다운
- 카우치코딩 #couchcoding #6주포트폴리오 #6주협업프로젝트
- PID
- 비동기
- address
- terminate
- 파이썬
- 필사
- expression statement is not assignment or call html
- 서버사이드렌더링
- Anaconda
- 플젝후체크
- Morphological analysis #Corpus
- 파이콘
- 클라이언트사이드렌더링
- gitbash
- #스파르타코딩클럽후기 #내일배움캠프후기
- github
- Today
- Total
개발 일기
서버사이드 렌더링 vs 클라이언트 사이드 렌더링 본문
* 드림코딩과 Jaro님의 블로그 자료를 바탕으로 개인 공부를 위해서 정리한 글입니다.
View 를 렌더링 하는 위치에 따라 서버사이드/클라이언트 렌더링으로 나뉜다.
서버사이드 렌더링(SSR), 클라이언트 사이드 렌더링(CSR) 모두 장단점이 있다.
그러니, 구동하고자 하는 서비스의 니즈에 맞춰서 선택하자.
서버사이드 렌더링(SSR), 클라이언트 사이드 렌더링(CSR) 이란?
서버사이드 렌더링
-전통적인 웹 페이지 구동방식이다.
-요청 시마다 새로고침이 일어나며, 요청이 있을 때마다, 서버에 새로운 페이지에 대한 요청을 한다.
-서버 측에서 HTML&View를 생성해서 응답해준다.
-필요한 물건이 있을 때마다 마트에 쇼핑하러가는 거라고 생각해보면 쉽다.
클라이언트 사이드 렌더링
-서버 사이드 렌더링은 client <-> server 로, 서버가 view 를 해석해서 보여준다. 반면, SPA 에서는 CLIENT 측에서 VIEW 를 생성한다. 자바스크립트를 통해 렌더링 후 뷰를 보여준다.
-SSR 이 중심이던 시기에서 어떻게 CSR 이 어떻게 등장하게 됐을까?
먼저, 클라이언트 사이드 렌더링은 SPA 구동 방식을 따른다. 전통적인 SSR 방식은 기술의 발전으로 웹에서 제공되는 정보량이 많아지면서 문제점들이 많이 발생했다고 한다. 이를 해결하기 위해서 Single Page Application (SPA) 기법이 등장했다. SPA 구동방식은 사용자가 한 페이지 내에서 머무르면서, 필요한 데이터 서버에서 받아와서 부분적으로 업데이트 하는 것이다(AJAX 또한 SPA 방식에 해당한다) 근래에 사용자들의 pc 성능도 좋아지다보니, 사용자 측에서 처리하는 데 무리가 없어졌다. 더불어 JS 가 표준화되면서,Angular, react, view 등의 강력한 커뮤니티가 조성되었고, SPA 가 발전하는 기반이 되었다.
*SPA 가 곧 클라이언트 사이드 렌더링 방식이라는 것은 아니다. SPA 가 클라이언트 사이드 렌더링을 사용하고 있을 뿐이다.
아래 그림은 CSR의 예제코드인데, 처음에 접속할 때는 빈 화면이 보이고 (JS 불러오기 전) 자바스크립트가 파일을 불러와야 view 가 로딩된다.
SSR vs CSR 기능 상 차이점
(1) 초기 VIEW 로딩 속도 & 사용자 경험.
-SSR: VIEW 를 서버에서 렌더링해서 가져옴. 그래서 VIEW를 보기까지의 로딩이짧다. 사용자 입장에서 로딩이 빠르다는 생각이 들 것이다. 하지만, JS 파일을 모두 다운로드하고 적용하기 전까지는 인터렉션에 반응하지 않기 때문에, 무조건 CSR 보다 빠르다고 보기는 어렵다. 즉 사용자가 화면을 보는 시점<--> 동적 인터렉션이 가능해지는 시점에 차이가 생긴다.
-CSR: SSR 보다는 초기 로딩 시간이 오래걸림. 서버에서 VIEW를 렌더하지 않고, html다운받은 다음 js, 각종 리소스 다운받은 후 브라우저에서 렌더링해서 보여줌.
view 가 보여진 시점에서 바로 인터렉션이 가능하다. 로딩 후에는 서버에 다시 요청할 필요 없이 클라이언트 내에서 작업이 이루어진다.
(2) 서버 부하
-SSR: CSR 보다 서버에 부하가 걸리기 쉽다. 특히 사용자가 많은 제품일 수록, 서버가 일을 많이 해야한다.
(3) SEO
-CSR: VIEW 를 생성하는 데 자바스크립트가 필요하다. 그 전에는 HTML 내용이 비어있어서, 웹 크롤러가 데이터를 제대로 수집할 수 없다. 구글은 자바스크립트를 해석해서 크롤링해주지만, 타 서비스는 그렇지 않기 때문에 SEO 가 잘 안된다. SEO 가 안된다는 것은 내가 만든 어플리케이션 내용이 검색 엔진에 제대로 표시되지 않는다는 것이며, 이는 사용자의 유입이 줄어든다는 것이다. 비즈니스에 치명적이다.
-SSR: 모든 컨텐츠가 HTML에 담겨져서 SEO 에 유리하다.
(4) 각 기법의 개선 포인트
-CSR: js 파일을 어떻게 효율적으로 분할해서, 사용자가 필수적으로 봐야하는 js 파일들을 보내서 interaction 을 개선할 수 있을지 고민한다.
-SSR: 사용자가 Interaction 하는 시간의 단차를 줄이기 위해 어떻게 매끄러운 ui 를 제공할 수 있을지 고민해보자!
출처
https://jaroinside.tistory.com/24
https://www.youtube.com/watch?v=iZ9csAfU5Os
'Tech > CS Foundations' 카테고리의 다른 글
JPA (0) | 2021.11.27 |
---|---|
브라우저의 동작 방법 (0) | 2021.11.01 |
HTTP와 HTTPS (0) | 2021.10.26 |