2022.01.08

rin·2022년 1월 8일

SSR vs CSR

사용자가 서버에 요청하면 HTML을 내려준다.

search engine
- google : google bot
- naver : yety engine
- 인터넷 상의 도메인을 호출해서 HTML을 가져옴
- search engine이 어떻게 컨텐츠를 가져오는가???? <- deep하게 알 필요는 없다.
- 검색봇은 인터넷의 컨텐츠를 특정 기준에 의해 무작위로 수집해 인덱싱 한 담에 사용자의 키워드에 따라 분류해서 보여준다.
- HTML(컨텐츠)의 태그 정보를 여러 형태로 파싱해서 키워드와 매핑
  - OG tag (Open graph)
  - SEO (search engine optimaigation)
  - 두 개의 차이가 뭔지 알아보기
  - 얘네는 HTML 기준으로 움직인다.
  - 빈 HTML을 서빙 -> 화면에서 직접 그림 : CSR (nginx에서 전송)
  - 서버에서 화면을 동적으로 생성해서 그림 : WAS에서 HTML 그려서 스트링 스트림으로 말아서 리퀘스트 응답으로 줌
SSR
- 서치엔진이 WAS에 가서 통채로 가져올 수 있음
- CSR이 되면서 모든 path에 대해 static한 (정해진) html을 응답함 (nginx) - 서버에서 html을 건드릴 구간이 없음 -> 해당 html이 검색 엔진에 넘어가면 검색 페이지를 구성할 수가 없음
- SPA가 나왔지만 SSR, CSR이라는 개념이 사라질 수가 없음

구식

서버에서 페이지를 만들어줌 (역할의 중복이 많아짐)
서버와 클라이언트가 항상 붙어있어야하므로 개발 사이클이 같아야함
이런 문제 해결을 위해 SPA가 나옴 -> 서버 클라이언트를 분리할 수 있게 됨 (서치엔진 옵티마이제이션이 생각이 안됨) -> SPA+SSR (현재)

서버사이드 렌더링이 필요한가??

검색에 민감한 서비스인 경우 : 모든 서비스의 메인 페이지, 커머스 페이지
회원가입을 하지 않으면 접근할 수 없는 페이지는 검색될 필요가 없어서 SSR을 할 필요가 없음
메인 페이지 등 동적으로 ui가 바뀔 가능성이 적은 페이지는 pre-build(pre-render)로 제공 : 빌드 시점에 react로 화면을 그린 다음에 완전히 완성된 상태로 서버에 배포함. (고정된 상태임) 이후에 react를 구동할 수 있음. 혹은 아예 구동되지 않고 js만 작동하게 할 수도 있음
서버사이드 vs pre-build : pre-build는 내용이 바뀔 수 없음. SSR은 동적으로 내용이 바뀔 수 있음.

HTML을 서빙하는건 생각보다 간단하지 않음.
프론트엔트 서비스는 화면 제공이 전부가 아니다.
궁극적으로는 HTML을 서비스 해주는 것. 즉, 정적인/동적인 컨텐츠를 서빙한단 것. 정적인것과 동적인것에 따라 방법이 여러개가 있고 외부적인 요인(OG 태그나, 서치엔진 옵티마제이션)에 의해 서버측을 이해해야하는 것도 있음.

html은 서버에서는 스트링일 뿐임 (서버에서 넘길 때 스트링 스트림으로 넘김)
-> html parser로 파싱해야함. (서버에서는 쓸 필요가 없으니 그냥 스트링으로 씀. 파싱 처리 없이 그냥 스트링 치환하는 식으로 구성함)

서버사이드 렌더링을 위해선 기존 브라우저에서 했던 렌더링 기능을 서버에서도 가져와야함.

