Core Web Vitals 개선을 위한 Google Fonts 자체 호스팅

Core Web Vitals 개선을 위한 Google Fonts 자체 호스팅

2025 Web Almanac에 따르면 전체 웹사이트의 54%가 Google Fonts를 사용합니다. 이 중 대부분은 Google 서버에서 폰트를 로드합니다. 이것이 문제입니다. Google Fonts를 요청할 때마다 외부 연결이 추가되고, render blocking CSS가 발생하며, 직접 preload하거나 캐시하고 제어할 수 없는 폰트 파일을 불러오게 됩니다. 이 폰트를 자체 호스팅하면 이런 문제가 모두 해결됩니다. 작업 시간도 10분 정도면 충분합니다.

Arjen Karel 최종 검토: 2026년 2월

Core Web Vitals 이해하기

Core Web Vitals는 Google이 랭킹 신호로 활용하는 세 가지 지표, 즉 LCP(로딩), INP(상호작용성), CLS(시각적 안정성)를 의미합니다. 폰트를 자체 호스팅하면 주로 LCP와 CLS가 개선되며, First Contentful Paint (FCP)도 함께 향상될 수 있습니다.

Google Fonts가 Core Web Vitals에 미치는 영향

웹 페이지의 타이포그래피와 디자인을 살리기 위해 Google Fonts를 많이 사용합니다. 하지만 Google Fonts는 Core Web Vitals, 특히 Largest Contentful Paint (LCP)와 Cumulative Layout Shift (CLS)에 상당한 영향을 미칩니다.

현장에서 만나는 분들 대부분에게는 생소한 이야기입니다. Google CDN은 세계 최고 수준으로 알려져 있습니다. 그런데 왜 Google Fonts가 페이지 속도를 떨어뜨릴까요?

1. '공유 캐시' 논리는 이제 끝났습니다. 여전히 많은 개발자가 Google Fonts의 높은 인기도 덕분에 방문자가 다른 사이트에서 이미 해당 폰트를 캐시해 두었을 것이라 믿습니다. 2020년 이전에는 맞는 말이었습니다. 하지만 Chrome 86버전과 Safari(2013년부터 적용) 이후 브라우저는 최상위 도메인별로 HTTP 캐시를 분할합니다. 즉, 방문자가 이전에 어떤 사이트를 방문했든 상관없이 새로운 방문자가 올 때마다 사이트는 Google Fonts를 처음부터 다시 다운로드합니다. 공유 CDN 캐시를 통한 성능상 이점은 이제 더 이상 존재하지 않습니다.

2. 첫 방문자에게 스타일시트는 브라우저 캐시에 절대 없습니다. Google Fonts의 첫 번째 문제는 fonts.google.com이나 fonts.googleapis.com에서 호스팅하는 외부 스타일시트에 의존한다는 점입니다. 흔히 생각하는 것과 달리 서로 다른 도메인끼리는 이 스타일시트를 재사용할 수 없습니다. 따라서 첫 방문자에게는 이 render blocking 스타일시트가 빠른 브라우저 캐시에서 제공될 수 없으며, 항상 페이지 렌더링을 늦추게 됩니다.

3. 새로운 서버 2곳과 2번의 연결이 필요합니다. 두 번째 문제는 CSS 파일과 폰트 파일을 다운로드하기 위해 서로 다른 서버 2곳에 연결해야 한다는 점입니다. 새 서버에 대한 초기 연결은 매번 심각한 오버헤드를 유발하며 추가 시간을 소모합니다. 자체 서버에 이미 열려 있는 연결을 통해 파일을 제공했다면 아낄 수 있었던 시간입니다. 이를 피하기 위해 Google은 도메인에 preconnect할 것을 권장합니다. 이렇게 하면 문제가 다소 완화되기는 하지만 여전히 완벽과는 거리가 멉니다.

4. font-display 속성에 대한 제어권이 제한적입니다. Google Fonts에서도 font-display 속성을 설정할 수는 있지만 전역으로만 지정할 수 있습니다. 즉, 모든 woff2 파일에 동일한 font-display 설정이 적용됩니다.

5. woff2 파일의 최종 위치를 알 수 없습니다. 즉, 가장 중요한 폰트를 preload할 수 없습니다. 이로 인해 폰트 파일의 다운로드 대기열 진입 시점이 늦어지고, FOUT(flash of unstyled text)로 인한 눈에 띄는 레이아웃 이동이 발생하기 쉽습니다. 웹폰트 로드 중에도 텍스트가 항상 표시되도록 유지하는 방법에 대해 자세히 알아보세요.

6. 폰트 파일에 대한 제어권이 전혀 없습니다. 서브셋을 추가로 생성할 수도 없고, 캐시 헤더를 길게 설정할 수도 없으며, 자체 CDN을 통해 제공할 수도 없습니다.

