반응형 웹 폰트 로딩: 디바이스 인식 전략

더 빠른 LCP와 제로 레이아웃 이동을 위한 반응형 폰트 로딩 전략

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-03-05

반응형 폰트 디스플레이 및 반응형 사전 로딩 전략

Core Web Vitals 전문가로서 저는 매일 다양한 창의적인 솔루션들을 봅니다. 대부분은 큰 의미가 없지만, 가끔 특정 사이트에 확실히 적용될 만큼 단순하고 우아한 전략을 접하곤 합니다.

2025 Web Almanac에 따르면, 88%의 웹사이트가 웹 폰트를 사용하며 페이지당 중앙값 기준 4개의 폰트 파일을 로드합니다. 그러나 폰트를 사전 로드하는 사이트는 12%에 불과하며, font-display: optional을 사용하는 사이트는 겨우 0.5%입니다. 대부분의 사이트가 폰트 로딩을 획일적인 문제로 취급합니다. 이 글에서는 데스크톱과 모바일에서 폰트를 다르게 로드하는 더 스마트한 접근 방식을 설명합니다.

이 전략은 데스크톱에서는 반응형 사전 로딩과 font-display: optional을 결합하고(Flash Of Unstyled Text 제거), 모바일에서는 font-display: swap을 결합합니다(시각적 일관성보다 빠른 텍스트 렌더링 우선).

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

tip: 이 전략은 LCP 요소 이전에 여러 폰트, 스타일시트 및 스크립트를 로드하는 사이트, 즉 크리티컬 렌더링 패스가 큰 사이트에서 잘 작동합니다. 사이트가 가벼운 단일 폰트를 로드하는 경우, 추가적인 복잡성을 감수할 가치가 없습니다.

조기 폰트 로딩의 문제점

Core Web Vitals를 최적화할 때 항상 적용되는 간단한 규칙이 하나 있습니다:
"Largest Contentful Paint 이전에 수행하는 모든 작업은 해당 Largest Contentful Paint를 지연시킵니다."

이 원칙은 웹 폰트에도 적용됩니다. 페이지 로드 중 웹 폰트 로딩을 우선시하면 UX가 향상될 수 있지만, 사이트가 특정 디바이스 유형에서 Core Web Vitals 기준을 충족하는 데 어려움을 겪고 있다면 UX와 LCP 개선 사이의 균형을 맞춰야 할 수 있습니다.

2025 Web Almanac 성능 챕터에 따르면, 모바일 페이지의 약 24%에서 텍스트가 LCP 요소입니다. 텍스트가 LCP 요소일 때, 폰트 로딩 전략은 LCP 점수에 직접적인 영향을 미칩니다. 이미지가 LCP 요소인 나머지 76%의 페이지에서도, 폰트는 초기 네트워크 대역폭을 두고 경쟁하며 이미지 로드를 뒤로 밀어낼 수 있습니다.

아래 네덜란드 신문 사이트의 예시를 살펴보겠습니다. 모바일 디바이스에서 LCP 요소 이전에 3개의 폰트가 대기열에 추가됩니다. 이로 인해 3개의 폰트가 초기 네트워크 리소스를 두고 경쟁하게 되어 이미지 로드 타이밍이 지연됩니다.

font-display: optional과 swap의 이해

반응형 전략을 살펴보기 전에, 이 전략이 의존하는 두 가지 font-display 값에 대해 이해해야 합니다. font-display에 대한 더 넓은 개요는 웹폰트 로드 중 텍스트가 계속 표시되도록 하는 방법을 참조하세요.

font-display: swap은 fallback 폰트를 즉시 표시하고 커스텀 폰트가 로드되면 교체합니다. 이는 텍스트가 처음부터 표시되므로 LCP에 매우 좋습니다. 단점은 커스텀 폰트가 도착하여 fallback을 대체할 때, 폰트 메트릭의 차이로 인해 눈에 띄는 레이아웃 이동이 발생하여 CLS 점수를 훼손할 수 있다는 것입니다. 약 50%의 사이트가 swap을 사용하며, 단연코 가장 인기 있는 값입니다.

