Lighthouse Font display: 경고 대상과 해결 방법

font-display 경고가 점수를 떨어뜨립니까?

Lighthouse는 font-display: block, auto 또는 fallback으로 로드되는 모든 웹 폰트에 Font display 인사이트("Consider setting font-display to swap or optional", Lighthouse 13 이전에는 "Ensure text remains visible during webfont load") 경고를 표시합니다. 이 항목은 점수 가중치가 0이지만, 헤드라인이 LCP 요소라면 텍스트가 숨겨져 모바일에서 LCP가 늦어집니다. 방문자에게 가장 먼저 보이는 폰트에는 swap을 지정하고, metric overrides로 fallback의 크기를 맞추십시오.

Font display 인사이트는 무엇을 검사합니까?

Lighthouse 13과 PageSpeed Insights에서 이 인사이트는 다음과 같이 안내합니다. "텍스트가 항상 표시되도록 font-display를 swap 또는 optional로 설정하는 것이 좋습니다. swap은 font metric overrides를 통해 레이아웃 이동을 줄이도록 추가 최적화할 수 있습니다." Lighthouse 13 이전에는 이 감사의 이름이 "Ensure text remains visible during webfont load"였습니다.

Lighthouse는 Chrome이 기록한 페이지 로드 트레이스를 읽습니다. 페이지에서 다운로드를 시작하는 모든 웹 폰트에 대해, 트레이스에는 Chrome이 적용한 font-display 값이 기록됩니다. 이 인사이트가 경고하는 값은 세 가지입니다:

• block: 폰트가 다운로드되는 동안 최대 3초 동안 텍스트가 보이지 않습니다.
• auto: 값을 전혀 지정하지 않은 상태입니다. Google Fonts에서 &display= 없이 전송할 때 적용되며, 이전 테마나 Font Awesome 4, Material Icons에서도 이 값을 사용합니다.
• fallback: 텍스트가 100ms 동안만 보이지 않습니다. 그럼에도 Lighthouse 13은 여기에 경고를 표시합니다.

통과하는 값은 swap과 optional 두 가지뿐입니다. 이는 Lighthouse 13에서 바뀐 부분입니다. 이전 감사에서는 block과 fallback도 통과했기 때문에, 몇 년 전 fallback으로 이를 "해결"했던 사이트도 다시 경고를 받게 됩니다. WordPress 블록 테마는 기본적으로 fallback을 사용하고, Font Awesome 5와 6은 block을 사용합니다.

"Est savings"는 트레이스에서 폰트 요청에 걸린 시간이며, 최대 3,000ms로 제한됩니다. PageSpeed Insights는 쓰로틀링 없이 트레이스를 기록하므로 수치가 작게 나오는 경우가 많습니다. 아래 보고서는 DevTools 쓰로틀링(Slow 4G)이 적용된 모바일 기기에서 장폭(condensed) 헤드라인 폰트를 사용하는 아웃도어 쇼핑몰 제품 페이지를 테스트한 결과입니다. 여기서는 본문 폰트 로드에 3초 이상 걸려 표에 상한치(3,000ms)가 표시되었습니다. 어느 쪽이든 그 시간을 그대로 돌려받을 수는 없습니다. fallback은 텍스트를 최대 100ms만 숨기며, auto의 경우 Chrome은 내비게이션 시작 2초 후에 폰트 대기를 중단하기 때문입니다.

설명 옆에 Lighthouse는 두 개의 라벨을 표시합니다. FCP는 Lighthouse가 절감 가능하다고 판단한 지표입니다. Unscored는 가중치가 0이라는 뜻으로, 인사이트 자체가 점수를 직접 바꾸지는 않습니다. block 폰트는 Speed Index와 LCP를 통해 점수에 반영됩니다.

사용되지 않는 @font-face 규칙은 이 경고를 유발하지 않습니다. 또한 Lighthouse는 트레이스를 분석하므로, Typekit 키트나 플러그인의 Google Fonts 파일처럼 직접 추가하지 않은 폰트도 목록에 표시합니다. 이전 감사에서는 외부 도메인의 폰트에 대해 "unable to check"를 출력했습니다.

