최근 제 티스토리 블로그에서 갑자기 또 !
코어 웹 바이탈(Core Web Vitals) 중 LCP(Largest Contentful Paint) 최적화 실패 알림이 뜨기 시작했습니다.
전에 수정 해서 개선했는데. 다시 문제가? 다시 스크립트 최적화, 이미지 용량 압축, CSS와 HTML 구조 개편까지 웹사이트의 로딩 속도를 높이기 위해 정말 할 수 있는 모든 것을 시도했습니다. 마치 손으로 삽질하는 것도 모자라, 포크레인을 끌고 와 사이트 구석구석을 뒤엎는 심정으로 작업에 몰두했죠.
블로그 로딩 속도 갑자기 느려졌나요? 폰트 최적화로 LCP 점수 올리기
하지만 결론은 의외였습니다.
문제의 핵심은 이미지도, 자바스크립트도 아닌 바로 웹폰트 (webfont)였습니다.
최적화되지 않은 TTF 폰트가 예상보다 훨씬 큰 영향을 미치고 있었고, 이로 인해 코어 웹 바이탈(Core Web Vitals) 중 하나인 LCP(Largest Contentful Paint) 점수까지 급격히 나빠졌던 것입니다.
결국 불필요한 글리프를 제거한 서브셋(subset) 폰트를 만들고, 용량이 훨씬 작은 WOFF2 형식으로 변환한 뒤 link rel=”preload”와 font-display: swap 전략을 적용함으로써 문제를 해결할 수 있었습니다.
단순히 몰라서가 아니라, 미처 생각하지 못했던 폰트 문제
사실 폰트 문제라는 건 너무 기본적인 부분이라 생각조차 하지 못했습니다. 복잡한 자바스크립트 코드, 무거운 이미지, CDN 설정 등 큰 문제만 찾아 헤맸던 것이죠. 그런데 뒤늦게 찾은 문제는 폰트, 웹 페이지 로딩 시간에서 폰트가 차지하는 비중이 매우 컸다는 사실이었습니다.
폰트가 웹 속도에 미치는 영향과 그 이유
웹 페이지가 제대로 표시되려면, 브라우저가 해당 페이지에 사용되는 폰트를 모두 로드해야 합니다. 만약 폰트 파일이 크거나 압축이 제대로 되어 있지 않다면, 그만큼 로딩이 늦어지게 됩니다.
제가 사용하던 폰트는 TTF(TrueType Font) 형식이었는데, 이는 웹 최적화에 적합하지 않은 경우가 많아 페이지 로딩 시간을 크게 끌어올렸습니다.
해결책 WOFF2 폰트로 변경과 유니코드 서브셋 적용
구글 등 최신 웹 환경에서는 WOFF2(Web Open Font Format 2) 폰트 사용을 권장합니다. WOFF2는 TTF에 비해 압축률이 뛰어나 훨씬 가볍고 빠른 로딩 속도를 제공합니다.
또한 저는 폰트 파일 크기를 줄이기 위해 필요한 문자 유니코드 영역만 포함하는 서브셋(subset) 폰트를 사용했습니다. 한글, 영어, 숫자 등 꼭 필요한 문자만 포함하도록 설정해 불필요한 데이터를 최대한 줄였죠.
직접 적용 후 체감한 효과
- TTF WOFF2 변경 후 페이지 로딩 속도가 눈에 띄게 빨라졌습니다.
- 코어 웹 바이탈에서 LCP 점수가 정상권으로 회복되었습니다.
- 방문자 체감 속도도 확실히 개선되어 이탈률 감소 효과까지 기대할 수 있었습니다.
웹폰트 종류 비교 및 최적화 방법
| 폰트형식 | 확장잦 | 특징 | 브라우저 지원 | 파일 | 최적화 | 비교 |
| TrueType | .ttf | 전통적인 폰트 형식, 널리 지원됨 | 거의 모든 브라우저 지원 | 비교적 큼 | 최적화 어려움 | 데스크탑용, 모바일 웹에는 비효율적 |
| OpenType | .otf | TrueType의 확장, 고급 타이포그래피 지원 | 대부분 브라우저 지원 | 비교적 큼 | 최적화 어려움 | 고품질 타이포그래피에 적합 |
| WOFF | .woff | 웹에 최적화된 폰트 압축 형식 | 모든 현대 브라우저 지원 | 중간 크기 | 최적화 가능 | 웹용 폰트 표준, 기본 웹폰트로 추천 |
| WOFF2 | .woff2 | WOFF의 향상된 압축 버전 | 최신 브라우저 지원 (80% 이상) | 가장 작음 | 매우 용이 | 웹폰트 최적화의 표준, 빠른 로딩에 적합 |
| SVG | .svg | 벡터 기반, 애니메이션 가능 | 일부 구형 브라우저만 지원 | 보통 | 최적화 어려움 | 특정 애니메이션 및 특수 효과용 |
| EOT | .eot | IE 전용 폰트 형식 | IE 지원 | 중간 크기 | 제한적 | 구형 IE 대응용, 현대 웹에서는 권장하지 않음 |
G마켓 Sans 폰트
웹폰트를 최적화하여 한글, 영어, 숫자만 포함한 최소 서브셋 웹폰트로 변환하려는 경우, 폰트 변환기(예: Transfonter)에서 아래 옵션들 중 어떤 걸 선택해야 하는지 간단히 설명드리겠습니다.
필수 옵션 (기본 글자만 포함 시)
1. Family support
- 체크 권장
- 여러 굵기/스타일(font-weight/font-style 등)을 패밀리로 묶어 CSS 관리가 편해집니다.
2. Fix vertical metrics
- 체크 권장
- 줄 간격 문제를 방지하고 폰트 베이스라인 정렬이 브라우저 간에 일정해집니다. 특히 한글 폰트에 유용합니다.
3. Add local rule
- 체크 해제 권장
- local()은 사용자 PC에 설치된 같은 이름의 폰트를 우선 로드하는 기능입니다.
- 사용자마다 폰트가 다를 수 있어 렌더링 일관성 문제를 유발할 수 있으므로 비권장.
4. Base64 encode
- 체크 해제 권장
- 폰트를 CSS 안에 삽입하는 방식인데, 파일 크기가 커지고 캐싱이 불리해져 비권장입니다.
- 일반 .woff2 파일로 분리하여 사용하는 것이 최적화에 더 좋습니다.
요약: 웹폰트 변환 시 기본 세팅
| 옵션 | 선택 | 설명 |
|---|---|---|
| Family support | 선택 | 글꼴 패밀리 관리에 도움 |
| Fix vertical metrics | 선택 | 줄 높이/정렬 오류 방지 |
| Add local rule | 해제 | OS 폰트 영향 배제 |
| Base64 encode | 해제 | 용량 증가, 캐싱 불리 |
폰트 로딩 전략
- link rel=”preload” as=”font” crossorigin=”anonymous” href=”…” /로 폰트를 미리 로드해 렌더링 블로킹 최소화
font-display: swap;속성으로 폰트 로딩 지연 시 시스템 기본 폰트로 먼저 보여주고, 폰트가 로드되면 교체
웹폰트 캐싱 활용
- 폰트 서버에 캐시 정책을 설정하면 재방문 시 빠른 로딩 가능
- CDN 활용 시 글로벌 분산으로 로딩 속도 개선
배운 점과 마무리
이번 경험을 통해 깨달은 가장 중요한 점은,
복잡한 문제를 해결하려고 할 때 기본에 충실한 점검부터 놓치지 말자는 것입니다.
모든 문제는 원인이 있습니다. 그 원인이 크거나 작다는 것은 중요하지 않습니다.
오히려 작은 문제는 빨리 파악하기 어려워 해결하는 데 더 어려움을 겪을 수 있습니다.
우리의 인생도 마찬가지 아닐까요?
모두가 성공하려고 열심히 살지만, 누구는 성공하고 누구는 실패합니다.
아무리 열심히 블로그에 좋은 콘텐츠를 올려도 방문자가 없는데, 누군가는 별다른 노력 없이도 더 많은 방문자를 끌어 모으기도 합니다. 이처럼 미처 파악하지 못한 아주 작은 차이가 성공과 실패를 좌우할 수 있다는 것을 다시금 새겨봅니다.
살아가면서 생기는 작은 문제들을 스스로 발견하고 인식하는 것은 거의 불가능할 수도 있습니다.
어떤 문제는 그것이 존재하는지도 모른 채 젊은 시절을 보내기도 하죠.
그래서 젊은 시절에 반드시 해야 할 일이 있다면, 몸과 마음을 전적으로 맡길 수 있는 멘토를 찾는 것이라고 생각합니다.
그들은 우리가 미처 알아차리지 못한 작은 문제들을 정확히 파악하고 알려줄 수 있는 존재이기 때문입니다.