[Next] Next.js 시작하기 : CSR, SSR, SSG, ISR 렌더링 기법, 코드 스플리팅

 

 

💡 Next.js 를 배워봅시다 🥹

 

: 웹 개발을 위한 React 프레임워크! 개발에 필요한 다양한 기능과 구조를 제공한다.

• 다양한 렌더링 기법 : CSR, SSR, SSG(Next.js 기본), ISR
• 라우팅 : 파일(폴더) 기반 라우팅
• Route Handler : 백엔드 가능
• 스타일링 : CSS, Sass, CSS-in-JS
• 최적화, 번들링 : 코드 스플리팅, 이미지 최적화(img 태그가 아닌 Image 컴포넌트), 웹팩 설정 등

 

👀 라이브러리? 프레임워크?

라이브러리: 개발자가 필요할 때 마다 설치, 혹은 호출함으로써 개발자가 능동적으로 사용하게 됨

프레임워크: 프로그램이 필요한것을 개발자에게 알려줌으로써 제어권을 역전

 

😲 코드 스플리팅 ? 코드 분할!

번들링된 파일을 잘라내 웹페이지 로딩 시간을 줄이는 방법!

• 런타임 시 사용자가 필요로 하는 부분만 우선 로딩 ➡️ TTV 향상!

TTV Time To View : 사용자가 최초 뷰를 볼 수 있을 때까지의 시간 - 화면 렌더링

TTI Time To Interact : 사용자가 웹의 기능을 쓸 수 있을 때까지의 시간 - 버튼 클릭해 이동

 

😲 다양한 렌더링 기법

CSR Client Side Rendering : 브라우저에서 js 를 이용해 동적으로 페이지를 렌더링

• 순수 리액트 사용했을 때 방식
• 렌더링 주체 : 클라이언트
• 최초 로드가 끝나면 사용자와의 상호작용이 빠르고 부드럽다.
• 서버에게 추가 요청을 보낼 필요가 없어 사용자 경험이 좋다.
• 서버 부하가 적다
• 하지만 첫 페이지 로딩 시간(TTV)이 길 수 있다.
• html 이 비어있기 때문에 검색 엔진 최적화(SEO)에 불리하다.

SSR Server Side Rendering : 빌드 시점에 모든 페이지를 미리 생성해 서버 부하를 줄임

• 렌더링 주체 : 서버
• 클라이언트가 요청하면 리렌더링
  클라이언트 ➡️ 서버 "이 페이지 줘!"
  서버 ➡️ 클라이언트 "(데이터베이스 읽고 등등 한 후) HTML 파일 제공"
• 빠른 로딩 속도(TTV)
• 높은 보안성
• SEO 에 유리
• 마이페이지처럼 데이터 의존 페이지 구성 가능
• CDN(Content Delivery Network) 캐싱 불가
• 사이트의 콘텐츠가 변경되면 전체 사이트를 다시 빌드해야하는데, 그 과정이 오래 걸릴 수 있다.
  ➡️ 서버 과부하
• 요청할 때마다 페이지를 만들어야 한다.

SSG Static Site Generation : 서버에서 페이지를 렌더링해 클라이언트에게 HTML 을 전달

• 렌더링 주체 : 서버
• 최초 빌드시에만 생성이 됨
• 사전에 미리 정적페이지를 여러개 만들어놓음
  ➡️ 클라이언트가 홈페이지 요청을 하면, 서버는 만들어져있는 사이트를 바로 제공! 클라이언트는 표기만 함!
• TTV 가 매우 짧아 빠르게 페이지를 볼 수 있다.
• SEO 에 유리
• CDN(Content Delivery Network) 캐싱 가능
• 정적인 데이터에만 사용 가능
• 사용자와의 상호작용이 서버 통신에 의존하므로, CSR 보다 상호작용이 느릴 수 있다.
• 서버 부하가 클 수 있다.
• 마이페이지처럼 데이터에 의존하는 화면 렌더링에 사용 불가

ISR Incremental Static Regeneration : SSG 처럼 정적 페이지를 제공하지만 설정한 주기마다 페이지를 다시 생성

• 렌더링 주체 : 서버
• 정적 페이지를 먼저 보여주고, 필요에 따라 서버에서 페이지를 재생성
• 정적 페이지를 먼저 제공하니 사용자 경험이 좋다.
• 콘텐츠가 변경되었을 때 서버에서 페이지를 재생성하니 최신 상태를 그나마 유지할 수 있다.
• CDN 캐싱 가능
• 동적인 컨텐츠를 다루기에 한계가 있을 수도? 결국 실시간 페이지가 아니니
• 마이페이지처럼 데이터에 의존하는 화면 렌더링에 사용 불가

	CSR	SSR	SSG	ISR
빌드 시간	짧다	짧다	길다	길다
SEO	나쁘다	좋다 (미리 렌더링되니)	좋다 (미리 렌더링되니)	좋다 (미리 렌더링되니)
페이지 요청에 따른 응답 시간	보통	길다	짧다 (빌드가 길므로)	짧다 (빌드가 길므로)
최신 정보인가?	맞다	맞다	아니다	그럴 수도?

 

😲 Hydration ?

: HTML 코드와 JS 코드를 매칭시켜 동적인 웹사이트를 브라우저에 렌더링

 

CSR

: 모든 파일을 받아와 화면 렌더링 빈 HTML 에

JS 파일이 모두 다운되야지만(hydration 되야지만) 최종 소스코드를 볼 수 있다.

(하지만 CSR의 과정에서의 Hydration 과정을 Hydration으로 볼 것이냐 하는 것은 이견이 있을 수 있다고 합니다..)

 

SSR

: 서버에서 사용자의 요청이 있을 때마다 페이지를 새로 그려 사용자에게 제공

• pre-rendering : 사용자와 상호작용하는 부분을 제외한 껍데기만 먼저 브라우저에 제공! TTV 짱 빠름!
• hydration : 이 과정이 일어나기 전엔 껍데기만 있는 HTML 이기 때문에 사용자가 버튼을 클릭해도
  아무 동작이 일어나지 않는다. 익터렉션에 필요한 모든 파일을 받는 과정, hydration 이 끝나야 인터렉션이 가능해진다.
  이 간극 ! TTI 를 줄이는게 관건이다!

SSG, ISR 도 SSR 과 마찬가지로 hydration 과정이 존재한다.

 

 

🫠 그럼 시작해보자..

npx create-next-app@latest

현재 폴더에 프로젝트를 생성하려면 npx create-next-app@latest .

하위 폴더 중 원하는 폴더에 프로젝트를 생성하려면 npx create-next-app@latest '폴더명'/

설정 ~

 

순수 리액트와는 달리 폴더 안 page 가 하나의 Route 가 된다!

 

 

 

🔗 https://akku-dev.tistory.com/21

캐시(Cache)와 CDN(Content Delivery Networks)

🔗 https://velog.io/@whitecloud94/%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC-vs-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC

프레임워크 vs 라이브러리