참고자료 : 테코톡 프론트엔드 성능 측정
웹 화면을 구현하고 서버로부터 데이터를 받아오는 과정에서 리소스들을 사용자들에게 빠르게 보여줄 수 있는 것
성능 == 속도
그렇다면 프론트엔드에서 성능은 왜 중요할까?


동일한 사이트더라도 사용자의 환경은 모두 다를 수 있음

따라서 속도는 상대적인 개념임

처음 그려지는 화면이 어떤 화면인지, 어떤게 사용자에게 의미있는 화면인지, 상호작용하는 시점은 언제인지와 같은 고민을 통해 보다 다양한 사용자 환경에서 성능을 측정한다.
따라서 사용자 정의 지표가 제공하는 특징들을 이해한 다음 사용자 경험에 중요한 부분들을 설정하는 것이 중요

Core Web Vitals : 구글에서 만든 신뢰성 있는 지표

우수한 사용자 경험을 제공하기 위해서는 페이지가 처음으로 로딩된 후 2.5초 이내에 LCP가 발생해야 함

우수한 사용자 경험을 제공하려면 페이지의 FID가 100ms 이하여야 함
예를들어 사용자가 처음 입력을 입력했을 때 브라우저가 응답을 하는 시간이 100ms 이하여야 함

CLS가 안좋은 예시

56개의 아이템을 장바구니로 이동중이라고 가정하자
이때 로딩중에는 뒤로 가기를 눌러도 버튼이 동작하지 않는다.
프론트엔드 성능 측정 방법에는 크게 실험실 도구와 필드 도구를 사용하는 방법이 있다.
웹 페이지 품질을 검사하기 위한 오픈 소스 도구
DevTools의 Light house 패널에서 사용
실험실 환경에서 성능 및 접근성 등의 사용자 경험 품질을 측정
사이트 성능에 영향을 주는 항목과 각 항목별로 설명과 함께 개선 방안 제공

페이지와 사용자의 상호작용을 확인할 수 없는 실험실 도구이므로 FID 대신 확인할 수 있는 지표인 TBT를 제공
TBT(총 차단 시간)는 메인 스레드가 입력 응답을 막을 만큼 오래 차단되었을 때 시간을 측정

더 간소화된 UI, 사용 사례에 따른 분석 지원, 브라우저 작동 방식에 대한 전문 지식이 없어도 사용할 수 있도록 지원

녹화를 시작하고 페이지와 상호작용하면 리소스를 가져오는 시간 등의 각 지표들에 대해 상세히 확인할 수 있다.

또한 Layout Shift가 일어났다면 어느 부분인지 프레인 단위로 확인할 수 있다.

또한 Coverage 패널에서는 현재 페이지에서 사용하는, 사용하지 않는 js의 비율을 보여줌

Network 패널에서는 리소스 요청 개수와 응답 시간, 용량 등을 확인할 수 있음

인기 사이트의 실제 사용자 경험 데이터를 제공하는 공개 데이터 세트
모든 사용자 중심의 Core Web Vitals 메트린이 데이터 세트에 표시
유의미한 데이터를 제공 받기 위해 공개적으로 검색 가능하고, 충분한 사용자가 있어야 함


위의 방법들 중 상대적으로 적은 노력으로 크게 개선할 수 있는 방법에 대해 알아보자


위의 이미지(랜더링이 느린 이미지)는 원본 이미지로 약 4.3MB이고 아래의 이미지는 사이즈 조정 및 압측을 통해 30.6KB이다.
파일 크기를 99% 축소하였고 이미지 로드 시간을 108ms에서 10ms로 속도를 약 10배 상승했다.

브라우저 동작


위의 코드는 home페이지와 about 페이지가 있는 예제 코드이다.

이 코드를 webpack으로 빌드하면 bundle 크기는 2.9MB이고 응답으로 오는 bundle의 크기는 877KB이다.
home 페이지에 들어왔는데 about페이지에 필요한 모듈과 라이브러리가 포함된 bundle 파일이 오고있다.

분할 결과

이제 초기 진입시 더 빠르게 브라우저를 랜더링할 수 있음


위의 코드처럼 이미지 요소를 작성하면 텍스트가 먼저 위치해있다가 이미지를 가져오면서 텍스트가 밀림

따라서 이미지 요소에 width, height 속성을 추가하여 이미지 가져오기 전 공간 확보하여 텍스트가 밀리는 현상을 방지할 수 있다.

Light house를 통해 확인해보면 CLS 지표가 개선되었다.
또한 앞서 설명한 이미지 압축을 통해 Layout Shift 뿐만아니라 다른 부분까지 개선한다.
