SEO(검색 엔진 최적화), SSR(서버 사이드 렌더링), CSR(클라이언트 사이드 렌더링), SSG(스테틱 사이트 제너레이션) 설명

1. SSR (Server Side Rendering)

• SSR 은 정확한 의미로는 서버에서 자바스크립트 파일을 해석(랜더링) 하고 완성된 HTML, JS, CSS 파일을 보내주는 것
• JSP, ASP 등도 해석하는 언어만 다를 뿐 서버에서 해석 한 이후에 사용자에게 전달함

• 식당을 예를 들면 음식을 주문 시키면 해당 음식을 주방에서 조리하고 식탁으로 가져다 주는 느낌

• 단점 :

  • 모든 요청에 대해서 서버에서 계산을 한 후에 완성본을 보내야 하기 때문에 요청이 늘어날 수록 서버가 과부화 됨
  • 서버가 과부화 되면서 서버 비용이 늘어남
  • 요청이 올때까지 대기해야 하기 때문에 속도가 느림

2. CSR (Search Engine Optimize)

• CSR 은 서버에서 하나의 페이지(SPA, Single Page Application)와 자바스크립트 번들(묶음)을 보내는 형태 (React, Vue, Angular, Flutter Web)
• 서버에서 매번 해석할 필요가 없이 클라이언트에서 요청하는 데이터만 주고받음 (Api 서버).
• 자바스크립트의 해석은 각 사용자 PC/Mobile 의 웹 브라우져에서 진행함.
• 식당을 예를 들면 식당에서 하루에 팔 재료 전체를 장바구니에 넣어두고 한번에 던지는 방식. 요리는 각 테이블(웹 브라우져)에서 함

• CSR 이후로 웹 기반 프론트 앤드의 역할과 요구 기술 사항이 높아졌음. (ex 서버 상태 관리로 서버 요청 최소화 등)

• 장점 :

  • 서버에서 랜더링을 하지 않고 api 데이터만 보냄으로써 서버에서 계산하는 부하가 크게 줄어듬
  • 웹 브라우저에서 랜딩 이후 (첫 로딩 이후) 사용자 환경에 따른 반응속도 등이 빨라짐 (Virtual Dom)
  • Virtual Dom : 기존 SSR 방식처럼 HTML, CSS, JS 를 받아서 화면을 다시 그리는게 아니라 기존 DOM 을 메모리에 넣어두고 버추얼 돔과 비교해서 변화가 생기는 부분만 다시 랜더링
  • 전통적인 JSP 와 같은 환경에서 Front-End, Back-End 로 역할과 책임이 분명해짐

• 단점 :

  • 검색앤진에서 크롤링을 할 경우 GET 을 요청 시 HTML 과 JS, CSS 의 번들만 볼 수 있음.
  • 식당을 예로 들면 SSR 에서는 주문 후 나오는게 무슨 요리인지 알지만 CSR 에서는 장바구니만 보임
  • 구글, 네이버등에서 검색 불가, 현재 구글만 부분적으로 JS 를 해석한다고 알고 있음.
  • 첫 로딩 때 전체 JS 를 해석해야 함으로 번을 양이 많으면 첫 로딩이 느릴 수 있음.

3. NextJS, NuxtJS, Angular Universal

• CSR 은 장점이 많음에도 불구하고 B2C 모델일 경우 검색이 안된다는 치명적인 단점이 있음.
• 따라서 CSR 만을 수행하지 않고 SSR 도 수행할 수 있는 풀스택 프레임워크가 필요해짐.
• NextJS 는 서버, 클라이언트 역할을 동시에 수행할 수 있는 프레임워크로 별다른 백앤드 없이 백앤드도 구성 가능

• CSR 과 SSR 을 더해서 빌드시에 만들어놓은 페이지를 단순히 던저주는 기능(SSG) 도 구현

• 장점 :

  • CSR 의 장점(속도, 서버 부하 줄이기)과 SSR의 장점(검색 엔진 최적화)를 동시에 가질 수 있음.
  • 식당을 메인메뉴만 알면 되는 사람에게 그것만 알려주고 나머지 추가 메뉴, 반찬, 음료 들은 장바구니 형태로 있음

• 단점 :

  • 비교적 최근부터 생긴 기술로 안정성이 부족할 수 있음.
  • 프론트앤드 개발자가 리엑트 개발자 + 서버 기술 이해 등의 지식이 필요해짐
  • SEO 가 가능하지만 전통적인 SSR 보다 훨씬 복잡해짐 (ex: 각 컴포넌트 및 페이지가 SSR일지, CSR 일지, SSG 일지부터 파악하고 설계)
  • SSR, CSR, SSG 각 페이지 별로 사용이 가능한 기능들이 다르고 서로가 섞이는 경우도 있어서 개발이 복잡해짐