font-display: optional은 브라우저에 폰트를 로드할 시간을 약 100ms 정도 부여합니다. 폰트가 시간 내에 도착하면(일반적으로 캐시나 빠른 사전 로딩에서) 사용됩니다. 그렇지 않으면 전체 페이지 로드 동안 fallback 폰트가 사용되며 교체(swap)는 발생하지 않습니다. 이는 레이아웃 이동이 0임을 의미하지만, 첫 방문 시 커스텀 폰트가 표시되지 않을 수 있습니다. optional이 CLS에 가장 안전한 옵션임에도 불구하고, 0.5%의 사이트만이 사용하고 있습니다.

Chrome 83부터 font-display: optional을 <link rel="preload">와 결합하면 첫 번째 페인트가 최대 ~100ms(절대 최대 1500ms)까지 차단되어 폰트가 도착하기를 기다립니다. 폰트가 사전 로드(preload)되면, 거의 항상 해당 시간 내에 도착합니다. 결과적으로 첫 페인트 시 스타일이 적용된 텍스트가 렌더링되며, FOUT 0, 레이아웃 이동 0을 달성합니다. 이것이 반응형 전략의 데스크톱 측면이 매우 잘 작동하는 이유입니다.

해결책: 반응형 폰트 전략!

초기 네트워크 경쟁이 치열한 이와 같은 경우, 디바이스 유형을 구분하는 것이 합리적입니다. 일반적으로 유선(및 더 빠른 네트워크 연결)을 사용하는 더 빠른 데스크톱 디바이스는 한 번에 더 많은 초기 네트워크 리소스를 처리할 수 있으므로, 일부 중요한 폰트 파일들을 사전 로드하는 것이 완벽하게 이치에 맞습니다.

반면 모바일 디바이스는 최적이지 않은 네트워크 조건 하에서 출퇴근길에 사용될 수 있습니다. 또한 모바일 디바이스는 데스크톱에 비해 CPU가 느리고 가용 메모리가 적은 경우가 많습니다. 이러한 한계는 디바이스 유형에 따라 폰트 로딩을 다르게 취급하는 것이 합리적일 수 있음을 의미합니다.

  • Desktop: 폰트를 사전 로드하면 대역폭과 처리 능력이 더 우수한 디바이스에서 렌더링 성능이 향상됩니다. font-display: optional을 사용하여 폰트 교체 문제를 제거하십시오. 사전 로딩과 결합하면 Chrome은 폰트를 기다리기 위해 렌더링을 잠시(최대 ~100ms) 차단하여, CLS 없이 첫 페인트에 스타일이 적용된 텍스트를 제공합니다.
  • Mobile: 네트워크 경쟁 때문에 폰트를 사전 로드하지 마십시오. 더 빠른 텍스트 렌더링을 위해 font-display: swap을 사용하십시오. 이 방식은 커스텀 폰트가 백그라운드에서 계속 로드되는 동안 fallback 폰트를 즉시 표시하여, 성능이 낮은 디바이스에서 더 나은 경험을 제공합니다.

<link rel="preload">와 미디어 쿼리를 사용한 구현

폰트를 일괄적으로 로드하는 대신, HTML <link> 태그의 media 속성과 CSS를 사용하여 디바이스 유형에 따라 다른 폰트 전략을 적용할 수 있습니다.

완전한 구현

<head>
  <!-- 뷰포트 메타 태그는 미디어 조건부 사전 로드보다 반드시 먼저 와야 합니다 -->
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <!-- 데스크톱 전용 폰트 사전 로드 -->
  <link rel="preload" href="/fonts/custom-font.woff2"
        as="font" type="font/woff2" crossorigin
        media="(min-width: 768px)">

  <style>
    /* 모바일: swap은 빠른 텍스트 렌더링을 보장합니다 */
    @font-face {
        font-family: 'CustomFont';
        src: url('/fonts/custom-font.woff2') format('woff2');
        font-display: swap;
    }

    /* 데스크톱: optional + preload = 첫 페인트 시 스타일이 적용된 텍스트 */
    @media (min-width: 768px) {
        @font-face {
            font-family: 'CustomFont';
            src: url('/fonts/custom-font.woff2') format('woff2');
            font-display: optional;
        }
    }

    body {
        font-family: 'CustomFont', sans-serif;
    }
  </style>
