[TIL] Next.js

혱·2023년 12월 22일

TIL next.js

TIL

목록 보기

62/85

React는 UI를 편리하게 만들어주는 라이브러리
Next.js는 React를 사용하여 Web을 만드는 프레임워크

📌 참고

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

프레임워크 : 개발을 단순화하기 위한 뼈대나 구성을 제공해주는 코드의 집합

Next.js 를 사용하는 이유

Full Stack을 가능하게 해준다.
파일을 베이스로 한 Routing을 해준다.
SEO, Image, Font 최적화를 해준다.
Server Side Rendering, Static Site Generation 을 가능하게 해준다.
하이브리드 렌더링을 가능하게 해준다.

Next.js가 제시한 6가지 특징

복잡한 설정 없이 사용하기 편하게 해줄게
JavaScript 만으로 FE, BE 다 하게 해줄게
자동으로 코드스플리팅 해주고, SSR 가능하게 해줄게
- 코드 스플리팅 : 웹페이지의 로딩 시간을 최적화하기 위한 기법 중 하나로, 전체 코드를 한 번에 로딩하는 대신, 필요한 부분만 분할하여 로딩하는 방식을 말한다. 일반적으로 웹사이트를 방문할 때 해당 웹사이트의 전체 코드를 한 번에 다운로드 받는다. 그런데 이렇게 되면 사용자가 실제로 방문하지 않을 수도 있는 페이지의 코드까지 불필요하게 다운로드 받게 되어 초기 로딩 속도가 느려질 수 있다. 이를 해결하기 위해 코드 스플리팅을 사용하면, 사용자가 실제로 필요로 하는 부분만 우선 로딩하고, 나머지는 필요할 때 로딩하게 된다.
다양하게 (언제, 어디서나, 어떻게, 얼마나) data-fetching 하게 해줄게
- data fetching의 주기를 입맛대로! -> 1번 / 일정 주기 / 영구적으로
요청사항을 예상 가능하게 해줄게
- 사용자가 보는 부분에서 필요한 것만 예측해서 똑똑하게 먼저 받아오겠다.
배포 쉽게 하게 해줄게
- 기존 => FE : vercel, BE : aws ac2 / next.js => FE+BE : vercel

Next.js가 등장한 배경

React는 CSR (Client Side Rendering)을 제공하는데, CSR에는 다음과 같은 단점이 있다.

FCP(First Contentful Paint) (초기 화면이 보이는 시간) 이 길다.
보안에 취약하다. (클라이언트 단에서 파일들을 가지고 있어야 하므로)
CDN (Content Delivery Network) 캐시가 안된다.
SEO (검색 엔진 최적화) 가 안좋다. (빈 HTML 이므로)
자바스크립트가 필수적이다. (사용자가 브라우저에서 자바스크립트를 비활성화 하면 아무것도 못한다.)

그래서 Next.js는 SSG (Static Site Generation)를 제공한다.
SSG는 빌드할 때 렌더링을 한다. 그래서 처음 브라우저가 서버에 요청했을 때 CSR 처럼 빈 HTML 파일이 오는 게 아니라 이미 필요한 데이터들, 화면을 다 그린 HTML을 응답받는다. 그러먼 다음과 같은 장점이 있다.

처음에 자바스크립트 파일 등 다른 파일을 다운받을 필요가 없으니 초기 로딩 속도가 빠르다.
보안에 좋다 (클라이언트 단에서 다운받을 파일이 없고, 그 파일은 서버에 있으므로)
CDN에 캐시가 되어서 나중에 다시 요청해도 빠르게 응답받을 수 있다.
SEO에 좋다. (빈 HTML이 오는 것이 아닌 다 들어있는 HTML을 받으므로)
자바스크립트가 없으도 빌드할 때 다 그려주니까 화면을 보여줄 수 있다.

그러나 빌드할 때 렌더링이 되므로 데이터들이 정적이고, 모든 사용자에게 동일한 내용을 보여줘야 한다는 단점이 있다.
그러면 최신화 된 데이터들을 받으려면 어떻게 해야 할까?

