📌 SPA와 MPA

• 오늘날 웹 어플리케이션 개발 한다고 하면 대부분 JS 기반 프레임워크(ex. 리액트, 앵귤러, 뷰 등)를 사용해서 SPA를 개발하게 됨.

• SPA란

  • Single Page Application의 약자
  • 하나의 페이지로 구성된 웹 어플리케이션

• MPA란

  • Multi Page Application의 약자

  • 전통적인 웹 페이지 구성 방식

    탭을 이동할 때마다 페이지 전체를 새로 렌더링 (서버로부터 새 html을 새로 받아옴)
    

  • 단점

    • 매번 새 HTML을 서버로부터 받아옴

    • 전환 시마다 화면 깜빡임

• MPA 단점 때문에 AJAX가 등장하면서부터는 SPA를 사용하게 됨

  • 이유

    • 원하는 부분만 클라이언트에서 동적으로 갈아끼울 수 있음

    • 화면 깜빡임 X

📌 CSR과 SSR

🔹 SPA, MPA와의 관계

• SPA & MPA가 일반적으로 차용하는 렌더링 방식

  

• SPA가 렌더링 방식으로 CSR을 사용하게 된 이유

  웹 애플리케이션에 필요한 정적 리소스를 초반 한 번에 모두 다운로드 하고 그 이후 새로운 페이지 요청이 있을 때 페이지 갱신에 필요한 데이터만 전달받아서 클라이언트에서 페이지를 갱신하기 때문
  

• MPA가 렌더링 방식으로 SSR을 사용하게 된 이유

  새 요청이 있을 때마다 서버에서 이미 렌더링된 정적 리소스를 받아오기 때문
  

🔹 CSR, SSR, SSG의 개념

• 개요

  	CSR	SSR	SSG
  풀네임	Client Side Rendering	Server Side Rendering	Static Site Generation (Static Rendering 이라고도 불림)
  렌더링 방식	클라이언트 측	서버 측	서버 측

• CSR & SSR 차이

  

• SSR vs SSG

  • 비슷한 점 : 서버에서 HTML을 보내줌

  • 차이점

    • 언제 만들어 주느냐

      

    • 적합한 경우

      	SSR	SSG
      이유	요청 시, 서버에서 즉시 HTML을 만들어서 응답	페이지들을 서버에 모두 만들어둔 뒤에 요청 시, 해당 페이지를 응답
      적합한 경우	미리 만들어 두기 어려운 페이지 (데이터가 달라지거나 자주 바뀌어서)	캐싱 해두면 좋은 페이지 (바뀔 일이 거의 없어서 )

      

      

🔹 CSR의 동작 과정과 특징

• 동작 과정

  

  유저가 웹사이트에 방문하면 브라우저가 서버에 콘텐츠를 요청하고 서버는 빈 뼈대만 있는 HTML을 응답으로 보내줌. 브라우저가 연결된 JS 링크를 통해 서버로부터 다시 JS 파일을 다운로드 받고 JS를 이용해 동적으로 페이지 만들어서 브라우저에 띄워줌.
  

• 중요 특징

  1. 초기 로딩 속도 느림

     

     이유 : 브라우저가 JS 파일을 다운로드 받고 동적으로 DOM을 생성하는 시간을 기다려야 하기 때문

  2. 이후 구동 속도 빠름

     

     이유 : 초기 로딩 이후에 페이지 일부를 변경 시, 서버에 해당 데이터만 요청하면 되기 때문

  3. 서버 부하 ↓

     

     이유 : 서버가 빈 뼈대만 있는 HTML을 넘겨주는 역할만 수행하면 되기 때문

  4. 반응 속도 빠름 & UX 우수

     이유 : 클라이언트 측에서 연산, 라우팅 등을 모두 직접 처리 하기 때문

  5. SEO 불리

     

     이유 : 브라우저들이 가지는 웹 크롤러는 HTML을 읽어서 검색 가능한 색인을 만듦. 웹 크롤러 봇 입장에서 본 HTML은 이렇게 텅텅 비어 있음. 검색엔진이 색인을 할 만한 콘텐츠가 존재 X

     

     • 구글에서 SSR을 고려해보라고 하는 이유

       • 남다르게 똑똑한 구글의 크롤러 봇은 JS를 실행할 줄 앎. 그래서 CSR 웹 크롤링도 가능.

       1. 하지만 아직 완벽한 단계가 아님.

       2. 크롤러 봇이 JS를 실행하기전에 더 빨리 크롤링을 할 수 있도록

       3. JS를 실행할 수 없는 다른 크롤러 봇들을 위해서

🔹 SSR의 동작 과정과 특징

• 동작 과정

  

  유저가 웹사이트에 방문하면 브라우저에서 서버로 콘텐츠를 요청함. 서버에서는 즉시 페이지에 필요한 데이터를 얻어와 모두 삽입하고 css 까지 모두 적용해서 렌더링 준비를 마친 HTML과 JS코드를 브라우저에 응답으로 전달함.

  브라우저에서는 바로 전달 받은 페이지를 띄움. 이어, 브라우저가 JS 코드를 다운로드하고 html에 JS 로직을 연결함.
  

