최근 운영 중인 티스토리 블로그에서 갑자기 예상치 못한 문제가 발생했습니다. 바로 코어 웹 바이탈(Core Web Vitals) 항목 중 하나인 LCP(Largest Contentful Paint) 최적화에 실패했다는 알림이 뜬 것이죠. 예전에 한 번 수정을 거쳐 개선했던 부분이라 당혹감이 더 컸습니다.
문제를 해결하기 위해 다시금 자바스크립트 최적화를 진행하고 이미지 용량 압축은 물론, CSS와 HTML 구조 개편까지 웹사이트 로딩 속도를 높일 수 있는 모든 수단을 동원했습니다. 정말 구석구석을 뒤엎는 심정으로 작업에 매달렸던 것 같아요.
블로그 로딩 속도가 갑자기 느려졌다면? 폰트 최적화가 정답입니다
그런데 모든 노력을 쏟아부은 끝에 찾아낸 결론은 의외로 간단했습니다. 문제는 이미지나 스크립트가 아니라 바로 웹폰트(webfont)에 있었거든요. 최적화 과정을 거치지 않은 TTF 폰트가 생각보다 큰 용량을 차지하며 페이지 로딩을 방해하고 있었고, 이것이 결국 LCP 점수를 깎아먹는 주범이었습니다.
저는 이 문제를 해결하기 위해 불필요한 글자를 모두 걷어낸 서브셋(subset) 폰트를 제작했습니다. 그리고 용량이 획기적으로 작은 WOFF2 형식으로 변환한 뒤, link rel=”preload”와 font-display: swap 전략을 적용하여 문제를 말끔히 해결했습니다.
기본이라서 더 놓치기 쉬웠던 폰트 용량 문제
사실 웹폰트 최적화는 아주 기초적인 부분이라 오히려 의심을 덜 했던 것 같습니다. 그저 복잡한 코드나 무거운 이미지 파일, 혹은 CDN 설정 같은 거창한 곳에서만 원인을 찾으려 했으니까요. 하지만 웹 페이지 로딩 시간에서 폰트 파일이 차지하는 비중은 상상 이상으로 컸습니다.
폰트가 웹사이트 속도에 미치는 진짜 이유
우리가 사용하는 브라우저는 웹 페이지를 보여줄 때 해당 페이지에 설정된 폰트 파일을 먼저 로드해야 합니다. 만약 이 파일이 너무 크거나 압축률이 떨어진다면 그만큼 화면이 뜨는 시간은 늦어질 수밖에 없겠죠. 특히 제가 사용했던 TTF(TrueType Font) 방식은 데스크탑 환경에는 적합할지 몰라도 모바일 웹 최적화 관점에서는 비효율적인 경우가 많습니다.
가장 확실한 해결책: WOFF2 변환과 유니코드 서브셋
구글을 비롯한 최신 웹 환경에서 가장 권장하는 방식은 WOFF2(Web Open Font Format 2)입니다. 기존 형식들에 비해 압축률이 매우 뛰어나서 용량을 획기적으로 줄일 수 있기 때문입니다. 여기에 더해 저는 필요한 문자 영역만 남기는 서브셋 작업을 병행했습니다. 한글은 조합 가능한 글자 수가 워낙 많아 폰트 파일이 무거워지기 쉬운데, 실제 사용되는 글자들만 추려내면 데이터를 최소화할 수 있습니다.
직접 적용해보니 체감되는 속도 변화
- 기존 TTF 파일을 WOFF2로 변경하자마자 페이지가 뜨는 속도가 확실히 빨라졌습니다.
- 나빴던 LCP 점수가 다시 정상 범위로 돌아왔습니다.
- 방문자가 느끼는 체감 속도가 좋아지면서 블로그 이탈률을 낮추는 효과도 얻을 수 있었습니다.
주요 웹폰트 종류와 특징 비교
| 폰트형식 | 확장자 | 특징 | 브라우저 지원 | 파일 크기 | 최적화 | 비교 |
| TrueType | .ttf | 전통적인 형식 | 대부분 지원 | 큼 | 어려움 | 모바일 웹 비효율적 |
| OpenType | .otf | 고급 타이포그래피 | 대부분 지원 | 큼 | 어려움 | 디자인 작업에 적합 |
| WOFF | .woff | 웹 최적화 표준 | 현대 브라우저 | 중간 | 가능 | 기본 웹폰트 추천 |
| WOFF2 | .woff2 | 최상의 압축률 | 최신 브라우저 | 가장 작음 | 매우 용이 | 웹 최적화의 필수 |
G마켓 Sans 서브셋 적용 예시
만약 여러분도 한글, 영어, 숫자만 포함된 최소 용량의 서브셋 폰트를 만들고 싶다면, Transfonter 같은 변환기에서 제공하는 옵션을 잘 선택해야 합니다. 어떤 것들을 체크해야 할지 간단히 알려드릴게요.
폰트 변환 시 꼭 챙겨야 할 필수 옵션
1. Family support
- 체크 권장: 다양한 굵기의 폰트를 하나의 패밀리로 묶어주어 CSS 관리가 훨씬 수월해집니다.
2. Fix vertical metrics
- 체크 권장: 폰트마다 제각각인 줄 간격이나 정렬 문제를 잡아줍니다. 특히 한글 폰트의 레이아웃을 일정하게 유지하는 데 큰 도움이 됩니다.
3. Add local rule
- 체크 해제 권장: 사용자 PC에 이미 설치된 폰트를 불러오는 기능인데, 오히려 디자인 일관성을 해칠 수 있어 사용하지 않는 편이 좋습니다.
4. Base64 encode
- 체크 해제 권장: 폰트 데이터를 CSS에 직접 박아넣는 방식입니다. 파일 하나로 관리하기는 편할지 몰라도 브라우저 캐싱 면에서 불리하고 전체 용량이 커집니다.
핵심 요약: 웹폰트 변환 기본 세팅 가이드
| 옵션 | 선택 여부 | 이유 |
|---|---|---|
| Family support | 선택 | 폰트 패밀리 관리 효율성 |
| Fix vertical metrics | 선택 | 줄 높이 및 정렬 오류 방지 |
| Add local rule | 해제 | 방문자 OS 환경 영향 배제 |
| Base64 encode | 해제 | 캐싱 활용 및 로딩 효율 극대화 |
더 빠른 로딩을 위한 추가 전략
- link rel=”preload” as=”font” crossorigin=”anonymous” 태그를 사용해 브라우저가 폰트를 가장 먼저 인식하게 하세요.
- font-display: swap; 속성을 넣어 폰트가 로딩되는 동안에도 텍스트가 바로 보이도록 설정하는 것이 좋습니다.
- 서버의 캐시 정책을 활용하거나 CDN을 거치게 하면 전 세계 어디서든 빠른 로딩이 가능해집니다.
이번 최적화 과정을 겪으며 다시 한번 느낀 점은, 복잡한 문제를 풀어나갈수록 기본에 충실한 점검이 정말 중요하다는 사실입니다. 모든 현상에는 반드시 원인이 있고, 그 원인이 사소하다고 해서 결코 가벼운 것은 아닙니다. 오히려 너무 작아서 눈에 보이지 않는 문제가 우리를 더 힘들게 하기도 하죠.
우리의 삶도 이와 비슷하지 않을까 싶습니다. 누구는 열심히 노력해도 제자리인 것 같고, 누구는 조금만 움직여도 큰 성과를 내는 것처럼 보일 때가 있죠. 그 차이는 어쩌면 우리가 미처 발견하지 못한 아주 작은 습관이나 문제점에서 시작될지 모릅니다.
스스로 그 사소한 결함을 찾아내는 것은 참으로 어려운 일입니다. 그래서 저는 인생의 멘토가 필요하다고 생각합니다. 내가 보지 못하는 사각지대를 정확히 짚어주고, 성공과 실패를 가르는 결정적인 차이를 알려줄 수 있는 존재가 곁에 있다면 훨씬 효율적으로 나아갈 수 있을 테니까요.
