웹폰트, 가볍게 최적화 하기.
실제 사용하는 글자만 남긴, 최적화 웹폰트 작업기.
간편 전자계약 서비스 모두싸인은 지난 6월 서비스 리뉴얼과 모바일 지원에 대한 업데이트를 했습니다.
서비스 UI개선과, 랜딩페이지 개편, 프론트 프레임워크 변경 등 대대적인 리뉴얼을 진행했었는데요.
특히 기존에 랜딩페이지와 본 서비스가 하나의 프로젝트로 구성되어있던 것에서,
랜딩은 좀 더 유연하게, 본 서비스는 좀 더 안정적으로 운영하기 위해 두 서비스를 별도의 프로젝트로 쪼개서 작업하게 되었습니다.
그 과정에서 비교적 유연해진 랜딩 페이지의 작업에 대해서는 디자이너인 제가 많은 부분을 작업할 수 있게 되었고, 디자인 의도에 더 맞는 랜딩 페이지 코드를 작성하기 위한 고민들을 하게 되었습니다.
본격적으로 디자인 시안을 작업하다보니, 서체 굵기를 다양하게 사용하고 싶은 욕심이 계속해서 발생했고, 디자인팀 내부에서는 Light, Regular, Medium, Bold 무려 4가지 웨이트의 폰트를 지원하기를 바랬습니다. 당시 스포카 한 산스의 서브셋 버전과, 스포카 한산스에서 지원하지 않는 Medium 웨이트의 noto sans 서브셋을 사용하려고 했으며, 4가지 폰트의 총 용량은 woff2 기준으로 약 1.3MB 달했고.
네트워크 상황에 따라 정말 느릴때는 10초 이상의 FOIT(웹폰트 다운로드가 완료되기 전까지 텍스트가 나오지 않음)가 발생하기도 하는 등 로딩속도의 해결책에 대해 심각하게 고민하게 되었습니다.
그러다 불현듯 떠오른 아이디어는, 큰 용량의 원본 폰트파일을 2,350자의 한글 서브셋으로 만들 듯이, 해당 페이지에서 사용하는 글자에 대해서만 글리프를 남기는 '사이트에 최적화된' 웹폰트를 만들면 어떨까였습니다.
유저가 만들어내는 동적인 텍스트가 없고, 정적인 정보만을 담고있는 랜딩 페이지이기에, 최소한의 실제 사용되는 글리프만 남기더라도 큰 문제가 없으며, 효과는 상당할것으로 생각되었습니다.
하지만 지원하고자하는 폰트의 수는 4개에다가, 다양한 브라우저의 지원을 위해 여러가지 확장자로 뽑아내야하고, 사용하고 있는 글리프가 어떤것이 있는지 걸러내기도 해야하는데, 이 작업들을 수동으로 한다면, 수정이 잦은 랜딩페이지 프로젝트를 작업하기에는 너무 많은 수고가 필요했고, 자동화가 되지않는다면 유지보수에 너무 큰 무리가 따를것 같았습니다.
그러던 중, 스포카 기술 블로그의 스포카 한 산스 웹폰트로 사용하기 글에서 서브셋 폰트파일을 쉽게 만드는 스크립트를 제작했다는 내용을 보고, 해당 스크립트를 활용해 자동화를 진행해볼수 있겠다는 생각을 가졌습니다.
스포카에서 배포한 스크립트는 서브셋 글리프들이 적혀있는 txt 파일을 소스로 오리지날 폰트를 서브셋 폰트로 바꾸어주는 스크립트였는데, 해당 서브셋 txt 파일의 내용만 바꾸어 준다면 손쉽게 최적화 폰트를 만들수 있었습니다.
완전한 자동화를 위해 Gulp라는 자동화 모듈에 대해서도 익히고, 빌드된 html 파일들에서 사용되는 글리프들을 txt파일로 추출해주는 코드도 짜서, gulp 커맨드만으로 현재 프로젝트에 정말 최적화된 폰트 파일을 만들어 낼수 있게 되었습니다 .ㅎㅎ
5페이지 정도되는 모두싸인 랜딩페이지의 경우에는 사용되는 글리프들을 추출해보니 약 510자 정도 되었습니다. 3000자에 달하는 서브셋 폰트에 비해 6분에 1수준입니다.
꽤 많은 글이 들어가는 랜딩이라고 생각했는데, 글리프만 뽑아보니 생각보다 적은 느낌..폰트파일로 만들어낸 결과는 상상 이상이었습니다. woff2 기준으로 총 1.3MB에 달하던 4개의 폰트파일들은, 총 128KB, 폰트 하나당 30kb 대로 급감했고,
Regular 3G 환경에서 테스트하였을때, 18초까지 걸리던 로딩시간은 무려 2초대까지로 줄어들었습니다.
더 이상 폰트파일은 로딩에 영향을 주는 자원이 아니게되었습니다.
약 3,000자로 서브셋된 스포카 한 산스 (Regular 3G)
필요한 글리프만 따로 최적화한 500자 정도의 서브셋 폰트 (Regular 3G)여기서 조금더 욕심을 내서, 각 웨이트 별로 실제로 적용되는 글리프만 골라낼수 있다면, 제목용으로만 사용되는 웨이트의 폰트같은 경우에는 1자리 수에 가까운 용량을 만들수도 있을지도 모릅니다만, 살짝만 고민해봐도 많이 어려울것같아 포기합니다...
이 방법은 제한사항이 많지만. 유저가 만들어내는 동적인 텍스트보다는 정적인 정보의 랜딩페이지가 많은 페이지에서는 최적의 적용방법이라고 생각합니다. 어도비의 Type Kit 같이 자동으로 필요한 타입만 나중에 로딩하는 API들을 활용하는것도 비슷한 방법이지만, 완전히 완성된 최소한의 폰트파일을 이용하는것이 더 안정적이고 속도도 빠릅니다.
동적인 정보가 있는 서비스라고 하더라도, Regular 웨이트만 기본 서브셋 폰트를 이용하고, 제목, 안내글, 타이틀과 같은 비주얼 디자인 요소에는 최적화된 Bold, Light 웨이트의 폰트들을 따로 만들어 사용하면, 최소한의 용량으로 디자이너의 웨이트 욕심을 확실히 채울수 있습니다.
쉽게 서브셋화 할 수 잇는 도구들을 이용해 해당 작업들을 자동화하고, 적절하게 해당 폰트들을 활용하면 최적의 효율로 만족할만한 디자인 결과물을 얻을수 있을것이라고 생각합니다.
