한글 폰트 파일은 영문 폰트의 열 배가 넘는다
웹사이트 속도를 점검하다 보면 이미지보다 의외로 무거운 자원이 폰트인 경우가 많다. 라틴 알파벳은 모든 글자를 모아도 100여 자에 그치지만, 한글은 KS X 1001 기준 완성형만 2,350자, 유니코드 한글 영역까지 합치면 11,172자에 이른다. 그래서 같은 디자인의 폰트라도 영문 파일이 30KB라면 한글 파일은 보통 500KB에서 3MB를 넘는다. 첫 화면이 뜨기 전에 이 파일이 다 도착해야 글자가 디자인된 모습으로 보이고, 그렇지 않으면 흰 화면이 길어지거나 시스템 폰트로 잠시 보였다가 갑자기 글자가 바뀌는 깜빡임이 발생한다. 한글 사이트가 영문 사이트보다 체감 속도가 느린 가장 큰 이유 중 하나다. 폰트 한 줄만 제대로 정리해도 첫 화면 도달 시간이 눈에 띄게 줄어든다. 우리 사이트에 바로 적용할 수 있는 다섯 가지 원칙을 정리했다.
1. font-display: swap 한 줄로 흰 화면을 없앤다
가장 먼저 점검할 것은 @font-face 안의 font-display 속성이다. 이 값을 정해두지 않으면 브라우저는 폰트가 도착할 때까지 최대 3초 동안 글자를 아예 그리지 않는다. 이른바 FOIT(Flash of Invisible Text), 흰 화면이다. font-display: swap을 한 줄 추가하면, 폰트가 도착하기 전에는 시스템 기본 폰트로 글자를 먼저 보여주고 폰트가 도착하는 즉시 바꿔치기한다. 글자가 한 번 바뀌긴 하지만 사용자는 콘텐츠를 0초부터 읽을 수 있다. 한글 사이트라면 거의 모든 경우에 swap이 정답이고, 본문 폰트보다 제목용 디스플레이 폰트에서 효과가 가장 크다.
2. 서브셋 — 우리 사이트가 쓰는 글자만 다운로드 받는다
한글 완성형 11,172자를 모두 내려받게 두는 것은 낭비다. 구글 폰트의 한글 폰트는 이미 유니코드 범위별로 잘게 쪼개진 서브셋 파일을 unicode-range로 구분해 제공한다. CDN 한 줄만 잘 붙여도 브라우저가 실제로 화면에 등장한 글자가 들어 있는 조각만 골라 받아간다. 우리 폰트를 직접 호스팅한다면 pyftsubset이나 fonttools로 자주 쓰는 한글 2,350자만 추려둔 서브셋 파일을 만들어 두는 것이 좋다. 1MB짜리 본문용 폰트가 300KB로 줄어드는 일은 흔하다. 단, 사용자 이름이나 게시판 본문처럼 어떤 글자가 등장할지 알 수 없는 영역이라면 서브셋이 빠진 글자를 시스템 폰트로 대체하지 않도록 fallback 설계를 함께 점검해야 한다.
3. preload로 첫 글자가 HTML과 같이 도착하게 한다
브라우저는 HTML을 받아 CSS를 파싱하고 나서야 폰트 파일을 요청한다. 그래서 같은 폰트라도 페이지를 그리는 일정 위에서는 늘 뒤늦게 출발한다. <link rel="preload" as="font" crossorigin>을 head 상단에 박아두면, 브라우저가 HTML을 읽으면서 폰트를 동시에 요청하기 시작한다. 한 페이지에서 가장 먼저 보이는 본문 폰트 한 종류, 제목 폰트 한 종류 정도만 preload하는 것이 좋다. 너무 많이 걸면 정작 중요한 이미지나 스크립트의 차례가 뒤로 밀려 역효과가 난다. preload는 만능 도구가 아니라 '가장 먼저 보일 글자가 들어 있는 파일'에 한정해서 쓰는 우선순위 도구다.
4. WOFF2와 가변 폰트로 파일 수와 용량을 줄인다
같은 폰트라도 포맷에 따라 용량이 크게 달라진다. 구식 TTF나 EOT는 더 이상 쓸 이유가 없고, WOFF2 한 가지만 두는 것이 표준이다. WOFF2는 TTF 대비 30% 안팎으로 가볍고, 모든 현대 브라우저에서 지원된다. 한 단계 더 들어가면 가변 폰트(Variable Font)가 있다. Pretendard, 나눔스퀘어 네오 같은 한글 폰트는 가변 폰트 버전이 나와 있는데, Light·Regular·Medium·Bold 네 개 파일을 따로 받는 대신 한 파일로 굵기 100~900을 모두 표현한다. 네 번 요청을 한 번으로 줄이는 효과가 크다. 다만 가변 폰트는 파일 자체가 일반 단일 굵기보다는 무거우니, 굵기를 두 종류 정도밖에 안 쓰는 사이트라면 단일 굵기 두 개를 따로 두는 편이 더 가벼울 수도 있다. 우리 사이트에서 실제로 쓰는 굵기 개수를 세어 보고 결정한다.
5. 시스템 폰트 fallback은 안전망이자 디자인의 일부다
웹폰트가 끝내 늦게 도착하거나 도착하지 못하는 경우를 대비해 fallback 폰트 스택을 잘 짜두는 것이 마지막 안전망이다. font-family 마지막에 막연히 sans-serif만 적어두는 사이트가 많은데, 한글 사이트라면 'Apple SD Gothic Neo', 'Malgun Gothic', 'Noto Sans KR', sans-serif 순으로 명시하는 것이 안전하다. iOS·macOS, Windows, 안드로이드 모두에서 한글이 시스템 기본 폰트로 깔끔히 그려진다. 한 걸음 더 나아가 size-adjust, ascent-override 같은 CSS Font Metrics 속성으로 fallback 폰트와 실제 웹폰트의 줄 높이를 맞춰두면, swap이 일어날 때 레이아웃이 흔들리는 CLS(Cumulative Layout Shift) 점수까지 같이 챙길 수 있다. fallback은 '임시방편'이 아니라 사이트 디자인의 일부로 다뤄야 한다.
폰트 한 줄이 우리 사이트의 첫인상을 결정한다
한글 사이트의 속도 점검은 보통 이미지에서 시작해서 스크립트로 끝나지만, 그 사이에 폰트가 조용히 600KB를 끌고 들어와 첫 화면을 1초씩 늦추는 일이 가장 흔하다. font-display: swap, 서브셋, preload, WOFF2와 가변 폰트, 그리고 fallback 스택 — 이 다섯 가지를 같이 점검하면 사용자가 흰 화면을 보는 시간도, 글자가 한 번 바뀌는 깜빡임도 모두 줄어든다. CYAN 에이전시는 사이트를 만들 때 폰트 선택과 함께 이 다섯 가지 항목을 처음부터 함께 설계한다. 이미 운영 중인 사이트라도 브라우저 개발자 도구의 네트워크 탭에서 폰트 파일의 크기와 도착 시간만 확인하면 어느 항목부터 손볼지 한눈에 보인다. 가장 가벼운 SEO·성능 개선이 폰트에서 출발한다.