https://nextjs.org/learn/dashboard-app/static-and-dynamic-rendering
이전 탭터에서 데이터 패칭을 했지만 두개의 한계점이 있었다.
1. 데이터 요청이 의도적이지 않은 waterfall 을 만듦
2. 대시보드가 정적이기 때문에 업데이트가 앱에 반영되지 않음
In this chapter...
정적 렌더링의 정의와 이것이 앱 성능을 향상시키는 법
동적 렌더링의 정의와 언제 사용하는지
대시보드를 정적으로 만드는 여러 방법
느린 데이터 페치 후 무슨 일이 일어나는지 보기
What is Static Rendering?
정적 렌더링 시, 데이터 페칭과 렌더링은 빌드 타임 (배포)혹은 재검증 시 서버에서 일어난다. 결과는 CDN으로 배포, 캐시 된다.
앱 방문 시, 저장된 캐시가 serve 된다
정적 렌더링의 장점
- 빠른 앱
: 미리 렌더된 컨텐츠는 캐시되고 전역으로 배포된다. 이것은 용자가 앱 컨텐츠에 빠르게 접근하게 한다. - 서버 로드 감소
: 컨텐츠가 캐시되었기 때문에, 서버는 각 유저 요청마다 컨텐츠를 동적으로 생성할 필요가 없다 - SEO
: 미리 로드 된 컨텐츠는 페이지 로드 시 이미 available해서, 서치 엔진 크롤러가 인덱스 하기 쉽다. 이것은 서치 엔진 랭킹 향상을 일으킨다.
정적 렌더링은 블로그 포스트 | 상품 페이지처럼 데이터가 없거나 사용자 전반에게 공유된 데이터일 때 UI에 유용하다.
이것은 정기적으로 업데이트 되는 개인 맞춤형 데이터를 가진 대시보드에는 잘 맞지 않는다.
정적 렌더링 <=> 동적 렌더링
What is Dynamic Rendering?
컨텐츠는 요청 시간에 각 유저에 대해 서버에서 렌더된다(페이지 방문 시).
정적 렌더링의 이점
- 실시간 데이터
: 동적 렌더링은 실시간 | 빈도수 높게 업데이트 되는 데이터를 표시한다.
데이터가 자주 변경되는 앱에 이상적 - 사용자 특화 컨텐츠
: 개인 맞춤형 컨텐츠 전달과 사용자 상호작용 기반 데이터 업데이트에 적합나다. - 시간 정보 요청
: 쿠키, URL 서치 인자 등 요청 시에만 알 수 있는 정보에 접근 가능하게 한다.
Making the dashboard dynamic
기본적으로, @vercel/postgres는 고유한 캐싱 시맨틱을 설정 안 하고, 이것은 프레임워크가 고유한 정적, 동적 행위를 설정하게 한다.
서버 컴포넌츠 | 데이터 페칭 함수 안에서 unstable_noStore라고 불리는 API를 통해 정적 렌더링 해제를 할 수 있다.
data.ts에서, unstable_noStore를 next/cache로부터 불러오고 함수 상단에서 호출한다.
Simulating a Slow Data Fetch
대시보드를 정적으로 만드는 것은 좋은 첫 걸음이지만, 하나의 문제점이 있다.
만약 한 데이터 요청이 다른 요청보다 늦어진다면?
Slow Data Fetch를 시뮬레이션 해보자.
data.ts 파일에서, fetchRevenue() 안의 console.log, setTimeout()을 주석 해제 한다.
이제 http://localhost:3000/dashboard 를 새 탭에서 열고 페이지가 얼마나 걸리는지 본다. 터미널엔 다음과 같이 찍힌다.
인위적으로 3초 딜레이를 만들어봤다.
결과는 데이터가 페치되는 동안 전체 페이지가 블락 되는 것으로 보여진다.
동적 렌더링을 적용하면, 앱은 데이터가 가장 늦게 페치되는 만큼의 속도를 보인다.
