July 31, 2023

React Test and Optimization(feat. Web Vitals)

📦 잡동사니

하나의 키워드를 잡고 좀 편하게 정리하고 싶어 만든 잡동사니<br/>

잡동사니는 조선 후기 학자 안정복이 편찬한 잡동산이(雜同散異)에서 유래된 말이다.<br/> 잡동산이는 잡기(雜記)의 형태를 빌려온 책으로 구체적인 체계가 잡혀있지 않은 형식이다.<br/> 항목이 다소 난잡하고 내용의 구분이 혼동되어있다고 한다. 🤣

들어가기에 앞서

이 글은 원티드에서 주관하는 프리온보딩 프론트엔드 챌린지 8월 - 리액트 리팩토링 실전가이드: 테스트부터 최적화까지 에 제출할 사전과제를 기반으로 작성한 글입니다.

🗂️ 1) 테스트

1-1) 유닛테스트 vs 통합테스트 vs E2E테스트를 비교하여 설명해주세요

유닛테스트

실행 가능한 가장 작은 단위의 소프트웨어(주로 함수)를 테스트
일반적으로 함수, class의 method 단위로 진행한다.
가장 작은 단위를 테스트하는만큼 좀더 직관적이고 빠른 테스트가 가능하다.
사실상 테스트의 기본이라고 할 수 있다.
JS 진영에서는 주로 Jest를 사용한다.

// sum.test.js

const sum = (a, b) => a + b;

describe('더하기', () => {
  it('1과 2를 더하면 3이 반환된다.', () => {
    expect(sum(1, 2)).toBe(3);
  });
});

통합테스트

유닛테스트보다는 큰 단위의 소프트웨어를 테스트
개발자가 변경할 수 없는 외부 의존성을 가진 모듈을 테스트할 때 사용한다.
- ex) DB에 접근하는 것, 다른 모듈을 import 하는 것, 외부 API를 호출하는 것 등
테스트의 범위가 넓어지기 때문에 유닛테스트보다 에러 검출이 어렵다.
사실상 유닛테스트의 확장판이라고 할 수 있다.
JS 진영에서는 주로 Jest를 사용한다.

// sum.test.js

import sum from './sum'; // 외부의 라이브러리에서 가져온 함수라고 생각하자

describe('더하기', () => {
  it('1과 2를 더하면 3이 반환된다.', () => {
    expect(sum(1, 2)).toBe(3);
  });
});

E2E테스트

End to End 테스트의 약자로, 사용자의 시점에서 테스트를 진행한다.
소프트웨어의 내부 코드 구조를 테스트하기보단 비즈니스쪽에 초점을 두고 사용자가 사용하는 관점에서 동작이 잘 되는지를 테스트한다.
Acceptance Test(인수 테스트), UI Test라고도 불린다.
JS 진영에서는 주로 Cypress를 사용한다.

// sum.spec.js

describe('더하기', () => {
  it('1과 2를 더하면 3이 반환된다.', () => {
    cy.visit('http://localhost:3000');
    cy.get('input[name="a"]').type('1');
    cy.get('input[name="b"]').type('2');
    cy.get('button[type="submit"]').click();
    cy.get('div[name="result"]').should('have.text', '3');
  });
});

1-2) 리액트 테스트에 사용되는 도구들을 비교하여 설명해주세요

테스트를 진행한다는 것은

테스트를 진행하는 방법은 크게 2가지가 있다.

HTML 페이지를 만들고 JS 테스트 코드를 작성하여 브라우저에서 직접 테스트를 진행하는 방법
Headless 브라우저를 사용하여 브라우저를 띄우지 않고 테스트를 진행하는 방법
- Headless 브라우저: 브라우저의 화면을 띄우지 않고 브라우저의 기능을 사용할 수 있는 브라우저(주로 브라우저의 Headless mode를 사용한다.)
- 우리가 일반적으로 사용하는 크롬, 파이어폭스 등의 브라우저는 Headful 브라우저라고 한다.
브라우저가 아닌 Node.js 환경에서 테스트를 진행하는 방법 => 당연히 직접 렌더링을 할 수는 없고 jsdom과 같은 가상 DOM(혹은 가상 브라우저)를 사용한다.
- 이 때, 브라우저의 Headless mode와는 다르다. Headless mode는 실제 브라우저를 사용하지만 브라우저의 화면을 띄우지 않는 것이다.

3번의 방법을 추천한다. 또한, 일반적으로 3번의 방법이 자주 사용된다.

테스팅 툴 in JS

테스팅 툴들의 종류는 매우 많다. 하나의 기능만을 제공하는 것들부터 여러 기능을 조합해서 제공하는 것들까지 말이다. 보통은 후자의 테스팅 툴을 사용한다.

🗂️ 최적화

CDN(Content Distributed Network)에 대해 설명해주세요

전세계 여러 지역에 분산된 서버 네트워크로 유저에게 웹사이트 콘텐츠를 효율적이고 빠르게 전달하는 역할을 한다.
웹사이트의 트래픽을 처리하고 데이터 로딩 시간을 최소화하기 위해 서버들이 여러 곳에 분산 배치되어 있다.
- 일반적으로 유저가 웹사이트에 엑세스하려면 해당 웹사이트의 원격 호스트 서버로부터 정보를 가져와야하는데, 거리가 멀수록 더 많은 시간이 소모된다.
CDN은 웹사이트의 콘텐츠를 여러 지역에 위치한 여러 서버에 복제하여, 유저가 웹사이트에 접속할 때 가장 가까운 서버에서 콘텐츠를 제공한다.
- 전송 시간이 줄어든다.
- 웹사이트의 로딩 시간이 단축된다.
- 트래픽이 분산되어 원격 호스트 서버의 부하를 줄일 수 있다.

