저사양 기기를 위한 Core Web Vitals 최적화

저사양 기기를 위한 Core Web Vitals 최적화

Core Web Vitals는 사이트 품질에 대한 객관적인 벤치마크의 일부가 되어야 합니다. 하지만 실제로는 그렇지 않습니다! 이 지표는 사용자가 사용하는 기기와 밀접하게 연결되어 있습니다. 고가 제품이나 서비스를 판매하는 비즈니스의 경우, 고객은 대체로 빠른 스마트폰, 데스크톱 및 안정적인 네트워크 환경을 갖추고 있습니다.
반면, 비용에 민감한 소비자나 신흥 시장을 겨냥하는 비즈니스는 다릅니다. 이들의 주요 고객층은 노후화된 스마트폰, 성능이 떨어지는 프로세서 또는 열악한 네트워크 환경에 의존합니다.
플래그십 iPhone에서는 테스트를 가볍게 통과하는 동일한 웹사이트가 중급형 Android 기기나 대역폭이 낮은 국가에서는 만족스럽게 로드되는 데 어려움을 겪습니다.

최종 검토: Arjen Karel (2026년 3월)

숫자가 말해주는 진실

2025 Web Almanac에 따르면, 모바일 오리진의 48%만이 Core Web Vitals를 통과하는 반면 데스크톱은 56%가 통과합니다. 가장 큰 격차를 보이는 것은 INP입니다. 데스크톱 오리진은 97%가 통과하지만 모바일은 77%에 불과합니다. 이 20%포인트의 격차는 거의 전적으로 Android 기기의 느린 CPU 때문에 발생합니다.

모바일 Total Blocking Time의 중간값은 1,916밀리초입니다. 데스크톱은 어떨까요? 92밀리초입니다. 무려 20대 1의 비율입니다. MacBook에서 스크립트가 잘 실행된다고 해서 저가형 스마트폰에서도 잘 실행되는 것은 절대 아닙니다.

Alex Russell의 연구에 따르면, 실제 사용되는 기기의 약 30%가 저사양(4코어 이하, 4GB RAM 이하)입니다. 이러한 기기의 싱글 코어 성능은 최신 iPhone보다 최대 9배 더 느립니다. CoreDash Real User Monitoring 데이터에서 볼 때, 저사양 기기에 최적화된 사이트는 모바일 페이지 로드의 62%에서 Core Web Vitals를 통과한 반면 고사양 하드웨어에서만 테스트한 사이트는 41%에 불과했습니다.

1단계: Client Capability Score 생성

방문자가 고사양 기기를 사용하는지 저사양 기기를 사용하는지 평가하기 위해 브라우저에서 직접 Client Capability Score를 계산할 수 있습니다. 이 점수는 0(매우 제한적)부터 100(최고급 하드웨어)까지입니다. 실제 환경에서는 점수가 40 미만인 기기는 성능 부족으로 분류해야 합니다.

아래 함수는 실제 RUM 및 Google의 Core Web Vitals 데이터와 강한 상관관계를 갖는 하드웨어 및 네트워크 지표를 사용하여 Client Capability Score를 계산합니다. 점수가 높을수록 기기가 리소스 제약이 적고 빠른 페이지 성능을 제공할 수 있음을 나타냅니다.

function getClientCapabilityScore() {
  const mem = navigator.deviceMemory || 4;
  let cpu = navigator.hardwareConcurrency || 4;
  cpu = Math.min(cpu, 8);

  let net = 4;
  if (navigator.connection) {
    const { effectiveType, rtt = 300 } = navigator.connection;
    const map = { 'slow-2g': 1, '2g': 2, '3g': 3, '4g': 4, '5g': 5 };
    net = map[effectiveType] || 4;
    if (rtt > 500) net = Math.max(net - 3, 1);
    else if (rtt > 300) net = Math.max(net - 2, 1);
    else if (rtt < 150) net = Math.min(net + 1, 5);
  }

  const score = mem + cpu * 0.5 + net * 2;
  return Math.min(100, Math.round(score * 5));
}

getClientCapabilityScore();