웹 폰트가 로드되는 동안 브라우저에서는 무슨 일이 일어납니까?

브라우저는 화면에 보이는 요소에 폰트가 필요하다는 사실을 알기 전까지 폰트를 요청할 수 없습니다. HTML을 받고, CSS를 받은 다음, "이 제목은 Barlow Condensed를 사용한다"는 스타일 계산이 끝나야 합니다. 그제서야 폰트 요청이 시작됩니다. 쓰로틀링이 적용된 모바일 기기에서는 HTML과 CSS가 모두 들어온 후인 0.74초 시점이었습니다. 폰트는 항상 늦게 발견됩니다. preload는 이 시작 시점을 앞으로 당겨줄 뿐이며, 폰트는 이미 브라우저에서 최고 우선순위로 요청됩니다.

그 시점부터 font-display 값이 방문자에게 무엇을 보여줄지 결정합니다. 브라우저 소스 코드에 정의된 타이밍은 다음과 같습니다:

Safari와 Firefox 역시 block과 auto 설정 시 최대 3초 동안 텍스트를 숨깁니다. Firefox는 폰트의 75%가 이미 다운로드된 경우 1.5초 더 기다립니다. 두 브라우저 모두 fallback과 optional에서는 100ms 동안 텍스트를 숨기며, Firefox는 swap에서도 동일하게 100ms 동안 숨깁니다.

Chrome에서 block은 auto보다 느립니다. auto에는 2초 제한이 있지만 block에는 없기 때문입니다. 또한 Chrome의 optional에는 100ms 유예 기간이 없습니다. preload가 없으면 빠른 서버에서 제공하더라도 폰트가 첫 렌더링 시점에 맞춰 도착하는 일이 사실상 불가능합니다. preload를 적용하면 페이지가 렌더링될 수 있는 시점 전후 약 100ms 이내에 폰트가 도착할 경우 첫 렌더링에 반영될 수 있습니다. 다음 페이지에서 캐시를 통해 로드될 때는 첫 렌더링에 바로 반영됩니다.

쓰로틀링이 적용된 모바일 환경에서 0.9초 첫 페인트 시점의 제품 페이지입니다. 어두운 상자는 두 버전 모두 아직 로딩 중인 사진입니다. corewebvitals.io 테스트 페이지, Chrome 155, 412px 너비 모바일 기기, Slow 4G 및 CPU 4배 감속 환경.

block을 적용하면 첫 페인트 시점에 헤더, 브레드크럼, 별점만 표시되고 상품명이 들어갈 자리는 빈 공간으로 남습니다. 헤드라인 폰트는 크기가 작아(15kB) 1.7초에 도착합니다. 본문 폰트는 344kB로, Chrome이 대기를 중단하는 3.7초까지도 다운로드 중이어서 그때까지 사진 아래에 아무것도 표시되지 않습니다. 반면 swap을 적용하면 첫 페인트부터 상품명과 설명을 바로 읽을 수 있습니다.

3초 시점의 동일한 페이지: 헤드라인 폰트와 사진은 로드되었지만, 본문 폰트는 아직 로드되지 않았습니다.

font-display는 LCP, CLS, FCP에 영향을 줍니까?

LCP

보이지 않는 텍스트는 LCP 요소가 될 수 없습니다. block이나 auto를 사용하면 텍스트가 화면에 표시되는 시점, 즉 폰트가 도착하거나 block 기간이 끝나는 시점에 텍스트 LCP가 기록됩니다. LCP 요소가 제목이나 문단인 페이지에서 block은 LCP를 최대 3초까지 지연시킬 수 있습니다. Chrome의 auto는 지연 시간이 이보다 짧으며, Slow 4G 환경에서는 즉시 Arial로 해당 텍스트를 표시하기도 했습니다. swap을 사용하면 fallback 폰트로 렌더링된 페인트가 LCP가 되며, 이후 웹 폰트로 바뀌면서 텍스트 면적이 커지더라도 새로운 LCP 항목이 추가되지 않습니다.