</head>

이 구현에 대한 몇 가지 중요한 세부 사항은 다음과 같습니다:

  1. Viewport 메타 태그 순서: <meta name="viewport"> 태그는 사전 로드 링크 앞에 나타나야 합니다. 브라우저의 사전 로드 스캐너는 다른 메타 태그를 파싱하기 전에 media 속성을 평가합니다. 뷰포트가 설정되지 않은 경우 미디어 쿼리는 모바일 디바이스에서 잘못된 크기를 기준으로 평가됩니다.
  2. 완전한 @font-face 선언: 각 @font-face 블록은 font-family와 src를 모두 포함해야 합니다. 일반적인 CSS 속성과 달리 @font-face 설명자는 캐스케이딩(cascade)되지 않습니다. 전체 폰트 페이스를 다시 선언하지 않고 두 번째 블록에서 font-display만 재정의할 수 없습니다. 브라우저는 불완전한 @font-face 규칙을 무시합니다.
  3. crossorigin 속성: crossorigin 없이 사전 로드된 폰트는 두 번 가져옵니다(fetch). 동일 출처(same-origin) 폰트이더라도 폰트 사전 로드 시 항상 이를 포함하십시오.
  4. 일치하는 중단점(Breakpoints): 사전 로드의 media 속성(768px)은 CSS 미디어 쿼리(768px)와 일치해야 합니다. 일치하지 않으면, 한 중단점에서 사전 로드하고 다른 중단점에서는 잘못된 font-display를 적용하게 됩니다.

Fallback 폰트 매칭으로 모바일에서 레이아웃 이동 줄이기

모바일 전략은 font-display: swap을 사용하며, 이는 커스텀 폰트가 fallback을 대체할 때 짧은 Flash Of Unstyled Text가 발생함을 의미합니다. CSS 폰트 메트릭 재정의(overrides)를 사용하여 이 시각적인 점프를 최소화할 수 있습니다:

@font-face {
    font-family: 'CustomFont Fallback';
    src: local('Arial');
    ascent-override: 105%;
    descent-override: 25%;
    size-adjust: 97%;
}

body {
    font-family: 'CustomFont', 'CustomFont Fallback', sans-serif;
}

ascent-override, descent-override, size-adjust 설명자를 사용하면 fallback 폰트의 크기를 커스텀 폰트에 맞출 수 있습니다. swap이 발생할 때 텍스트는 거의 움직이지 않습니다. 이러한 설명자는 모든 최신 브라우저에서 지원됩니다. Capsize와 같은 라이브러리는 특정 폰트에 대한 올바른 재정의 값을 자동으로 계산할 수 있습니다.

이 방식의 이점

  • Desktop UX: 데스크톱은 첫 페인트 시 웹 폰트로 렌더링되어 FOUT와 FOIT를 모두 방지합니다. 폰트 로딩으로 인한 레이아웃 이동이 0입니다.
  • Mobile 성능: font-display: swap은 커스텀 폰트가 아직 로드되지 않더라도 사용자가 텍스트를 즉시 볼 수 있도록 보장합니다. 사전 로드를 하지 않는다는 것은 폰트가 대역폭을 두고 LCP 이미지와 경쟁하지 않음을 의미합니다.
  • 선언적 단순성: 순수 HTML 및 CSS. JavaScript도, 폰트 로딩 라이브러리도, 프레임워크 종속성도 없습니다. 이는 또한 이미 적용되어 있는 어떠한 리소스 우선순위 지정 전략과도 함께 작동함을 의미합니다.

실제 현업에서의 영향

이 전략은 제가 이커머스 사이트를 감사(audit)하면서 접한 실제 예시를 기반으로 합니다. 해당 사이트는 헤딩 폰트, 본문 폰트, 아이콘 폰트 등 3개의 커스텀 폰트를 로드했습니다. 데스크톱에서는 모든 것이 충분히 빠르게 로드되어 폰트가 문제를 일으키는 경우가 거의 없었습니다. 하지만 4G 환경의 모바일에서는 3개의 폰트 사전 로드가 히어로 이미지와 경쟁하여 LCP를 2.5초 임계값보다 훨씬 높게 밀어내고 있었습니다.

