한글 폰트는 영어처럼 쉽게 폰트를 다룰수 없습니다. 폰트 최적화라고 설명되어 있는 대부분의 글들은 영어를 기준으로 작성된 것입니다. 한국어로 쓰여진 글조차도 똑같이 설명하고 있는 곳이 많습니다. 그냥 영어 사이트 보고 그런가 부다 하고 옮겨적은 거죠. 저같은 사람은 또 아무생각없이 사이트에 좋다고 적용시켜 놓는 일이 벌어지기도 하구요. (반년넘게 font-display:optional을 했으니 최적화가 되었다, 이게 최선이라고 착각하고 살았습니다)
최근에 사이트 최적화작업을 하면서 font-display:optional 가 제대로 쓰이기 위해서는 200 kb나 되는 한글 기본폰트가 100m이내로 폰트가 로딩되어야 한다는 것을 알게되었습니다. 20kb이하의 영어기본폰트에서 할수 있는 optional 최적화는 최적화가 아니라, 사족에 불과했습니다.
한글 폰트 최적화를 어떻게 하는지 제대로 배우기 위해서 참고할 만한 한글 사이트를 찾기 시작했습니다. 한글의 경우 정답이 없다는 것을 알고 있기 때문에,영어권에서는 사용하지 않는 꼼수를 찾기 위해서 입니다. 제가 생각하는 한글 폰트 최적화의 목표지점은 영어사이트에서 font-display:optional을 사용했을때 수준의 웹폰트 최적화입니다. 예를 들면, web.dev 의 영문사이트에서 느껴지는 쾌적함이라고 할수 있겠네요. (이곳은 font-display:optional을 사용하고 있습니다. 한국어 버젼의 폰트는 그냥 기본폰트입니다. 한글폰트는 최적화를 포기한거죠) 구체적으로 아래와 같습니다.
- 첫 방문, 첫 로딩에서 부터 한글 웹폰트로 글자를 보여준다.
- 100ms 이내로 웹폰트가 로딩되야 한다.
- 한번 표시된 텍스트는 폰트가 유지되야 한다.
- 깜박임이나 흔들리는 현상이 없어야 한다.
그리고, 아래와 같은 경우는 포기하기로 했습니다.
- 오래된 구식 브라우저
- 3G 이하의 속도
특별히 대단한 조건이 아닙니다. 적당한 속도에서 제대로 보여주면 됩니다. (현재는, 대부분의 경우, 제대로 보여주지 못합니다.)
웹폰트 최적화 구경을 시작합니다. 요즘 유행하는 네카라쿠배당토직야를 중심으로 찾아보았습니다.
구글 로고는 이미지 입니다. 하단 한글 텍스트 버튼은 기본폰트입니다.
웹폰트는 없습니다.
구글과 비슷합니다. 폰트는 malgun 고딕.
일단 내린 결론, 검색은 웹폰트가 부담스러운가 보다.
그디어 웹폰트가 보이네요. 아쉽지만 첫페이지 로딩때 메뉴표시까지 1초이상 걸렸습니다. 이 현상이 어쩔수 없이 그런건지 햇갈리는데요. 의도된 것이라면 좋은 꼼수라고 할수 있겠습니다.
꼼수1- 어차피 웹폰트로 바로 보여줄수 없다면,의도된 것으로 포장할 것
코드를 보니 unicode-range가 사용되었습니다. @font-face가 188개가 사용되었네요. 아래는 일부코드입니다. 전체는 이곳
@font-face {
font-family: 'Toss Product Sans';
src: url("/tps/20211111/bold/0.woff2") format('woff2'), url("/tps/20211111/bold/0.woff") format('woff');
unicode-range: U+F9CA-FA0B, U+FF03-FF05, U+FF07, U+FF0A-FF0B, U+FF0D-FF19, U+FF1B, U+FF1D, U+FF20-FF5B, U+FF5D, U+FFE0-FFE3, U+FFE5-FFE6;
font-weight: 700;
font-style: normal;
}코드를 입력하세요
폰트를 그룹화해서 로딩을 하고 있습니다. 토스도 구글과 같이 머신러닝으로 그룹화를 했나 보다라고 생각을 하고 어떻게 다른가 비교를 해보려 했더니..
어? range값이 구글폰트와 똑같습니다. 아래는 일부 코드입니다.
/* [0] */
@font-face {
font-family: 'Noto Sans KR';
font-style: normal;
font-weight: 100;
src: url(https://fonts.gstatic.com/s/notosanskr/v27/Pby6FmXiEBPT4ITbgNA5CgmOsn7tqoAetwxcvEcQNuukkRBBEIyMcFQ.0.woff2) format('woff2');
unicode-range: U+f9ca-fa0b, U+ff03-ff05, U+ff07, U+ff0a-ff0b, U+ff0d-ff19, U+ff1b, U+ff1d, U+ff20-ff5b, U+ff5d, U+ffe0-ffe3, U+ffe5-ffe6;
}
그러니까, 구글이 나눈 그룹을 그대로 가져다가 쓰고 있는 것입니다.
찾아보니 아예 이런 툴이 있네요.
머신러닝을 돌리느니 그냥 만들어진것을 가져다 쓴것입니다. 이것이 비난받을 일은 아닙니다. 문제는, 최첨단 머신러닝이 동원되었지만, 첫번째 방문, 첫번째 로딩의 폰트 문제는 여전히 해결하지 못했다는 것입니다. 토스이전에 구글의 문제입니다.
익숙한 배민 폰트로 강렬하게 표시하고 있습니다. 속도도 빠릅니다.
오.. 그디어! 이런.. 웹폰트가 아니라 그냥 이미지 입니다..
웹폰트를 사용하고 있습니다. 글자가 표시되기까지 시간이 걸리고, 폰트변화를 보이기도 합니다. 폰트를 여러개 로딩하는데, 각 사이즈가 300kb정도 됩니다. 당연한 결과죠.
웹포트를 사용하고 있습니다. 바로 표시는 되지만, 폰트 변화를 항상 보이고 있습니다.
웹폰트를 전혀 사용하지 않고 있습니다.
애니메이션을 적극사용하고 있습니다. 아예 구글폰트를 쓰고 있구요.
토스와 같은 문제가 있습니다.
제가 볼때 가장 많은 꼼수를 동원한 고민이 많이 한 사이트 같습니다.
토스나 라인처럼 긴 애니메이션이 아니고 아주 짧은 효과라서 읽기를 거의 방해하지 않습니다.
문제는 이렇게 애니메이션이 짧으면, 웹폰트로딩이 준비되지 않은 상태에서 화면을 보여줘야 하는 경우가 발생할 수 있습니다.
(위 화면을 사용자가 볼 일은 거의 없을 것입니다. 테스트로 속도를 느리게 해서 잡은 화면입니다.)
기본폰트가 보여질것 같지만, 배경이미지도 로딩중이라 잘 보이지 않습니다.
폰트(350kb)를 불러오지 못한 상태라면, 당연히 사이즈 큰 배경이미지(650k)도 로딩중이라 가정할 수 있는거죠. 그래서, 못생긴 폰트를 보여주면서도, 암시적으로 상태를 전달하고 있습니다. "지금은 로딩중이라서 임시로 보여주는 거야. 진짜 화면은 아니야"
이미지가 로딩이 될때 이용자는 사이트가 제대로 로딩이 되었다고 기대를 할것이고,
그때는 이미 폰트가 로딩되어 있을것입니다. 물론, 이것이 의도된 것인지는 알도리가 없습니다. 의도된 것이라면 스마트한 꼼수라 할수 있겠습니다.
한글폰트 최적화를 구현하는 사이트를 찾지 못했습니다. 원하는 꼼수를 찾지 못했지만 배운것이 있어 정리를 해보자면,
한글 웹폰트 최적화를 위한 쉬운 방법은 없다는 것을 알게 되었습니다. 이제 갈림길에 섰습니다.
오기가 발동하여 4번을 선택하고 돌아올 수 없는 길을 떠납니다.
다음편에서는 제가 찾은 꼼수에 대해서 소개하겠습니다.