사무실의 광섬유(fibre) 네트워크에서 사이트를 테스트하고, 95점 이상의 Lighthouse 점수를 얻은 뒤 성능 최적화가 "완료"되었다고 말하기는 쉽습니다. 그러다 지방 도시의 누군가가 자신의 휴대폰에서 사이트가 느리게 느껴진다고 언급하는 순간, "테스트된" 성능과 "실제" 성능 사이의 격차가 명확해집니다.

이론적으로 이것은 파키스탄에만 국한된 문제는 아니지만, 실제로는 매우 흔한 문제입니다. 이곳의 실제 사용자 중 상당수는 혼잡한 3G 또는 속도가 제한된(throttled) 4G를 사용하며, 인프라가 가장 잘 갖춰진 주요 대도시 외곽의 중급 Android 기기를 사용하고 있습니다. 만약 여러분이 파키스탄(또는 일반적으로 신흥 시장)의 사용자를 위해 서비스를 구축하고 있다면, "사무실에서 잘 작동하는 것"은 "실제 사용자에게 잘 작동하는 것"과 같지 않습니다.

단순히 CDN을 연결하는 것 이상으로, 실제로 유의미한 변화를 만들어내는 방법은 다음과 같습니다.

CDN은 도움이 되지만, 라스트 마일(last mile) 문제를 해결하지는 못합니다

CDN은 자산(assets)을 사용자와 물리적으로 더 가깝게 배치하여 도움을 줍니다. 하지만 사용자의 휴대폰과 가장 가까운 에지 노드(edge node) 사이의 연결이 여전히 혼잡한 3G 링크라면, CDN의 역할은 기본적으로 끝난 것입니다. 병목 현상은 라스트 마일(last mile)에 있으며, 아무리 많은 에지 캐싱(edge-caching)도 이를 해결할 수 없습니다. 실제로 도움이 되는 것은 애초에 그 라스트 마일을 통해 이동해야 하는 양을 줄이는 것입니다.

이는 문제의 프레임을 완전히 바꿉니다. 즉, "바이트를 더 빠르게 전달하는 것"보다 "더 적은 바이트를 보내는 것"이 핵심입니다.

1. 이미지 용량이 보통 가장 큰 원인입니다

이미지는 일반적으로 페이지 용량(page weight)을 차지하는 가장 큰 요인이며, 해결 방법은 특별한 것이 아닙니다.

// Next.js 예시 — 명시적인 너비/높이(width/height)는 레이아웃 이동(layout shift)을 방지하며,
// Image 컴포넌트는 현대적인 포맷을 자동으로 제공합니다.
import Image from "next/image";
...

차곡차곡 쌓여 효과를 발휘하는 몇 가지 구체적인 습관은 다음과 같습니다:

• 가능한 경우 원본 JPEG/PNG 대신 WebP/AVIF를 제공하세요 — 동일한 시각적 품질에서 보통 25-50% 더 작습니다.
• 브라우저가 이미지를 로드하는 동안 레이아웃이 밀리지 않도록 항상 명시적인 width/height를 설정하세요 (또는 이를 자동으로 처리해 주는 프레임워크 컴포넌트를 사용하세요). 이는 누적 레이아웃 이동 (Cumulative Layout Shift, CLS) 점수에도 직접적인 영향을 미칩니다.
• 스크롤 전 영역 (below the fold)에 있는 모든 것은 지연 로딩 (Lazy-load) 하세요. 방문자가 스크롤하지 않을 수도 있는 이미지를 로드하는 데 대역폭을 낭비할 이유가 없습니다.

한 이커머스 리빌딩 사례에서는 디자인을 전혀 건드리지 않고 이미지 파이프라인(포맷, 지연 로딩, 명시적 크기 지정)만 최적화하여 전체 페이지 무게를 약 3분의 1로 줄였습니다.

2. 모든 서드파티 스크립트를 마치 돈이 나가는 것처럼 감사하세요 (실제로 그렇기 때문입니다)

채팅 위젯, 분석 (analytics), 마케팅 픽셀 (marketing pixels), 임베디드 소셜 위젯 등 모든 서드파티 스크립트는 클라이언트 측의 파싱 (parse) 및 실행 시간을 추가하며, 이 비용은 개발자의 노트북보다 저사양 기기에서 불균형적으로 더 높게 나타납니다. 광섬유 인터넷 환경의 Chrome DevTools에서는 "즉각적인" 것처럼 느껴지는 스크립트가 3G 환경의 저가형 안드로이드 폰에서는 상호작용을 눈에 띄게 차단할 수 있습니다.

