Next.js

Next.js 첫 진입이 느릴 때 범인 찾기: 폰트 preload, staleTime, 인증 왕복

2026.07.30 11분

Next.js 성능 최적화 next/font TanStack Query Supabase

Next.jsApp Router · RSC · MDX

개인용 라이프 관리 앱을 리디자인해서 배포한 다음 날, 이런 제보를 받았습니다.

"첫 진입할 때랑 페이지 이동할 때 너무 느려요. 한 번 들렀던 페이지는 빠른데 처음 들어가는 페이지들은 너무 느려요."

성능 이슈를 받으면 손이 먼저 움직입니다. 이미지를 줄여볼까, 번들을 쪼개볼까 하고요. 그런데 이 제보에는 쓸 만한 단서가 하나 들어 있었습니다. 한 번 들른 페이지는 빠르다. 뭔가가 캐시되고 있다는 뜻이고, 그럼 범위가 꽤 좁혀집니다.

결과적으로 원인은 네 개였습니다. 그리고 가장 큰 원인은 제가 그 리디자인에서 직접 심은 것이었습니다.

1. 무엇을 재야 하는가

"첫 진입만 느리고 재방문은 빠르다"면 후보는 대략 셋입니다.

후보	첫 진입	재방문
정적 자원(폰트·JS·CSS) 다운로드	느림	브라우저 캐시로 빠름
클라이언트 데이터 페칭	느림	쿼리 캐시로 빠름
서버 렌더링 / 미들웨어	느림	여전히 느림

세 번째는 매번 발생하니까 "재방문은 빠르다"를 설명하지 못합니다. 비용이긴 하지만 이 증상의 주범은 아니라는 뜻이죠. 1번과 2번을 먼저 봐야 합니다.

이 구분을 안 하고 들어가면 엉뚱한 곳을 파게 됩니다. 저는 여기서 브라우저 콘솔을 열었습니다.

// 이 페이지가 실제로 받아온 것들
const rs = performance.getEntriesByType('resource');
const fonts = rs.filter(r => r.name.includes('.woff2'));
const nav = performance.getEntriesByType('navigation')[0];
 
console.log({
  fontRequests: fonts.length,
  domContentLoaded: Math.round(nav.domContentLoadedEventEnd),
});

code

{ fontRequests: 197, domContentLoaded: 192 }

폰트 파일 197개. 페이지 하나 열었을 뿐인데요.

2. 원인 1: next/font의 preload가 한글을 만나면

next/font는 폰트를 자동으로 셀프호스팅해주는 좋은 도구입니다. 그리고 preload 옵션의 기본값이 true입니다. 공식 문서에도 그렇게 적혀 있습니다.

라틴 폰트라면 합리적인 기본값입니다. 서브셋이 몇 개뿐이라 미리 받아두면 텍스트가 빨리 보이니까요. 문제는 한글입니다.

한글은 글자 수가 많아서 Google Fonts가 폰트를 유니코드 범위별로 90여 개 조각으로 쪼개 제공합니다. unicode-range가 붙은 @font-face가 90개쯤 생기는 거죠. 원래는 훌륭한 최적화입니다. 브라우저가 화면에 실제로 쓰인 글자의 조각만 골라서 받으니까요.

그런데 preload: true면 이 최적화가 무력화됩니다. Next.js가 그 조각들에 <link rel="preload">를 달아버리고, 브라우저는 미리 받으라니까 화면에 없는 글자의 조각까지 전부 내려받습니다.

무게(weight)까지 곱해지면 이렇게 됩니다.

document.querySelectorAll('link[rel="preload"][as="font"]').length;
// 193

첫 로드가 느렸던 가장 큰 이유였습니다.

해결: 한글 폰트는 preload를 끈다

tsx

// app/layout.tsx
const plexSansKr = IBM_Plex_Sans_KR({
  variable: '--font-plex-sans-kr',
  subsets: ['latin'],
  weight: ['400', '500', '600'],
  // 한글은 유니코드 범위별 서브셋이 90여 개다.
  // preload를 켜두면 화면에 없는 글자까지 첫 로드에 전부 받는다.
  preload: false,
});

preload: false로 바꾸면 preload 태그가 사라지고, 브라우저가 unicode-range를 보고 필요한 조각만 가져옵니다.

	전	후
preload 태그	193개	5개
폰트 요청	197개	12개
DOMContentLoaded	192ms	90ms