위 제품 페이지에서는 모든 버전에서 사진이 LCP 요소였기 때문에 font-display가 LCP에 영향을 주지 않았습니다. 페이지에서 가장 먼저 확인해야 할 점도 바로 이것입니다. LCP 요소가 텍스트입니까, 아니면 이미지입니까? 동일한 Lighthouse 보고서의 LCP breakdown 인사이트에서 확인할 수 있습니다.

CLS

텍스트가 차지하는 공간을 바꾸는 모든 교체(swap)는 그 뒤에 오는 모든 요소를 밀어냅니다. 이는 block과 auto에서도 마찬가지입니다. 보이지 않는 텍스트도 fallback 폰트만큼의 공간을 차지하므로, 웹 폰트로 교체될 때 동일한 레이아웃 흔들림이 발생합니다. block, auto, swap 버전 모두 헤드라인 폰트가 도착하는 순간 동일하게 CLS 0.031을 기록했습니다.

기본 swap을 사용하면 1.7초에 Barlow Condensed가 도착하면서 헤드라인이 세 줄에서 두 줄로 바뀝니다. 그 아래의 모든 요소가 39px 위로 이동하면서 CLS 0.031이 발생합니다. 점선 윤곽선은 사진이 원래 있던 위치입니다.

Arial Bold의 너비를 Barlow의 너비에 맞게 조정한(size-adjust: 68.32%) fallback face를 적용한 동일한 페이지입니다. 첫 페인트부터 헤드라인이 두 줄로 표시되며 아무것도 이동하지 않아 CLS가 0입니다.

결국 swap은 Font display 인사이트는 통과하지만 레이아웃 이동은 그대로 남깁니다. 0.031은 0.1 미만이지만, 실제 제품 페이지에서는 나중에 로드되는 두 번째 폰트, 다른 폰트로 표시되는 가격, 또는 고정(sticky) 바가 맞물리면서 수치가 누적될 수 있습니다. fallback에 metric overrides를 적용하면 이러한 이동을 막을 수 있습니다.

Lighthouse는 그 원인이 폰트라고 짚어주지 않습니다. swap 버전에서 Layout shift culprits는 사진을 "Unsized image element"로 지목합니다. 하지만 해당 이미지에는 이미 width와 height가 지정되어 있습니다. 사진을 움직인 진짜 원인은 바로 그 순간 도착한 헤드라인 폰트입니다. 이미 존재하는 이미지 크기를 찾아 헤매기 전에, 레이아웃 이동 발생 시점을 폰트 요청 시간과 대조해 보십시오.

FCP

Lighthouse는 절감 효과를 FCP로 보고합니다. 하지만 대부분의 페이지에서는 다른 요소가 FCP를 결정합니다. 예시 제품 페이지의 경우 헤더와 배송 안내 바가 시스템 폰트로 되어 있어, block이든 swap이든 똑같이 0.8초에 페인트됩니다. 페이지에 웹 폰트 텍스트만 두고 진행한 개인 테스트에서도, 텍스트가 보이지 않는 동안 Chrome 155는 FCP를 112ms로 보고했습니다. Chrome은 텍스트가 페인트된 것으로 간주하고 글리프(glyph) 그리기만 건너뛰기 때문입니다. 따라서 Lighthouse가 FCP 절감 시간으로 보여주는 수치는 실제 FCP에 나타나지 않습니다. block으로 인해 실제로 손해를 보는 것은 텍스트 요소의 LCP, Speed Index, 그리고 방문자에게 보이는 화면입니다.

얼마나 많은 사이트가 이 경고를 받으며, 언제 무시할 수 있습니까?

State of CWV가 웹 폰트를 선언한 170,706개 사이트의 홈페이지에 있는 @font-face 규칙을 측정한 결과, 폰트가 로드될 때 이 인사이트를 유발하는 규칙이 절반에 달했습니다. 39.7%는 값이 없었고(auto), 9.6%는 block, 0.9%는 fallback을 사용했습니다. optional 값을 조금이라도 사용하는 사이트는 471곳에 불과했습니다.