간단한 감사 습관: 네트워크 (Network) 탭을 열고, JS로 필터링한 뒤, 크기순으로 정렬하세요. 용도를 즉시 알 수 없는 항목에 대해서는 그것이 실제로 비용을 지불할 가치가 있는지 자문해 보세요. 가능한 것은 지연 (Defer) 시키세요:

<!-- 나쁨: 즉시 파싱을 차단함 -->
<script src="https://widget.example.com/embed.js"></script>

...

정말로 중요하지 않은 항목(대부분의 채팅 위젯, 대부분의 마케팅 픽셀)의 경우, 이를 크리티컬 경로 (critical path)에 두는 대신 메인 콘텐츠가 상호작용 가능해진 이후에 로드하는 것이 보통 여러분이 할 수 있는 가장 영향력 있는 JS 변경 사항입니다.

3. 폰트를 셀프 호스팅 (Self-host) 하세요

서드파티 CDN에서 폰트를 가져오는 것(Google Fonts의 기본 임베드가 가장 흔한 예시입니다)은 단 하나의 폰트 파일이 다운로드되기 시작하기도 전에 추가적인 DNS 조회 (DNS lookup)와 연결 왕복 (connection round-trip)을 발생시킵니다. 셀프 호스팅을 하면 이러한 단계를 완전히 제거할 수 있습니다:

// @fontsource (셀프 호스팅 폰트 패키지) 사용 예시
import "@fontsource/inter/400.css";
import "@fontsource/inter/600.css";

이를 font-display: swap과 결합하면, 커스텀 폰트가 다운로드되는 동안 텍스트가 보이지 않는 상태로 유지되는 대신(전형적인 "invisible text의 깜빡임" 현상 방지), 폴백 (fallback) 폰트로 즉시 렌더링됩니다:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter.woff2") format("woff2");
...

작은 변화이지만, 느린 연결 환경에서 최대 콘텐츠 페인트 (Largest Contentful Paint, LCP) 수치를 일관되게 측정 가능한 수준으로 개선합니다.

4. 광섬유(fibre)뿐만 아니라 제한된(throttled) 연결에서도 측정하세요

Chrome DevTools에는 네트워크 제한 (network throttling) 옵션이 내장되어 있습니다 (Network 탭 아래의 "Slow 3G" / "Fast 3G" 프리셋) — 이는 정말로 잘 활용되지 않는 기능입니다. 빠른 연결에서 생성된 Lighthouse 점수를 신뢰하기보다, 시뮬레이션된 3G 환경에서 실제 빌드를 테스트하면 실험실 점수(lab score)가 숨길 수 있는 문제들을 드러낼 수 있습니다. PageSpeed Insights의 "현장 데이터 (Field Data)" 섹션(사용 가능한 경우)은 훨씬 더 유용합니다. 이는 합성된 실험실 실행(synthetic lab run)이 아니라, 실제 방문자로부터 얻은 실제 Chrome 사용자 경험 보고서 (Chrome User Experience Report) 데이터에 기반하기 때문입니다.

이 모든 것은 특별한 기술이 아닙니다 — 그것이 핵심입니다

위의 내용 중 어떤 것도 영리한 트릭이 아닙니다. 대부분 페이지에 무엇을 추가할지, 그리고 그것이 언제 로드될지에 대한 규율 (discipline)에 관한 것입니다. 하지만 그 규율이야말로 실험실 테스트에서 높은 점수를 받는 사이트와, 주요 대도시 외곽의 실제 3G 연결을 사용하는 사용자에게 빠르게 느껴지는 사이트 사이의 실질적인 차이를 만듭니다. 이곳에서 구축되는 많은 제품에 있어, 이는 크고 쉽게 잊히기 쉬운 실제 타겟 관객층입니다.

저는 파키스탄 라왈핀디에 기반을 둔 웹 개발 스튜디오인 WebTech Solutions를 운영하고 있습니다. 저희는 파키스탄, 영국, 미국, UAE, 사우디아라비아 전역의 클라이언트를 위해 제품을 구축합니다. 위의 많은 규율은 특히 낮은 대역폭 (lower-bandwidth) 환경을 위해 구축하며 얻은 경험에서 비롯되었지만, 이는 어디에서나 유효합니다. 여기에서 성능이 사후 고려 사항이 아닌 의도적인 우선순위였던 최근 Next.js 빌드 사례를 확인하실 수 있습니다.