DIL: 모던 리액트 딥 다이브, 4주차-1

스터디: 월간 CS, https://github.com/monthly-cs/2024-03-modern-react-deep-dive
오늘 진행: 개인공부

---

DIL-week4-1_2024-03-25

| DIL 주차 | 범위 | 내용 | 오늘차 진도 | | -------- | ------ | ------------------------------- | ----------- | | 4주차 | 4, 8장 | SSR과 ESlint, 테스트 라이브러리 | 252p~269p |

오늘 읽은 내용을 markdown으로 간단히 메모
읽은 시간: 10~11시

---

서버 사이드 랜더링 SSR

CSR

• 클라이언트 사이드 라우팅, 클라이언트 사이드 랜더링, 싱글 페이지 애플리케이션
  • 최초 데이터 로딩 이후, 페이지 전환은 history.pushState, history.replaceState
• ex) Gmail

웹 기술 스택

| 스택명 | 스택 내용 | | ------ | --------------------------------------- | | LAMP | Linux, Apache, MySQL, PHP/Python | | JAM | JavaScript, API, Markup | | MEAN | MongoDB, Express.js, AngularJS, Node.js | | MERN | MongoDB, Express.js, React, Node.js |

• 프런트엔드는 JS, HTML, CSS를 빌드 후, 정적으로 사용자에게 제공 -> 클라이언트에서 실행
  • 서버 확장성이 더 자유로워졌다
• Node.js의 고도화 => MEAN, MEAN 스택

평균 자바스크립트 리소스 크기의 우상향

• https://httparchive.org/reports/state-of-javascript#reqJs

| | desktop | mobile | | -------------------------------------------------------------------------------- | ----------- | ----------- | | JavaScript Bytes | 601.1 KB | 552.6 KB | | JavaScript Requests | 23 Requests | 22 Requests | | First Contentful Paint | 2.3 | 3.8 | | Time to Interactive | 4.2 | 14.3 |

• 체감상 웹 애플리케이션의 로딩 속도가 느려짐
  • https://www.nngroup.com/articles/the-need-for-speed/
  1. 웹 개발 환경이 바뀌었다
  2. 웹에서 더 많은 작업을 처리하고 있다
  • 코드의 양이 증가 -> JS 파싱을 위해 CPU를 소비하는 시간이 증가
  • 모바일 기준: onLoad는 10.8초, Time to Interactive 14.3초
• 두 가지 원인 모두 고객을 설득할 수 있는 내용이 아님
  • 제품의 웹 서비스 환경에 대한 고민을 해야 함

Server-Side Rendering이란?

MPA, Multi-Page Lifecycle은

• 서버에서 페이지 요청 받은 후, 완성된 HTML를 랜더링한다

SPA, Single-Page Application Lifecycle은

• 자바스크립트를 활용해 하나의 페이지에서 랜더링을 수행한다. 태생적인 한계가 있다.
  • 사용자에게 제공되는 자바스크립트 번들에서 랜더링
  • 사용자 기기의 성능에 영향을 받음 (SSR보다 불안정)

SSR은

장점

장점1. 최초 페이지 진입 First Contentful Paint이 비교적 빠르다

• ex) 외부 API 호출에 많이 의지하는 페이지, HTML의 크기가 큰 페이지
• HTTP 요청: 서버에서 하는 게 빠름
• HTML 그리기: 서버에서 문자열로 미리 그려서 내려주는 게, 클라이언트에서 기존 HTML에 삽입하는 것보다 빠름

장점2. 검색 엔진 최적화

• 검색 엔진, SNS 공유, 메타 데이터 적용
• 검색 엔진 로봇 > HTML 다운로드(JS는 실행 안함) > OG 태그 기반으로 검색(공유) 정보를 가져오고, 검색 엔진에 저장한다

장점3. Cumulative Layout Shift

• 누적 레이아웃 이동이 적다
• API 요청 완료 후 완성된 페이지를 제공하므로 Layout Shift가 적지만, 최초 페이지 다운로드가 느려질 수 있는데 > 리액트 18에서 등장한 스트림으로 해결될 수 있다 > 이후에 다룸

장점4. 사용자의 디바이스 성능에 비교적 자유로움

• 부담을 서버에~

장점5. 보안

• JAM 스택: 애플리케이션의 모든 활동이 브라우저에 노출
• API 호출과 인증 등의 민감한 작업 > 서버에서 수행하고 결과만 브라우저 제공

단점

단점1. 서버 환경에 대한 고려가 필요

• 소스 코드 전반에 걸쳐, 서버 환경 고려
  • ex) window, sessionStorage, 전역 객체

단점2. 적절한 서버 구축

• 사용자의 요청을 받아 랜더링을 수행할 서버가 필요
• 물리적인 가용량, 장애 복구 전략, 요청 분산, 프로세스 매니저의 도움

단점3. 서비스 지연

• 지연된다면? 병목 상태에서 어떤 정보도 제공할 수 없음

SPA vs SSR

• SSR is not 만능
  • 무거운 작업을 서버에 미룬다고 해서 모든 성능 문제가 해결되지 않음
  • 잘못된 설계 시, 성능을 해치고 관리 포인트만 늘어나는 역효과
• 잘만든 SPA
  • 레이지 로딩 lazy loading: 중요성 낮은 리소스
  • 코드 분할 code splitting: 불필요한 리소스 다운로드 및 실행 방지
  • 변경 필요한 HTML만 교체하는 최적화
• SPA의 성능 최적화
  • 사용자 기기에 의존
  • 최적화: 페이지 전환 시 필요한 리소스/공통 리소스, 다운로드와 랜더링 우선 순위 전략 => 어렵다
    • Paint Holding: 같은 출처(origin)에서 라우팅이 일어날 경우, 이전 페이지의 모습을 보여주는 기법
    • back forward cache(bfcache): 앞으로 가기 뒤로 가기 페이지 캐싱
    • Shared Element Transitions: 페이지 라우팅 시, 동일 요소 콘텍스트를 유지하기
• 현대의 SSR (Next.js, Remix)
  • 최초 웹 사이트 진입 시, SSR
  • 이후 라우팅, SPA같이 작동
  • 작동 방식을 이해하지 못하면, LAMP 스택과 다름없는 MPA를 만들어버리거나, 서버에서 암시롱 안하는 SPA 서비스를 만들 수 있다
• 두 가지 방법을 모두 숙지하고, 각 장점을 취하는 웹 서비스 구축 =>
• 필요에 따라 맞는 방법을 사용할 수 있다.