홈페이지에서 로드하는 폰트 파일 수와 @font-face 규칙의 font-display 값에 따라 분류한 모바일 우수 LCP 사이트 비율. State of CWV, 2026년 10월: 웹 폰트를 선언한 170,706개 사이트, 모바일 CrUX p75 기준, 우수 LCP는 2.5초 이하.

폰트 파일이 한두 개인 경우에는 차이가 거의 없습니다. swap이나 optional만 사용한 사이트의 88%가 모바일에서 우수한 LCP를 기록한 반면, block, auto, fallback만 사용한 사이트는 87%였습니다. 폰트 파일이 6~10개인 경우 격차는 6%포인트로 벌어지고, 11개 이상이면 9%포인트까지 벌어집니다. 두 방식을 혼용하는 사이트의 성적이 가장 나쁩니다. 이런 사이트는 @font-face 규칙의 중앙값이 18개인 다른 그룹에 비해 훨씬 많은 44개를 선언하고 있는데, 이는 테마 폰트에 플러그인 폰트, 아이콘 폰트까지 뒤섞인 전형적인 구성입니다. 그룹 간 CLS 차이는 거의 없습니다.

이는 상관관계일 뿐입니다. 폰트 관리에 신경 쓰는 사이트는 대개 다른 모든 요소도 잘 관리합니다. 앞서 살펴본 브라우저 동작까지 종합했을 때 필자의 원칙은 명확합니다. 폰트 파일 수를 먼저 줄이고, 그 다음에 font-display를 설정하십시오.

다음의 경우에는 이 경고를 그대로 두어도 됩니다:

• 푸터나 후기처럼 폰트가 below the fold 텍스트만 렌더링할 때
• LCP 요소가 이미지이고 폰트로 인한 레이아웃 이동이 없을 때

field data에서 폰트 문제를 어떻게 확인합니까?

Lighthouse는 하나의 시뮬레이션 모바일 기기에서 한 번 측정한 결과만 제공합니다. 실제 방문자의 네트워크 연결 상태는 제각각이며, 재방문자는 폰트를 캐시에 보관하고 있습니다. CoreDash의 두 가지 분석 데이터를 보면 폰트로 인한 성능 저하가 실제로 발생하는지 확인할 수 있습니다.

• LCP by element. 모바일에서 LCP 요소가 제목이나 문단인 경우, block이나 auto로 설정된 폰트는 폰트 다운로드를 기다리는 모든 방문에서 LCP를 지연시킵니다. LCP 요소가 이미지라면 폰트는 LCP에 아무런 영향을 주지 않습니다.
• CLS by element. 폰트 교체(swap)는 텍스트 아래에 위치한 사진, 다음 섹션, 구매 버튼 등을 밀어냅니다. CoreDash는 이동한 요소의 이름을 표시해 줍니다. 폰트가 원인이라고 직접 명시하지는 않지만, 이동한 요소가 제목이나 문단 바로 아래에 있고 width와 height가 지정되어 있다면 폰트 교체가 원인일 가능성이 높습니다.

CrUX는 도메인(origin) 또는 특정 URL에 대해 최근 28일간의 동일한 지표를 p75 기준으로 제공하지만, 어떤 요소가 원인인지에 대한 세부 분석(attribution)은 제공하지 않습니다.

LCP by element

CLS by element

샘플 쇼핑몰 acme-pagespeed.com의 CoreDash 데이터(모바일, p75 기준). 상품 제목은 다른 어떤 요소보다 많은 세션에서 LCP 요소로 잡혔으며, LCP는 3.28초였습니다. 반면 상품 사진이 LCP 요소였을 때의 LCP는 2.21초였습니다. CLS 표에서는 제목 바로 아래에 있는 해당 사진이 최상단 행을 차지했습니다(1,214개 세션에서 0.07). 여전히 양호(good) 등급이지만, 이만큼 많은 세션에서 이동한 다른 요소는 없습니다.

DevTools에서 경고가 발생한 폰트를 어떻게 찾습니까?

