[3차] 프리온보딩 챌린지(FE) - 백엔드 코드를 수정할 수 없을 때 프론트엔드가 할 수 있는 최적화 방법

[Week 2-1] 백엔드 코드를 수정할 수 없을 때 프론트엔드가 할 수 있는 최적화 방법

 

3-1) 성능 측정 툴 소개 및 사용법

웹 애플리케이션의 성능을 측정하고 분석하는 데 사용할 수 있는 툴에 대해 알아보았다.

애플리케이션의 로딩 속도, 실행 시간, UX 등 다양한 측면에서 성능을 평가하고, 이를 통해 성능 저하의 원인을 찾아 개선할 수 있도록 도와준다.

 

Lighthouse

Lighthouse

- 웹 성능을 분석하는 오픈 소스
- 주요 기능
1) 성능 분석
2) 접근성 검사
3) SEO 평가
4) PWA 기준 평가

https://chromewebstore.google.com/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk?hl=ko

Lighthouse

 

lighthouse

Web Vitals

https://developers-kr.googleblog.com/2020/05/Introducing-Web-Vitals.html

Web Vitals 소개: 건강한 사이트를 위한 필수적인 측정항목

사용자 경험을 측정하는 프로그램인데 항목은 LCP, FID, CLS 총 3가지가 있다.

- Largest Contentful Paint는 인식되는 로드 속도를 측정하는 항목으로, 페이지의 주요 콘텐츠가 로드되었을 가능성이 높은 시점에 페이지 로드 타임라인에 점을 표시합니다.

- First Input Delay는 응답성을 측정하는 항목으로, 사용자가 페이지와 처음 상호 작용하려고 할 때 느끼는 경험을 정량화합니다.

- Cumulative Layout Shift는 시각적 안정성을 측정하는 항목으로, 눈에 보이는 페이지 콘텐츠의 예기치 않은 레이아웃 변화량을 정량화합니다.

 

https://developers-kr.googleblog.com/2020/05/Introducing-Web-Vitals.html

LCP : 페이지의 주요 콘텐츠가 얼마나 빨리 로드되는지 측정하는데 주요 컨텐츠라는 기준이 애매하며, 실제로는 가장 큰 텍스트나 이미지를 나타낸다.

 

FID : 첫 이벤트 핸들링에 소요되는 시간을 측정한다. 이벤트가 걸려있는 버튼 또는 메뉴를 클릭하였을 때 해당 이벤트가 언제 발생하는지 측정하게 된다.

 

CLS : 페이지의 레이아웃이 얼마나 많이 변동하는지 측정한다. 만약 UI가 자주 변경이 된다면 UX에 방해를 주는 요인이기 때문에 사용자에게 직접적으로 연관이 있다.

 

Performance

https://developer.chrome.com/docs/devtools/performance?hl=ko

런타임 성능 분석  |  DevTools  |  Chrome for Developers

 

https://mike-diaz006.medium.com/what-i-learned-at-work-this-week-chrome-devtools-performance-tab-4dfdf5aa531e

What I Learned at Work this Week: Chrome DevTools Performance Tab

Performance는 Chrome의 개발자도구 중 탭에서 확인할 수 있다.

렌더링 성능, CPU/메모리 사용량 등을 측정할 수 있다. 타임라인 기능을 통해 웹 페이지가 로드되고 실행되는 동안 발생하는 이벤트들을 시간 순으로 볼 수 있기 때문에 성능 저하를 일으키는 요소를 파악하기 쉽다.

https://developer.chrome.com/docs/devtools/performance?hl=ko#analyze

 

Profiler

https://ko.react.dev/reference/react/Profiler

<Profiler> – React

React에서 컴포넌트의 렌더링 성능을 측정하기 위한 내장기능이다.

특정 컴포넌트가 얼마나 자주 렌더링 되는지, 렌더링 시간은 얼마나 소요되는지 알 수 있다.

오늘하날 Home 컴포넌트

개인 프로젝트의 첫 페이지 컴포넌트인 Home 컴포넌트를 Profiler를 통해 측정해 보았다.

mount : 마운트시 actualDuration이 baseDuration보다 높게 측정이 되어 다른 작업이 동시에 실행되는 것으로 나타났다. 차이가 크게 난다면 병목 현상이 일어날 수 있다고 하니 확인해 볼 필요가 있다.

nested-update, update : actualDuration이 낮은 수준으로 측정되고 있기에 업데이트가 빠르게 되고 있음을 알 수 있었다.

 

---

 

3-2) 최적화

Code Splitting

코드 스플리팅을 통해 하나의 번들로 묶여있는 코드를 분리해 나갈 수 있다. 이렇게 하면 초기 렌더링 시간을 줄일 수 있다.

오늘 챌린지에선 React에서 사용할 수 있는 React lazy와 Suspense를 알려주셨는데 같이 조합하여 사용하면 더 효과적으로 최적화를 할 수 있다.

 

https://web.dev/articles/code-splitting-suspense?hl=ko

React.lazy 및 Suspense를 사용한 코드 분할  |  Articles  |  web.dev

 

React lazy는 동적 import를 사용하여 컴포넌트를 비동기적으로 로드하는 기능인데, 이를 통해 컴포넌트의 코드를 별도의 번들로 나누고 해당 컴포넌트가 실제로 필요할 때까지 로딩을 미룰 수 있다.

https://ko.react.dev/reference/react/lazy

lazy – React

// React lazy
const OtherComponent = React.lazy(() => import('./OtherComponent'));

 

Suspense는 React lazy로 불러온 컴포넌트의 렌더링을 지연시키는 역할을 한다. 컴포넌트의 로딩 상태를 관리하고, 컴포넌트가 로드되는 동안 로딩 화면(로딩 스피너)을 출력할 수도 있다.

https://ko.react.dev/reference/react/Suspense

<Suspense> – React

// React lazy + Suspense
import React, { Suspense } from 'react';

const OtherComponent = React.lazy(() => import('./OtherComponent'));

function MyComponent() {
  return (
    <div>
      <Suspense fallback={<div>Loading...</div>}>
        <OtherComponent />
      </Suspense>
    </div>
  );
}

 

https://crystallize.com/comics/no-code-splitting-vs-code-splitting

📝 오늘의 3줄 요약
1. 간단한 애플리케이션을 만들 때 고민하지 않았던 로드/렌더링 등의 성능의 개념을 처음 알게 되었다.
2. React Profiler를 사용하면 컴포넌트 별로 성능을 측정할 수 있으므로 큰 도움이 될 것 같다.
3. 측정을 통해 문제를 찾고 해결하는 능력도 개발자의 주요 역량이므로 많이 공부해야겠다.