SSR
- SSR이란?
- SSR은 서버에서 사용자에게 보여줄 페이지를 모두 구성(렌더링 준비를 마친 HTML, JS code)하여 사용자에게 페이지를 보여주는 방식이다. 렌더링 준비를 마친 HTML 파일을 받아오면 HTML을 렌더하고 JS code를 다운로드하여 HTML에 연결한다.
- 장점
- 서버를 이용해서 페이지를 구성하기 때문에 클라이언트에서 구성하는 CSR보다 페이지를 구성하는 속도는 늦어지지만 전체적으로 사용자에게 보여주는 콘텐츠 구성이 완료되는 시점은 빨라진다. (화면에 보이는 것은 느릴 수 있지만 실제로 동작할 수 있는 페이지가 완성되는 시점은 빠르다)
- 서버에서
HTML파일을 완성하기 때문에 HTML파일에 모든 컨텐츠가 저장되어 있어 SEO가 쉽다. - SEO(Search Engine Optimization === 검색 최적화)
웹 크롤러 봇이 웹 상의 페이지를 돌아다니며 웹페이지에서 정보를 추출한다. 이러한 과정을 ‘크롤링’이라고 한다.- 웹 크롤러가 수집한 데이터에 검색 알고리즘을 적용 함으로써 사용자의 검색 질의에 대한 응답으로 관련 링크를 제공한다. (CRA를 하면 robot.txt 파일을 만나볼 수 있다)
- 단점
- 서버로부터 화면을 렌더 하기 위한 필수적인 요소를 먼저 가져오기 때문에 CSR 보다 초기 로딩 속도가 빠릅니다. 하지만 이것이 단점이 될 수도 있습니다.
TTV(Time To View)와TTI(Time To Interact) 간에 시간 간격이 존재합니다.




- MPA(Multi Page Application)
- MPA란?
- 여러 페이지로 구성된 웹 어플리케이션이다. 새로운 페이지 요청 시마다
정적리소스가 다운로드되고 전체 페이지를 다시 렌더링하는 방식을 사용한다. - 장점
- SEO에 유리하다. 완성된 형태의 HTML 파일을 서버로부터 전달받기 때문에 검색엔진이 페이지를
크롤링하기에 적합하다. - 첫 로딩이 매우 짧다. 서버에서
이미 랜더링해 가져오기 때문이다. 그러나 클라이언트가 JS파일을 모두 다운로드하고 적용하기 전까지는 각각의 기능은 동작하지 않는다. - 단점
- 전체 페이지를 다시 렌더링 하기떄문에 새로고침이 일어나게 되고(flickering) 변경이 필요없는 부분까지 포함하여
전체 페이지를 갱신하므로 비효율적이다.
CSR
- CSR?
- 사용자의 요청에 따라 필요한 부분만 응답 받아 렌더링 하는 방식이다. 브라우저는 최초의 요청에서 html, js, css 확장자 파일을 다운로드한다.
최초의 html은 비어있다.js 파일의 다운로드가 완료되면 해당 js 파일이 DOM을 빈 html 위에 그리기 시작한다. (TTV = TTI) - 이후에는 화면에서 변화가 일어나야 하는 만큼의 데이터만 요청한다(ex. JSON)
- 라우팅을 하더라도 html 자체가 바뀌는 것이 아니라 JS 차원에서 새로운 화면을 그리는것.

- 장점
- 빠른 속도와 서버 부하 감소라는 장점이 있다. 변경된 부분과 관련된 데이터만 가져오므로 SSR보다 빠른 속도를 보인다.
- 네이티브 앱과 비슷한 빠른 인터렉션을 구현할 수 있습니다.
- View 랜더링을 브라우저에게 담당시킴으로서 서버 트래픽을 감소시키고, 사용자에게 더 빠른 인터렉션을 제공해 줍니다. (JS가 로드되기 전의 사용자 인터렉션을 기억함)
- 단점
- JavaScript 파일을 번들링해서 한 번에 받기 때문에 초기 구동 속도가 느리다.(code splitting, tree-shaking, chunk 분리를 사용해보자.)
- SEO가 어렵다. html 파일을 보면 아무것도 안들어있다.

!! 구글 크롤링 봇은 JS를 실행시켜서 SEO를 할 수 있다고 하지만 완벽하지는 않은 상태고 다른 크롤링 봇들은 이를 제대로 수행하지 못함으로 SEO를 위해서는 SSR 방식을 고려해 볼 필요가 있다.
- SPA
- 하나의 페이지로 구성된 웹 어플리케이션이다. 웹 애플리케이션에 필요한 모든 정적요소를 최초 접근시 단 한번만 다운로드한다. 이후 새로운 페이지 요청 시, 페이지 갱신에 필요한 데이터만을 JSON으로 전달받아 페이지를 갱신하므로 전체적인 트래픽을 감소시킬 수 있고, 전체 페이지를 다시 렌더링하지 않고
변경되는 부분만을 갱신하므로 새로고침이 발생하지 않아네이티브 앱과 유사한 사용자 경험을 제공할 수 있다. - 초기 구동속도는 SPA가 상대적으로 느리다.
- SPA와 CSR
- SPA는 일반적으로 SSR이 아닌 CSR으로 동작한다. CSR은 일반적으로 데이터 패치 요청을 통해 서버로부터 데이터를 응답받아 뷰를 동적으로 생성하는데 이때 브라우저의 주소창의 URL이 변경되지 않는다. 이는 사용자 방문 history를 관리할 수 없음을 의미하며
SEO 이슈의 발생 원인이기도 하다. - 그러나 요즘은 Next.js, Nuxt, Angular Universal 등을 통한 SSR이나 Pre-rendering, History API등을 사용하여 SEO를 할 수 있다.
- Pre-rendering: 클라이언트측 Javascript에서 모든 작업을 수행하는 대신 미리 각 페이지에 대한 HTML을 생성한다. 페이지 동작은 JS가 로드되고 가능하지만 모습은 미리 볼 수 있다(버튼이 눌릴 순 있지만 이벤트 리스너 같은것들은 연결되지 않은 상태).
- Static-Site-Gerneration: HTML을
빌드타임에 생성해 두고 요청시마다 재사용하는 방법이다. - 미리 렌더링된 HTML이 각 요청에 재사용된다(SSR:요청시마다 HTML을 생성) 바뀔일이 별로 없는 페이지에 적합하다. 미리 만들어 놓은 웹페이지를 유저와 지리적으로 가까운 곳에 캐싱 해놓을 수도 있다.
- 정적 생성하여 각 요청에 동일한 문서를 반환할 수 있을 때 사용해볼만하다.

그래서 뭘 써야하냐?????????????
⇒ 그때 그때 다르다! 적절하게 서비스에 적합한 것을 방법을 사용하자.

