Largest Contentful Paint 점수 개선

[sungwonnoh]

Spectator LCP 개선 이슈

현재 문제

Lighthouse 보고서 기준 spectator 홈의 LCP는 15.2s로 측정됨.

• URL: https://www.hufscheer.com/soccer?org=9
• Performance score: 67
• LCP 요소: 2026 제24회 고황컵_축구
• 코드 위치: apps/spectator/src/app/[sport]/(home)/_components/tab.tsx

LCP 요소는 이미지가 아니라 홈 화면의 리그명 텍스트다.

LCP에 영향을 주는 요소

1. 홈 핵심 콘텐츠가 client-only 렌더링됨

apps/spectator/src/app/[sport]/(home)/page.tsx

<Suspense clientOnly fallback={<Spinner />}>
  <RecentTab />
</Suspense>

리그명과 경기 목록이 초기 HTML에 포함되지 않고, 클라이언트 렌더링과 API fetch 이후에 표시된다.

단, RecentTab을 그대로 clientOnly 밖으로 빼는 것은 안전하지 않다. 현재 RecentTab은 useParams, useRouter, useOrganizationId, useTracker, React Query suspense에 의존하는 client component이므로, LCP에 필요한 읽기 전용 UI만 서버 렌더링 경로로 분리해야 한다.

2. 리그명 렌더링이 API fetch에 의존함

apps/spectator/src/app/[sport]/(home)/_components/tab.tsx

• useSuspenseLeagueRecentGames
• useSuspenseLeagueCheerCount

특히 cheer-count는 LCP 텍스트와 같은 렌더 경로에 있어 리그명 표시를 늦출 수 있다.

3. 폰트 파일이 너무 큼

apps/spectator/src/app/_fonts/PretendardVariable.woff2

• Lighthouse 기준 약 2.06MB
• LCP 요소가 텍스트라 폰트 전송량이 점수에 불리할 수 있음

4. 이미지 최적화가 꺼져 있음

apps/spectator/next.config.ts

images: {
  unoptimized: true;
}

팀 로고가 작은 크기로 표시되지만 큰 원본 이미지가 내려오고 있음. LCP 직접 요소는 아니지만 전체 payload와 성능 점수에 영향.

해야 할 일

P0

• RecentTab 에서 리그명/첫 경기 목록을 렌더하는 서버 컴포넌트를 새로 분리
• 서버 컴포넌트에서 params.sport, searchParams.org를 읽고 fetchLeagueRecentGames로 최근 경기 데이터를 가져오도록 변경
• 리그명과 첫 경기 목록이 초기 서버 HTML에 포함되도록 구성
• useRouter, useTracker, useOrganizationId가 필요한 버튼 액션 영역은 별도 client component로 유지
• cheer-count를 리그명 렌더와 분리하고, 별도 client component 또는 별도 Suspense로 처리

P1

• Pretendard font subset 적용 또는 필요한 weight만 분리 로드
• 폰트 파일 cache header 확인

P2

• images.unoptimized: true 제거 가능 여부 검토
  • 이미지 최적화가 활성화된 뒤 팀 로고 Image에 sizes="28px" 추가
• 팀 로고 썸네일/CDN 리사이즈 적용
• images.hufscheer.com 이미지 cache header 개선

P3

• cheer-count 분리 작업과 함께 @number-flow/react를 LCP 경로에서 제거
• analytics/third-party script가 초기 렌더에 주는 영향 확인

검증

동일 URL로 Lighthouse mobile 재측정:

https://www.hufscheer.com/soccer?org=9

확인 항목:

• LCP
• Speed Index
• Total byte weight
• Image delivery insight
• Cache insight

참고

• https://developer.chrome.com/docs/lighthouse/performance/lighthouse-largest-contentful-paint/
• https://developer.chrome.com/docs/performance/insights/lcp-breakdown
• https://web.dev/articles/optimize-lcp
• https://nextjs.org/docs/app/api-reference/components/image

[seongminn]

오 완전 깔끔하게 정리해주셨네요!
우선 할 수 있는 작업이 몇개 보이는데, 정리해볼게요.

현재 홈 화면에서 보여주는 거의 대부분의 데이터가 RecentTab 내부의 useSuspenseLeagueRecentGames 쿼리에 의존하고 있고, API 워터폴으로 인해 LCP가 많이 저하된 상황으로 보여요. 그래서 제가 생각할 때 이걸 개선하려면 두 가지 정도로 나뉠 거 같은데 아래와 같아요.

• API를 서버 환경에서 호출하기
• 백엔드 개발자와 협업해서 API 워터폴 구조 개선하기

두번째 방법은 당연히 백엔드 분들과 함께 작업해야 하니까 시간도 오래 걸리고 좀 대공사가 될 가능성이 있어 보입니다. 그래서 프론트 단에서 처리하려면 첫번째 방법을 시도해보면 좋을 것 같은데, 우리가 지금 API 호출을 위해 tanstack query를 사용하고 있다는 점에서 API가 클라이언트 환경에서 처리되는 건 어쩔 수 없는 상황이긴 해요. 그래도 Tanstack Query 팀에서도 이런 부분을 해결하고자 문서를 잘 작성해두긴 했지만, 예전에 훕치치에서 이 방법을 실제로 적용해봤을 때 플레이트가 너무 많이 생기는 바람에 좀 경험이 좋지 않았던 것으로 기억합니다.. 이 부분을 어떻게 해결해보면 좋을지 같이 논의해봐도 좋을 것 같아요.

