Next.js 장점과 렌더링 종류

1. Next.js 사용 장점

- 풀스택, 파일 베이스 라우팅, SEO, 이미지/폰트 최적화, 서버사이드 렌더링/하이브리드 렌더링

- 라이브러리인 리액트 + 프레임워크인 Next로 리액트만으로는 힘든것들을 가능하게 해줌

 

2. CSR의 단점

- TTV가 길다 (FCP - First Contentful Paint) : REACT 소스코드와 UI를 가지고 있는 JS 를 초기에 모두 다운로드받고 -> DOM 생성

- 자바스크립트 활성화가 필수

- SEO 최적화 👎

- 클라이언트에서 모든 코드 다운로드 & 실행 -> 보안에 취약함 (데이터 받아오는 방식, 키 등 노출)

- CDN(Content Delivery Network)에 캐시가 안됨

 

 

* SSG와 SSR은 모두 렌더링하는 주체가 서버이지만, 언제 렌더링하는지에 따라 나뉨

3. SSG

- 앱을 배포해서, 서버에서 빌드할 때 한번 렌더링 됨

- 빌드 때 리액트 코드를 HTML로 변환 (fetch, read 등 모두 미리 동작...)

- CDN에서 캐싱된 HTML파일을 가져올 수 있음

- 장점: TTV가 빠름, 자바스크립트없이도 내용 확인, SEO 굳, 서버측에서 동작하므로 보안이 뛰어남

- 단점: 데이터가 정적임(웹 성격에 따라), 사용자별 정보 제공 어려움, 

 

+ 그럼 변경된 데이터를 반영하려면 빌드 과정이 이루어져야하는데 그럼 그때마다 앱을 새로 배포해야하는건지?

=> CI/CD 파이프라인을 설정하거나, Rehydration을 통해 초기에는 미리 생성된 정적 HTML을 사용하고 이후에는 클라이언트 측 JS를 이용해 동적인 데이터를 처리할 수 있음

 

4. ISR 

- 주기적으로 렌더링 됨 (빌드할 때 SSG, 그 이후 설정한 시간에 따라 변경사항이 반영되서 새로운 사이트가 만들어짐)

- SSG의 장점 + 데이터를 주기적으로 업데이트 

- 문제점: 주기적이긴 하지만 실시간 데이터는 아님

 

5. SSR 

- 요청 시 렌더링

- SSG의 장점 + 실시간 데이터를 사용하므로 최신 데이터 제공 + 사용자 별 필요한 데이터를 사용함

- 단점: 비교적 느림, 서버 과부하, CDN 캐시 x

 

6. Hydration

- server 에서 정적인 html(pre-rendering)을 client에 먼저 보내주고, 그 다음 react, js 파일을 보내서 interaction 가능하게 만듦

-> Component Rendering (컴포넌트를 인터렉션 가능하게 해줌)

 

즉 정적인 HTML과 Hydration의 간극을 좁히는것이 관건

 

 

7. 언제 어떤 렌더링 방식을 사용할까?

1) 사용자의 로그인이 필요없다 (사용자별로 달라지지 않는다)

     + 데이터가 자주 변경되지 않는다 => SSG

 

     + 데이터가 자주 변경된다 

            + 5분, 10분, 하루 간극은 괜찮다 => ISR

            + 즉각적으로 봐야한다 => SSR / ISR또는SSG + CSR (Hybrid)

 

 

2) 사용자의 로그인이 필요하다 (사용자별로 다르다)

    => CSR / SSR / Hybrid

 

 

 

 

- 메인페이지: Hybrid (맵 CSR, 게시판(커뮤니티) SSR)

- 로그인/회원가입:  CSR 또는 CSR + 레이아웃 SSG

- 게시물 작성: CSR 또는 CSR + 레이아웃 SSG

- 게시물 상세페이지: SSR + 레이아웃 SSG