더 나은 Core Web Vitals를 위한 Google 폰트 자체 호스팅
Google 폰트를 자체 호스팅하고 더 나은 Core Web Vitals를 위해 폰트를 최적화하는 방법을 알아보세요.
향상된 Core Web Vitals를 위한 Google 폰트 자체 호스팅
2025 Web Almanac에 따르면 Google 폰트는 전체 웹사이트의 54%에서 사용됩니다. 이러한 사이트의 대부분은 Google 서버에서 폰트를 로드합니다. 이것이 문제입니다. 모든 Google 폰트 요청은 사전 로드, 캐시 또는 제어할 수 없는 외부 연결, 렌더링 차단 CSS 및 폰트 파일을 추가합니다. 동일한 폰트를 자체 호스팅하면 이러한 모든 문제가 해결되며 약 10분밖에 걸리지 않습니다.
최종 검토: 2026년 2월, Arjen Karel
Core Web Vitals 이해하기
Core Web Vitals는 Google이 순위 신호로 사용하는 세 가지 지표입니다: LCP(로딩), INP(상호작용성), CLS(시각적 안정성). 폰트를 자체 호스팅하면 주로 LCP 및 CLS가 향상되며, First Contentful Paint (FCP)도 개선할 수 있습니다.
Google 폰트가 Core Web Vitals에 미치는 영향
타이포그래피와 디자인을 향상시키기 위해 종종 웹 페이지에 포함되는 Google 폰트는 Core Web Vitals, 주로 Largest Contentful Paint (LCP) 및 Cumulative Layout Shift (CLS)에 상당한 영향을 미칠 수 있습니다.
제가 이야기하는 대부분의 사람들에게 이것은 새로운 정보입니다. Google CDN은 세계 최고인 것으로 여겨집니다. 그렇다면 왜 Google 폰트가 페이지 속도에 나쁜 영향을 미칠까요?
"공유 캐시" 논쟁은 끝났습니다. 많은 개발자들은 Google 폰트가 매우 인기가 있기 때문에 방문자가 이미 다른 사이트에서 폰트를 캐시했을 것이라고 여전히 믿습니다. 이는 2020년 이전에는 사실이었습니다. Chrome v86 및 Safari(2013년부터 적용) 이후로 브라우저는 최상위 도메인별로 HTTP 캐시를 분할합니다. 즉, 방문자가 다른 어떤 사이트를 방문했는지와 관계없이 모든 신규 방문자에 대해 사이트가 Google 폰트를 처음부터 새로 다운로드합니다. 공유 CDN 캐시의 성능상 이점은 더 이상 존재하지 않습니다.
스타일시트는 신규 방문자의 브라우저 캐시에 절대 존재하지 않습니다. Google 폰트의 첫 번째 문제는 fonts.google.com 또는 fonts.googleapis.com에서 호스팅하는 외부 스타일시트에 의존한다는 것입니다. 이 스타일시트는 (많은 사람들이 생각하는 것과 달리) 다른 도메인에서 재사용할 수 없습니다. 이는 렌더링 차단 스타일시트가 첫 방문자를 위해 초고속 브라우저 캐시에서 제공되는 일이 절대 없으며, 항상 페이지 렌더링을 지연시킴을 의미합니다.
2개의 새로운 서버에 대한 2개의 연결이 필요합니다. 두 번째 문제는 CSS 파일과 폰트 파일을 다운로드하기 위해 2개의 다른 서버에 연결해야 한다는 것입니다. 새로운 서버에 대한 각각의 초기 연결은 심각한 오버헤드를 가지며 추가 시간이 소요됩니다. 이미 열려 있는 우리 서버의 연결에서 파일을 제공했다면 절약할 수 있었을 시간입니다. 이를 피하기 위해 Google은 자사 도메인에 대한 사전 연결(preconnect)을 권장합니다. 이는 문제를 약간 완화시키지만 여전히 완벽과는 거리가 멉니다.
font-display 속성에 대한 제어가 제한적입니다. Google 폰트에서 font-display 속성을 설정할 수는 있지만 전역으로만 정의할 수 있습니다. 즉, 모든 woff2 파일이 동일한 font-display 설정을 갖게 됩니다.
woff2 파일의 최종 위치를 알 수 없습니다. 이는 가장 중요한 폰트를 사전 로드(preload)할 수 없음을 의미합니다. 결과적으로 폰트 파일의 다운로드 대기열이 비교적 늦게 지정되고, 스타일이 적용되지 않은 텍스트의 깜빡임(FOUT)으로 인한 가시적인 레이아웃 이동이 발생할 가능성이 큽니다. 웹 폰트 로드 중 텍스트가 계속 표시되도록 보장하는 방법에 대해 자세히 알아보세요.
폰트 파일에 대한 제어권이 없습니다. 더 이상 서브셋(subset)을 만들 수 없고, 긴 캐시 헤더를 설정할 수 없으며, 자체 CDN에서 폰트를 제공할 수도 없습니다.
<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
Google 폰트 자체 호스팅의 장점
Google 폰트 자체 호스팅은 외부 Google 서버에 의존하는 대신 자체 서버에서 폰트 파일을 제공하는 것을 의미합니다. 이 접근 방식은 다음과 같은 여러 가지 이점을 얻을 수 있습니다:
향상된 폰트 전송 속도: 폰트를 자체 호스팅하면 외부 서버에 대한 의존도가 줄어들어 폰트 전송이 빨라지고 결과적으로 텍스트 콘텐츠의 렌더링이 더 빨라집니다. 이러한 개선은 LCP에 긍정적인 영향을 미쳐 가장 큰 텍스트 요소가 더 빨리 표시되도록 보장합니다. 2025 Web Almanac에 따르면 자체 호스팅이 증가하고 있습니다: 현재 데스크톱 사이트의 31.5%가 폰트를 전적으로 자체 호스팅하고 있으며, 이는 2024년 28%에서 증가한 수치입니다.
레이아웃 이동(Layout Shifts) 감소: Google 폰트를 자체 호스팅하면 폰트가 로드되고 표시되는 방식을 제어할 수 있어 지연된 폰트 렌더링으로 인해 발생하는 레이아웃 이동의 가능성을 최소화합니다. 이는 웹 페이지의 전반적인 시각적 안정성을 향상시키고 CLS에 긍정적인 영향을 미칩니다.
캐싱 및 사전 로드(preloading)에 대한 완벽한 제어: 자체 호스팅을 하면 모든 폰트 파일의 정확한 URL을 알 수 있습니다. 즉, 중요한 폰트를 사전 로드하고, 공격적인 캐시 헤더(1년 이상)를 설정하며, 페이지의 나머지 부분과 동일한 연결에서 폰트를 제공할 수 있습니다.
GDPR 준수
2022년 1월, 뮌헨 지방 법원은 판결을 내렸습니다. Google 서버에서 Google 폰트를 로드하는 것은 방문자의 IP 주소를 동의 없이 Google에 전송하기 때문에 GDPR을 위반한다는 내용이었습니다. 자체 호스팅은 폰트가 로드될 때 Google로 데이터가 전송되지 않으므로 이 문제를 완전히 제거합니다. 사이트에 유럽인 방문자가 있다면 이는 자체 호스팅해야 하는 또 다른 이유가 됩니다.
Google 폰트 자체 호스팅을 위한 모범 사례
더 나은 Core Web Vitals 성능을 위해 자체 호스팅된 Google 폰트를 최적화하려면 다음 모범 사례를 구현하는 것을 고려해 보세요:
WOFF2 형식만 사용: WOFF2는 최고의 압축률(WOFF보다 약 30% 작음)을 제공하며 96% 이상의 브라우저 지원을 갖추고 있습니다. WOFF2를 지원하지 않는 유일한 브라우저는 2022년 6월에 수명이 다한 Internet Explorer입니다. 이제 더 이상 WOFF fallback이 필요하지 않습니다.
폰트 서브셋(Font Subsetting): 폰트 파일 크기를 더 줄이려면 웹 페이지 콘텐츠에 필요한 문자만 포함하는 폰트 서브셋을 사용하는 것이 좋습니다. 이는 더 빠른 폰트 로드와 개선된 Core Web Vitals로 이어질 수 있습니다. Google 폰트는 이미 unicode-range별로 서브셋을 사용하고 있지만, 자체 호스팅을 할 경우 fonttools와 같은 도구를 사용하여 한 단계 더 발전시킬 수 있습니다.
전략적인 font-display 속성: 폰트 로딩 중 텍스트 렌더링을 제어하기 위해 font-display 속성을 전략적으로 구성합니다. "swap" 값은 웹 폰트가 완전히 로드될 때까지 fallback 폰트가 표시되도록 보장하여 First Contentful Paint 속도를 높입니다. "optional" 값은 폰트 스왑을 완전히 건너뛰고 fallback 폰트를 대체하지 않음으로써 레이아웃 이동을 방지합니다. 이 두 가지를 전략적으로 혼합하면 Cumulative Layout Shift와 First Contentful Paint를 모두 최적화하는 경우가 많습니다. 2025 Web Almanac에 따르면 현재 페이지의 50%가 font-display: swap을 사용하지만, 0.5%만이 font-display: optional을 사용합니다. 이는 중요하지 않은 폰트에서 최대의 CWV 성능을 얻기 위한 최선의 선택입니다.
폰트 사전 로드(Preload fonts): 링크 사전 로드 메커니즘을 사용하여 가장 중요한 폰트(최대 1개 또는 2개)를 사전 로드하여 폰트를 가능한 한 빨리 사용할 수 있도록 합니다. 동일 출처(same-origin) 폰트의 경우에도 항상
crossorigin속성을 포함해야 합니다. 그렇지 않으면 브라우저가 폰트를 두 번 다운로드합니다. 오직 페이지의 12%만이 폰트를 사전 로드하므로, 이는 쉽게 얻을 수 있는 이점입니다.
<link rel="preload" as="font" href="/fonts/inter-400.woff2" type="font/woff2" crossorigin>
Google 폰트를 자체 호스팅하는 방법 (올바른 방법)
Google 폰트를 다운로드하고 자체 호스팅하는 데는 약 10분이 걸립니다. 폰트를 사용하기 전에 항상 라이선스를 검토해야 한다는 점을 명심하세요. 대부분의 Google 폰트는 SIL Open Font License에 따라 제공되며, 상업적 용도를 포함하여 무료로 사용할 수 있습니다.
가장 빠른 방법은 즉시 사용 가능한 CSS와 함께 WOFF2 파일로 모든 Google 폰트를 다운로드할 수 있는 google-webfonts-helper를 사용하는 것입니다. 하지만 어떤 일이 일어나는지 정확히 이해하기 위해 수동으로 수행하려면 다음 단계를 따르세요:
fonts.google.com의 Google 폰트 웹사이트로 이동합니다.
사용하려는 폰트를 선택하고 포함할 폰트 굵기를 선택합니다.
폰트 페이지 상단 표시줄에서 'selected families 버튼'을 클릭합니다. 거기에서 Google이 호스팅하는 스타일시트에 대한 링크를 찾을 수 있습니다.
이 스타일시트의 URL을 복사하여 브라우저에서 엽니다. 이제 해당 폰트에 사용할 수 있는 모든 font-face 선언을 볼 수 있습니다.
하나의 폰트 파일만 사용했는데도 woff2 파일이 두 개 이상 있다는 것을 눈치채셨을 것입니다. 이는 다른 유니코드 범위에 대해 서로 다른 폰트 파일이 존재하기 때문입니다. 어떤 폰트를 다운로드해야 하는지 알아보려면 웹사이트에 임시로 Google 호스팅 스타일시트를 추가해야 합니다. 단축키 Ctrl-Shift-I를 사용하여 Chrome DevTools를 엽니다. 네트워크(Network) 탭으로 이동하여 Font를 클릭합니다. 이제 페이지를 새로고침(Ctrl-R)하여 어떤 폰트가 다운로드 트리거되는지 확인합니다.
이 폰트 파일 이름을 스타일시트의 해당 woff2 파일과 일치시킵니다. 이제 웹사이트에 어떤 폰트 파일이 사용되는지 알 수 있습니다!
다음 단계는 전체 폰트 URL을 복사하여 브라우저에서 여는 것입니다. 이렇게 하면 이 폰트 파일의 다운로드가 트리거됩니다. 이 파일을 웹사이트에 복사합니다.
7단계에서 사용된 웹 폰트용 CSS를 복사하여 스타일시트에 붙여넣습니다. URL을 Google CDN에서 자신의 서버(예: '/fonts/inter-400.woff2')로 변경하는 것을 잊지 마세요.
폰트를 사전 로드합니다(시각적으로 중요한 폰트인 경우).
이제 원하는 Google 폰트를 성공적으로 다운로드하고 자체 호스팅했습니다.
실제 사례
다음은 사전 로드, 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 데이터에 따르면 적절한 사전 로드를 통해 폰트를 자체 호스팅하는 사이트는 Google 폰트 CDN에서 로드하는 것에 비해 LCP 중앙값이 180ms 개선되는 것을 보여줍니다. 변경 사항이 제대로 작동하는지 확인하기 위해 시간에 따라 LCP, CLS 및 FCP를 추적하세요.