측정은 로컬 개발 서버 기준입니다. 프로덕션 수치는 아니지만, 요청이 195개 줄어드는 효과는 지연이 큰 모바일 네트워크에서 훨씬 크게 벌어집니다.

트레이드오프도 있습니다. 폰트 요청이 CSS 파싱 이후로 밀립니다. 다만 font-display: swap이 기본이라 텍스트는 폴백 폰트로 바로 보이고 곧 교체되니까, 화면에 없는 글자 180개를 미리 받는 것보다는 낫다고 판단했습니다.

3. 원인 2: 안 쓰는 폰트 무게

한글 폰트에서 무게 하나는 서브셋 90여 개입니다. "혹시 쓸까 봐" 넣어둔 무게의 비용이 라틴 폰트와는 차원이 다릅니다.

제 코드를 실제로 뒤져봤습니다.

bash

grep -rohE "\bfont-(light|normal|medium|semibold|bold)\b" src/ | sort | uniq -c
#  27 font-medium     (500)
#   9 font-semibold   (600)
#   3 font-normal     (400)

font-light(300)과 font-bold(700)는 한 번도 안 쓰였습니다. 그런데 저는 5개 무게를 전부 싣고 있었죠. 세리프 폰트도 타이틀 전용이라 굵게 쓸 일이 없는데 2개 무게를 넣어뒀습니다.

쓰는 것만 남겼습니다.

tsx

weight: ['400', '500', '600'],  // 5개 → 3개

빌드 산출물이 이렇게 줄었습니다.

	전	후
폰트 파일	673개 (8.0MB)	393개 (4.5MB)
폰트 CSS	380KB	244KB

@font-face 선언만으로 380KB였다는 게 좀 놀라웠습니다. 이 CSS는 렌더링을 막는 자원이라 크기가 그대로 체감으로 이어집니다.

4. 원인 3: 재방문만 빠른 이유

이제 처음 단서로 돌아갑니다. 재방문이 왜 빠를까요?

TanStack Query를 쓰고 있었고, QueryClient를 이렇게 만들어뒀습니다.

tsx

const [queryClient] = useState(() => new QueryClient());

staleTime의 기본값이 0입니다. 컴포넌트가 마운트될 때마다 데이터를 낡았다고 판단해서 매번 다시 받아옵니다.

첫 방문에는 캐시가 없으니 isLoading: true가 되고 화면이 로딩 상태로 멈춥니다. 재방문에는 캐시된 값이 즉시 그려지고 재조회는 백그라운드에서 돌아갑니다. 증상과 정확히 맞습니다.

tsx

// app/providers.tsx
function makeQueryClient() {
  return new QueryClient({
    defaultOptions: {
      queries: {
        staleTime: 60_000,
        gcTime: 10 * 60_000,
        retry: 1,
      },
    },
  });
}

여기서 한 번 판단을 뒤집었다

처음엔 refetchOnWindowFocus: false도 같이 넣었습니다. 모바일은 앱 전환이 잦으니 포커스마다 재조회하면 손해라고 생각했거든요.

그런데 다시 보니 이건 낡은 데이터를 남기는 설정이었습니다. 앱을 몇 시간 뒤에 열었을 때 어제 기록이 그대로 보일 수 있습니다. 습관 체크 앱에서 그건 좀 곤란하죠.

staleTime이 있으면 이 옵션은 필요 없습니다. 포커스 재조회를 켜둬도 데이터가 낡았을 때만 다시 받으니까요. 60초 안에 앱을 나갔다 오면 재조회가 없고, 몇 시간 뒤에 돌아오면 갱신됩니다. 원하던 게 정확히 이거라서 옵션을 넣지 않고 기본값에 맡겼습니다.

5. 원인 4: 매 요청 인증 서버를 왕복

이건 재방문도 느리게 만드는, 모든 이동에 붙는 고정 비용입니다.

Supabase 인증을 쓰면 미들웨어에 이런 코드가 있을 겁니다. Next.js 16에서는 middleware.ts가 proxy.ts로 이름이 바뀌었습니다.

// src/proxy.ts (Next.js 15 이하: middleware.ts)
const { data: { user } } = await supabase.auth.getUser();
if (!user) return NextResponse.redirect(loginUrl);

getUser()는 매 요청마다 Supabase 인증 서버에 요청을 보내 토큰을 검증합니다. 안전하지만 페이지 이동 하나하나에 왕복이 붙습니다.

getClaims()가 이걸 대신합니다.

const { data: claims } = await supabase.auth.getClaims();
const user = claims?.claims.sub ? claims.claims : null;

