Hydration 개념 공략

다루는 내용:

하나의 온전한 페이지를 유저에게 보여주는 방법은 3가지가 있다

• SSR (Server Side Rendering): 웹 서버가 열심히 온전한 페이지를 만들어서 웹 브라우저가 그걸 받아와 유저에게 보여줌
  • 온전한 페이지를 Run Time에 만듬
• CSR (Client Side Rendering): 웹 브라우저가 열심히 빈 페이지를 온전한 페이지로 만들어서 유저에게 보여줌
• SSG (Static Site Generation) : 이미 만들어져 있는 웹 페이지를 웹 서버가 갖고, 바로 웹 브라우저에게 반환하여 유저에게 보여줌
  • 정적의 웹 페이지를 생성함
  • 정적인 페이지를 Build Time에 미리 만들어둠

Run Time vs. Build Time

• 프로그램은 개발과 구동으로 나눠짐
  • 개발 = Build and Compile = Build Time
    • 특징:
      • 리소스가 필요하지 않음 (서버 리소스가 필요하지 않음)
      • 그저 만들어서 적재만 하면 됨 (= SSG)
    • ex.) Github Pages
  • 구동 = Interpret = Run Time
    • 특징:
      • 상주 서버가 필요함
      • 비용이 발생함

---

SSG vs SSR vs CSR

• 장단점:
  • SSG:
    • (+) 속도가 제일 빠름
    • (-) 실시간성에 위배됨
  • SSR:
    • (+) 실시간성이 좋음
    • (-) 만드는데 오랜 시간이 걸림
  • CSR:
    • (+) 페이지 전환이나 동작이 부드러움
    • (-) Bundled JS가 너무 무겁다 (= 크다)

---

Hydration

• SSG + SSR + CSR 의 모든 장점을 가져와 합치는 방법
  • 정확하게는 SSG와 SSR의 장점 위에 CSR의 장점을 얹기 위한 방법
  • SSG: 웹 페이지내 비실시간성 요소를 미리 준비하여 제일 빠르게 반환
  • SSR: 실시간성이 필요한 웹 페이지 내 부분은 웹 서버로부터 요청이 들어오자마자 반환
  • CSR: 모바일 앱과 같은 사용성을 제공하면서 일부 요소들을 CSR로 렌더링하여 Bundle JS를 경량화 시킴
• Hydration 적용 시 JS가 늦게 로드되기 때문에 짧은 시간동안 유저 사용성에 관련된 버튼 등이 동작하지 않음

---

Next.js는 어떻게 작동하는가?

• Next.js는 Streaming & Partial Rendering이라는 Rendering 전략을 갖는다
  • 빌드타임에 생성하는 것들 (Pre-rendering)
    • Static without Data
    • SSG with Data (using API)
  • SSR: Next.js 빌드 로그에서는 Dynamic / Server로 표기함
  • CSR: 빌드 로그에 First Load JS로 표기 됨
• MPA (Multi-Page Application) + SSR (Server-Side Rendering) 특징과 동일하다
  • 서버가 필요함
  • 서버가 동적 웹 페이지를 생성 & 반환하기 때문에 모든 웹 페이지를 가지고 있을 필요가 없다
    • 웹 페이지를 만들고, 유저가 보기까지 시간이 걸릴 수 있다
  • 서버가 생성해서 반환하기에 웹 페이지의 반환 속도는 DB 조회 속도, 웹 페이지 생성 속도에 의존한다
    • 웹 서버의 CPU, 메모리 자원이 사용되기 때문에 클라우드 사용시 비용이 부담될 수 있다
  • SEO 최적화가 가능함
• 여기에 Hydration을 활용하여 여전히 모바일 앱과 유사항 사용성을 제공 가능 하다
  • 웹 브라우저가 동적 웹 페이지를 생성하여 반환하기 때문에, 웹 페이지 전환시 깜빡임이 존재하지 않음

---

SSG (Static Site Generation) with Hydration

• React같은 프레임워크로 개발 및 빌드한 정적 페이지를 반환하는 웹 서버를 활용함
  • ex.) Nginx, Apache, S3, ...
• Web Frontend Framework (React, Vue, ...)를 통해 CSR 개발하듯이 개발한 뒤 빌드를 하면 정적 페이지 생성이 가능하다
  • SSG 등장 배경
    • SEO 개선을 위해 페이지 로딩 속도를 극단적으로 줄일 필요가 있음
      • HTML, JS, CSS를 직접 생성하는 Static Websites와 달리, SSG는 빌드 (Prerender)로 생성함
      • Static Websites와 특징이 동일하다
        • 미리 만들어진 웹 페이지의 정적인 웹 페이지를 요청에 따라 반환함
          • ex.) 1000명의 유저 정보 페이지 = 1000개의 유저 정보 페이지
            • 하나의 Template과 Data가 아님