Javascript engine, html parser 필요함
javascript, html은 web api라는걸로 묶여있음 -> js engine을 이용해서 web api를 사용할 수 있어야함.
web api는 브라우저꺼임 (사용할 수 있도록 open api처럼 노출해둔거임) -> 사용자가 건들일 수 있는건 이 api 뿐이다! 라고 제한하는 것. react는 web api와 event를 이용해서 화면을 작성하는 거임
SSR engine에서는 화면처럼 js 실행 환경(js runtime engine), web api와 동일한 형태의 mocking 환경을 제공하여 HTML을 생성할 수 있는 엔진을 제공.
하이드레이션 : 서버에서 받은 html을 아직 리액트가 소모를 안한 상태, 리액트가 html을 컨슘해서 주도권을 가져와야함
SSR이 내려주는 html은 jsp에서 만들어준거랑 같음 근데 jsp처럼 스태틱하지는 않음
- 서버에서 일어나는 동작이 클라이언트에서도 동일하게 작동할 것 : 최초의 렌더링은 서버에서 일어나므로 클라이언트에서 마운트하는 작업이 없어짐.
- 레거시는 클라이언트에서 서버에서 한 일을 반복할 수 없음
SSR은 서버측에서 api를 다 호출함

❗️ HTML - React(하이드레이션) -> SPA

브라우저에서 어떻게 렌더링을 할 것인가

브라우저 : 싱글 스레드 -> 잘못 설계 시 성능 문제가 생길 수 있음, 브라우저는 리소스가 부족하기 때문에 코드가 잘 돌아가지 않을 수 있다.
single thread model
JS | IO는 분리되어있음 - 대표적인 io : file, input, output(GPU), network
Single thread와 event-loop가 떨어져 있으면 병목 현상을 극복할 수가 없음 + callstack
프레임 (web api) (tick) 단위로 콜스택(함수 스택)에 쌓여있는 JS 함수들을 실행시켜줌. 각 스택은 앞의 스택이 모두 소모돼야함. 이 스택이 소모되는 매 순산(초)가 프레임이라고 생각하면됨. 이러한 틱과 틱 사이에 UI가 변경됨. 따라서 매 틱 당 소모되는 스택이 적어야지 UI 그리는데에 지연이 적어짐
브라우저 내 이벤트나 사용자의 개입에 의해 실행하고픈 함수들을 끼워넣기 하는 거임
web api 까보면 콜스택에 함수를 집어넣는 이벤트 콜백으로 작성되어있다.
io 작업 요청 시 io 작업이 끝나고 응답이 들어왔을 때 콜백을 스택에 넣어줌 -> 비동기처럼 작동함 -> 단, 다음 콜스택에 돌아올 거라고 확신을 못하므로 방어로직 필요함.

node.js 모델 / v8 engine
기존에는 브라우저 엔진에 js 엔진이 붙어있어서 서버에서는 사용할 수 없었는데 v8엔진이 나오면서 서버에서도 사용할 수 있게됨.(nodejs)
es spec을 다 구현을 못하기 때문에 import 못 씀 (required 사용)

이벤트 루프 모델링(node.js 모델링)

ecmsScript - javaScript

추가 학습

SEO

Search Engine Optimization
웹페이지 검색엔진이 자료를 수집하고 순위를 매기는 방식에 맞게 웹 페이지를 구성하여 검색 결과의 상위에 나올 수 있도록 하는 작업

MAP vs. SPA

페이지를 여러개 쓰는지 혹은 하나만 쓰는지에 대한 개념

MAP(Multiple Page Application)

사용자가 페이지를 요청할 때 마다, 웹 서버가 요청한 UI와 필요한 데이터를 HTML로 파싱해서 보여주는 방식
사용자의 사소한 요청에도 매번 전체 페이지를 렌더링 해줘야한다.

SPA(Single Page Application)

하나의 HTML 파일을 기반으로 자바스크립트를 이용해 동적으로 화면의 컨텐츠를 바꾸는 방식
처음에 한 번만 정적 리소스(index.html로 합쳐짐)를 다운받고, 그 이후에는 새로운 요청이 들어왔을 때 필요한 데이터만 부분적으로 바꾸어준다.

