개요
새해가 밝은 지금, 지금까지 번들사이즈를 측정하고 감소시키려고 여러 시도를 했다.
오늘은 마지막으로 로컬 폰트로 변경, Next 이미지의 Objectfit 속성 전환, size 지정을 해주었다.
최종 번들사이즈 결과를 비교하고, 성능 점수를 보고 번들사이즈에 대한 리팩토링을 마무리 해보자
로고 폰트 로컬 폰트로 변경
개발 마무리 단계가 아닌 초반부터 의아했던 점이 있는데 늘 Lighthouse 성능 평가의 LCP 부문에서 유독 낮은 점수를 받았다.
근데 다름 아닌 텍스트인 FLEX 로고 부분에서 매번 낮은 붉은색 경고가 보이곤해서 무슨 문제일까 냅두다가 우리 전역 폰트인 Pretendar와는 다르게 로고에서 사용중인 폰트는 웹폰트로 사용중이어서 이부분에서 문제인가 하고 접근하게 되었다.
먼저 로고에 해당하는 Dela Gothic One의 경우 Google폰트를 사용 중인데 이거 또한 NextJS에서 제공하고 CDN을 거쳐 최적화 후 제공하기에 따로 건들지 않았다.
장점으로는 빌드크기에 영향이 없고 단점으로는 네트워크에 의존해 폰트를 가져오기에 FOUT문제 발생 문제나, 네트워크의 성능에 의존된 성능이슈가 있다는 점이다.
반대로, Pretendard의 경우 로컬폰트를 사용중이며, 내가 폰트 파일을 다운받아 사용하는 것이기에, 빌드 파일은 증가하지만, 네트워크 요청이 없기에 렌더링이 빠르다는 장점이 있다.
따라서 빌드 파일의 용량문제냐, 네트워크 지연에 따른 성능저하냐 고민을 해보다 두 개중에 좀 더 나은 결과를 갖는걸 사용하자 해서 로고 폰트를 다운 받았다.
ttf? woff?
문제는 GoogleFont에선 ttf를 제공한다는 점이었다.
Pretendard 로컬폰트 파일의 경우 woff형식이었는데 둘의 차이는 다음과 같다.
당연히 woff가 좋아보여 방법을 찾던중 hwp -> pdf 변환이 있듯이 폰트 파일 확장자도 변환이 가능하길래 이 방법을 택했다.
다음과 같이 이제 woff2확장자의 폰트 파일이 두 개 존재하고 Pretendard는 전역으로 설정을 해 방법이 조금은 다른데
import localFont from 'next/font/local';
export const delaGothic = localFont({
src: '../../../static/fonts/DelaGothicOne-Regular.woff2',
weight: '400',
display: 'swap',
variable: '--font-dela',
});
<div className{`${delaGothic.className}`}> //tailwind사용
...code
</div>
이렇게 선언을 해주고 폰트가 필요한 곳에서 delaGothic을 import해 아래의 div처럼 사용하면 된다.
추가 변경 사항
이렇게 폰트를 바꾸고 눈엣가시처럼 걸리는 코드들이 여전히 몇개 있어 다음과 같은 수정을 시도했다.
NextJS에서 사라진 Objectfit을 tailwind 속성으로 넣어주어 변경했다.
fill 속성의 경우 부모에 사이즈지정을 하고 relative를 명시후 컴포넌트엔 fill 속성을 사용하고 있다.
그런데 이 경우 이미지가 크기를 맞추는 기준이 불완전하거나 이미지 위치, 비율의 경우 명확한 크기를 요하기에 왜곡방지, 성능 최적화면에서 선언을 해주어야한다해서 선언을 해주었다.
결과 성능, 번들 사이즈
성능면에선 75점에서 80점으로 향상 되었지만 여전히 LCP와 관련된 문제가 있는걸로 보아 차차 수정을 해가면 좋은 점수를 받을 수 있지 않을까 싶다.
시원하게 바로바로 고치고 싶지만 사용하지 않는 css구문제거 등 빌드 파일과 관련된 수정 내용들이 많아 해당 파트에 대해 접근을 어떻게 해야할지 감이 잘 오지 않는다.
번들 사이즈
가장 먼저 파일, 라인 수를 보자면
초기
1차 변경 (불필요 코드 삭제)
2차 변경(폰트 확장자, 기타 수정)
1차 변경 이후로는 큰 변화가 없는 거 같다.
번들사이즈의 경우 cloc을 통해 보면
생각보다는 많이 줄지는 않은 것 같다. 폰트 변화나 이미지 변화가 전체 번들사이즈에선 감소를 시켰으나 초기 파일 사이즈는 더 커졌다... 아마 차트를 Light로 바꾸면서 코드를 일부 수정해 이렇게 된게 아닌가 싶다.
next/bundle-analyzer 통한 차이
내가 아직 잘 이해를 못한건지는 몰라도 왜 나오는 구성 파일들이 달라진건지 모르겠다.
둘 다 client html을 비교한건데 흠 전체적 사이즈는 그래도 감소해서 일말의 후련함을 챙겼다.
결론
막상 하다보니 하는 방법 전부 성능과 번들사이즈를 감소면에서 모두 좋은 결과를 보이기 보단 성능과 번들사이즈가 별개로 작용할 때가 많았다.
예를들어 이미지 컴포넌트를 사용하고 초기 사이즈를 지정하는 경우엔 성능면에선 좋게 작용하나, 코드 자체가 길어지기에 번들 사이즈면에선 아무래도 안좋게 작용할 수 밖에 없었다.
따라서, 내가 결정하기로는 성능차이가 크지 않은 경우엔 굳이 변경하지 않는 것도 하나의 방법이라고 생각했다.
물론, 이런 성능 개선 사항들을 여러 번 시도해야 상황에 맞는 해결책을 떠올리는 좋은 안목을 얻을 수 있다는 생각도 갖게 되었다.
'코딩 > Flex프로젝트' 카테고리의 다른 글
재테크 블로그 프로젝트 (12) - 리팩토링 [Next.js caching ] (0) | 2025.01.05 |
---|---|
재테크 블로그 프로젝트 (11) - 리팩토링 [getStaticProps, data fetching] (2) | 2025.01.03 |
재테크 블로그 프로젝트 (9) - 리팩토링 [번들 사이즈 줄이기] (0) | 2024.12.29 |
재테크 블로그 프로젝트 (8) - 리팩토링 [번들 사이즈 측정] (1) | 2024.12.28 |
재테크 블로그 프로젝트 (7) Lighthouse 성능 측정 및 개선 (0) | 2024.11.24 |