[FE] dynamic import와 LCP

 

 

Next.js 로 개발을 진행할때 간간히 dynamic import 를 사용한다. 기능에 대해서는 한번 쯤 들어봤을거다. 커다란 라이브러리를 클라이언트에서 불러오게끔, SSR 되지않게 끔(ssr: false!!) 사용한다. 결과적으로 초기 번들 크기를 줄여준다.  이런 연유에서 dynamic을 사용시에 무조건적으로 이점을 보는것으로 인지하고 있었다.

 

그러다가 어느 한 테스트 페이지의 클라이언트 컴포넌트 전체가 dynamic으로 import 되어있는 페이지를 발견했다. 어쩌다 이렇게 import  된건지 확인하고 싶었지만 이미 닿을 수 없는 분이기도 했고, 이렇게 import를 한들 그렇게 큰 이슈가 있을 것이라고는 생각하지 않았다. 그런데 LCP 점수 차이를 비교하고 당황하지 않을 수 없었다.

 

---

 

 

dynamic 사용 유무에따라 어떻게 렌더링 되는지 먼저 생각해보자

 

[미사용시]

페이지 시작

서버측 HTML 파싱

렌더링 → LCP 측정

 

[사용시]

페이지 시작

서버측 HTML 파싱 

JS 실행 및 A 컴포넌트 요청(추가 작업)

A 렌더링  → LCP 측정

 

 

당연히 추가적인 작업이 들어간다. 그런데 저 요청이 얼마나 많은 소모값이 들지 생각해본적이 있는가?

해당 작업에 따른 LCP 차이는 무려 3초였다. 일반 import 변경시에 0.4초 아래로 나오던 LCP 점수가 현재 4.6초 이상의 점수가 나오고 있었다.  이 경우 클라이언트 컴포넌트 전체가 dynamic에 쌓여있어서 너무 극한의 예시이지만 일반적으로도 큰 라이브러리를 dynamic 으로 사용하면 추가적인 작업이 생기기 때문에 렌더링에 추가적인 시간이 필요하다. 초기 리소스를 줄이는 대신 트레이드 오프를 하는 기분이랄까.. 

 

사용시에 무조건 LCP가 안좋아질까? 꼭 그렇지만은 않다. 사용하는 컴포넌트가 페이지 하단에 있어서 첫 렌더링시 LCP에 영향을 미치거나 모달이나 팝업이어서 클릭시에만 필요한 조건부 컴포넌트의 경우는 큰 영향을 끼치지 못한다.

 

그럼 최상단에 차트를 사용할때 LCP점수가 낮아지니까 dynamic을 사용하면 안되는가..? 보통 최상단에 차트가 많이들 오던데... 혹은 그냥 점수를 포기하고 dynamic을 사용해야할까? 물론 다수의 경우 dynamic을 선택했을 것이다. ssr에서 차트 라이브러리 같은 경우는 거의 필수이기에 말이다. 우리는 LCP를 보완해줄 장치를 추가해주면 된다. 해당 차트가 로드되기 전까지 다른 스켈레톤이나 로딩바를 이용해서 해당 부분을 채워준다면 LCP는 해당 컴포넌트를 기준으로 점수를 측정하게 될것이다. 그렇게 되면 우리는 꿩먹고 알먹고를 해버릴수있는것~

 

---

 

개발할때 옆에 콘솔만 켜놨는데

성능창을 켜놓는것도 새로운 경험들을 마주하게 한다.