Chrome에서 페이지를 열고 Performance 패널로 이동한 뒤, 네트워크를 Slow 4G로, CPU를 4배 감속(4x slowdown)으로 설정하고 새로고침을 녹화하십시오. Insights 사이드바에 경고가 발생한 모든 폰트와 함께 Font display가 표시됩니다. 이를 클릭하면 DevTools가 Network 트랙에서 해당 폰트 요청을 강조 표시합니다.

그런 다음 각 폰트 요청이 끝나는 위치, LCP 마커의 위치, 그리고 폰트 로드가 끝난 직후 Layout shifts 트랙에 레이아웃 이동이 발생했는지 확인하십시오.

경고가 발생한 파일을 가리키는 모든 @font-face를 찾으려면 Sources 패널을 열고 전체 파일 검색(Windows: Ctrl+Shift+F, Mac: Cmd+Option+F)으로 해당 파일 이름을 검색한 뒤, 검색된 각 규칙에 값을 지정하십시오.

Font display 인사이트는 어떻게 해결합니까?

Lighthouse 표에 있는 폰트 URL을 보면 출처를 알 수 있으며, 이에 따라 font-display를 설정할 위치와 설정 가능 여부가 결정됩니다.

직접 정의한 @font-face

자체 도메인의 폰트 중 URL에 /wp-content/, /cdn/fonts/, /_next/가 포함되지 않은 것은 자체 CSS에서 로드되는 폰트입니다. 두 번째 스타일시트에 복사된 항목을 포함하여 해당 폰트의 모든 @font-face 규칙에 font-display: swap을 추가하십시오. 아이콘 폰트는 예외이며, 아래 내용을 참고하십시오.

@font-face {
  font-family: "Barlow Condensed";
  src: url(/fonts/barlow-condensed-700.woff2) format("woff2");
  font-weight: 700;
  font-display: swap;
}

Google Fonts

표에는 fonts.gstatic.com으로 표시되지만, 실제 설정은 폰트를 로드하는 fonts.googleapis.com/css2 링크에서 해야 합니다. 여기에 &display=swap을 추가하십시오:

<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Barlow+Condensed:wght@700&display=swap">

더 빠른 방법은 폰트를 직접 호스팅하는 것입니다. 추가 연결이 필요 없고 preload를 직접 제어할 수 있습니다.

Adobe Fonts

use.typekit.net의 폰트는 fonts.adobe.com의 웹 프로젝트 설정에서 font-display를 가져옵니다. 프로젝트 편집(Edit Project)을 선택하고 사이드바에서 설정하십시오. Adobe의 기본값은 auto이며, URL에 매개변수를 추가해도 아무런 효과가 없습니다.

WordPress

테마 폰트는 URL에 /wp-content/themes/가 포함되어 있습니다. 블록 테마의 경우 theme.json에서 각 font face별로 fontDisplay를 설정하십시오:

"fontFace": [{
  "fontFamily": "Barlow Condensed",
  "fontWeight": "700",
  "fontStyle": "normal",
  "fontDisplay": "swap",
  "src": ["file:./assets/fonts/barlow-condensed-700.woff2"]
}]

클래식 테마의 경우 wp_enqueue_style의 Google Fonts URL에 &display=swap을 추가하거나, 테마 자체의 @font-face 규칙에 font-display를 넣으십시오. /wp-content/plugins/ 경로의 폰트는 플러그인이나 페이지 빌더에서 사용하는 것이므로 해당 설정에서 폰트 옵션을 먼저 찾아보십시오. 페이지 빌더가 로드하는 Google Fonts의 경우, Elementor 설정 위치는 Elementor > Editor > Settings의 Advanced 탭에 있는 Google Fonts Load입니다. OMGF 플러그인은 Google Fonts를 로컬에서 호스팅하고 swap을 강제로 적용할 수 있습니다. 나머지 폰트 및 CSS 최적화 작업은 WordPress 가이드를 참고하십시오.

Shopify

Shopify 테마 폰트는 쇼핑몰 도메인의 /cdn/fonts/ 경로를 가집니다. 이 폰트들은 theme.liquid의 font_face 필터를 통해 로드되는데, font_display를 지정하지 않으면 font-display 속성이 작성되지 않습니다:

