웹 페이지의 성능 최적화에 대해

최근 AightNow 팀 프로젝트를 진행하면서 최적화에 대해 생각해 보는 기회가 있었다.

 

사실 처음 페이지와 공통 컴포넌트를 구현할 때는 말 그대로 '완성'만 생각하느라 최적화에 대해 생각하지도 못하고 있었다.

 

어느정도 구현이 끝난 후 팀원분과 최적화를 진행한 내용을 포함하여 이것저것 정리해 본다.

 

---

그래서 최적화 왜 해야되나?

1) 비즈니스 관점과 사용자 경험

단순히 생각하면, 웹 페이지의 성능을 최적화 한다는 것은 사용자가 보는 페이지를 빠르게 보여주는 것이다.

일반적으로 생각해봐도, 페이지의 빠른 로딩은 사용자에겐 긍정적인 사용자 경험(UX)을 제공 할 것이다.

 

나 같은 경우에도, 사이트에 방문했는데 흰 화면이나 부분부분 천천히 렌더링되는 사이트를 보고 있으면 답답하다는 생각부터 드는 것이 당연하니까 말이다.

이런 경우가 잦아지게 되면 사용자의 이탈로 넘어가게 되고 사용자에 대한 비즈니스에도 문제가 생길 수 있다.

 

 

2) 검색 엔진 최적화(SEO)

2021년 5월부터 웹 성능 지표(웹 성능 최적화가 어느정도 되었는가)가 Google의 검색엔진 순위에 영향을 미친다고 발표했다고 한다.

 

웹 성능 지표에 관한 항목들이다.

---

1) FCP (First Contentful Paint)
페이지 로드가 시작된 후 페이지 콘텐츠의 일부가 화면에 렌더링 될 때까지의 시간을 측정.

※ 개선방법
 - 리소스 요청 수를 줄이고 응답 크기 작게 유지
 - 효율적인 캐시 정책으로 정적 asset 제공
 - CSS 용량 최적화
 - 렌더링 차단 리소스 제거 
 - 과도한 DOM 크기 피하기

 

2) LCP (Largest Contentful Paint)
페이지에서 핵심 요소의 콘텐츠 로딩 속도를 측정.
일반적으로 페이지에서 가장 큰 영역으로 해당 영역에 있는 이미지, 영상, 텍스트 부분 등 요소의 렌더링 성능을 기반으로 측정된다.


※ 개선방법

 - 느린 서버 응답 시간을 최적화

 - JavaScript와 CSS 같은 렌더링 차단 요청 최적화

 - 웹 폰트, 이미지와 같은 리소스 로딩 시간 최적화

 - 클라이언트 사이드 렌더링 최적화


3) FID (First Input Delay, 최초 입력 지연 시간)
콘텐츠의 상호작용 속도를 측정합니다.
사용자가 페이지와 처음 상호 작용(링크 클릭이나 버튼 클릭 등)을 할 때, 브라우저가 그 이벤트를 처리하기 까지의 시간을 측정하는 것
Lighthouse에서는 TBT(Total Blocking Time)이라는 지표와는 다르지만, Lighthouse에서 성능을 측정할 시 TBT를 개선하는게 FID에도 개선효과를 줌

 

※ 개선방법

 - Third-party 코드 영향 감소

 - JavaScript 실행 감소

 - 적은 요청 수와 작은 응답 사이즈

 - 메인 쓰레드 실행 최소화

4) CLS (Cumulative Layout Shift, 페이지 로드 시 축적된 화면의 움직임)
페이지에서 발생하는 모든 예기치 않는 레이아웃 이동에 대한 모든 개별 레이아웃 이동 점수의 합계를 측정.
이동 거리 비율 X 이동한 영역 비율로 계산.
페이지 방문자의 시각적인 안정성을 측정하는 것으로 사용자 경험(UX)에 중요한 경향을 끼침.
사용자에게 웹 페이지가 표시되고 최종적으로 변화하는 정도를 측정한 수치.

 

※ 개선방법

 - 항상 이미지 및 동영상 요소에 크기 속성을 포함

 - 사용자 상호 작용에 대한 응답을 제외하고는 기존 컨텐츠 위에 컨텐츠를 삽입하지 않기

 - 레이아웃 변경을 트리거 애니메이션보다 transform 애니메이션으로 적용

 

5) TTI (Time to Interactive)
페이지가 로드 되기 시작한 시점부터 기본 하위 리소스가 로드 된 시점까지의 시간을 측정하며 사용자 입력이 가능한 시점을 측정.

 

