[React-Basic-Hooks] 4. Render React Element(ReactDOM / ReactDOMServer) about today_i_learned HOT 2 OPEN

Ref.

• https://velog.io/@zansol/%ED%99%95%EC%9D%B8%ED%95%98%EA%B8%B0-%EC%84%9C%EB%B2%84%EC%82%AC%EC%9D%B4%EB%93%9C%EB%A0%8C%EB%8D%94%EB%A7%81SSR-%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8%EC%82%AC%EC%9D%B4%EB%93%9C%EB%A0%8C%EB%8D%94%EB%A7%81CSR
• https://d2.naver.com/helloworld/7804182

SSR (Server Side Rendering)

• 서버에서 사용자에게 보여줄 페이지(HTML)를 모두 구성하여 사용자에게 페이지를 보여주는 방식 (JSP/Servlet 아키텍처 방식과 동일)
• 따라서 JS가 다운로드될 때까지 기다리지 않고도 렌더링 가능
• 서버에 요청할 때마다 브라우저 새로고침 발생, 서버에 새로운 페이지 요청
• 장점
  • 전체적으로 사용자에게 보여주는 콘텐츠 구성이 완료되는 시점은 CSR보다 빠름
  • SEO 구성이 쉬움 (HTML 정보가 처음에 포함되어 있어 데이터 수집 가능)
• 단점
  • CSR보다 페이지를 구성하는 속도는 늦음 -> 사용자가 보는 시간과 실제 동작까지 gap이 존재
  • 서버와 잦은 응답(view 변경시마다)을 하기 때문에 트래픽, 서버 부담
  • 매번 페이지 요청시 새로고침되어서 사용자 UX가 다소 떨어짐

CSR (Client Side Rendering)

• 페이지 로드 후 JS로 동적으로 DOM Tree를 생성하여 브라우저에게 전달하는 방식
• 장점
  • SSR보다 초기 전송되는 페이지의 속도는 빠름
  • data 요청이 있을 때만 서버에 요청하기 때문에 트래픽, 서버 부담이 상대적으로 적음
• 단점
  • SEO 구성이 어려움
  • 서비스에 필요한 데이터를 클라이언트/브라우저에서 추가로 요청해서 재구성해야하기 때문에 전체적인 페이지 완료 시점은 SSR보다 늦음 -> 사용자가 화면을 보기까지 시간이 오래 걸림 (JS 로딩 시간 + 실행 시간 + api 호출 시간)

실제로 사용하면 ?

• CSR과 SSR을 섞어서 사용
  • 서버에서 첫 요청은 HTML 만들어서 내려주고 클라이언트(브라우저)에서 SPA 형태로 동작
• 일반적으로 로딩되었을 때 화면에 보이는 범위(미 스크롤)까지는 SSR, 스크롤 이후에 보여지는 곳은 처음부터 렌더링 되지 않아도 되기에 CSR
  • SSR 시점에서는 클라이언트 뷰포트를 알 수 없으므로, 일반적으로 커버 가능한 적당한 위치 컴포넌트까지 렌더링하곤 한다

• 최초 응답된 HTML의 렌더링 형태
• 실제 렌더링과 다르게 최초 응답시에는 커버 가능한 적당한 영역만 렌더링한 것 확인 가능

SEO (Search Engine Optimization)

• 웹 페이지 검색 엔진이 자료를 수집(crawling) 순위를 매기는(ranking) 방식에 맞게 페이지를 구성하여 검색 결과 상위에 나올 수 있도록 하는 작업
  • 웹 사이트 traffic의 quality와 quantity를 증가시키는 것
• crawl (content crawling) -> index (content를 저장하고 oraganize하는 과정) -> rank (relevant -> least relevant 순으로 sort) 과정 진행

왜 SSR에서는 SEO 지원이 쉬울까?

• 대부분의 웹 크롤러, 봇들은 JS를 실행시키지 못하고 HTML 내에서만 컨텐츠를 수집(JS엔진이 내장된 크롬은 제외)하기 때문에 CSR 방식으로 개발된 페이지는 빈 페이지로 인식 -> 별도 SSR을 구현 or SEO 지원 필요
• SSR 방식에서는 모든 정보를 포함한 HTML이 있기 때문에, 즉각적으로 HTML에 대해 크롤링 & 인덱싱 가능 -> 검색 결과를 보여주고 ranking 하는데 더 빠름

Ref.

• https://medium.com/@benjburkholder/javascript-seo-server-side-rendering-vs-client-side-rendering-bc06b8ca2383
• https://moz.com/beginners-guide-to-seo/why-search-engine-marketing-is-necessary#index
• https://moz.com/beginners-guide-to-seo/how-search-engines-operate

SPA (Single Page Application)