<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Google Fonts 자체 호스팅의 이점

Google Fonts 자체 호스팅은 외부 Google 서버에 의존하는 대신 자체 서버에서 폰트 파일을 직접 제공하는 방식입니다. 이 방식을 적용하면 다음과 같은 여러 이점을 얻을 수 있습니다:

1. 폰트 전송 속도 향상: 폰트를 자체 호스팅하면 외부 서버에 대한 의존성이 줄어들어 폰트 전송이 빨라지고, 결과적으로 텍스트 콘텐츠의 렌더링 속도도 빨라집니다. 이러한 개선은 가장 큰 텍스트 요소를 더 빠르게 표시하여 LCP에 긍정적인 영향을 줍니다. 2025 Web Almanac에 따르면 자체 호스팅 도입률은 꾸준히 증가하고 있습니다. 데스크톱 사이트 중 자체 호스팅 방식으로만 폰트를 제공하는 비율이 2024년 28%에서 현재 31.5%로 증가했습니다.

2. 레이아웃 이동 감소: Google Fonts를 자체 호스팅하면 폰트 로드 및 표시 방식을 직접 제어하여 폰트 렌더링 지연으로 인한 레이아웃 이동 가능성을 최소화할 수 있습니다. 이는 웹 페이지의 전반적인 시각적 안정성을 높이고 CLS에 좋은 영향을 줍니다.

3. 캐싱과 preload에 대한 완전한 제어권: 자체 호스팅을 하면 모든 폰트 파일의 정확한 URL을 파악할 수 있습니다. 즉, 핵심 폰트를 preload하거나 1년 이상의 적극적인 캐시 헤더를 설정할 수 있으며, 페이지의 다른 리소스와 동일한 연결을 통해 폰트를 제공할 수 있습니다.

GDPR 준수

2022년 1월, 독일 뮌헨 지방법원은 동의 없이 방문자의 IP 주소를 Google로 전송한다는 이유로 Google 서버에서 Google Fonts를 로드하는 행위가 GDPR 위반이라고 판결했습니다. 자체 호스팅을 하면 폰트 로드 시 Google로 데이터가 전혀 전송되지 않으므로 이 문제를 완전히 해결할 수 있습니다. 유럽 방문자가 있는 사이트라면 자체 호스팅을 해야 할 또 하나의 분명한 이유입니다.

Google Fonts 자체 호스팅 모범 사례

자체 호스팅하는 Google Fonts의 Core Web Vitals 성능을 최적화하려면 다음 모범 사례를 적용하세요.

1. WOFF2 형식만 사용: WOFF2는 압축률이 가장 뛰어나며(WOFF보다 약 30% 작음), 브라우저 지원율도 96% 이상입니다. WOFF2를 지원하지 않는 브라우저는 2022년 6월 지원이 종료된 Internet Explorer뿐입니다. 이제 WOFF fallback은 전혀 필요하지 않습니다.

2. 폰트 서브셋(Subsetting): 폰트 파일 크기를 더 줄이려면 웹 페이지 콘텐츠에 실제로 필요한 문자만 포함하는 서브셋 작업을 적용하세요. 이렇게 하면 폰트 로드가 빨라지고 Core Web Vitals가 개선됩니다. Google Fonts는 이미 unicode-range별로 서브셋을 제공하지만, 자체 호스팅을 하면 fonttools 같은 도구를 활용해 최적화를 한 단계 더 진행할 수 있습니다.

3. 전략적인 font-display 속성 설정: font-display 속성을 전략적으로 구성하여 폰트 로드 중 텍스트 렌더링을 제어하세요. "swap" 값을 사용하면 웹폰트가 완전히 로드될 때까지 fallback 폰트를 먼저 표시하므로 First Contentful Paint를 앞당길 수 있습니다. "optional" 값은 폰트 교체(swap)를 완전히 생략하여 fallback 폰트를 교체하지 않으므로 레이아웃 이동을 방지합니다. 이 두 값을 전략적으로 적절히 조합하면 Cumulative Layout Shift와 First Contentful Paint를 모두 최적화할 수 있습니다. 2025 Web Almanac에 따르면 현재 페이지의 50%가 font-display: swap을 사용하지만, font-display: optional을 사용하는 페이지는 0.5%에 불과합니다. 그러나 optional은 중요도가 낮은 폰트에서 Core Web Vitals 성능을 극대화할 수 있는 최선의 선택입니다.

