지난 시간 고전적(;) 웹 사이트를 만드는 방식이었던 SSR과 XMLHttpRequest API, Ajax의 등장까지 살펴보았다.
이번 시간에는 본격적으로 SPA와 CSR에 대해 정리해보려 한다.
0. Intro
데스크탑이나 노트북보다 모바일을 사용하는 사람들이 점점 늘어났지만..
데스크탑/노트북에 비하면 모바일의 성능이 부족한 편.
이런 성능이 낮은 모바일 환경에서 웹 페이지를 잘 출력하기 위해서
SPA 방식을 많이 사용하게 되었다고 한다.
1. SPA
SPA는 Single Page Application의 줄임말로 모던 웹의 패러다임이다.
기존에는 여러개의 웹 페이지가 합쳐져서 하나의 웹 사이트가 되었다면
SPA는 기본적으로 단일 페이지로 구성된다.
SPA===CSR인 것은 아니고, SPA를 구현하는 방식이 CSR이다.
2. CSR
그렇다면 CSR은 무엇인가
CSR은 Client-Side Rendering의 약자다.
(이름만 봐도 알 수 있다. '이번에는 클라이언트쪽 그러니까 브라우저에서 알아서 하는 구나!')
CSR은 서버에서 뷰(View)를 렌더하지 않고
HTML, CSS, JS 등 각종 리소스를 다운 받은 후
브라우저에서 뷰를 렌더링 하는 방식이다.
최초 한 번 하나의 단일한 웹문서 전체를 로드한다.
도중에 사용자와의 인터액션이 발생하면 필요한 부분만 자바스크립트를 이용해서 업데이트한다.
새로운 데이터가 필요하면 서버 API를 호출해서 필요한 데이터만 새로 불러와서 업데이트 한다.
좀더 자세히 들여다보면
서버에서 브라우저에게 index.html 파일을 보내준다.
이 index.html 파일의 body를 보면 아래와 같이 구성되어 있다.
<body>
<div id="root"></div>
<script src="app.js"></script>
</body>
'root'라는 id를 가진 텅빈 div 하나와 애플리케이션에 필요한 자바스크립트 링크 하나만 들어있다.
그러니 HTML은 텅 비어있는 것이나 다름 없다.
링크된 app.js 파일을 서버로부터 다운 받는다.
이 파일에 중요한 것들이 다 들어있다!
app.js에는 애플리케이션에 필요한 로직뿐만 아니라
애플리케이션 구동을 위한 프레임워크나 라이브러리의 소스코드 등이 다 담겨있다.
그렇기 때문에 사이즈가 좀 커서 다운로드 받는 데에 시간이 소요될 수 있다. (처음 접속하면 하아얀 빈 화면만..)
이 리소스들을 다 다운로드 받아서 브라우저가 뷰를 렌더링한다!
나중에 추가로 필요한 데이터가 생기면 서버에 요청을 하는데
이때 html 파일을 다시 받아오는 것이 아니라 JSON 형태로 받아온다.
(아래 그림 참고)
CSR은 이렇게 뷰 렌더링을 브라우저가 담당하고
서버는 필요한 JSON 파일을 보내주는 역할을 한다.
웹 페이지 전체가 새로고침 되지 않고
변경사항이 있는 부분만 업데이트 되기 때문에
사용자 경험이 훨씬 좋고,
웹 애플리케이션이 마치 데스크톱 애플리케이션처럼 부드럽게 작동하도록 도와준다.
3. CSR의 장점
- CSR 방식은 기본적으로 웹 애플리케이션에 필요한 모든 리소스를 최초 한 번에 다 다운로드한다고 했다.
이후 새로운 페이지로 사용자가 이동하려고 하면, 페이지 갱신에 필요한 데이터만 전달받아 업데이트한다.
따라서 서버측에서 뷰를 모두 렌더링하여 전체 페이지를 다시 읽어 새로고침하는 것보다
사용자와의 인터액션이 더 빨라져 사용자 경험이 향상된다.
전체 트래픽이 감소하는 효과도 있다.
4. CSR의 단점
- 초기 구동 속도
웹 애플리케이션에 필요한 모든 리소스를 최초 한 번에 다운로드 받으니까
앱의 규모가 크면 클 수록 자바스크립트 파일의 사이즈가 커질 것이다.
리소스를 받는 시간이 길어지면 사용자가 첫 화면을 보기까지 시간이 오래 걸릴 수 있다.
(사용자가 방문하지 않을 수도 있는 페이지의 스크립트도 어쨋든 모두 다 처음에 받아야 하는 것도 단점 중 하나인데
이 부분은 나중에 Code Splitting으로 해결이 가능하다고 한다.)
- SEO(검색 엔진 최적화) 이슈
대부분의 웹 크롤러는 자바스크립트 파일을 실행시키지 못하고 HTML 파일에서만 컨텐츠를 수집한다.
좀더 쉽게 말해보자면..
구글이나 네이버 같은 포털의 검색 엔진들은 서버에 등록된 웹 사이트들을 하나씩 돌아다니며
웹 사이트의 HTML 파일을 분석해서 사용자가 검색할 때 웹사이트를 빠르게 찾을 수 있도록 도와준다.
하지만 아까 위에서도 말했지만 CSR의 HTML 파일 바디는 대부분 텅텅 비어있다.
그래서 검색 엔진들이 CSR 방식으로 작성한 페이지들을 분석하는 데에 어려움을 겪고 있다.
(그런데 사실 CSR은 정보 전달이 목적인 웹 사이트가 아니라 웹 어플리케이션에 적합한 기술이라서
SEO가 큰 문제가 되지는 않는다는 글도 읽었다.. 게다가 Angular나 React 같은 SPA 프레임워크는 서버 렌더링을 지원하는 SEO 대응 기술이 이미 존재하고 있어서 SEO 대응이 필요한 페이지에 대해서는 선별적으로 SEO 대응이 가능하다고..)
4. SSG (쓱-)
그런데 요즘에는 꼭 CSR, SSR 둘 중 하나만 고집하지 않고
SSG라는 것도 있다고 하네요!
SSG는 Static Site Generation의 약자.
React는 CSR에 특화된 프레임워크이지만
Gatsby(Static Generator)라는 라이브러리와 함께 사용하면
React로 만들어진 웹 애플리케이션을
정적으로 웹 페이지를 미리 생성해두어서 서버에 배포해놓을 수도 있다고 합니다.
그러면 이렇게 만들어진 사이트들은 또 다 모두 정적이냐하면 그런 것은 아니라고..
추가적으로 데이터를 서버에서 받아오거나 동적으로 처리해야하는 로직은 JS 파일을 이용해 충분히 추가할 수 있다고.
Gatsby 다음으로 리액트에서 많이 사용되는 것이 Next.js!
Next.js는 서버사이드 렌더링을 지원하는 라이브러리인데 요즘은 SSG도 지원한다고 한다.
CSR과 SSR을 잘 섞어서 조금더 강력하면서도 유연한!
목적에 맞는 웹 애플리케이션을 만들 수 있도록 도와준다고 한다.
도움을 받은 자료들
https://goodgid.github.io/Server-Side-Rendering-and-Client-Side-Rendering/
https://asfirstalways.tistory.com/244
https://d2.naver.com/helloworld/7804182
'웹개발상식' 카테고리의 다른 글
| SSR(Server-Side Rendering) (0) | 2021.05.25 |
|---|
