Next.js 정리 + 아키텍쳐

Background SSR vs SSG vs CSR TTFB(Time to First Byte)FCP(First Contentful Painting)TTI(Time to Interactive)SSG에 대한 오해 Next.js 배포 아키텍쳐 References

Background

원티드에서 주관하는 7월 프리온보딩 챌린지를 통해 Next.js에 대한 이해를 조금씩 하고 있는 중이다. 아직까지는 조각조각 흩어져있는 느낌이 들어 배운 내용들을 정리해보려고 한다.

시작하기 전, 항상 염두해야 할 점은, Next.js가 결국 React 기반 프레임워크라는 것이다. Next.js와 React를 너무 분리해서 생각했던 것 같다.

SSR vs SSG vs CSR

앞선 아티클에서 계속 언급했던 Server Side Rendering과 Client Side Rendering의 차이를 다루지는 않을 것이다. 해당 내용에 대해서는 어느 정도 이해를 했다고 생각하고, 이를 기반으로 웹 성능 지표에서의 차이점을 확인해볼 것이다.

우선 아래의 사진들은 이런 주제에서 교과서 같은 web.dev 에서 가져온 앱 실행 과정이다.

Client Side Rendering

Server Side Rendering (사실 SSR과 SSG의 차이는 서버 로직이 있느냐 없느냐의 차이.)

Static Site Generation

사진에 여러가지 지표를 나타내는 FCP, TTI 등을 확인할 수 있는데, 조금 더 자세히 알아보자.

TTFB(Time to First Byte)

HTTP 요청을 했을 때 첫 byte(정보)가 브라우저에 도달하는 시간 (서버의 성능 척도이다. FCP와 헷갈릴 수 있는데, TTFB가 빠르다고 해서 FCP가 빠르지는 않다.)

CSR - HTTP 요청이 들어오면 빈 화면을 제공하면 되기 때문에 비교적 TTFB가 빠르다.

SSR - HTTP 요청이 들어오면 서버에서 페이지를 렌더링해서 제공하기 때문에 비교적 느리다.

FCP(First Contentful Painting)

페이지가 로드되기 시작한 시점으로부터, 컨텐츠 일부가 화면에 렌더링 되기 시작한 시점의 시간

CSR - 빈 화면이 제공된 후에 JavaScript 번들 파일들을 한꺼번에 다운로드 하기 때문에 비교적 느리다.

SSR - 서버에서 페이지를 렌더링해서 제공하기 때문에 비교적 빠르다.

TTI(Time to Interactive)

사용자와 상호작용할 준비가 된 시점

CSR - 서비스에 필요한 모든 JavaScript 번들 파일들을 한꺼번에 다운받기 때문에 비교적 느리다.

SSR - 해당 페이지에 필요한 JavaScript 번들 파일들만을 다운받기 때문에 비교적 빠르다. 하지만, SSR도 마찬가지로 번들 사이즈가 커지면 TTI가 느려질 수 있다.

Client Side Rendering의 단점들을 Server Side Rendering이 완벽하게 보완하지는 못하는 것 같다. 매 요청마다 서버에서 페이지를 렌더링하기 때문에, 서버의 부하 위험도 존재한다. SSR도 지니고 있는 한계를 SSG(Static Site Generation)이 보완을 해주는데, SSG는 SSR과 달리


Static Site Generation은 빌드 타임에 데이터를 받아와 HTML 파일을 미리 생성하고, 유저가 접속하면
만들어진 HTML을 제공한다.

하지만, 실제로 위의 설명처럼 작동하지 않을 때가 있다. 이 설명은 틀린 것일까?

SSG에 대한 오해

해당 내용은 이 분의 블로그(링크)를 읽고 그 동안 SSG에 대해서 제대로 알지 못했구나를 깨닫고 정리하는 내용이다. 이 아티클을 작성한 분께 너무나도 감사하다.

운영하고 있는 블로그 페이지의 리소스들을 확인하면서 살펴보자. 블로그의 각 아티클들의 데이터는 업데이트될 일이 거의 없기 때문에 ISR(Incremental Static Generation)으로 구현되어있다.

ISR은 정적 증분 생성으로, SSG와 같이 동작하지만, 사용자가 정한 시간에 한 번씩 revalidation을 하여 데이터를 새로 불러온다.

해당 페이지의 리소스들을 살펴보면 다음과 같이 HTML파일을 받는다.

클릭 이벤트를 통해 해당 페이지로 들어오면 SSG가 정의한 내용과 달리 HTML이 아닌 SSR처럼 JSON을 받아오는 것을 확인할 수 있다.

정리를 하자면, 두 가지 케이스로 나눌 수 있다.

새로고침 or url 통해 SSG 페이지로 이동 → HTML 받아옴

클릭 이벤트를 통해 이동 → JSON 받아옴

따라서, 2번 상황에서도 SSG의 이점을 얻기 위해서는 next/link의 Link 태그, prefetch 속성을 활용하면 된다.

Next.js 배포 아키텍쳐

Next.js 배포 아키텍쳐로 굉장히 유명한 사진이 있다.

SSR과 SSG 페이지는 결국 서버가 반드시 필요한가, 필요하지 않은가로 구분할 수 있다.

SSR - 사용자의 요청 시점에 서버 사이드의 로직이 필요하기 때문에, 서버가 반드시 필요하다.

→ AWS EC2 혹은 서버리스 서비스인 AWS Lambda를 활용하면 된다.

SSG - 서버가 있으면 활용하고, 없어도 상관없다.

→ 서버가 있다면 SSR과 동일하고, 그렇지 않다면 CDN 역할을 하는 AWS Cloudfront와 AWS S3를 활용할 수 있다. 모두 AWS EC2에 올리는 것도 상관 없으나, 정적인 파일들은 CDN을 활용하여 사용자와 가깝게 하는 것이 성능 상 좋다.