-
Notifications
You must be signed in to change notification settings - Fork 0
이미지 레이지 로딩과 폰트 서브셋으로 Lighthouse 퍼포먼스 100점 찍기
저희 페이지는 실시간성이 중요한(실시간 이벤트가 존재함) 이벤트 페이지이기 때문에, 사용자에게 더 빠르게 컨텐츠를 보여주어야 해요. 그래서 크롬 Lighthouse의 Performance 점수를 올리는 걸 4주차의 목표로 삼고 있었어요. 저희는 Static Site Generation을 채택하고 있기 때문에, 당연히 fcp와 lcp가 빨리 나올 것이라고 기대하고 있었어요. 하지만, 이게 웬걸! (PC 기준) FCP가 5초 이상, LCP가 10초 이상 걸리는 것이었어요. 분명 클라이언트 사이드 렌더링에 비해서 스태틱 사이트 제너레이션은 자바스크립트 파싱 후 레이아웃 변경 과정을 생략해서 렌더링 속도를 개선한다고 알고 있었는데, 그렇지 않았던 것이었어요.
우선 가능한 전략은 이미지에 lazy loading을 적용시키는 것이었어요. 저희의 페이지는 스크롤 위주로 구성된 긴 페이지였어요. 그렇기 때문에 대부분의 이미지들은 시작 시점에 바로 보여지지는 않고, 나중에 보여져요. 하지만, lazy loading을 적용하지 않으면 유저 플로우상 나중에 보여지는 이미지들도 페이지가 로딩될 때 같이 로딩되기 때문에, 초기 렌더링 속도를 저해해요.
<img src="/my-image.png" alt="이미지임" loading="lazy" />
그래서 인트로 섹션을 제외하고, 나머지 섹션에 존재하는 이미지에 lazy loading을 걸어주었어요.
그 결과, FCP가 5초 가량 개선되는 모습을 볼 수 있었어요.
하지만 이미지 lazy loading을 적용했음에도 불구하고 아직 5초의 FCP 지연과 5초의 LCP 지연이 남아있었어요. 저희는 다양한 시도를 해 보다가, 우연히 폰트를 제거해 보았고, 폰트를 제거했더니 FCP와 LCP가 극적으로 향상되는 것을 볼 수 있었어요. 그래서, 저희는 원인 불명의 렌더링 지연의 이유를 '폰트'로 규정했어요.
폰트 최적화 방법을 모색하다, 폰트 프리로드라는 것을 알게 되었어요.
<link rel="preload" href="/font/HyundaiSansTextKROTFBold.woff2" as="font" type="font/woff2" crossorigin="anonymous">
<link rel="preload" href="/font/HyundaiSansTextKROTFRegular.woff2" as="font" type="font/woff2" crossorigin="anonymous">
<link rel="preload">
속성을 이용하면, 다른 속성 대비해서 우선적으로 로딩되는 속성을 정의할 수 있어요. 저희의 폰트는 페이지 전역적으로 반드시 사용되기 때문에, 폰트를 미리 로딩하는 것이 다른 리소스를 로딩하는 것보다 중요해요.
폰트 프리로드를 적용한 결과, FCP가 5초 가량 개선되었어요.
폰트 프리로딩을 한 결과 FCP가 개선되는 이유를 추정하자면, 기존에는 CSS에서 폰트를 로딩할 때, 폰트 리소스를 발견하면 폰트가 없기 때문에, 폰트가 전부 로딩될 때까지 기다린 뒤 폰트를 body에 적용하는 것으로 보여요. 비록 font-display: swap;
을 설정했는데도 불구하고 말이죠. 하지만, 폰트를 미리 로드하면, CSS는 폰트가 로드되고 있다는 것을 인지하고 즉시 대체 폰트를 보여주게 되어 FCP 성능이 향상되는 것으로 추정되어요.
하지만 폰트를 미리 로딩해도 한글 폰트 자체가 크기 때문에, 실제로 폰트가 적용되는 시간이 길어져서 LCP의 지연을 막을 수는 없었어요. 그래서, 저희는 폰트의 크기 자체를 줄이는 방법을 모색했어요.
한 가지 방법은 폰트를 woff2로 변경하는 것이었어요. woff2는 최신 포맷인 만큼 OTF보다 약 44% 감소된 용량을 볼 수 있어요. woff2 자체는 ie에서는 지원하지 않지만, 대부분의 모던 브라우저에서 지원하기 때문에, ie를 지원하지 않을 계획인 저희가 사용하기 문제 없다고 판단했어요. 이 결과, LCP가 2초 정도 개선되었어요.
마지막으로 시도한 방법은 폰트 서브셋을 적용하는 것이었어요. 폰트 서브셋은 사용하지 않는 폰트를 제거하는 것으로, 자주 사용되는 완성형 한글 2350자만을 폰트에 포함시키는 것이었어요. 물론, 사용하지 않는 폰트는 기본 폰트로 표현되어서 레이아웃이 틀어지는 문제는 있지만, 적어도 입력 창을 제거한 나머지 영역에서는 완성형 한글 2350자만 사용하기 때문에 크게 문제되지 않을 것이라고 판단했어요.
폰트 서브셋을 적용한 결과, LCP가 3초 정도 개선되어, 최종적으로 FCP와 LCP가 0초대를 달성하게 되어, 라이트하우스 퍼포먼스 점수를 100점을 찍을 수 있게 되었어요! 이예에!
-
🎯 기술적 선택 이유
-
✨ UX 및 접근성
-
#️⃣ 코드 퀄리티
-
🛠️ 구현