{{ settings.type_header_font | font_face: font_display: 'swap' }}

Dawn 테마에는 이미 이 설정이 적용되어 있습니다.

Next.js

next/font는 기본적으로 display: 'swap'을 사용하며, 폰트를 preload하고 metric overrides(adjustFontFallback)가 적용된 fallback을 생성합니다. 해당 폰트의 URL에는 /_next/static/media/가 포함됩니다. 이 경로를 가진 폰트에서 경고가 발생했다면 next/font 호출 시 다른 값(display: 'block')이 지정된 것이므로 그곳에서 수정하십시오. 이 경로가 없는 폰트에서 경고가 발생했다면 레이아웃에 들어간 Google Fonts <link> 태그나 컴포넌트 라이브러리의 CSS 파일 등 다른 방식으로 로드된 것입니다.

변경할 수 없거나 변경해서는 안 되는 폰트

• 아이콘 폰트(fa-solid-900.woff2, bootstrap-icons.woff2, eicons.woff2): swap을 적용하면 아이콘 자리에 문자나 빈 네모가 표시됩니다. 가능하면 아이콘 폰트를 SVG로 교체하고, 그렇지 못하다면 block 상태로 두십시오.
• 폰트 설정이 없는 플러그인 또는 앱(WordPress 플러그인, Shopify 앱이 추가하는 폰트): 해당 개발자에게 swap 설정을 요청하십시오.
• 페이지에 폰트를 추가하는 서드파티 스크립트(벤더 도메인): 직접 손쓸 수 없는 영역입니다. 페이지가 렌더링된 후에 스크립트를 로드하거나, 해당 항목을 그대로 두십시오.

폰트 파일 수 줄이기

사용하지 않는 두께(weight)와 스타일을 제거하고, 6개의 정적 파일 대신 하나의 가변 폰트(variable font)를 사용하십시오. 폰트 파일을 하나씩 제거할 때마다 요청이 하나 줄고, 교체(swap)가 하나 줄며, 이 인사이트의 경고 한 줄이 사라집니다.

swap 또는 optional: 어떤 것을 선택해야 합니까?

헤드라인이나 로고처럼 브랜드를 나타내는 폰트에는 크기를 맞춘 fallback과 함께 swap을 사용하십시오. 시스템 폰트로 대체되어도 무방한 본문 텍스트에는 optional을 사용하고, 첫 페이지에서도 로드될 수 있도록 해당 폰트를 preload하십시오:

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
<style>
@font-face {
  font-family: "Inter";
  src: url(/fonts/inter-var.woff2) format("woff2");
  font-weight: 100 900;
  font-display: optional;
}
</style>

자체 도메인의 폰트라도 crossorigin 속성은 필수입니다. 이 속성이 없으면 브라우저가 폰트를 두 번 다운로드합니다. Chrome에서 폰트 preload는 첫 렌더링을 최대 100ms까지 지연시킬 수 있으므로 한두 개의 폰트만 preload해야 하며, 절대 모든 폰트에 적용해서는 안 됩니다. Slow 4G 환경에서는 preload된 폰트조차 첫 페인트 이후에 도착하여 페이지에 fallback이 그대로 유지되었습니다.

metric overrides로 레이아웃 이동 방지하기

fallback 폰트의 크기를 웹 폰트와 맞추십시오. 로컬 폰트를 가리키고 크기를 조절하는 두 번째 @font-face를 선언하면 됩니다:

@font-face {
  font-family: "Barlow Fallback Arial";
  src: local("Arial Bold"), local("Arial-BoldMT");
  font-weight: 700;
  size-adjust: 68.32%;
  ascent-override: 146.37%;
  descent-override: 29.27%;
  line-gap-override: 0%;
}
h1 {
  font-family: "Barlow Condensed", "Barlow Fallback Arial", Arial, sans-serif;
}

