웹폰트를 붙이는 가장 쉬운 방법은 공용 CDN의 링크 한 줄을 붙여 넣는 것입니다. 오랫동안 그것이 합리적인 선택이기도 했습니다. 그런데 그 선택을 뒷받침하던 근거 하나가 브라우저 쪽 변화로 사라졌습니다.
공유 캐시라는 이점은 이미 없습니다
과거 공용 폰트 CDN의 가장 강력한 논거는 “방문자가 다른 사이트에서 이미 그 폰트를 받아 뒀을 테니 우리 사이트에서는 즉시 렌더링된다” 였습니다. 지금은 성립하지 않습니다. 주요 브라우저들이 HTTP 캐시를 최상위 사이트 단위로 분리했기 때문입니다. 추적 방지를 위한 조치였고, 그 결과 같은 URL의 같은 파일이라도 사이트가 다르면 다시 내려받습니다.
즉 오늘날 공용 CDN을 쓴다고 해서 “이미 캐시돼 있을 것” 을 기대할 수 없습니다. 어차피 처음 받아야 한다면, 어디서 받느냐가 순수한 비용 비교의 문제가 됩니다.
왕복이 한 번이 아닙니다
외부 도메인에서 폰트를 받으려면 DNS 조회 → TCP 연결 → TLS 협상이 먼저 끝나야 합니다. 우리 서버와는 이미 맺어 둔 연결이 있지만, 새 도메인에는 없습니다.
게다가 대부분의 CDN 링크는 CSS 파일을 먼저 받고, 그 CSS 안에서 폰트 파일을 다시 요청하는 2단 구조입니다. 첫 화면을 그리는 데 필요한 폰트가 두 번의 왕복 뒤에야 요청되기 시작한다는 뜻입니다.
preconnect로 연결 수립을 앞당길 수는 있지만, 그것은 비용을 줄이는 것이지 없애는 것이 아닙니다. 같은 도메인에서 폰트를 내보내면 그 단계가 통째로 사라집니다.
통제권과 방문자 정보
비용 말고도 두 가지가 더 있습니다.
방문자의 IP가 제3자에게 전달됩니다. 폰트 요청도 HTTP 요청이므로 접속 정보가 그 서버에 남습니다. 유럽에서는 이 문제가 실제 법적 쟁점으로 다뤄진 사례가 있어, 개인정보 처리를 신경 쓰는 사업이라면 자체 호스팅이 더 설명하기 쉬운 구성입니다.
버전이 우리 손에 있습니다. 외부 서비스가 폰트 파일을 갱신하면 어느 날 글자 폭이 미세하게 달라지고, 우리가 맞춰 둔 줄바꿈과 레이아웃이 함께 흔들립니다. 자체 호스팅에서는 파일을 우리가 갈아 끼우기 전까지 아무 일도 일어나지 않습니다 — 테스트한 것이 그대로 배포되는 상태입니다.
옮기는 절차
실제 작업은 단순합니다. woff2 파일만 준비하면 됩니다 — 현대 브라우저는 전부 woff2를 지원하므로 woff · ttf · eot를 함께 올릴 이유가 없습니다. 파일은 자식 테마의 assets/fonts/처럼 테마 안에 두는 편이 배포와 버전 관리에 유리합니다.
@font-face {
font-family: 'Pretendard Variable';
src: url('../fonts/PretendardVariable.woff2') format('woff2');
font-weight: 100 900; /* 가변 폰트의 굵기 범위 */
font-style: normal;
font-display: swap;
}
body { font-family: 'Pretendard Variable', system-ui, sans-serif; }서버 쪽에서는 폰트 파일에 긴 캐시 수명을 줍니다. 파일 이름에 버전이나 해시를 넣어 두면 Cache-Control: public, max-age=31536000, immutable을 안심하고 쓸 수 있습니다 — 내용이 바뀔 때는 이름이 함께 바뀌니까요.
마지막으로 플러그인이 폰트를 다시 붙이고 있지 않은지 확인합니다. 자체 호스팅으로 옮겼는데도 개발자 도구 네트워크 탭에 외부 폰트 도메인이 보인다면, 대개 테마 옵션이나 다른 플러그인이 자기 폰트를 따로 불러오고 있는 경우입니다. 이 확인을 빠뜨리면 두 벌을 모두 내려받는 최악의 구성이 됩니다.
자산 로딩과 캐시 정책 전반은 성능 최적화 아카이브에 정리돼 있고, 폰트 · 캐시 · 서버 설정을 한 번에 정비하는 작업은 최적화 지원 사업에 포함됩니다.
다음 회차
자체 호스팅으로 옮기면 파일 크기가 곧바로 눈에 들어옵니다. 한글 폰트는 라틴 폰트와 비교가 안 되게 무겁습니다. 다음 회차는 그 파일을 필요한 조각만 내려받게 나누는 방법입니다.