• 여기에 CSR의 장점을 누릴 수 있도록 Hydration이 추가됨

---

ISR (Incremetnal Static Regeneration)

• React 같은 Framework로 개발 및 빌드한 정적 페이지를 주기적으로 갱신 + 반환하는 Web Application Server를 활용함
• 등장배경:
  • Database나 API를 사용한 SSG인 경우, 근원의 정보가 바뀌었을때 빌드밖에 갱신할 방법이 없음
  • SEO 개선을 위해 SSG를 사용했으나 실시간 페이지 업데이트를 위해 너무 잦은 빌드가 필요함
    • SSG를 위해서는 Web Server로 충분하지만
    • 주기적으로 근원 정보 호출을 통해 정적 페이지 리빌드를 위해서 Web Application Server가 필요함
• SSG와 특징이 동일하다
  • 미리 만들어진 Static Web Page를 요청에 따라 반환함
  • • 여기에 CSR의 장점을 누릴 수 있도록 Hydration이 추가됨
  • ++ 여기에 Revalidation 옵션으로 SSG로 빌드했던 웹 페이지가 일정 시간이 지나면 Rebuild되어 준 실시간성을 보장할 수 있음
• 특징:
  • SSG임에도 불구하고 서버가 필요함
    • 기술 블로그같은 Hosting이 매우 어려움
  • 서버가 반환하고자 하는 모든 Static Web Page를 가지고 있어야 한다
  • 웹 버전 변경시, 개발 -> 빌드 과정을 거치면 되서 비교적으로 Static Website의 버전을 변경하는 것보단 간편하다
  • 서버가 가지고 있는 웹 페이지를 반환만 하면 되기에 매우 빠른 웹 페이지 반환 속도를 가지고 있음
  • SEO에 유리함
    • 웹 크롤러가 웹 페이지를 수집할 수 있음
  • 정적 웹 페이지이지만 일정 주기에 따라 WAS가 웹 페이지를 리빌드하여 준 실시간성이 보장된다
  • Hydration을 활용하여 여전히 모바일 앱과 유사한 사용성 제공이 가능하다
    • 웹 페이지 전환 시 깜빡임이 없음!

---

Rendering Optimization Strategies (렌더링 최적화 전략)

1. Partially Hydration
   • Code Splitting의 일종인 Lazy Loading
     • CSR을 수행하는 JS에게 "그거 아직 필요없으니까 나중에 Render해줘"
     • ex.) 무한 스크롤처럼 유저가 지금 당장 봐야할 HTML 요소를 먼저 가져오고, 스크롤 아래있는 것들을 늦게 가져옴
2. Island
   • 정적인 영역은 서버를 통해 미리 만들어놓은거나, 만들어서 가져오고 동적인 부분에 대해서만 JS를 로드함
3. Streaming SSR
   • RSC (React Server Component)의 등장으로 인해 SSR에서 Streaming이 가능해졌다!
     • Streaming: 서버에 Rendering된 Contents를 한꺼번에 전달하지 않고, Rendering이 완료된 부분부터 *순차적으로 클라이언트 (Web Browser) *에 전송하는 방식을 의미함
     • SSR 해야하는 전체 Componenet 중 가장 먼저 Rendering 해야하는 Componenet 부터 Server Rendering 및 병렬 처리
       • 병렬처리: 서버에서 여러 Component를 동시에 처리하는 것을 의미함
         • 즉, 서버가 모든 Component를 순차적으로 Rendering 하기 보단, 필요한 Component를 동시에 처리함
         • 이 방식으로 Rendering 완료된 Components는 즉시 Client (Web Browser) 로 전송되어 페이지가 구성됨
         • 장점:
           • 페이지의 로딩시간을 줄임
           • UX를 개선하는데 도움을 줌
             • 중요한 Component 먼저, 덜 중요한 부분은 나중에 Rendering되도 사용자에게 큰 영향을 미치지 않음
4. Resumability
   • Qwik이 채택한 새로운 Rendering 전략
     • Serializable: HTML을 조각으로 갈아서 (including JS Event Handlers) 전송함
   • SSR과 CSR의 장점을 결합한 방식
     • 서버에서 Rendered된 HTML을 Web Browser로 전송할 때, Client측에서 필요한 JS 코드를 최소화하고, 사용자가 상호작용을 할때만 필요한 부분의 logic을 로드하여 실행하는 방법
   • 장점:
     • 빠른 초기 로딩 (Fast initial loading): 전달되는 JS의 양이 최소화되고 필요한 시점에만 로드하기 때문
     • 효율적인 자원 사용: JS를 필요한 시점에만 로드하기 때문에 Client의 리소스를 절약함
     • UX 개선: 페이지가 빨리 로딩되고 상호작용도 빠르게 이루어짐
   • 단점:
     • 개발하기 어려움
     • 초기 로딩 시 제약이 생길 수 있음
     • 상태 관리가 복잡함

---