이를 위해 ISR (Incremental Static Regeneration) 이 존재한다.
이는 주기를 정해서 페이지를 다시 생성하는 것을 말한다.
그래도 실시간 데이터가 아니고 사용자 별로 다양한 데이터를 보여줄 수 없다는 문제가 있다. 주기를 실시간 수준으로 하게 된다면 서버에 무리가 많이 간다.

이는 SSR (Server Side Rendering) 으로 해결할 수 있다.
SSR은 빌드 시에 HTML 파일을 만들지 않고 클라이언트에서 요청할 때 HTML을 만들어서 보내주는 것이다. 그러므로 다음과 같은 장점이 있다.

최신의 데이터를 보여준다. (요청할 때 만들기 때문에)
사용자마다 다른 데이터를 보여줄 수 있다. (요청한 사람이 누군지 알기 때문에)

그러나 여전히 다음과 같은 단점도 있다.

SSG, ISR 보다 비교적 느리다. (요청할 때 만들기 때문에)
서버에 과부하가 일어날 수 있다. (서버에 요청이 많아지면)
CDN 캐싱이 안된다. (요청할 때마다 만들기 때문에)

Next.js는 page 특징에 맞게 필요한 렌더링 방식을 섞어서 사용할 수도 있다.

Next.js는 사용자에게 빠르게 화면을 보여주기 위해 정적인 HTML을 pre-rendering 해서 보여준다. 이 정적인 HTML은 JavaScript 코드가 없기 때문에 사용자의 인터렉션이 불가능하다. 그래서 클라이언트는 정적인 HTML 파일을 먼저 받고, 리액트 코드나 자바스크립트 코드를 나중에 받아서 이미 받은 HTML 안의 DOM 요소들 위에 다시 렌더링이 되면서 자바스크립트 코드가 입혀지면서 동적인 웹으로 바뀌는 것이다. 이를 Hydration (수화) 라고 한다.

출처: https://jaebong8it.tistory.com/45

CSR (Client Side Rendering)

CSR (Client Side Rendering) 이란 브라우저에서 표기하기 위한 모든 코드들을 클라이언트 측에서 다운받아서 코드를 실행하고 분석해서 표기하는 것을 말한다.

특징

순수 리액트를 사용했을 때 CSR 방식으로 렌더링된다.
브라우저에서 JavaScript를 이용해 동적으로 페이지를 렌더링하는 방식이다.

장점

한번 로딩되면 빠른 UX 를 제공하고, 서버의 부하가 적다.

단점

사용자가 처음으로 페이지를 보기까지 페이지 로딩 시간(TTV:Time To View)이 길다.
자바스크립트 활성화가 필수적이다.
SEO 최적화가 힘들다 -> UI 요소가 HTML에 없기 때문에
보안에 취약하여 CDN에 캐시가 안된다.

코드

import React from 'react';
import ReactDOM from 'react-dom';

function App() {
  return <h1>Hello, Client Side Rendering!</h1>;
}

// index.js
ReactDOM.render(<App />, document.getElementById('root'));

SSG (Static Site Generation)

SSG (Static Site Generation)은 렌더링하는 주체가 서버이다. 어플리케이션을 서버에 배포해서 처음 빌드할 때 렌더링이 된다.

특징

서버에 페이지를 렌더링하여 클라이언트에게 HTML을 전달하는 방식이다.
최초 빌드 시에만 생성이 된다.
사전에 미리 정적 페이지를 여러개 만들어 놓는다. -> 클라이언트가 홈페이지에 요청을 하면 서버는 이미 만들어져있는 사이트를 제공한다. -> 클라이언트는 표기만 한다.

장점

페이지 로딩 시간 (TTV) 이 짧아 사용자가 빠르게 페이지를 볼 수 있다.
SEO 가 좋다.
보안이 뛰어나다.
CDN(Content Delivery Network) 에 캐시가 된다.

단점

정적인 데이터에만 사용할 수 있다.
사용자와의 상호작용이 서버와의 통신에 의존하므로 CSR 보다 상호작용이 느릴 수 있다. 또한 서버 부하가 클 수 있다.
마이페이지 와 같이 데이터에 의존하여 화면을 그려주는 경우 사용 불가능하다.

