사이트 성능을 볼 때는 모든 화면을 한 번에 다 고치기보다,
문제가 더 크게 보이는 구간부터 먼저 정리하는 편이 낫습니다.

이번에는 PageSpeed 결과를 기준으로
데스크톱 UI는 건드리지 않고, 모바일 초기 렌더에 영향을 줄 수 있는 부분만 먼저 손봤습니다.

여기서 말하는 수치는 PageSpeed 테스트 환경 기준 결과이며,
실제 사용자 환경에서는 기기 성능과 네트워크 상태에 따라 다르게 보일 수 있습니다.

문제

PageSpeed 결과를 보면 데스크톱과 모바일이 꽤 다르게 나왔습니다.

데스크톱은 비교적 안정적이었습니다.

  • FCP: 0.9초
  • LCP: 1.2초
  • TBT: 30ms
  • CLS: 0

반면 모바일은 초기 렌더 구간이 더 느리게 보였습니다.

  • FCP: 5.5초
  • LCP: 7.3초
  • Speed Index: 6.2초

즉, 사이트 전체 구조가 망가진 상태라기보다
모바일에서 첫 화면이 늦게 보이는 구간을 먼저 살펴볼 필요가 있었습니다.

처음 떠오르는 생각

처음에는 CSS 양을 줄이거나 레이아웃 자체를 바꿔야 하나 생각할 수 있습니다.

그런데 이번 경우에는 데스크톱 점수가 이미 괜찮았고,
CLS도 0이라 화면이 흔들리는 문제도 보이지 않았습니다.

그래서 이번 작업은 화면 구조를 뜯어고치기보다,
초기 렌더 시점에 불필요하게 경쟁할 수 있는 로딩 요소부터 정리하는 쪽이 더 맞다고 판단했습니다.

핵심 아이디어

이번에 먼저 본 부분은 아래 두 가지였습니다.

  1. 폰트 로딩 방식
  2. 분석 스크립트 로딩 시점

둘 다 화면을 직접 바꾸는 요소는 아니지만,
초기 구간에서 네트워크 요청이나 스크립트 작업이 겹치면 모바일에서 체감이 나빠질 수 있습니다.

즉, 이번 작업의 방향은
데스크톱 디자인은 유지하면서, 모바일 첫 렌더 경로에 있는 부담만 조금 줄여보는 것이었습니다.

변경한 코드

이번에 실제로 바꾼 파일은 하나입니다.

  • app/layout.tsx

1. Google Fonts 로딩 방식 변경

기존에는 Space Grotesk를 Google Fonts <link>로 직접 불러오고 있었습니다.

이번에는 이를 next/font/google로 바꿨습니다.

next/font/google를 사용하면 폰트 로딩을 Next.js 방식으로 통합해서 관리할 수 있고,
외부 폰트 스타일시트 요청에 의존하던 구조를 줄이는 데 도움이 될 수 있습니다.

즉, 무조건 속도가 빨라진다고 단정하기보다는
초기 렌더 경로를 조금 더 예측 가능하게 정리하는 목적에 가깝습니다.

2. Google Analytics 스크립트 로딩 시점 조정

기존에는 GA 스크립트를 afterInteractive로 불러오고 있었습니다.

afterInteractive도 일반적인 스크립트 삽입보다 부담이 적은 편이지만,
모바일 환경에서는 초기 구간의 스크립트 작업이 겹치면서 렌더링 여유를 줄일 수 있다고 보고
이번에는 lazyOnload로 더 뒤로 미뤘습니다.

즉, 분석 기능을 없앤 것이 아니라
첫 화면 이후에 조금 더 여유 있을 때 불러오도록 순서를 바꾼 것입니다.

왜 데스크톱은 그대로 뒀을까

이번 작업에서 데스크톱 UI는 일부러 건드리지 않았습니다.

이유는 단순합니다.

  • 데스크톱 점수는 이미 비교적 괜찮았고
  • CLS도 0이라 레이아웃 안정성이 좋았고
  • 사용성 자체도 크게 불편해 보이지 않았기 때문입니다.

즉, 지금 단계에서 데스크톱까지 같이 흔들기보다
문제가 더 크게 보이는 모바일 쪽만 먼저 손보는 편이 우선순위에 맞다고 봤습니다.

변경 후 수치는 아직 어떻게 봐야 할까

이 글을 쓰는 시점에는 변경 직후 수치를 다시 비교하는 작업이 아직 끝나지 않았습니다.

즉,

  • 변경 전에는 어떤 구간이 느렸는지 확인했고
  • 그 원인 후보 중 먼저 손대기 쉬운 부분을 정리했고
  • 변경 후 수치는 같은 조건에서 다시 확인해 기록할 예정입니다

그래서 이번 글은
“이미 확실히 빨라졌다고 결론 내리는 기록”보다, 어떤 근거로 먼저 손댔는지 남기는 작업 메모에 더 가깝습니다.

이번 글에서 조심해서 본 부분

성능 글은 표현을 너무 단정적으로 쓰면 오해를 만들기 쉽습니다.

예를 들어:

  • 폰트 최적화가 항상 더 빠른 결과를 보장하는 것은 아닙니다
  • 스크립트를 늦췄다고 해서 LCP가 반드시 크게 줄어드는 것도 아닙니다
  • PageSpeed 수치가 실제 모든 사용자 경험과 완전히 같지도 않습니다

그래서 이번 글은
“이렇게 바꾸면 무조건 빨라진다”보다
**“이 구조가 초기 렌더 부담을 줄이는 데 도움이 될 수 있다고 보고 먼저 정리했다”**는 수준으로 보는 게 맞습니다.

아직 남아 있는 것

이번에는 구조 전체를 다 건드리지는 않았습니다.

예를 들면 아래 같은 부분은 아직 추가로 볼 수 있습니다.

  • 광고 스크립트의 로딩 시점
  • 코드 하이라이트 스타일의 전역 로딩 범위
  • 모바일 홈에서 처음 그리는 콘텐츠 양
  • 캐시 정책과 이미지 최적화

즉, 이번 작업은 성능 최적화의 끝이라기보다
가장 먼저 손대기 쉬운 공통 로딩 구조를 정리한 첫 단계에 가깝습니다.

정리

이번 작업의 핵심은 아래 두 줄로 정리할 수 있습니다.

  • 폰트 로딩 방식을 next/font/google로 바꿨다
  • 분석 스크립트를 더 늦게 불러오도록 조정했다

즉, 화면을 새로 그리거나 데스크톱 UI를 바꾸지 않고도
모바일 초기 렌더 구간에 경쟁하던 요소를 조금 줄이는 방향으로 접근한 것입니다.

성능 최적화는 항상 큰 리팩터링부터 시작할 필요는 없습니다.
이번처럼 문제 구간을 먼저 좁혀 보고, 공통 로딩 구조부터 정리하는 방식도 충분히 의미가 있습니다.

※ 이 글은 실제 블로그 코드 변경을 바탕으로, 작업 이유와 판단 기준을 정리한 기록입니다.