먼저 이 개념을 이해하기 전 "Web"에대한 기본적인 지식이 필요하다.
1, 2, 3세대와 Modern Web까지의 흐름을 간단하게 살펴보자.
Web
1세대 : 정적인 웹
- HTML과 CSS로만 구성된 웹.
- 사용자와의 interaction은 불가능 하고 단지 정보 전달의 용도로 사용되었다.
2세대 : 동적인 웹
- Javascript의 사용으로 Server로부터 필요한 데이터터를 주고받을수 있는 동적인 사용이 가능해 졌고, 사용자와의 interaction이 가능해졌다.
- 🔥 그러나 JS는 "일부"에서만 사용되었고, HTML과 JS에 대한 데이터를 하나의 서버에서 모두 전송해주는 형태였다. (구분 X)
3세대 : SPA (Single Page Application)
- SPA의 개념의 등장. 즉, 하나의 Page로 전체 사이트를 구현할 수 있게 되었다.
- 또한 HTML태그 자체를 JS가 동적으로 생성할수 있게 되었고 HTML/JS부분과 data 부분이 구조적으로 분리되면서 FrontEnd와 BackEnd가 구별되기 시작했다.
- 이후 FE에서는 좀더 효율적인 Framework 혹은 Library들이 많이 탄생했다.
Modern Web
- 규모가 커진 형태 (사용자와의 Interaction 중요성 증가 + 웹 서비스의 복잡성 증가 + 사용자 수, data의 양 증가)
=> 때문에 시스템 부하(동시접속자, 방대한 데이터의 양)와관련된 문제들이 발생했고 이를 해결하기 위해System architecture가 발전했다. - FE 서버와 BE 서버의 분리 발생
-------------------------------
CSR vs SSR
1. CSR
CSR은 Client Side Render라는 뜻으로 Cleint측에서 RENDERING 되는 형식이다.
여기서 또 하나 필요한 개념으로 CRA가 있다.
CRA (Create React App)
완전 Front 영역. 나는 아무것도 알지 못한다. 그치만 개념은 이해할수 있지. 나는 지성인이니까
"아무런 초기 설정이 없어도 CRA를 통해 React 기반의 SPA 사이트를 구현할 수 있다."
즉, React를 통해 app을 만듬으로써 초기설정 없이 빠르게 결과물을 만들어낼수 있다는 개념이다.
그러나 CRA 방식으로 build한 프로젝트는 검색에 잘 걸리지 않는다
그 이유는 CRA를 통해 만들어진 project는 오직 CSR(Client Side Render)로 실행되기 때문이다.
CSR방식에서 구글봇의 작동법
말그래도 Cleint 측에서 rendering이 됨을 듯한다.
웹 페이지에 접속하면 HTML, JS, CSS확장자의 file이 차례로 응답된다.
- 제일 먼저 응답된 HTML 파일에 의해서 내용이 비어있는 웹 페이지가 형성된다. (안에 data 없음)
- 🔥 구글로 예를들면 구글봇이 웹 페이지를 분석해 해당 페이지의 data정보를 알아낸다. BUT 내용없음! 정보 획득 X
- 이후 응답된 JS 파일의 다운로드가 완료되고 JS 파일이 dom을 비어있는 HTML에 그려진다 (RENDERING)
- 이미 구글봇은 떠난 후..
CSR을 사용함으로써 장점도 있다.
- BackEnd 호출을 최소화 할 수 있다
- 최초 호출 시에만 HTML과 JS, CSS를 요청하고 이후엔 요구되는 데이터 만큼만 통신한다. (by JSON)
- routing (라우팅, 새로운 페이지로 이동하는 것) 을 하더라도 HTML의 변화는 X! JS가 새로운 페이지를 그려낸다.
자투리 정보 : SEO (Search Engine Optimization)
SEO란 웹 페이지 검색엔진이 자료를 수집하고 순위를 매기는 방식에 맞게 웹 페이지를 구성해서 검색 결과의 상위에 나올수 있도록 하는 작업을 말한다.
출처 : wikipedia
커머스 사이트와 같은 "검색"이 곧 매출과 직결되는 사업분야의 경우 SEO 성능이 매우매우 중요하다!
2. SSR
이와 달리 SSR은 Server Side Render라는 뜻으로 Server에서 RENDERING이 되어 응답을 보내는 형식이다.
SSR방식에서 구글봇의 작동법
이미 Rendering이 되어 FE에 보내지는것!
- 응답된 HTML파일에 Rendering된 JS의 내용이 채워진 채 웹 페이지가 형성된다.
- 🔥 구글봇이 해당 웹 페이지에 존재하는 data의 정보를 수집한다. => 검색에 걸리는 효과!
SSR이 나오게 된 계기는 "SPA의 형식을 지키면서도 검색에 자주 노출되게 하기 위한 방법"을 찾았던 점이다. 즉, SPA도 챙기면서 SEO까지 챙기기 위한 방법으로 나온것이 SSR 방식이다.
SSR의 장점
위에서 말했듯 CSR방식에 비해 SEO 측면에서 유리하다
=> 검색엔진에게 보여줄 data를 마련할 수 있다.
또한 전체적으로 사용자에게 보여주는 콘텐츠 구성이 완료 되는 시점이 더 빠르다. 비록 CSR방식에 비해 페이지를 구성하는 속도는 느려지지만 !
SSR의 주의점
Server 측에서 rendering되어 data가 전해지기 때문에 페이지를 잘못 구성할 경우 CSR에 비해 서버 부하가 더 크고, 때문에 첫 로딩이 매우 느려질 수 있다
-------------------------------
MPA vs SPA
1. MPA
MPA란 Multi Page Application이라는 뜻으로 말그대로 "여러장의 페이지"로 구성된 application을 뜻한다.
현재 우리가 사용하고 있는 "사이트"하나를 생각해보면 해당 사이트가 "한 페이지"로 구성된건 아니라고 생각한다! (당장 구글만 봐도 검색창, 검색 후 창 등.. 페이지가 진짜 많아 보인다)
하지만 이러한 구성이 모두 MPA인것은 아니다. 이후에 나올 SPA에서 다루도록 한다.
다시 MPA로 돌아가서 말하면 MPA는 정적 웹사이트로 구현된 HTML 파일이 여러개 존재하고, 페이지간 이동하면서 화면이 깜빡이는걸 볼 수 있다. (서로 다른 HTML 파일로 이동됨)
2. SPA
SPA란 Single Page Application이라는 뜻으로 "하나의 페이지"로 구성된 application을 뜻한다.
즉, 하나의 HTML 파일로 구성되어 있다는 뜻.
그렇다면 우리가 보는 "페이지 간의 이동"은 어떻게 SPA로 설명할까??
바로 JS에서 HTML 태그를 생성해 내기 때문에 SPA구조가 될수 있기 때문이다.
즉, 페이지를 이동하게 되면 기존에 있던 HTML 파일에 JS의 특정함수로 생성된 새로운 HTML 태그들로 채워진다는 것이다.
때문에 페이지간 이동시 화면이 깜빡이지 않는다.
-------------------------------
MPA & SPA & CSR & SSR ?
그렇다면 현재 웹 기준으로 네가지의 관계성은??
현재웹 기준으로 한다면 SSR은 SPA로 구성된 SSR방식을 뜻하며, 이에 따라 SPA형식의 결과물은 CSR과 SSR방식으로 나뉜다!
CSR + SSR
가능하다! 효율이 더욱 높아지는 방법인데 이를 위한 모듈 하나 없을까. 바로 "Next.js"와 같은 훌륭한 framework들이 이미 존재한다.
더 자세한 개념은 지금상태보다 더 깊은 FE지식을 요하기 때문에 일단 "가능하다"라는 것!!
자투리 정보 : hydration
hydration이란 **Server에서 전송한 `정적 문서`를 데이터 변경에 반응할 수있는 `동적 형태`로 변환하는 _클라이언트 측 프로세스_**를 뜻한다.
이는 render와 동일하지만, dom이 이미 그려져 있는 상태이기 때문에 event listener만 부착하는 식으로 작동한다.
-------------------------------
끝!
BE로 공부하고 있는 지금 React나 dom에 대한 개념은 잘 모르지만 SSR과 CSR에 따른 SEO효율의 차이와 기존의 문제점을 극복하기 위해 현재 사용하는 방식 (SSR + CSR)에 대해서 알수 있었다.! 🥰