• 하나의 단일 HTML 위에서 구동되는 어플리케이션
• 최초 한번 페이지 전체를 로딩 후, javascript로 동적으로 데이터만 변경하여 사용
• 반대 방식은 MPA(Multi Page Application)
• 왜 만들어졌을까?
• 일반 웹 어플리케이션과의 차이?
  • 연속되는 페이지 간의 사용자 경험 향상
  • 웹 애플리케이션이 데스크톱 애플리케이션처럼 동작하도록 도와줌

그러면 CSR === SPA ?

• SPA는 하나의 단일 페이지에서 실행된다는 뜻
• 맨 처음 페이지를 모두 받아오고 이후에는 받아오지 않지만, 이럼에도 데이터가 수정 및 조회를 위해서 CSR이라는 렌더링 방식을 선택한 것일 뿐, 둘은 비교 대상이 아님
  • 반대로 MPA는 동적이지 않은 페이지를 상황에 맞게 클라이언트에 뿌려주기 때문에 SSR 렌더링 방식 채택
• 결론 : SPA와 MPA는 페이지를 여러 개 쓰냐 한 개만 쓰냐의 차이, CSR과 SSR은 렌더링을 어디서 하느냐의 차이
  • Node 환경을 통해 SPA에서 CSR + SSR을 적당히 조합해서 사용 가능

그러면 React는 SPA ? CSR ?

• React는 이러한 SPA를 쉽게 만들 수 있는 UI 라이브러리이며 CSR 방식 사용
• react-router를 사용해서 SPA 만들 수 있음 (routing : 주소에 따라 다른 뷰 렌더링, React 자체에 이 기능이 없기 때문에 별도 react-router 사용)

from today_i_learned.

Isomorphic Javascript (Universal Javascript)

• Isomorphic Javascript : 서버(Node.js)와 클라이언트에서 동일한 JS 코드를 가지고 동작 가능한 형태 (클라이언트에서 동작하던 라이브러리를 서버에서 똑같이 사용 가능)
• 이런 형태의 개발이 왜 생겼는지? : SPA에서 CSR 방식 사용시, 미흡한 SEO 대응을 위해 SSR 방식 추가됨
  • 하지만 SSR을 위한 서버 코드 & CSR 코드 2벌을 만들어야 함 -> 이를 한벌의 코드로 관리해서 해결하고자 Isomorphic 형태의 개발이 생김
• 기존 SPA의 한계는 브라우저에서 DOM 제어가 들어가는데 서버에서 렌더링 엔진이 없기 때문에 DOM 제어가 불가능
  • 서버에서는 string을 만들어내니까 이를 회피하기 위해 React가 취한 방식은 Virtual DOM(실제 DOM X) 개념으로 해결 (그냥 JS 객체) -> 클라이언트든 서버든 JS 실행 환경이면 모두 실행 가능 -> React에서 SSR 지원 가능해짐 (React가 AngularJS(1.x)와 비교했을 때 우위였던 이유)
  • Virtual DOM에서 string으로 HTML을 return하면 SSR이 되고, 그걸 DOM에 직접 붙이면 CSR

Isomorphic Javascript with SSR

• 서버에서 첫 요청은 SSR, 이후 동작은 클라이언트(브라우저)에서 CSR 방식으로 SPA 형태 동작한다는 SSR 전제

장점

• 서버, 클라이언트 두 벌로 관리되던 중복 코드의 제거로 코드량 감소
  • 서버에서 render를 할 때, CSR에서 render하는 동일한 함수를 사용
  • 예시) 통검은 SSR로 질의어로 각 서버에 요청을 하면 각 HTML 응답이 오고 노출된 영역에서 더보기 버튼 클릭시 서비스 페이지로 이동됨
    • 통검에서 보이던 동일한 영역이 확장되어서 서비스 페이지에서 보이는데, 통검 & 서비스 양쪽에 데이터를 동일하게 넣거나 동작을 맞춰야하는 경우가 생김 -> 코드 2벌 필요
    • Isomorphic Javascript를 사용하게 되면 공통 로직을 통검 SSR & 서비스에서 사용 가능, 코드 재사용 가능
• SEO 지원
• 사용자가 첫 화면을 보게 되는 시간이 빨라짐

단점

• 사용자가 SSR 화면을 본 후에 실제 동작이 되기까지 시간이 걸림(CSR 동작이 끝날 때까지)
  • 요즘 브라우저는 성능이 좋아서 사용자가 느끼기에 크지 않음
• TTFB(Time To First Byte)가 CSR에 비해 느림
  • SSR 과정에서 API 호출 및 render 시간
  • 하지만 CSR에서 브라우저에서 서버로 요청하는게 서버 to 서버 요청보다 API 응답이 더 길다 (사용자 API 호출 환경에 따라도 다름)
• 서버 비용이 많이 들어감 (보통 큰 회사 같은 경우 이 서버 비용이 크지는 않음)

Ref.

• https://subicura.com/2016/06/20/server-side-rendering-with-react.html

from today_i_learned.