반응형 전략(데스크톱에서만 사전 로드, 모바일에서 폰트 사전 로드 제거)을 구현한 후의 결과는 다음과 같습니다:

  • Desktop: 첫 페인트에 스타일이 적용된 폰트가 나타나며 CLS와 UX가 개선되었습니다. 사전 로드 + font-display: optional 조합은 폰트와 관련된 모든 레이아웃 이동을 제거했습니다.
  • Mobile: 폰트가 더 이상 초기 대역폭을 두고 경쟁하지 않기 때문에 First Contentful Paint 및 Largest Contentful Paint가 더 빨라졌습니다. 히어로 이미지가 경합 없이 로드되었습니다.

DebugBear의 연구에 따르면 그 효과가 입증되었습니다: 제대로 적용할 경우 폰트 사전 로딩은 LCP를 약 30% 개선(1.82초에서 1.24초로)할 수 있습니다. 하지만 과도하게 사용할 경우(어떤 사이트는 38개의 폰트를 사전 로드함), 사전 로딩은 상황을 더 악화시킵니다. 반응형 접근 방식은 모바일에서의 비용(cost) 없이 데스크톱에서 사전 로딩의 이점을 제공합니다.

CoreDash가 모니터링한 사이트 전반에 걸쳐, 디바이스 유형에 관계없이 동일한 방식으로 모든 폰트를 로드하는 페이지는 모바일 페이지 로드의 70%가 LCP를 통과하는 반면, 폰트가 전략적으로 사전 로드되는 경우에는 약 82%가 LCP를 통과합니다. 사전 로드 + optional 조합이 가장 잘 작동하는 데스크톱에서는 그 격차가 훨씬 더 큽니다.

이 전략을 사용해야 할 때 (그리고 사용하지 말아야 할 때)

다음의 경우에 이 전략을 사용하십시오:

  • 사이트에서 2개 이상의 커스텀 폰트 파일을 로드하는 경우
  • 모바일과 데스크톱의 Core Web Vitals 성능 프로필이 다른 경우 (데스크톱은 통과하지만 모바일은 LCP로 인해 어려움을 겪는 사이트에서 흔함)
  • 모바일에서 폰트가 다른 중요 리소스(히어로 이미지, 크리티컬 CSS)와 경쟁하는 경우
  • 폰트를 직접 호스팅(self-hosting)하는 경우 (이 전략은 모든 폰트 호스팅에서 작동하지만, 직접 호스팅하면 사전 로드 경로에 대한 완전한 제어권을 얻을 수 있습니다)

다음의 경우에 이 전략을 건너뛰십시오:

  • 가벼운 WOFF2 폰트(20 KB 미만) 하나만 로드하는 경우. 반응형 로딩의 오버헤드는 그럴 가치가 없습니다.
  • 사이트가 이미 모바일과 데스크톱 모두에서 모든 Core Web Vitals를 통과하는 경우. 존재하지 않는 문제에 복잡성을 추가하지 마십시오.
  • 시스템 폰트에 의존하는 경우. 이미 font-family: system-ui, sans-serif를 사용 중이라면 최적화할 대상이 없습니다.

이 전략이나 기타 폰트 로딩 전략을 구현한 후에는, RUM(Real User Monitoring)으로 그 영향을 모니터링하여 해당 변경이 실제로 필드 데이터를 개선했는지 확인하십시오. 실험실(Lab) 테스트는 이 전략을 가치 있게 만드는 실제 네트워크 조건의 변동성을 놓칠 수 있습니다.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

실시간 데이터. 28일 평균 말고.

CoreDash는 라우트, 디바이스, 브라우저, 회선별로 모든 지표를 쪼개서 보여줍니다.

CoreDash 둘러보기
반응형 웹 폰트 로딩: 디바이스 인식 전략Core Web Vitals 반응형 웹 폰트 로딩: 디바이스 인식 전략