Core Web Vitals 팁: 이러한 최적화는 모든 사용자에게 도움이 됩니다. 하지만 느린 연결을 사용하거나 메모리가 제한된 기기를 사용하는 사용자에게는 그 중요성이 훨씬 큽니다. 최적화를 생략했을 때의 단점이 더 빨리 나타나기 때문입니다.
이미지 다운로드를 예로 들어보겠습니다. 일반적인 연결에서는 이미지 다운로드가 Largest Contentful Paint 시간의 약 10%를 차지합니다. 하지만 느린 연결에서는 별다른 노력 없이도 이 비율이 두 배로 늘어날 수 있습니다. 대부분의 사용자에게는 이미지 최적화를 최우선 순위로 두지 않지만, 대역폭이 낮거나 메모리가 부족한 방문자를 처리할 때는 이 작업이 즉시 최우선 과제가 되는 이유가 바로 이 때문입니다.

QUIC 및 0-RTT와 함께 HTTP/3 활성화

서버에서 멀리 떨어져 있거나 느린 네트워크 환경에 있는 방문자는 긴 왕복 시간(RTT)을 경험합니다. HTTP/3는 QUIC 및 0-RTT와 결합하여 초기 연결 속도를 직접적으로 향상시킵니다. 이는 모든 방문자에게 중요한 최적화이지만, 대역폭이 낮은 방문자에게는 특히 필수적입니다. Cloudflare Radar에 따르면, 이제 HTTP/3는 전 세계 웹 트래픽의 21%를 처리합니다. Cloudflare를 사용하는 경우 Cloudflare 대시보드에서 HTTP/3를 활성화할 수 있습니다.

• 더 빠른 연결 설정: QUIC는 전송 및 암호화 핸드셰이크를 하나로 통합합니다. 0-RTT는 한 단계 더 나아가 재방문자가 핸드셰이크를 완전히 건너뛰고 즉시 데이터를 전송할 수 있게 합니다.
• 재방문자를 위한 지연 시간 감소: 0-RTT를 사용하면 클라이언트가 세션을 재개하고 지연 없이 요청을 보낼 수 있습니다. 수백 밀리초를 절약할 수 있으며, 이는 원거리 또는 모바일 사용자에게 특히 가치가 있습니다.
• 원거리에서의 높은 복원력: HTTP/3(UDP 기반)는 TCP의 Head-of-line blocking 문제를 피합니다. QUIC는 패킷 손실과 불안정한 네트워크를 더 유연하게 처리합니다. 이는 대륙을 횡단하는 통신이나 불안정한 모바일 연결에서 큰 차이를 만들어냅니다.

디자이너의 의도보다 더 공격적으로 이미지 압축하기

고해상도 이미지는 LCP를 지연시키며, 특히 GPU 압축 해제 성능이 제한된 기기에서 더욱 그렇습니다. 2025 Web Almanac에 따르면 모바일 홈페이지는 중간값 기준 911KB의 이미지를 로드합니다. 이는 전체 페이지 용량의 42%에 달합니다. P75 다운링크가 9Mbps인 저가형 기기에서 이러한 이미지는 필수 리소스와 직접적으로 경쟁하게 됩니다.

미적인 부분에만 타협하지 말고 시각적으로 수용 가능한 수준에서 더 작은 크기의 이미지를 목표로 하세요. WebP 및 AVIF가 도움이 되지만, 지연 로딩과 반응형 크기 제공이 훨씬 더 중요합니다.

명확한 규칙 하나: 저사양 기기의 히어로 이미지는 100KB 미만으로 유지하세요. 디자이너가 반대한다면, 더 이상 논쟁하기 전에 100유로짜리 Android 스마트폰에서 동일한 사이트를 테스트하게 해야 합니다.

CSS를 절대적으로 필요한 것만 남기고 제거하기

스타일과 관련해서는 단 하나의 규칙만 존재합니다. 완전히 정리하라는 것입니다. 사용하지 않는 선택자를 제거하고, 명시도를 낮추며, 중복되는 규칙을 병합하세요.

오버라이드를 최소화하여 예측 가능하고 일관된 레이아웃에 집중하세요. 복잡한 컴포넌트별 스타일보다는 소규모 유틸리티 클래스 세트를 사용하세요. 이는 브라우저의 CSSOM 구축과 개발자의 유지보수성에 모두 도움이 됩니다.

스크롤 없이 볼 수 있는 영역(above-the-fold)의 콘텐츠의 경우, 절대적으로 필요한 것만 인라인 처리하세요. 나머지는 지연 로딩하되, 분할을 최소화하고 명확하게 유지해야 합니다. Critical CSS Generator를 출발점으로 사용할 수 있지만, 최상의 결과를 얻으려면 핵심 CSS를 수동으로 세밀하게 정의하세요.