※ 개선방법

 - JavaScript 최소화

 - 요청 preload

 - 주요 요청 깊이 최소화

6)TBT (Total Blocking Time)
FCP와 TTI 사이의 총 시간을 측정.
메인 스레드는 50ms 이상 실행되는 작업인 Long Task가 있을 때 차단된 것으로 간주하는데, FCP와 TTI 사이에 발생하는 각 Long Task의 차단 시간의 합계가 TBT이다.

 

※ 개선방법

 - Third-party 코드 영향 감소

 - JavaScript 실행 감소

 - 메인 쓰레드 실행 최소화

 - 적은 요청 수와 작은 응답 사이즈

---

 

LCP 기준 2500ms 미만 성능 좋음 /  4000ms 초과 성능 나쁨
FID 기준 100ms 미만 성능 좋음 / 300ms 초과 성능 나쁨
CLS 기준 0.1 미만 성능 좋음 / 0.25 초과 성능 나쁨
으로 판단할 수 있다 

 

---

 

프로젝트에선 어떻게 적용을 했을까?

 

아래 이미지는 www.google.com의 Lighthouse 검사의 결과이다.

www.google.com 의 Lighthouse 검사 지표

 

 

검사 결과를 보면 항목에 FCP, LCP, CLS, TBT 가 있는 것을 볼 수 있다.

 

 

 

팀 프로젝트를 진행하면서 팀원분과 최적화를 진행하였고 그 결과이다.

배포된 팀 프로젝트의 Lighthouse 검사 지표

해당 페이지는 최적화를 진행한 '뉴스'탭을 검사한 것이고, FCP는 0.4초, LCP는 0.7초, CLS는 0이 나온것을 볼 수 있다.

 

최적화를 하기 전에는 성능이 88 ~ 89점, LCP가 2.4 ~ 2.5초로 측정되었다.

 

처음으로 뉴스 페이지에 사용된 카드 컴포넌트의 Image 태그에 최적화를 진행하였다.

        <Image
          src={news.thumbnail}
          alt="thumbnail"
          fill
          className=" object-cover transition-transform duration-700 ease-in-out hover:scale-125 cursor-pointer"
          sizes="420px"
          priority
        />

 

(Card 컴포넌트의 코드 중 일부. 최적화를 진행하기 전에는 sizes="420px", priority가 빠져있었다.)

 

 

1) 타입 별로 나눠둔 Card의 Image 태그에서 LCP 개선이 필요한 Card의 Image 태그에 div의 크기만큼의 sizes를 지정하여, 불필요하게 큰 이미지의 렌더링을 최소화하고, 이미지의 용량을 줄이도록 했다.

 

그럼에도 불구하고, 성능과 LCP가 변하지 않았는데, LCP의 로드지연이 감소되지 않는 것을 확인하였다.

 

 

2) 해당 페이지에서 사용되는 Card 컴포넌트는 3가지였고, 3가지의 Image 태그에 모두 1)과 같은 작업을 모두 적용하였다.

해당 페이지에서 이용되는 Card 컴포넌트의 이미지를 모두 최적화 하는 작업을 하였으므로 성능 및 LCP가 개선이 될 것이라고 생각하였지만, 그럼에도 불구하고 성능 88, LCP 2.4초는 개선되지 않았다.

 

3) LCP 개선방안 중   '웹 폰트, 이미지와 같은 리소스 로딩 시간 최적화' 에서, 렌더링 되는 모든 이미지를 최적화 했는데도 불구하고 개선이 되지 않았다면, 폰트가 문제가 아닐까? 하는 의문이 들었다.

"혹시 폰트 문제가 아닐까요?" 라는 물음과 함께 팀원분이 폰트 최적화를 시도하였다.

 

 

4) 기본 폰트에서 subset 폰트로 교체하면서 LCP가 개선되었고, 위의 사진과 같이 성능 99점, LCP 0.7초로 확실하게 개선이 되며 3시간 동안의 답답함이 해소가 되었다.

 

---

최적화를 진행하면서 몰랐던 부분도 너무 많았다. 완성만 생각하며 코드를 작성했는데, 최적화를 진행하면서

'만약 내가 최적화를 미리 생각했다면, 미리 작업을 해두었을 텐데'라는 생각도 들었고,

 

이미지만 최적화 작업을 하다가 폰트 최적화를 통해 개선된 모습을 보며, 

'다양한 요소가 영향을 끼칠 수 있으니, 당장 문제라고 생각되는 보이는 것 뿐만 아니라 여러 요소와 개념을 알고 적용 할 줄 알아야 한다'라는 생각을 하게 됐다.