페이지 로딩 속도 개선

사실 이전에 페이지 로딩 속도 개선한다고 SSR 적용하고, 조금 느린점에 대해서는 loading 처리로 대기하도록 처리했었는데, 더 개선이 필요하다는 생각이 들었다.

문제

왜냐하면 페이지에서 조회가 느린 페이지(block 이 많은)로 이동할 때, loading 처리로 넘어가기 이전에 조회를 먼저 거치면서 서버에서 응답이 없는 듯한, 페이지 이동이 되고 있는지 모르겠는 상태가 확인되었기 때문이었다.

원인은 app 디렉토리 하위에 바로 loading.tsx 를 적용하였는데, 거의 최상위 layout.tsx 와 같이 적용해두면서, 그 하위 route 간의 이동에만 적용되는 loading 이 되었다. 조금 더 풀어서 설명하면, 내 프로젝트는 크게 2 route 로 구분된다.

이렇게 구분하는데 최상위 계층에 적용한 loading.tsx 내용은 mention 과 posting 간의 이동에만 적용되었다. 즉, 같은 route 안에 묶이는 posting → posting 페이지 간의 이동에는 적용되지 않아, loading.tsx 적용이 되지 않아 마치 서버가 응답이 없는 듯한 느낌을 주었다.

해결

해결 방법은 단순하게 posting/[slug] route 에도 loading.tsx 파일을 적용해주면 간단하게 원래 원하는 방식으로 동작한다.

SSG 적용

처음에는 여기까지 문제를 인식하기 보단 loading.tsx 내용이 제대롤 적용되지 않는 것 겉아, notion API 요청 응답값을 저장하는 캐싱방식으로 적용하여 전체적인 페이지 로딩 속도를 개선하고, notion API 요청 자체도 줄일까 했다.

그래서 Gemini 에 SWR, React Query 등으로 fetch 요청에 캐싱을 거는건 어떤지 물어보고 더 나은 개선방안을 문의하니, 그것도 좋지만 SSG 방식을 고려하는것도 좋다고 했다. 생각해보니 블로그 내용이 자주 변경되는게 아니고, 오히려 빌드 과정에서 미리 만들어두고 TTL 처럼 특정 시간이 지나면 refresh 되는게 훨씬 사용자 경험에 좋을 것 같아, SSG 방식을 적용하기로 했다.

방법은 단순하게 page.tsx 파일에 generateStaticParams 함수를 만들어주면 된다.

// SSG를 위한 generateStaticParams 함수
export async function generateStaticParams() {
  const posts = await getPublishedPosts(); // 모든 게시물 가져오기

  // 각 게시물의 slug를 기반으로 params 배열 생성
  return posts.map((post) => ({
    slug: post.slug,
  }));
}

이렇게 app/posting/[slug] 부분에 들어가는 slug 부분에 대해 정적으로 어떻게 적용되는지 정의해주면 빌드시에 자동으로 정적으로 생성해준다.

하지만 내가 관리하는 페이지가 적은 편이라서 아직까지 빌드에 오래걸리지 않는 편이지만, 블로그로 정말 많은 페이지를 관리하는 사람이라면 나중에 얼마나 걸릴지는 모르겠다. 대략 이번 배포에서 Vercel 로깅 내역을 봤을 때는 페이지 당 1.5초 가량 걸리는 것으로 보인다.

결과

당연히 이미 페이지를 모두 그려둔걸 가져오기 때문에 속도는 정말 미친듯이 빠를 수 밖에 없다. 해당되는 모든 페이지의 LCP(Largest Contentful Paint) 수치를 0.5s 대로 관리할 수 있다.

사실 SSG 적용하면서 위에 언급한 posting/[slug] route 하위의 loading.tsx 를 적용하는건 크게 의미가 없어지긴했다. 그럼에도 적용해두는걸 추천하긴 한다. 왜냐하면 로컬에서 개발용도로 npm run dev 로 개발을 진행할 때는 SSG 를 적용해주지 않기 때문에 답답함을 느낄 수 있다.