스크립트는 단호하게 처리하기

모바일 Total Blocking Time의 중간값이 1,916ms(2025 Web Almanac에 따르면 전년 대비 58% 증가)인 상황에서 JavaScript는 저사양 기기에서 가장 큰 단일 문제입니다. 저가형 기기의 P75 네트워크 속도는 다운로드 약 9Mbps, RTT 100ms입니다. 전송하는 JavaScript 1킬로바이트마다 테스트용 스마트폰보다 9배나 느린 CPU에서 파싱되고 실행됩니다.

• 렌더링을 차단하는 스크립트 금지: 모든 비필수 스크립트가 렌더링을 차단하지 않도록 하세요. <script> 태그에 async 또는 defer 속성을 사용하십시오. 스크립트가 초기 페이지 로드나 사용자 상호 작용에 필수적이지 않다면 동기식으로 실행되어서는 안 됩니다. 지연 기술에 대한 전체 개요는 JavaScript를 지연시키는 16가지 방법을 참조하세요.
• 비필수 스크립트 예약: 당장 필요하지 않은 스크립트는 예약을 통해 처리해야 합니다. requestIdleCallback을 사용하여 브라우저가 유휴 상태일 때 스크립트를 실행하세요. 이를 통해 핵심 렌더링 경로를 방해하지 않고 무거운 작업을 분산시킬 수 있습니다.
• Client Capability Score를 사용하여 선택적으로 스크립트 로드: 이 점수를 사용하여 로드할 항목을 결정하세요. 저사양 기기에서는 스크립트 수를 줄이고 더 가벼운 대안을 선택해야 합니다. 사용자 메모리가 제한되어 있거나 구형 CPU를 사용하는 경우 무거운 스크립트를 로드하는 데 리소스를 낭비하지 마세요. 고사양 기기에서만 깊은 인상을 주고 저사양 기기에서는 좌절감을 주는 보여주기식 기능보다 성능을 우선시하세요.

시스템 폰트를 사용하거나 최소한 무거운 커스텀 폰트 피하기

커스텀 폰트를 로드하면 지연 시간이 추가되고 레이아웃 끊김 현상이 발생합니다. 메모리가 제한된 기기에서는 불필요하게 RAM 압박을 가중시킬 수도 있습니다. 2025 Web Almanac에 따르면, 88%의 사이트가 하나 이상의 웹 폰트를 로드하지만 미리 로드(preload)하는 비율은 12%에 불과합니다. 성능을 위한 최선의 옵션인 font-display: optional은 사이트의 단 0.4%만이 사용하고 있습니다.

시스템 폰트는 렌더링이 더 빠르고, 사용자 설정을 존중하며, 레이아웃 이동을 줄여줍니다. 브랜드 정체성 때문에 커스텀 타이포그래피가 필수적이라면, 서브셋을 적극적으로 생성하고 폰트를 늦게 로드하세요. 폰트 전송을 직접 제어할 수 있도록 폰트를 직접 호스팅하는 것도 고려해 볼 수 있습니다.

합성 테스트뿐만 아니라 실제 하드웨어로 모니터링하기

Lighthouse, WebPageTest 등과 같은 합성 테스트 도구는 스로틀링을 시뮬레이션하지만, 발열 관리, 실제 부하 시의 스로틀링, 가비지 컬렉션 일시 중지, 스토리지 병목 현상과 같은 저사양 하드웨어의 모든 특수성을 모방하지는 못합니다. PageSpeed Insights가 2024년 12월에 CPU 스로틀링을 4배에서 1.2배로 변경함에 따라 랩 점수가 실제 저가형 기기 성능을 더욱 대변하지 못하게 되었다는 점에 유의하세요.

저렴한 Android 스마트폰을 구입하여 사이트를 탐색해 보세요. 이 작업을 주기적으로 수행하기 부담스럽다면 CoreDash와 같은 RUM 도구를 사용하여 기기 등급별로 데이터를 분류하세요. P75 LCP가 iPhone 15에서는 우수하지만 Xiaomi Redmi 9에서는 형편없다면, 누구를 위해 최적화하고 있는지 솔직해질 때입니다.