size-adjust는 웹 폰트의 텍스트 너비를 fallback 폰트의 텍스트 너비로 나눈 값입니다. ascent-override와 descent-override는 웹 폰트 고유의 ascent와 descent를 동일한 size-adjust 값으로 나눈 것입니다. Fontaine이나 Capsize 같은 도구를 사용하면 폰트 파일에서 이 값들을 자동으로 계산할 수 있습니다.

본문 폰트도 마찬가지이며, 모바일 화면 너비와 실제 사용하는 글꼴 크기에서 직접 텍스트를 측정해야 합니다. Inter는 글꼴 크기에 따라 너비 비율이 달라집니다. 헤드라인 크기에서는 Arial의 약 98%이다가 18px에서는 약 105%가 됩니다. size-adjust를 97.6%로 설정했을 때는 상품 설명이 Inter에서 6줄이었던 반면 fallback에서는 5줄로 줄바꿈되어 구매 버튼이 여전히 움직였습니다. 101%로 맞추자 두 폰트 모두 줄바꿈이 동일해졌습니다. 이를 확인하려면 DevTools에서 폰트 파일을 차단하고(Network, 우클릭, Block request URL), 모바일 너비에서 새로고침하여 정상 로드 시의 줄바꿈과 비교해 보십시오. 줄바꿈이 일치할 때까지 size-adjust를 조정하십시오.

local()은 기기에 설치된 폰트만 찾습니다. Arial은 Windows, macOS, iPhone에 설치되어 있고 Android 스마트폰에는 Roboto가 있습니다. Android 방문자를 위해 Roboto에 맞춘 별도의 수치를 적용한 두 번째 fallback face를 추가하십시오:

h1 {
  font-family: "Barlow Condensed", "Barlow Fallback Arial", "Barlow Fallback Roboto", sans-serif;
}

local()은 폰트가 설치되어 있지 않은 face를 건너뛰므로, 각 기기는 설치되어 있는 첫 번째 폰트를 사용합니다. Safari는 size-adjust를 지원하지만 ascent 및 descent override는 아직 지원하지 않습니다. 따라서 너비는 일치하지만 line-height: normal 상태에서 줄 높이가 약간 다를 수 있습니다. WordPress와 Shopify에는 이런 설정을 지원하는 옵션이 전혀 없습니다. 개발자의 작업이 필요한 부분입니다.

수정 사항이 제대로 적용되었는지 어떻게 확인합니까?

모바일 환경에서 Lighthouse를 다시 실행해 보십시오. Font display가 통과된 인사이트(passed insights)로 이동합니다. 테스트 제품 페이지에서는 점수가 97점에서 98점으로 올랐는데, 이는 모두 점수에 반영되는 메트릭 덕분이었습니다. 텍스트가 더 일찍 표시되면서 Speed Index가 1.9초에서 1.3초로 단축되었고, overrides 적용으로 CLS가 0.031에서 0으로 개선되었습니다. 이제 자체 보고서에서 CLS를 확인해 보십시오. 폰트가 도착할 때 여전히 페이지가 흔들린다면 fallback에 metric overrides를 적용해야 합니다.

Lighthouse 13.5.0, 모바일, DevTools 쓰로틀링 환경.

optional을 선택한 경우 Lighthouse 스크린샷에는 대개 fallback 폰트가 표시됩니다. Lighthouse는 콜드 로드(cold load)로 페이지를 테스트하며, fallback 폰트가 표시되는 것은 optional이 의도대로 동작하고 있다는 증거입니다.

CoreDash는 다음 방문부터 기기별 영향을 바로 보여줍니다. 반면 CrUX와 Search Console은 최근 28일치 데이터를 보여주므로, 문제를 수정한 지 2주가 지나도 표시되는 데이터의 절반은 여전히 이전 사이트의 수치입니다.

모바일 LCP나 CLS가 빨간색으로 표시되는 원인이 폰트 때문인지 확인하고 싶으십니까? Core Web Vitals 파워 아워에서 실제 field data와 페이지 트레이스를 함께 분석해 드리며, 테마에서 어떤 폰트 규칙을 수정해야 하는지 정확한 해결책을 얻어갈 수 있습니다.