Light House를 통한 웹 성능 최적화 진행 해보기

최근 사이드 프로젝트의 담당 기능을 다 구현하여 Light House의 지표를 통한 성능 최적화를 진행해 보았습니다.

 

Light House의 점수 기준은 아래와 같습니다.

• 0~49(빨간색): 나쁨
• 50~89(주황색): 개선 필요
• 90~100(녹색): 양호

Light House의 공식문서에는 좋은 사용자 경험을 위해 90점 이상을 유지하도록 노력해야 한다고 말하고 있습니다.

Light House 측정은 정확한 측정을 위하여 yarn build -> yarn start를 진행하여 production 환경에서 진행하였습니다.

최적화 전 측정 점수

Performance 최적화

Performance를 측정하는 항목은 5가지로 정의됩니다. 

초록색은 빠름, 노란색은 중간, 빨간색은 느림을 의미합니다.

• First Contentful Paint (FCP) : 초기 DOM을 렌더링 하는 데 소요되는 시간
• Largest Contentful Paint (LCP) : 가장 큰 콘텐츠를 렌더링 하는 데 걸리는 시간
• Total Blocking Time (TBT) : 마우스 클릭, 키보드 누름과 같은 사용자 입력에 페이지가 응답하지 못하도록 차단된 총 시간
• Cumulative Layout Shift (CLS) : 사용자가 예상치 못한 레이아웃을 이동을 경험하는 것에 대한 점수
• Speed Index (SI) : 콘텐츠가 시각적으로 표시되는 진행 속도를 측정한 시간

 

Avoid an excessive DOM size

해당 증상은 페이지에 1500개 이상의 DOM node들이 있거나, 최대 node depth가 32개 이상이거나, 자식 node가 60개 이상인 상위 node가 존재하는 경우 발생하는 증상입니다. 현재 총 element가 1,747개라고 빨간색으로 표시되고 있습니다.

기존 svg

기존에 사용하고 있던 svg입니다. 불필요한 코드가 많아 보이며 불필요한 DOM node도 많이 생성될 것이라고 예상할 수 있습니다.

디자인은 똑같지만 새로운 svg로 교체해 주어 증상을 해결해 주었습니다.

 

Accessibility 최적화

Buttons do not have an accessible name

버튼에 식별 가능한 이름이 없다는 경고입니다.

스크린 리더 사용자가 특정 Button이 어떤 Button인지 쉽게 브라우저를 읽을 수 있도록 aria-label attribute를 넣어주어 해결하였습니다.

스크린 리더란?
스크린 리더란 시각장애인 사용자들에게 컴퓨터의 화면과 자신이 입력한 키보드 정보 그리고 마우스 좌표 등을 음성으로 알려 주어 컴퓨터를 사용할 수 있도록 도와주는 소프트웨어입니다.

   <button
          aria-label="Copy Button"
          type="button"
          onClick={() =>
            copyToClipBoard(`${process.env.NEXT_PUBLIC_CLIENT_URL}/chat/${id}`)
          }
        >
          <ShareIcon className="w-6 h-6" />
        </button>

 

 

최적화 후 점수

 

 

Performance는 총점이 88 -> 93점으로 향상되었습니다.

LCP의 아직 노란색이긴 하지만 2.5s 이하면 안정권이기 때문에 만족할만한 수치가 나온 것 같습니다.

 

Accessibility는 총점이 83 -> 95점으로 향상되었습니다.

 

최적화를 진행하며 느낀 점은 사소한 것 하나로 인해 점수가 크게 바뀔 수 있다는 점이며 성능에도 영향을 끼친다는 점이었습니다. 또한 Light house의 점수가 측정할 때마다 약간 바뀌는(?)것 같아 추가적인 기능을 추가할 때나 항상 성능을 주기적으로 모니터링해야 할 것 같습니다.