각 경로가 브라우저에 요구하는 폰트 작업을 줄이기
홈 페이지, 전환(컨버전) 페이지, 로그인 후 뷰, 그리고 다른 디자인 시스템을 사용하는 템플릿에서 콜드 캐시 상태의 폰트 요청을 목록화하세요. 패밀리, 굵기, 스타일, 파일, 출처(origin), 전송 크기, 그리고 선택자(selector)를 기록합니다. 선언된 @font-face 규칙 자체가 다운로드를 촉발하지는 않습니다; 브라우저는 일반적으로 현재 레이아웃이 해당 페이스를 사용하면 해당 페이스를 가져옵니다. 따라서 사용하지 않는 전역 굵기와 스타일은 먼저 제거할 가치가 있습니다.
디스플레이 제목 등 진짜 브랜드 가치가 있는 곳에 커스텀 타입을 사용하고, 디자인이 허용하면 일반 본문에는 시스템 스택을 고려하세요. 가변 폰트(variable font)가 항상 더 작다고 가정하지 마십시오: 여러 정적 파일을 대체할 수는 있지만 단일 정적 페이스보다 클 수 있습니다. 경로에서 실제로 요청되는 압축 자산을 비교하세요.
경로 수준에서 사용이 테스트되지 않은 패밀리, 굵기, 이탤릭, 아이콘 폰트는 제거하세요.
빌드를 변경하기 전에 라이선스가 웹 전달, 서브세팅(subsetting), 자체 호스팅을 허용하는지 확인하세요.
WOFF2를 사용하고 필요한 문자를 제거하지 않고 서브셋 생성
현대 브라우저의 기준으로 WOFF2부터 시작하세요. W3C 권고안은 WOFF2를 개선된 압축과 빠른 압축 해제를 위해 설계된 웹 폰트 패키지로 설명하며 주요 브라우저에서 구현되어 있습니다. 문서화된 레거시 브라우저 요구가 있을 때만 다른 포맷을 유지하고, 그렇지 않다면 잘 설계된 대체 폰트가 더 안전한 호환성 경로입니다.
서브세팅(subsetting)은 선택한 글리프(문자형상)만 포함하는 더 작은 파일을 만듭니다. unicode-range는 문자 범위와 서브셋을 연관시켜 브라우저가 텍스트에 맞는 파일을 선택하게 할 수 있습니다. 실제 페이지와 지원하는 언어에서 서브셋을 빌드하세요—구두점, 통화 기호, 이름, 법적 문구, 사용자 입력 스크립트까지 포함합니다. 글리프 누락은 올바름의 문제이며 바이트 절약을 위한 허용 가능한 방법이 아닙니다.
영어 디자인 샘플뿐 아니라 대표 지역화된 페이지와 폼 입력을 테스트하세요.
각 서브셋의 unicode-range와 굵기/스타일 범위가 배포된 파일과 일치하는지 확인하세요.
대체 폰트(fallback)와 font-display 정책을 함께 설계하기
대체 폰트는 커스텀 서체가 준비되지 않았을 때 사용자가 보는 것입니다. 비례(proportions)가 비슷한 것을 선택한 뒤 실제 제목, 여러 줄 버튼, 내비게이션, 표, 폼, 길게 지역화된 문자열을 비교하세요. 폭이 다르면 줄바꿈이 달라지고, ascent, descent, line-gap 차이는 블록 높이를 바꿉니다. 둘 다 이미 페이지에 보이는 콘텐츠를 이동시킬 수 있습니다.
font-display는 페이스가 없을 때의 렌더링 동작을 정의합니다. optional은 블록 기간(block period)이 매우 짧고 swap 기간이 없어 첫 방문에서 안정적인 대체 폰트를 선호할 때 본문 텍스트에 적합할 수 있습니다. swap은 대체를 즉시 보여주고 나중에 웹 폰트를 적용할 수 있지만, 늦게 교체될 때 파괴적인 재배치(reflow)를 일으키지 않는 곳에만 사용하세요. block 또는 fallback은 전역 기본값이 되어서는 안 되며 테스트된 디자인 이유로 사용되어야 합니다. CSS의 size-adjust는 대체 폰트의 메트릭을 조정하는 데 도움이 될 수 있지만, 지원하는 각 스크립트와 뷰포트에서 시각적으로 확인하세요.
결제, 복구, 계정, 안전 텍스트나 내비게이션 텍스트가 늦은 커스텀 폰트에 의존하지 않도록 하세요.
대체 문자 하나가 잘못된 의미를 전달할 수 있으므로 인터페이스 심볼에는 SVG 아이콘이 일반적으로 더 안전합니다.
발견을 개선하되 preload는 억제하고 데이터 흐름을 평가하기
외부 스타일시트에만 선언된 페이스는 해당 스타일시트가 다운로드되어 파싱된 후에 발견될 수 있습니다. 유지보수 가능한 초기 크리티컬 CSS가 필요한 선언을 더 빨리 노출할 수 있습니다; 폰트 바이너리를 인라인하면 문서가 커지므로 그렇게 하지 마세요. 서드파티(origin)인 경우 preconnect로 연결을 더 일찍 확립할 수 있습니다. 폰트 요청은 CORS 리소스이므로 교차 출처 제공과 preload는 올바른 crossorigin 처리가 필요합니다.
preload는 우선순위 재정의일 뿐이며 만능 속도 스위치가 아닙니다. 다른 크리티컬 작업과 경쟁할 수 있고, 경로에서 전혀 필요하지 않은 페이스를 다운로드할 수 있으며 unicode-range 선택을 우회하기도 합니다. 늦은 발견 문제를 먼저 고치고, 실제로 첫 뷰에서 사용이 입증된 파일 하나만 정확한 URL, as=font, crossorigin을 사용해 preload하세요. Google Fonts는 API 요청에 방문자 IP 주소, 요청된 URL, HTTP 헤더, 레퍼러(referer)를 포함한다고 설명하며 API가 쿠키를 설정하거나 기록하지 않으며 수집 정보를 프로파일링이나 타겟 광고에 사용하지 않는다고 밝힙니다. 자체 호스팅은 해당 로드에 대해 Google이 데이터를 받지 못하게 합니다. 전달 방식, 개인정보 처리방침, 관할권, 계약을 평가하고 필요시 적절한 자문을 구하세요.
콜드 캐시 트레이스를 비교하고 preloaded 파일이 경로에서 소비되는지 확인하세요.
연결 설정, 캐시 및 CDN 기능, 자산 유지보수, 방문자 데이터 흐름을 저울질하세요.
폰트 자산에 버전 관리를 적용하고 테스트된 CSS 대체 구성을 보존하세요.
렌더링 동작을 테스트하고 폰트를 복원력 의존성으로 운영하기
콜드 캐시 상태에서 브라우저 네트워크 도구를 사용해 CSS에서 폰트 요청 체인, 타이밍, 출처, 캐싱, 실패를 검사하세요. 제한된 연결에서 반복한 뒤 폰트를 쓰로틀하거나 차단하세요. 성공 기준은 커스텀 페이스가 나타나기 전에도 읽기 쉬운 텍스트, 사용 가능한 컨트롤, 정확한 심볼, 그리고 일관된 레이아웃입니다. 현실적인 좁은 레이아웃과 데스크탑 레이아웃, 긴 문자열, 오류 메시지, 동의(consent) 문구, 가격, 그리고 지원되는 모든 스크립트를 테스트하세요.
Chromium에서는 Performance 패널에서 리로드를 기록하고 Layout Shifts 트랙을 검사하세요; DevTools는 이동된 요소를 식별하고 시프트를 애니메이션으로 보여줄 수 있습니다. 폰트 로딩은 알려진 원인 중 하나지만 이동된 요소가 반드시 근본 원인은 아닐 수 있으므로 트레이스에서 폰트 적용과 상관관계를 확인하세요. Layout Instability API는 Chromium 전용이므로 교차 브라우저 시각 검사도 중요합니다. 릴리스 리뷰에 폰트 자산, CORS 동작, 캐시 정책, 대체 폰트, 롤백을 포함하세요. 의도된 저하 모드는 읽기 가능한 텍스트여야 하며 빈 콘텐츠나 망가진 내비게이션이 아니어야 합니다.
웜 캐시는 초기 요청과 렌더링 문제를 감출 수 있습니다.
파일, CMS 카피, 템플릿, 제공업체, 또는 CDN 규칙이 변경될 때 검사를 반복하세요.