Next.js 에 대해 내가 이해한 부분을 정리
기본적인 SSG, SSR, CSR 의 개념
SSG (Static-Site-Generation)
Static-Site-Generation 정적 사이트 생성이란 뜻으로
완성된 html , js 캐싱 데이타를 받는다고 생각하면 된다.
이 과정은 next에서 build시 정적인 페이지를 만든다는 뜻이다
쉽게 말해 완성 된 html을 서버 캐시에 저장하여 서버 주소로 접속 시
빠르게 이미 완성 된 html을 다운받아 화면에 그려주는 것이다.
넥스트에서는 서버캐싱에 RSC 와 html을 저장하고 처음 방문 요청시 이를 빠르게 클라이언트 캐시에 저장하고 보여준다
나의 궁금증
SSG 정적페이지로 만들게 된다면 데이터 페칭과 CSR이 이뤄지면 안되는가?
즉 데이타 통신과 client component가 존재하면 안되는지?
존재해도 된다 SSG는 서버에서 정적으로 그려진 페이지다 CSC가 포함되어도
dynamic import 로 ssr 속성을 줄 수 있다.
통신 요청에서 응답 데이터의 수가 정해져 있다면
예를들어 10개의 한정된 데이터가 있고 10라는 숫자는 유한함으로
사전에 미리 10개의 SSG페이지를 생성해낼 수 있다.
클라이언트 컴포넌트를 사용 해도 SSG 페이지가 될 수 있다
다이나믹 임포트를 통해 해당 컴포넌트를 렌더링을 클라이언트에 위임할 수 있다.
결국 SSG처럼 동작하게 서버 렌더링을 클라이언트로 위임해 서버 캐싱이 이루어지게 할 수 있다.
SSG의 주요 개념은 아래와 같다
1. 캐싱을 통해 검색엔진이 파악할 수 있는 정보를 많이 만들어내서 SEO를 향상 시킬 수 있는 장점
2. 캐싱을 활용하여 페이지 로딩 속도가 빠르다
SSR (Server Side Rendering)
SSR은 SSG 를 이해하였다면 이해가 쉽다고 생각한다
SSG은 정적인 페이지를 생산하려고 헀다면
SSR은 요청시 마다 서버에서 그려주는 페이지를 뜻 한다.
데이타 통신이 들어가고 그 데이타는 자주 변경되거나 예측이 불가능 한 경우
통신을 받아온 데이타를 가지고 만든어 페이지 그려낸다
SSR 에서 통신 캐싱과 관련한 다양한 next 옵션들이 있다.
- no-store 캐시 무효
- revalidate 캐시 수명 (초)
- tag 일부 태그만 적용
CSR (Client Side Rendering)
일반적인 javascript 페이지 , 리액트의 작동을 생각하면 된다
javascript 코드로 동적으로 페이지를 그려낸다.
이 과정은 검색엔진이 페이지의 내용이 무엇인지 페이지가 로드되야 알 수 있기 때문에,
검색 엔진이 이를 파악하는데 SSG보다 불리한 편이다.
CSR 를 개선하기 위해 등작한 RSC
RSC (React Server Component) payload 값과 일부 렌더링된 html을 사용자에게 보내주고,
이를 클라이언트에서 다시 렌더링하여
hydration (일부 렌더링된 페이지에서 -> 완성된 페이지를 그리기 위한 방법) 작업을 거쳐
최종적으로 동적인 페이지를 그려낸다.
쉽게 정리해보자
- SSR, SSG는 서버에서 페이지 완성된 페이지 혹은 서버에서 완성해서 보내주는 방식이고,
- CSR은 클라이언트 즉 사용자 브라우저에서 페이지를 그려내는 것
웹의 역사를 생각해보며 정리
-
초기 웹페이지는 html이라는 마크업 언어로 이루어진 텍스트와 다른 요청 주소로 이동할 수 있는 단순한 구조였다.
-
기술의 발전으로 html 마크업 언어를 동적으로 표현하기 위해 브라우저 스크립트 문법이 탄생하였다. JavaScript로 마크업을 동적으로 표현할 수 있게 되었다.
-
기술의 발전으로 동적인 요소를 더 극적으로 표현하기 위해, 예를 들면 페이지 이동 시에 깜빡임이 없이 자연스러운 페이지를 표현하기 위해 SPA (Single Page Application) 개념이 탄생하였고 이후 리액트가 탄생했다.
-
SPA 페이지의 단점 SEO, JavaScript의 번들링 용량에 낭비를 방지하기 위해 캐싱 처리 기법들이 나왔고 SSR 개념이 탄생하였다. 이를 이용한 프레임워크가 Next.js이다.