그리고 API를 서버 환경에서 한 번 호출 후, 클라이언트에서 다시 호출할 때 캐시가 있으면 refetch 하지 않기 때문에 stale time과 cache time을 잘 정의할 필요가 있을 것 같습니다..! 예전에 처음 프로젝트 시작할 때 이 부분에 대해서는 논의를 꽤 깊게 했었어서 지금 당장 논의해야 할 것 같진 않고, 만약 캐싱 문제가 발생하면 그 때 다시 이야기 해보면 좋을 것 같아요. 이 부분은 같이 인지하고 있으면 좋을 것 같아서 공유드립니다!

마지막으로 서버 컴포넌트가 좋은 점도 많지만, 서버 환경에서 화면을 그린 후 JS가 로딩될 때까지 상호작용이 불가능한 시간이 생긴다는 문제가 있어요. 이 시간을 TTI(Time to Interact)라고 하는데, 서버 컴포넌트로 분리 후 TTI가 길어지지는 않는지 트래킹 해보는 것도 좋을 것 같네요!

--

추가로 폰트 같은 경우에, 저는 보통 Pretendard 가변 프리셋을 사용하는데 이거 고려해봐도 좋을 것 같아요!

[sungwonnoh]

Tanstack Query hook에 묶여 있어서 서버에서 먼저 데이터를 가져오려면 컴포넌트 구조를 많이 바꿔야 할 것 같긴하네요. 제가 봤을 때도 RecentTab 개선이 가장 효과적일 것 같아서 조금씩 수정하면서 테스트해보면 어떨까요?

1. fetchLeagueRecentGames 직접 호출로 작은 PoC테스트
2. Network에서 recent-games 중복 호출 확인
3. 중복 fetch가 문제면 HydrationBoundary로 React Query cache 연결

이 방식을 생각해봤는데, 이러면 앞서 말해주신 보일러플레이트 문제가 있으려나요 ..

+폰트도 말씀해주신 가변 프리셋으로 변경해도 좋을 것 같아요!

[seongminn]

음 사실 fetchLeagueRecentGames를 따로 쓸거면 굳이 tanstack query를 쓸 이유가 없긴 할 거 같아요. tanstack query를 사용하는 이유가 서버 데이터를 캐싱해주는 게 가장 큰 이유라고 생각하는데, fetchLeagueRecentGames 호출 후 tanstack query API를 호출하면 결국 캐싱 없이 쌩으로 API를 두 번 호출하는 꼴이라서... 안그래도 페이지 하나에서 API를 여러개 호출하는데 그게 2번씩 호출되는거면 네트워크 자원을 꽤 많이 잡아먹지 않을까 싶습니다..!

그러면 차라리 nextjs 내장 fetch를 이용하거나, 아니면 보일러플레이트를 감수하더라도 Tanstack query + SSR을 사용하거 일 거 같은데, 어떠신 거 같으세요??

[sungwonnoh]

아 그러면 필요한 부분에만 먼저 Tanstack query + SSR 적용하는 건 어떤가요?

[seongminn]

좋아요 그럼 그렇게 하시죠!
우선 사용자가 딱 메인 페이지에 진입했을 때 바라보는 화면에 대한 성능 개선부터 해보고, 다음 페이지로 순차적으로 넘어가도 좋을 것 같아요.
그리고 SSR 적용한 뒤에도 다른 성능이나 UX 문제가 하나둘씩 생길 수 있어서, 일단 해보고 다음 단계를 정해봅시다!

그리고 같이 하면 좋을 거 같은 건, RecentTab에서 경기 정보 가져올 때, 모든 경기를 한번에 호출하고 있어요. 이것도 화면에 보이지 않는 데이터는 굳이 가져올 필요가 없을 것 같아서, 백엔드랑 얘기해서 무한스크롤 처리하거나, 가상화 처리하는 것도 해보면 좋을 것 같네요!

[sungwonnoh]

그러면 제가 메인페이지에 SSR 적용해보고 성능 비교한번 해볼게요! 성능이 안오르거나.. 다른 이슈가 생긴다면 그때 다시 얘기해 보면 좋을 것 같습니다.
경기 수가 엄청 많은건 또 아니라 가상화보단 무한스크롤이 좋을 것 같긴하네요. 사실 가상화는 안해봤는데 성능에 큰 차이가 있을까요?

[seongminn]

무한스크롤은 결국 백엔드의 지원이 필요한 작업인데 최대한 백엔드의 공수를 들이지 않으려면 무한스크롤은 어려울 것 같아서 대안 차원으로 말씀드렸어요!
근데 말씀하신 것처럼 가상화는 엄청나게 많은 데이터가 아니라면 오히려 오버 엔지니어링이기도 하고, 당장 문제가 되는 요소는 아니라서 무시해도 될 것 같네요!

그럼 성원님께서 SSR 처리하는 거 하시고, 저는 라우팅 구조 개선을 진행하는 걸로 해볼까요??
서로 영향을 주는 작업이긴 하지만 내용 공유 잘 하고, 작업이 너무 커지는 거 같으면 적당히 잘라서 PR 올려서 충돌 최소화 하면 적당히 처리할 수 있을 거 같아요!

[sungwonnoh]

넵 좋습니다!