4. 폰트 preload 적용: link preload 방식을 활용해 가장 중요한 폰트(최대 1~2개)를 preload하여 가능한 한 빠르게 준비하세요. 동일 출처(same-origin) 폰트라도 반드시 crossorigin 속성을 포함해야 합니다. 그렇지 않으면 브라우저가 폰트를 중복으로 다운로드합니다. 폰트를 preload하는 페이지는 12%에 불과하므로, 적은 노력으로 확실한 성능 개선 효과를 볼 수 있습니다.

<link rel="preload" as="font" href="/fonts/inter-400.woff2" type="font/woff2" crossorigin>

Google Fonts를 올바르게 자체 호스팅하는 방법

Google Fonts를 다운로드하여 자체 호스팅하는 데는 약 10분이면 충분합니다. 폰트를 사용하기 전에 항상 라이선스를 확인해야 한다는 점을 유념하세요. 대부분의 Google Fonts는 상업적 이용을 포함해 자유로운 사용을 허용하는 SIL Open Font License로 제공됩니다.

가장 빠른 방법은 바로 사용할 수 있는 CSS와 함께 원하는 Google Fonts를 WOFF2 파일로 다운로드해 주는 google-webfonts-helper를 사용하는 것입니다. 하지만 동작 과정을 정확히 이해하기 위해 수동으로 직접 진행하려면 다음 단계를 따르세요.

1. fonts.google.com 웹사이트로 이동합니다.

2. 사용하려는 폰트를 선택하고 포함할 폰트 두께(weight)를 고릅니다.

3. 폰트 페이지 상단 바에서 'selected families' 버튼을 클릭합니다. 여기서 Google이 호스팅하는 스타일시트 링크를 확인할 수 있습니다.

   

4. 이 스타일시트 URL을 복사하여 브라우저에서 엽니다. 해당 폰트에 사용 가능한 모든 @font-face 선언문이 표시됩니다.

   

5. 폰트를 하나만 선택했는데도 woff2 파일이 여러 개 있다는 것을 알 수 있습니다. unicode-range별로 서로 다른 폰트 파일이 나뉘어 있기 때문입니다. 어떤 폰트를 다운로드해야 하는지 파악하려면 웹사이트에 Google 호스팅 스타일시트를 임시로 추가해 보세요. 단축키 Ctrl-Shift-I를 눌러 Chrome DevTools를 열고 Network 탭에서 Font를 클릭합니다. 그런 다음 페이지를 새로고침(Ctrl-R)하여 어떤 폰트 파일이 다운로드되는지 확인합니다.

6. 다운로드된 폰트 파일 이름을 스타일시트의 해당 woff2 파일과 대조합니다. 이제 웹사이트에서 실제로 사용하는 폰트 파일이 무엇인지 확인할 수 있습니다.

7. 다음 단계로 해당 폰트의 전체 URL을 복사하여 브라우저에서 엽니다. 그러면 폰트 파일 다운로드가 시작됩니다. 다운로드한 파일을 웹사이트로 복사합니다.

8. 7단계에서 확인한 웹폰트의 CSS를 복사하여 스타일시트에 붙여넣습니다. 이때 URL을 Google CDN 대신 자체 서버 경로(예: '/fonts/inter-400.woff2')로 변경해야 합니다.

9. 시각적으로 중요한 폰트라면 preload를 적용합니다.

이제 원하는 Google Fonts의 다운로드와 자체 호스팅 설정이 모두 끝났습니다.

실제 적용 예시

다음은 preload, WOFF2 단독 사용, 전략적 font-display 값, 시스템 폰트 fallback 등 모든 모범 사례를 적용한 Inter 폰트의 전체 예시입니다.

<head>
  <title>Self-Hosted Google Fonts</title>
  <!-- preload the font (crossorigin is required, even for same-origin fonts) -->
  <link rel="preload" as="font" href="/fonts/inter-400.woff2" type="font/woff2" crossorigin>
  <style>
    /* Self-hosted Inter font with WOFF2 format */
    @font-face {
      font-family: 'Inter';
      font-style: normal;
      font-weight: 400;
      src: url('/fonts/inter-400.woff2') format('woff2');
      font-display: optional;
    }

    /* Fallback to system-ui font */
    body {
      font-family: 'Inter', system-ui, sans-serif;
    }
  </style>
</head>
<body>
  <h1>Welcome to My Website</h1>
  <p>This page uses Inter with a system-ui fallback.</p>
</body>

개선 효과 모니터링

자체 호스팅 폰트로 전환한 후에는 Real User Monitoring을 통해 개선 효과를 확인하세요. CoreDash 데이터에 따르면 적절한 preload와 함께 폰트를 자체 호스팅한 사이트는 Google Fonts CDN에서 로드할 때와 비교해 LCP가 중앙값 기준 180ms 개선되었습니다. 변경 사항이 제대로 효과를 내고 있는지 확인하려면 시간 경과에 따른 LCP, CLS, FCP 변화를 추적하세요.