지금 주인장은 Nest.js 공부 중 ···
Sign In
리캡

Stale While Revaildate (SWR), Prerender(ISR) 사용하면서..

현우
Created by
  • 현우
Created at
카테고리
Empty
실제로 내 다이어리 페이지에 렌더링 전략을 수정해보려고 적용하면서 기록을 해본다.
SWR: true (기본 값 1초) : 그냥 페이지 짧게 캐싱해주고, 데이터 패치로 재검증 느낌
SWR: ${sec} : 해당 sec 만큼 캐싱을 해줌
Prerender : Next의 SSG 느낌 (빌드 시에 정적 페이지를 생성)
SSR: true로 하게 되면 $fetch 코드가 존재할 때, 서버와 클라이언트 매번 페이지로 돌아올 때마다 둘 다 실행을 하게 되는데, SWR에 sec를 설정하게 되면 $fetch의 서버, 클라이언트 실행이 서버에서만 한번 실행되고, 다음 요청부터는 서버 요청은 캐시 상태로 더이상 요청을 안하고 클라이언트만 요청을 하게 됨
(당연히 useFetch는 SSR에서만 동작하기에, 캐시가 되지 않고)
그리고 아래 옵션을 넣으면 useFetch도 클라이언트에서만 실행되게 할 수 있음
useFetch('/api/todos', { server: true }) // SSR에서 실행 → HTML에 데이터 포함 → SWR 캐시에 포함 useFetch('/api/todos', { server: false }) // 클라이언트에서 실행 → SWR 무관, 매번 fresh useFetch('/api/todos') // 기본값 = server: true server: false를 쓰는 경우는 보통: - 로그인한 유저 전용 데이터 (SSR에서 인증 컨텍스트가 없을 때) - 빌드/SSR 시점에 굳이 가져올 필요 없는 데이터
/user/${uid} 형태로 페이지를 구성했어서, nuxt.config.ts 에도 아래와 같이 렌더링 전략을 구성했었는데..
routeRules: { "/user/**": { prerender: true }, "/": { prerender: true }, "/login": { prerender: true }, },
근데 "/user/**" 으로 하면 동적 유저 페이지에도 모두 정적으로 생길거라고 생각했었음.. prerender 는 빌드 시점에 정적 페이지를 만들기 때문에 사용자가 늘어날 때마다 빌드를 하는 것은 비효율적이기 때문에 swr 이 좋은 선택이라고 판단했다. (swr은 첫 요청에 자동으로 캐시가 만들어지기 때문에)
근데 내가 Next 공부할 때는 ISR을 적용해도 정적 페이지가 파일 시스템에 저장되었던 기억이 있는데..
Nuxt는 아무리 SWR을 적용해도 파일 시스템에 정적 파일로 저장이 되지를 않는다.
Next는 .next/ 파일 시스템에 캐시 형태로 페이지가 저장되지만, Nuxt SWR은 메모리로 저장이 된다.
Next는 서버 재시작 시에도 파일이 남아있지만, Nuxt SWR은 캐시가 사라진다.
Next는 Vercel CDN 같은, 엣지에 파일을 배포하지만, Nuxt SWR은 CDN 헤더로 위임한다.
👍