렌더링 패턴 ( ISR )

ISR ( Incremental Static Regeneration )

• Next.js에서 사용하는 렌더링 전략으로, 정적 생성(Static Generation)과 서버 사이드 렌더링(Server-side Rendering)의 장점을 절묘하게 조합한 렌더링 방식 입니다.
  • 자주 방문할 페이지는 빌드 시 미리 static rendering 방식으로 생성
  • 나머지는 요청이 들어올 때마다 동적으로 server side rendering 으로 생성
  • 이후 캐시에 저장해서 다시 요청이 들어오면 정적 페이지처럼 빠르게 제공합니다.
• Next.js 에서는 getStaticProps() 와 getStaticPaths() 메서드를 통해 구현됩니다.
  • getStaticProps – 정적 생성 + ISR 설정
    • 페이지 빌드 시 params.id에 해당하는 데이터를 미리 API로 fetch해서 listing 정보를 가져와서 정적으로 렌더링을 합니다.
    • 이 페이지는 60초 동안은 캐시된 정적 페이지를 그대로 사용하고 60초가 지나고 누군가 다시 이 페이지에 요청을 보내면, 기존 정적 페이지를 그대로 응답하고 백그라운드에서 새로운 데이터를 fetch해서 새로 정적 페이지를 생성합니다. 그리고 다음 요청부터는 그 새로 생성된 정적 페이지가 사용됩니다.
  • getStaticPaths – 어떤 페이지를 미리 생성할지 설정
    • 이 함수는 빌드 시 어떤 id를 갖는 페이지를 미리 생성할 것인지 정합니다.
    • fallback: 'blocking' 은 요청 시 서버가 동기적으로 페이지를 먼저 만든 후, 완성된 HTML을 한 번에 응답합니다.

import { Listings, ListingsSkeleton } from "../components";

export default function Listing(props) {
  return <ListingLayout listings={props.listing} />
}

export async function getStaticProps(props) {
  const res = await fetch(`https://my.cms.com/listings/${props.params.id}`);
  const { listing } = await res.json();

  return { props: { listing },  revalidate: 60,}
}

export function getStaticPaths() {
  const res = await fetch(`https://my.cms.com/listings?limit=20`);
  const { listings } = await res.json();

  return {
    params: listings.map(listing => ({ id: listing.id })),
    fallback: 'blocking'
  }
}

ISR 동작 과정

1. 사용자가 웹사이트에 접속합니다.

2. CDN은 자신이 가진 캐시 중 해당되는 정적 Html을 확인하고 반환한다.

3. CDN 캐시에 해당되는 정적 HTML에 없으면 서버에서 정적 HTML 생성 한 뒤 CDN 캐시에 저장하여 사용자에게 완성된 HTML을 반환한다.

4. 자바스크립트 번들이 다운로드되고 hydration 단계를 거칩니다.

• JS가 로드되어 실행되면, 기존 HTML에 이벤트 리스너를 연결되어 페이지가 인터랙티브하게 변함. 이 과정을 Hydration이라고 합니다.

장점

• 수천 개 페이지를 전부 미리 렌더링하지 않아도 되므로, 빌드 시간이 줄어듭니다.
• 정적 페이지로 제공되므로, 대부분의 사용자에겐 빠른 응답 속도를 보장하며, revalidate 설정에 따라 자동으로 최신화되므로 최신성도 챙길 수 있습니다.
• 최초 생성된 페이지는 정적 HTML이라서 Static Rendering 과 마찬가지로 SEO 최적화에 유리하다.
• 렌더링된 정적 HTML은 CDN에 저장되어 글로벌 사용자에게 빠르게 전송 가능합니다.
• 한 번 렌더링된 페이지는 다시 렌더링할 필요가 없어서 서버 부하 감소시킵니다.

단점

• 아직 생성되지 않은 페이지에 대해 처음 요청할 때는 느릴 수 있습니다.
  • 아직 생성되지 않은 페이지를 처음 요청하면, 서버에서 바로 렌더링을 시작합니다. 이 때는 정적 페이지처럼 빠르지 않고, 서버 사이드 렌더링처럼 느려질 수 있습니다. 페이지 생성이 끝나야 사용자에게 응답하므로 첫 요청자에게는 대기 시간이 발생합니다.
• 백그라운드 갱신이 실패할 수 있습니다.
  • revalidate 시간 이후 백그라운드에서 페이지 재생성 중 오류가 나면 기존 stale 페이지가 계속 유지되어 사용자에게 이전 정보가 계속 노출될 수 있습니다.
• 캐시 갱신 시점 제어의 어려움이 있습니다
  • revalidate 값은 초 단위로 지정되지만, 정확히 그 시점에 갱신되는 게 보장되진 않습니다. 사용자 요청 시점에만 재생성이 발생합니다.

Web Vitals

Lighthouse / Web Vitals

 

ISR 과 Web Vitals

• 처음 요청되는 ISR 페이지의 경우, 페이지가 아직 존재하지 않기 때문에 사용자에겐 빈 UI를 먼저 보여줍니다. 따라서, FCP가 빠르게 측정되고, LCP는 진짜 콘텐츠가 보여질 때까지 지연됩니다.
• 정적 생성된 페이지 (미리 렌더링된 페이지)의 경우, Static Rendering 처럼 빠른 FCP, LCP가 측정됩니다.
  • FCP ( First Contentful Paint ) : 브라우저에 최초로 콘텐츠를 화면에 렌더링한 시점
  • LCP ( Largest Contentful Paint ) : 가장 큰 콘텐츠 요소(주로 이미지, 텍스트 블록 등)가 화면에 표시되는 시간