Web Vitals에 대해 설명해주세요

UX(사용자 경험)를 평가하고 개선하기 위해 사용되는 웹 성능 측정 지표
Google에서 제공하는 Web Vitals는 웹 페이지의 로딩 속도, 상호작용 가능성, 시각정 안정성 등을 측정하여 웹 페이지의 품질을 평가하고 개선하는 데 도움을 준다.

크게 3가지 지표가 있다.

Largest Contentful Paint(LCP)

유저가 웹 페이지를 처음으로 볼 때 가장 큰 콘텐츠 요소가 화면에 표시되는 시간
일반적으로 이미지나 텍스트 블록과 같은 대형 요소가 가장 큰 콘텐츠가 된다.
좋은 UX를 위해서는 LCP가 웹 페이지의 로딩 시간 내에 발생해야 하며, 2.5초 이내로 완료되는 것이 권장된다.

First Input Delay(FID)

웹 페이지가 로딩된 후, 유저의 첫 번째 상호작용(클릭, 터치 등)과 실제로 브라우저가 해당 상호작용에 응답하는 시간
웹 페이지가 얼마나 빠르게 대화형으로 작동하는지 나타내며, 유저가 페이지와 상호작용하기까지 느끼는 지연 시간을 평가한다.
좋은 UX를 위해서는 FID가 100ms 미만이 되도록 최적화하는 것이 권장된다.

Cumulative Layout Shift(CLS)

웹 페이지의 로딩된 동안 콘텐츠의 레이아웃 변화에 따른 시각적 안정성을 측정한다.
유저가 버튼을 클릭하거나 이미지가 동적으로 로드되는 경우 페이지의 레이아웃이 변경될 수 있다. 이 때, 레이아웃의 변화가 사용자 경험에 부정적인 영향을 미치지 않도록 최적화하는 것이 중요하다.
좋은 UX를 위해서는 CLS가 0.1 미만이 되도록 최적화하는 것이 권장된다.
- CLS에 대한 점수 산출 방법은 CLS 점수 산출 방법을 참고하자!
- 정말 단순하게 말하면 레이아웃 변화가 일어날 때마다 변화된 요소의 크기와 위치를 곱한 값을 모두 더한 것이다.

Web Vitals는 웹 페이지 성능 측정을 위해 Chrome 브라우저와 다른 성능 측정 도구들에서 사용할 수 있다. Google Search Console에서 웹 페이지의 Web Vitals 데이터를 확인하고 개선 방안을 제시해 줍니다. 이러한 측정 지표를 바탕으로 웹 개발자들은 사용자 경험을 향상시키고 웹 페이지의 성능을 최적화하는 작업을 수행할 수 있습니다.

Lighthouse에 대해 설명해주세요

Lighthouse는 Google에서 개발한 오픈 소스로, 자동화된 웹 페이지 성능 측정 도구
웹 페이지의 성능과 품질을 평가하기 위해 다양한 측정 항목들을 실행하고 UX를 개선하는 데 도움이 되는 피드백과 권장 사항을 제공한다.
Lighthouse는 Chrome 브라우저의 DevTools에 포함되어 있으며, 커맨드 라인에서도 실행할 수 있다.

성능 지표:

First Contentful Paint(FCP): 웹 페이지가 로딩된 후 첫 번째 콘텐츠가 화면에 표시되는 시간을 측정한다.
Largest Contentful Paint(LCP): 웹 페이지에서 가장 큰 콘텐츠 요소가 화면에 표시되는 시간을 측정한다. Web Vitals의 하나로도 사용된다.
Speed Index(SI): 웹 페이지의 로딩 과정에서 얼마나 빨리 콘텐츠가 표시되는지에 대한 측정 지표입니다.
Time to Interactive(TTI): 웹 페이지가 로딩된 후 상호작용 가능한 상태가 되는 시간을 측정한다.
Total Blocking Time(TBT): 웹 페이지가 로딩된 후 사용자의 상호작용과 브라우저의 응답 사이의 지연 시간을 측정한다. Web Vitals의 하나로도 사용된다.
Cumulative Layout Shift(CLS): 웹 페이지의 로딩 중 발생하는 콘텐츠의 시각적 안정성을 측정한다. Web Vitals의 하나로도 사용된다.

품질 측정 항목:

Accessibility(접근성): 웹 페이지가 접근성 지침을 따르고 있는지를 평가한다.
Best Practices(모범 사례): 웹 페이지가 모범 사례를 따르고 있는지를 평가한다.
SEO(검색 엔진 최적화): 웹 페이지의 검색 엔진 최적화 상태를 평가한다.
Progressive Web App(PWA; 점진적 웹 앱): 웹 페이지가 점진적 웹 앱으로서의 조건을 충족하는지를 평가한다.

Lighthouse는 이러한 성능 지표와 품질 측정 항목들을 사용하여 웹 페이지의 전반적인 품질을 평가하고, 개발자들이 사용자 경험을 향상시키기 위해 어떤 부분을 개선해야 하는지에 대한 정보를 제공한다. 또한, Lighthouse 결과 보고서는 웹 개발자들이 성능 최적화 작업을 추적하고 검증하는 데도 유용하게 활용될 수 있다.

참고

undefined