코드

import React from 'react';

function HomePage({ data }) {
  return <div>{data}</div>;
}

export async function getStaticProps() {
  const res = await fetch('https://...'); // 외부 API 호출
  const data = await res.json();

  return { props: { data } };
}

export default HomePage;

ISR (Incremental Static Regeneration)

ISR (Incremental Static Regeneration) 은 렌더링 하는 주체는 여전히 서버지만, 주기적으로 렌더링을 한다. 설정한 주기만큼 계속해서 페이지를 다시 만들어 준다.

특징

SSG 처럼 정적 페이지를 제공한다.
설정한 주기만큼 페이지를 계속 생성해 준다.
- 예) 설정한 주기가 10분 -> 10분 마다 DB 또는 외부 영향에 의해 변경된 사항을 반영
정적 페이지를 먼저 보여주고, 필요에 따라 서버에서 페이지를 재생성하는 방식

장점

페이지 로딩 시간 (TTV) 이 짧아 사용자가 빠르게 페이지를 볼 수 있다.
SEO 가 좋다.
보안이 뛰어나다.
CDN(Content Delivery Network) 에 캐시가 된다.
데이터가 주기적으로 업데이트 된다.

단점

실시간 데이터가 아니다. (동적인 콘텐츠 다루는데 한계 존재)
사용자 별로 달라지는 정보를 제공하기 어렵다. (ex. 마이페이지)

코드

import React from 'react';

function HomePage({ data }) {
  return <div>{data}</div>;
}

export async function getStaticProps() {
  const res = await fetch('https://...'); // 외부 API 호출
  const data = await res.json();

  return { 
    props: { data },
    revalidate: 60, // 1초 후에 페이지 재생성
  };
}

export default HomePage;

SSR (Server Side Rendering)

SSR (Server Side Rendering) 은 렌더링 하는 주체가 마찬가지로 서버이다. 하지만 SSR 은 미리 렌더링을 하는 것이 아니라 클라이언트 요청 시 렌더링을 하여 결과를 보여준다.

특징

SSG, ISR 처럼 렌더링 주체가 서버이다.
클라이언트의 요청 시 렌더링 한다.

장점

페이지 로딩 시간 (TTV) 이 짧아 사용자가 빠르게 페이지를 볼 수 있다.
SEO 가 좋다.
보안이 좋다.
실시간 데이터를 사용하므로 최신 데이터 반영한 HTML을 받을 수 있다.
요청하는 사람이 누구냐에 따라 사용자 별 필요한 데이터를 사용할 수 있다. (ex. 마이페이지)

단점

요청할 때마다 서버에서 렌더링을 해서 클라이언트에 보내기 때문에 비교적 느릴 수 있다.
서버의 과부하가 걸릴 수 있다. (서버의 오버헤드가 높아진다.)
요청할 때마다 페이지를 만들어야 하기 때문에 CDN 에 캐시가 안된다.

코드

import React from 'react';

function HomePage({ data }) {
  return <div>{data}</div>;
}

export async function getServerSideProps() {
  const res = await fetch('https://...'); // 외부 API 호출
  const data = await res.json();

  return { props: { data } };
}

export default HomePage;

Hybrid Web App

특정 목적을 달성하기 위해 단 하나의 렌더링 방식이 아닌, 두 개 이상의 렌더링 방식을 결합하여 사용하는 것

웹 어플리케이션에서 이처럼 페이지 특징 별로 가장 최적화된 렌더링 방식을 선택해서 만들어 나갈 수 있으며, 한 페이지 내에서도 페이지 부분 별로 렌더링 방식을 섞어서 하이브리드 방식으로 만들 수 있다.

Hydration

서버에서 렌더링 된 정적 HTML을 브라우저에서 동적으로 다시 렌더링하는 과정
서버에서 렌더링 된 정적 페이지가 클라이언트에서 JavaScript에 의해 동적인 웹페이지로 변화하는 과정
하이브리드를 가능하게 해주는 것이 Hydration 이다.

혱

느리더라도 조금씩, 꾸준히

이전 포스트

[TIL] React Query 심화

다음 포스트