SSR vs. CSR

렌더링을 서버에서 하는지, 클라이언트에서 하는지

SSR(Server Side Rendering)

서버에서 정적인 페이지로 렌더링되어 사용자에게 내려온다.
초기 로딩속도가 빠르고(js파일 다운로드 전에 브라우저에서 화면만 보여짐) SEO에 사용되는 meta태그들이 미리 정의되어오므로 SEO에 유리하다.

CSR(Client Side Rendering)

브라우저가 JS를 받아와 동적으로 렌더링한다.
첫 로딩 시 HTML, JS, 그외 리소스를 모두 포함해와야 하므로 파일 크기는 더 크지만, 다 받기만 하면 동적으로 빠르게 렌더링되므로 사용자가 느끼는 UX에서는 유리하다.
하나의 HTML 파일로 모든 페이지를 구성하므로 meta 태그 정의에 약점이 있다.
View 생성을 위해 JS를 필요로하므로 그 전까지는 빈페이지이기 때문에 검색 엔진 크롤러의 데이터 수집에 제한적이게 된다.

전통적인 SSR은 빠른 초기 로딩 속도와 SEO에 유리한 특성을 가지나 화면 전환 시 (View 변경) 서버에 요청을 통해 새로고침이 되므로 서버 부담이 크다.
CSR은 초기 로딩 속도가 느리며 SEO에 불리하지만, 초기 로딩 후에는 View를 클라이언트에서 직접 렌더링하므로 화면 전환이 매우 빠른 이점이 있다.

두 렌더링 방법을 적절하게 사용하여 첫 페이지는 SSR을, 그 외 모든 페이지에서는 CSR을 사용하는 방법을 많이 사용한다.

React의 Next.js는 SPA에서 SEO를 할 수 있도록 도와준다.
또는 메타 태그를 정의해주는 라이브러리(ex. react-helmet)를 사용해 동적으로 SEO에 필요한 메타태그를 정의할 수 있도록 도와준다.

OG tag

Open Graph Protocol : 어떤 HTML 문서의 메타정보를 쉽게 표시하기 위해서 메타정보에 해당하는 제목, 설명, 문서의 타입, 대표 URL 등 다양한 요소들에 대해 사람들이 통일해서 쓸 수 있도록 정의해 놓은 프로토콜

❗ meta태그(meta데이터)란?

HTML 문서가 어떤 내용을 담고 있고, 문서의 키워드는 무엇이며, 누가 만들었는지 등의 문서 자체의 특성을 담고 있다.

즉, 사이트의 제목, 설명, 이미지 등 포털사이트 api 로봇이 크롤링 할 때, 우리가 지정해놓은 사이트 부가적인 설명 부분이 담긴 내용을 긁어갈 수 있도록 이정표 역할을 하게 된다.

OG를 이용해 URL로 공유되는 콘텐츠가 표시되는 방식을 관리한다.
즉, OG Tag(Open Graph Tag)로 웹사이트를 마크업할 수 있다.
이를 통해 해당 콘텐츠의 요약 내용이 SNS에 게시되는데 최적화된 데이터를 가지고 갈 수 있도록 설정하는 것이다.
👉 미리보기가 가능한 정보를 노출하여 미리보기 화면을 생성한다.

OG 태그과 SEO의 관련도
og 태그는 SNS의 퍼가기 용도 (대표적으로 페이스북)
사실상 og 태그가 검색엔진에 영향을 미치지 않아야한다.

페이스북은 자체적으로 검색엔진에 노출이 되는데, 퍼가기를 이용할 경우 검색엔진에 의해 페이스북에 링크된 것이 체크된다.
페이스북과 같은 유명 사이트(검색엔진이 생각하는 상위 사이트)에서 링크가 많이 될수록 해당 웹페이지의 신뢰도가 상승하고, 검색엔진은 신뢰도가 높은 페이지를 상위 노출시킨다.

즉, 간접적으로 영향을 미치고 있다고 볼 수 있다.