문서에 따르면 getClaims()는 비대칭 서명 키를 쓰는 프로젝트에서 캐시된 JWKS로 로컬 검증합니다. 네트워크를 타지 않는다는 뜻이죠. 액세스 토큰 만료가 임박하면 검증 전에 세션을 먼저 갱신하므로 로그인 유지도 깨지지 않습니다. 아직 대칭 시크릿을 쓰는 프로젝트라면 getUser()와 똑같이 동작합니다.

마지막 항목이 중요합니다. 최악의 경우가 "기존과 같음"이라 마음 편히 바꿀 수 있습니다. 다만 효과를 다 보려면 Supabase 프로젝트를 비대칭 JWT 서명 키로 옮겨야 합니다.

보안 쪽도 한 줄 적어두겠습니다. 이 미들웨어는 로그인 여부만 판단하고, 실제 권한은 DB의 RLS가 쿼리마다 강제합니다. 위조된 토큰은 서명 검증에서 걸러지니 로컬 검증으로 충분합니다. 인가 결정을 미들웨어에만 의존하는 구조라면 더 신중히 봐야 합니다.

6. 마감 처리: 유휴 프리페치와 loading.tsx

원인 네 개를 고친 뒤 두 가지를 더 얹었습니다.

화면들이 같은 데이터를 쓴다면 미리 데워두기

제 앱은 5개 탭이 대부분 같은 데이터를 씁니다. 습관, 기록, 목표, 할 일, XP 정도요. 그렇다면 첫 화면이 그려진 뒤 유휴 시간에 미리 받아둘 수 있습니다.

tsx

'use client';
 
function WarmQueries() {
  useHabits();
  useHabitLogs();
  useGoals();
  useTodos();
  // ...
  return null;
}
 
export function PrefetchCore() {
  const [ready, setReady] = useState(false);
 
  useEffect(() => {
    // 현재 화면이 먼저 그려지도록 유휴 시간까지 기다린다
    const handle = requestIdleCallback(() => setReady(true), { timeout: 2000 });
    return () => cancelIdleCallback(handle);
  }, []);
 
  return ready ? <WarmQueries /> : null;
}

여기서 일부러 피한 게 있습니다. queryClient.prefetchQuery()로 쿼리 키와 조회 함수를 다시 쓰지 않았습니다. 키를 한 글자라도 다르게 쓰면 캐시가 갈라져서 오히려 두 번 받게 되니까요. 기존 훅을 그대로 호출하면 키가 어긋날 일이 없습니다.

requestIdleCallback으로 미룬 이유도 단순합니다. 첫 화면과 대역폭을 다투면 첫 진입을 더 느리게 만들 뿐입니다.

효과를 검증해봤습니다. 방문하지 않은 페이지로 이동하면서 네트워크 요청 수를 셌습니다.

// 이동 전후 Supabase REST 호출 수 비교
{ newRestCalls: 0, showsLoading: false, hasContent: true }

추가 네트워크 0건. 처음 여는 페이지가 로딩 상태 없이 바로 렌더됐습니다.

서버 렌더를 기다리는 동안

동적 라우트는 서버 렌더를 기다려야 합니다. 이때 loading.tsx가 없으면 화면이 그냥 멈춰 보입니다. 게다가 <Link> 프리페치도 로딩 경계가 있어야 제 역할을 합니다.

tsx

// app/(app)/loading.tsx
import { PageSkeleton } from '@/components/page-skeleton';
 
// 이 그룹 하위 라우트 이동 시 즉시 뼈대가 보인다
export default function AppLoading() {
  return <PageSkeleton />;
}

라우트 그룹 하나에 파일 하나만 두면 그 아래 전체가 커버됩니다.

7. 결과

항목	전	후
preload 태그	193개	5개
첫 로드 폰트 요청	197개	12개
DOMContentLoaded (로컬)	192ms	90ms
빌드 폰트 산출물	8.0MB	4.5MB
폰트 CSS	380KB	244KB
미방문 페이지 이동 시 API 호출	화면당 5~8건	0건
미들웨어 인증 왕복	매 요청	로컬 검증

마무리

제보에 이미 답의 절반이 있었습니다. "한 번 들른 페이지는 빠르다"는 한 문장이 후보를 셋에서 둘로 줄여줬고, 그 문장을 흘려듣지 않은 덕에 staleTime을 금방 찾았습니다. 성능 제보를 받으면 사용자가 정확히 어떤 상황에서 느리다고 했는지를 먼저 붙잡는 게 낫습니다.