• 중요 특징

  1. SEO ↑

     

     서버에서 렌더링 준비를 마친 HTML을 브라우저의 응답으로 전달한다는 부분. 모든 데이터가 이미 HTML에 담겨진 채로 브라우저에 전달되기 때문에 SEO에 유리함. (이유 : JS를 실행 할 줄 모르는 크롤러 봇도 무리없이 HTML을 읽을 수 있어서)

  2. 초기 구동 속도 빠름

     

     JS 코드를 다운로드 받고 실행하기 전에 사용자가 화면을 볼 수 있다는 점. (JS 다운로드를 기다려야했던 CSR보다 초기 구동 속도가 빠를 수 밖에 없음)

  3. TTV ≠ TTI

     

     이것이 치명적인 단점이 되기도 함. 이 시점에는 사용자가 버튼을 클릭 하거나 이동하려고 아무런 반응이 없을 수 있음.

     

     인터랙션 가능한 페이지처럼 보이지만 그저 내용과 스타일이 입혀진 껍데기에 불가. 실제로 클라이언트 측 JS 가 실행되고 이벤트 핸들러가 첨부되어서 JS 로직이 모두 연결될때까지 사용자 입력에 응답 할 수 없기 때문.

     (사용자 입장에서는 뭔가 보여서 눌렀는데 아무런 반응이 없다면 굉장히 어이 없을 것 같음.)

     이렇게 SSR 안에는 TTV(Time To View)와 TTI(Time To Interact) 간에 시간 간격이 존재한다는 것이 단점.

     반면에 CSR은 사용자가 보는 시점과 이용할 수 있는 시점이 동일함. (이유 : JS가 동적으로 DOM을 생성하기 때문에 HTML은 JS 로직이 모두 완전히 연결된 상태)

🔹 CSR과 SSR의 장단점

	CSR	SSR
화면 깜빡임	X	O
초기 로딩 속도 빠름	X
(but, 초기 로딩 이후 구동 속도 빠름)	O
TTV와 TTI 사이 간극	X	O
서버 부하	분산	O
SEO	불리	유리

• CSR 장점

  • 전체적으로 매끄러운 사용자 경험이 특징

  • 서버에 부하가 클라이언트로 분산됨

• SSR의 단점

  • 사용자 경험이 나쁘다 (이유 : TTV와 TTI 사이 간극 有)

  • 서버에 부하 有 (이유 : 매 페이지 로딩 시마다 서버에 요청)

🔹 CSR 단점 보완 방법

• 초기 로딩속도 개선 방법

  code splitting, tree-shaking, chunk 분리를 통해

  → JS 번들 크기를 줄여서

  → 초기 DOM 생성 속도를 줄이기
  

• SEO 개선

  방법 : pre-rendering

  각 페이지에 대한 HTML 파일을 미리 생성해둔 뒤 (방법 : 라이브러리 or 웹팩 플러그인), 서버에서 요청하는 자가 만약 크롤러라면 사전에 렌더링 된 HTML 버전 페이지를 보여 주는 방식
  

• CSR을 사용하고 있는 SPA에 SSR or SSG를 도입

🔹 Isomorphic App / Universal Rendering

초기 렌더링 방식으로 SSR을 사용하고 그 이후에는 CSR을 사용하는 앱 or 렌더링 방식

• 의미

  서버와 클라이언트에서 동일한 코드가 동작하는 어플리케이션
  

• 최근 많이 사용 되고 있는 추세

  • 이유 :

    • 초기 로딩속도 & SEO를 해결

    • CSR의 장점 유지 가능

  • 불안한 점

    예상과는 다른 결과를 마주할 가능성 有 (이유 : 클라이언트와 서버가 모두 같은 코드로 돌아가기 때문)
    

📌 CSR + SSR/SSG

🔹 without 프레임워크

1. Express.js

   별도의 서버를 직접 운영하는 방법

2. NestJS

   기본적으로 타입스크립트를 지원

• 하지만 이 방법들은 다소 진입장벽이 있음. 이유 : 서버 환경 구성이나 빌드 등의 작업이 생소한 프론트엔드 개발자에게는 복잡하고 헷갈리는 부분이 많아서
  

🔹 without 프레임워크

1. Next.js

   

   리액트 SSR or SSG를 사용할 수 있게 해주는 프레임워크

   페이지의 성격 별로 어떤 것을(SSR / SSG) 사용할 것인지 미리 정해 주는 것도 가능

2. GatsbyJS

   

   SSG에 최적화된 리액트 기반 정적 페이지 생성 프레임워크

   • 장점

     • SSG에 최적화되어 있긴 하지만 CSR, SSR, 레이지 로딩 등도 지원
     • 다양한 플러그인 제공
     • 사용하면 좋은 경우 페이지가 적고, 작은 서비스 (이유 : 빌드 시점에 스태틱 HTML들을 만들어 주는 것이기 때문에)
       

• CSR에 비해 코드 복잡도 ↑ & 블랙박스 영역 존재

  

  • CSR에 SSR이나 SSG 도입을 훨씬 편하게 만들어 주는 것은 사실이지만 프레임워크를 사용하더라도 일반 SPA. 즉 CSR 개발에 비해 코드 복잡도는 올라갑니다.
  • 직접 제어할 수 없는 블랙박스 영역도 존재

📌 CSR, SSR, SSG, Universal (무엇을 써야할까)

정답 : 서비스 성격에 따라 달라짐

• CSR

  

  • 고객의 데이터를 보호하는 것이 더 중요할 수 있음. 의미 : 모든 서비스 SEO가 필요하지는 않다.
    

• SSR

  

  • 회사 홈페이지 이기 때문에 상위 노출 되어야 하는 경우

• SSG

  

  • 내용을 업데이트 하는 일이 거의 없는 경우

• CSR + SSR (유니버셜 렌더링)

  

  이 경우에는 유니버셜 렌더링을 고려

---

참고 자료

• 우아한 테크 : [10분 테코톡] 🎨 신세한탄의 CSR&SSR