목차
- 서론 및 출처
- SSR(서버사이드 렌더링) 방식
- CSR(클라이언트 사이드 렌더링) 방식
- SSR과 CSR의 장단점 비교분석
- etc...
서론 및 출처
룸메이트와 학교 과제를 위해 웹 프로젝트를 하나 같이 하게 되었고
룸메이트가 Spring 템플릿 엔진을 이용해서 거의 만들어놓은걸 간단한 디자인 수정만 맡게 되었다.
그런데 로컬로 디자인을 수정 해 가며 직접 서버를 돌려 결과물을 테스트 할 수 없는 부분에 의문이 들었고
어차피 룸메랑 쭉 졸작까지 같이 협업을 할 예정이여서, 이 참에 이 부분에 대해서 확실히 공부 하자는 생각이 들었고
SW마에스트로를 연수중인 매력만점 선생님
Juwon's blog
blog.jujuwon.dev
"jujuwon"님에게 자문을 구했고, 그 내용을 정리요약 해보고자 한다.
거기에 더해 아래 출처를 남긴 분들의 글을 참고하여 글을 작성하였음을 명시합니다 !!
SSR(서버사이드 렌더링)과 CSR(클라이언트 사이드 렌더링)
MPA와 SPA, SSR과 CSR에 대한 포스트입니다. 목차 MPA vs SPA SSR 개념, 동작과정, 장단점 CSR 개념, 동작과정, 장단점 렌더링 방식 선택 기준 Universal Rendering MPA vs SPA 먼저 MPA, multi page application의 약자로 여
miracleground.tistory.com
https://hahahoho5915.tistory.com/52
[간단정리] CSR vs SSR 특징 및 차이
개요 CSR vs SSR 특징 및 차이점 알아보기 내용 CSR Client Side Rendering의 약자 말 그대로 SSR과 달리 렌더링이 클라이언트 쪽에서 일어난다. 즉, 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내준다
hahahoho5915.tistory.com
SSR(서버사이드 렌더링)방식이란?
SSR방식이란 server side rendering의 약자로 서버로부터 완전하게 만들어진 html 파일을 받아와 페이지 전체를 렌더링 하는 방식이다.
사진으로 SSR 과정을 살펴보자
- 유저가 웹사이트 요청을 보낸다.
- 프론트 -> 백엔드(서버)로 요청을 보낼 것이고, 서버는 'Ready to Render', Rendering준비를 끝마친 완성된 HTML파일을 만들어낸다
- 클라이언트에 전달되는 순간, 이미 렌더링 준비를 끝마친 완성된 HTML파일을 받았기 때문에, 빠르게 렌더링 된다. 그러나 Javascript가 읽히지 않은 HTML 파일만이 보여지므로 상호작용(interactive)은 불가능하다.
- 클라이언트가 정적인 Javascript 파일을 다운로드 받는다.
- 위 4번과정에서 유저는 렌더링 된 HTML파일을 볼 수 있지만, 사이트를 조작할순 없는 상태이나, 유저의 조작은 기록된다(recorded)
- 브라우저가 Javascript 다운로드를 마치고 JS Framework를 실행한다.
- JS까지 컴파일을 마치면 사용자와 웹 페이지 간 상호작용이 활성화되고, 기억되었던 유저의 조작을 실행한다.
SSR방식은 서버로부터 화면을 렌더하기 위한 필수적인 요소를 먼저 들고오기 때문에
초기 로딩 속도가 빠르다는 특징이 있다.
허나 이 특징 때문에 유저의 TTT(Time To View)와 TTI(Time To Interact)간의 시간 간격이 존재한다는 단점이 있다.
즉, 초기 렌더링 된 HTML 파일을 유저가 보기 시작하는 시간(TTT)과 조작하는 시간(TTI)사이의 간극이 존재하기 때문에 유저에게 불편함을 줄 수 있다.
CSR(클라이언트 사이드 렌더링)방식이란?
CSR 방식이란 client side rendering의 약자로 서버로부터 사용자의 요청에 따른 응답값을 받아 렌더링 하는 방식이다.
*요청에 따른 응답값만을 받아와 클라이언트에서 렌더링하는 방식!
마찬가지로 사진을 통해 CSR 과정을 살펴보자
- 유저가 웹사이트 요청을 보낸다.
- CDN이 HTML파일과 접근 가능한 JS링크를 클라이언트로 보낸다. *CDN = Content Delievery Network, 서버와 사용자 사이의 물리적인 거리를 줄여 콘텐츠 로딩에 소요되는 시간을 최소화하는 시스템
- 클라이언트는 위 과정의 HTML과 JS를 다운받는다(이때, 유저는 아무것도 보지 못한다.)
- 마찬가지로 JS를 다운받는다
- 다운이 완료된 JS가 실행되고 데이터를 위한 API가 호출된다.(이때, 유저는 placeholders를 보게된다)
- 서버가 API로부터 온 데이터 요청에 응답한다. (응답값을 리턴 해 주겠죠?)
- API로 부터 받아온 data를 rendering해 placeholder에 집어넣는다. 이제 유저는 상호작용이 가능해진다.
CSR방식은 서버에서 처리없이 클라이언트로 보내주기 때문에 JS가 모두 다운되고 실행이 끝나기 전까진 유저는 볼 수 없게된다. 클라이언트가 서버로 부터 받은 데이터를 렌더링 하기 때문에 서버의 부하가 적다는 특징이 있다.
SSR과 CSR의 장단점 비교
1. 로딩 시간
| SSR 방식 | CSR 방식 | |
| 방식 | 서버에서 이미 렌더링 된 완전한 HTML 파일을 먼저 로딩 해 유저에게 보여준 후 JS 다운로드를 시작한다 | HTML, CSS와 모든 스크립트들을 한번에 다 불러온다. |
| 첫 페이지 | SSR 방식이 더 빠르다 | CSR방식은 모든 스크립트를 한번에 다 불러와야 되므로 비교적 더 느리다. |
| 나머지 페이지 | 사이트의 다른곳으로 이동하는 과정을 생각할때, SSR 방식은 첫 페이지를 로딩했던 과정을 그대로 한번 더 수행해야 하므로 느리다. |
CSR방식은 이미 첫 페이지를 로드할 때 모든 스크립트를 불러왔으므로 더 빠르다. |
2. 서버 자원 사용
어찌보면 당연한 얘기인데,
SSR은 페이지가 요청될 때 마다, 매번 새로고침 되고, 매번 서버에 페이지를 구성하는 모든 리소스를 요청하기 때문에 서버의 부하가 크고,
CSR은 페이지가 요청될 때, 변경된 부분에 대해서만 서버에게 데이터를 요청하기 때문에 서버의 부하가 적다.
3. 사용자 친화성
2번 특징의 연장선으로
SSR은 페이지가 요청될 때 마다, 필요한 모든 리소스를 요청한 뒤 새로운 HTML파일을 보여주므로 화면이 새로고침 한다.
CSR은 페이지가 요청될 때 변경된 데이터에 한해서만 서버에 요청을 해서, 응답값을 렌더링하기 때문에 새로운 링크, 즉 새로고침이 필요가 없기 때문에
CSR 방식이 사용자 친화성에서 더 우수하다.
★ 결론적으로, SSR과 CSR이 각자의 장단점이 존재하기 때문에 위 처럼 상황에 맞게, 필요에 맞게 선택하여 사용하면 됨
etc...
형에게 질문하다 보니, 협업 방식 뿐만 아니라 다양한 정보들을 얻을 수 있었는데
(가령 HTML, CSS, JS가 정적인 파일이고 브라우저에서 DOM(Document Object Model)을 통해 뿌려진다와 같은 정보)
(특정 도메인으로 들어오는 요청은 특정 포트로 보내게 해주는 리버스 프록시 기능이라던가)
내가 보려고 남겨놓은 이미지들
어쨋든 내가 답답했던 부분은 로컬로 돌리니 제대로 된 테스팅이 불가능하다는거였고
중요한건 SSR방식이나 CSR방식에 상관없이 온전한 내 웹서버를 두고 개발을 해야 제대로 된 협업이 가능하다는 생각이 들었다.
SSR방식은 원래 내 웹 서버를 따로 두진 않지만, Next.js를 사용하면 내 웹서버를 둔 채, SSR 방식으로도 사용이 가능하기 때문이다.(Next.js는 다음에 따로 자세히 다뤄봐야겠다.)
앞으로도 계속 룸메이트와 프론트-백엔드 간의 협업을 진행할 예정이고, 계속해서 인지하고 있어야 되는 부분에 대해서 제대로 숙지해야겠다는 생각을 했다.