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을 생성) 바뀔일이 별로 없는 페이지에 적합하다. 미리 만들어 놓은 웹페이지를 유저와 지리적으로 가까운 곳에 캐싱 해놓을 수도 있다.
- 정적 생성하여 각 요청에 동일한 문서를 반환할 수 있을 때 사용해볼만하다.

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