그리고 제일 큰 원인은 제가 며칠 전에 직접 심은 것이었습니다. 한글 폰트를 예쁘게 쓰려고 무게를 넉넉히 싣고 나머지는 기본값으로 뒀는데, 그게 preload 태그 193개로 돌아왔습니다. 리디자인할 때 "잘 보이는가"만 봤고 "얼마나 받아오는가"는 안 봤던 거죠.

한글로 서비스를 만든다면 한글 웹폰트에 preload: false를 주고, 실제로 쓰는 무게만 싣는 것부터 확인해보시면 좋겠습니다. 한글은 유니코드 서브셋 분할이라는 최적화를 이미 갖고 있어서, 그걸 방해하지만 않으면 됩니다.

불러오는 중…

이낙 InakFrontend Developer

소개 보기

/ related

Next.jsApp Router · RSC · MDX

Next.js

Next.js + DaisyUI + next-themes로 완벽한 다크모드 구현하기

서버 컴포넌트 환경에서 깜빡임 없는 다크모드를 만드는 방법을 정리했습니다. DaisyUI의 data-theme 시스템과 next-themes를 조합하고, Hydration 문제·코드 블록 테마·로고 전환·FOUC까지 실제로 부딪힌 지점들을 해결합니다.

2026.03.02 9분

Next.jsApp Router · RSC · MDX

Next.js

Next.js App Router + MDX로 개인 블로그 만들기: 설계부터 배포까지

Next.js 16 App Router와 MDX로 파일 기반 블로그를 만든 전 과정을 정리했습니다. 폴더로 카테고리를 관리하는 구조 설계, gray-matter 프론트매터 파싱, remark·rehype 렌더링 파이프라인, 동적 라우팅, glob 목록 조회, 코드 블록 스타일링, SEO까지 다룹니다.

2026.03.01 8분

React NativeExpo · Mobile · Native

React Native

안드로이드 Edge-to-Edge 지옥에서 살아남기: 탭바 짤림·키보드에 깔리는 바텀시트의 진짜 원인들

iOS에서는 완벽하던 하단 UI가 안드로이드에서만 무너졌습니다. 탭바는 시스템 바에 잘리고, 바텀시트는 키보드에 깔리고, 고치면 고칠수록 이상해지는 상황. 인셋이 0으로 나오는 반쪽짜리 edge-to-edge 설정, RN Modal이 별도 창이라 adjustResize가 무효라는 사실, 그리고 '잘림'의 실체가 픽셀 측정으로 뒤집힌 순간까지 8차에 걸친 트러블슈팅 과정을 정리합니다.

2026.07.11 9분

/ buy me a coffee

이 글이 도움이 되었다면 ☕

커피 한 잔으로 응원해 주세요. 다음 글을 쓰는 큰 힘이 됩니다.

Next.js 첫 진입이 느릴 때 범인 찾기: 폰트 preload, staleTime, 인증 왕복

1. 무엇을 재야 하는가

2. 원인 1: next/font의 preload가 한글을 만나면

해결: 한글 폰트는 preload를 끈다

3. 원인 2: 안 쓰는 폰트 무게

4. 원인 3: 재방문만 빠른 이유

여기서 한 번 판단을 뒤집었다

5. 원인 4: 매 요청 인증 서버를 왕복

6. 마감 처리: 유휴 프리페치와 loading.tsx

화면들이 같은 데이터를 쓴다면 미리 데워두기

서버 렌더를 기다리는 동안

7. 결과

마무리

관련 글

Next.js + DaisyUI + next-themes로 완벽한 다크모드 구현하기

Next.js App Router + MDX로 개인 블로그 만들기: 설계부터 배포까지

안드로이드 Edge-to-Edge 지옥에서 살아남기: 탭바 짤림·키보드에 깔리는 바텀시트의 진짜 원인들

이 글이 도움이 되었다면 ☕

1. 무엇을 재야 하는가

2. 원인 1: next/font의 preload가 한글을 만나면

해결: 한글 폰트는 preload를 끈다

3. 원인 2: 안 쓰는 폰트 무게

4. 원인 3: 재방문만 빠른 이유

여기서 한 번 판단을 뒤집었다

5. 원인 4: 매 요청 인증 서버를 왕복

6. 마감 처리: 유휴 프리페치와 loading.tsx

화면들이 같은 데이터를 쓴다면 미리 데워두기

서버 렌더를 기다리는 동안

7. 결과

마무리