(리액트 딥다이브 12장 정리)
사용자가 웹 사이트에 접속했을 때 공통적으로 기대하는 사항
이 외에는 어떻게 만들었든지 고객들에게 전혀 중요하지 않다. 리액트가 아무리 좋은 프레임워크라고 해도 웹 사이트의 성능이 뒤떨어진다면 이용자들의 호응을 얻기란 힘들다. 사용자가 느끼는 성능이 제일 중요하다.
웹 사이트 성능과 사용자 경험 사의 상관관계 (2019년 디지털 마케팅 에이전시 회사인 Protent의 조사)
구글에서 웹 사이트의 성능에 관한 통계
방문자들은 그다지 인내심이 많지 않다. 웹페이지 성능 또한 개발자의 책임이며, 웹사이트의 성능은 조직이 이루고자 하는 목표와 직결된다고 봐도 무방하다.
핵심 웹 지표
특정 문제를 진단하는데 사용될 수 있는 지표
⇒ 각 엘리먼트가 등장한 시점부터 텍스트 또는 이미지가 완전히 로딩되는 시점
사용자의 기기가 노출하는 뷰포트 내부에서 가장 큰 영역을 차지하는 요소가 렌더링되는데 얼마나 걸리는지를 측정하는 지표인 것이다.
단순히 사용자에게 로딩이란 뷰포트 영역에 보이는 부분을 기준으로 메인 컨텐츠가 화면에 완전히 전달되는 속도를 기준으로 하는데 사용자에게 페이지 정보를 화면에 전달하는 속도를 객관적으로 판단하기 위한 지표로 만들어진 것이 바로 LCP이다.
LCP 에서 좋은 점수란 해당 지표가 2.5 내로 응답이 오는 것이다.
LCP 지표에 이미지가 아닌 문자열을 넣는게 확실히 더 빠르다. 가능한 한 텍스트로 채우는 것이 좋다.
개발자가 선택할 수 있는 이미지 노출 방법
// img
<img src="lcp.jpg" ... />
// svg
<svg xmlns="http://www.w3.org/1000/svg">
<image href="lcp.jpg" />
</svg>
// video.poster
<video poster="lcp.jpg"></video>
// background-image: url()
<div style="background-image: url(lcp.jpg)">...<div/>
사용자가 페이지와 처음 상호 작용할 때부터 해당 상호 작용에 대한 응답으로 브라우저가 실제로 이벤트 핸들러 처리를 시작하기까지의 시간을 측정한다.
사용자가 얼마나 빠르게 웹페이지와 상호작용에 대한 응답을 받을 수 있는지 측정하는 지표이다. 최초의 입력 하나에 대해서만 그 응답 지연이 얼마나 걸리는지 판단한다.
웹사이트 내부의 이벤트 반응이 늦어지는 이유는 브라우저의 메인 스레드가 바쁘기 때문이다. 바쁜 이유는 대규모 렌더링이 일어나거나 대규모 JS 파일을 분석하고 실행하는 등 다른 작업을 처리하는데 리소스를 할애하고 있기 때문이다.
메인 스레드가 바쁜 경우, JS 실행 환경은 ‘싱글 스레드’이기 때문에 자바스크립트가 이벤트 리스너와 같은 다른 작업을 실행할 수 없어 지연이 발생한다.
FID를 이해하기 위해 알아야 할 것은 ‘사용자의 입력’이다. 반응성에 해당하는 클릭, 터치, 타이핑 등 사용자의 개별 입력에 초점을 맞추고 측정한다.
구글은 사용자 경험을 크게 4가지로 분류하는데 이를 RAIL이라고 한다.
이 가운데 FID는 R에 해당하는 응답에 초점을 맞추고 있다.
⇒ FID란 화면이 최초로 그려지고 난 뒤, 사용자가 웹페이지에서 클릭 등 상호작용을 수행했을 때 메인 스레드가 이벤트에 대한 반응을 할 수 있을 때까지 걸리는 시간을 의미한다. 그리고 이 시간은 메인 스레드가 처리해야 하는 다른 작업이 많을수록 느려진다.
메인 스레드에 이벤트를 할 여유를 줘야 한다.
긴 작업(long task)이란 말 그대로 실행을 완료하는 데 오래 걸리는 작업을 의미한다.
크롬 개발자 도구에서 [도구 더보기]로 들어가서 [커버리지]를 클릭하고 기록버튼을 클릭하고 새로고침하면 커버리지가 기록된다.
이를 통해 웹페이지에서 사용되지 않은 코드가 얼마나 있는지 알 수 있다. 폴리필을 넣는 것 또한 매우 큰 용량을 차지하는데 SWC를 사용하고 있다면 SWC 내부에 구현되어 있기 때문에 별도의 처리는 필요 없다.
타사 스크립트는 대부분 웹페이지 로드에 중요한 자원이 아니므로
따라서 타사 자바스크립트에서 최고는 defer, 그 다음 async로 지연시키는 것이 좋다.
페이지의 생명주기 동안 발생하는 모든 예기치 않은 이동에 대한 지표를 계산하는 것.
CLS는 사용자의 가시적인 콘텐츠의 영향을 미쳐야 하기 때문에 뷰포트 내부의 요소에 대해서만 측정하며, 뷰포트 밖의 요소에 대해서는 측정하지 않는다. 최초 렌더링이 시작된 위치에서 레이아웃 이동이 발생하면 누적 레이아웃 이동 점수로 기록하게 된다. 위치에 영향을 미치지 않았다면 레이아웃 이동으로 간주되지 않는다.
사용자의 액션으로 인해 발생한 레이아웃 이동은 점수에 포함되지 않는다. 점수를 계산할 때 포함되는 내용은 다음과 같다.
useEffect
의 내부에서 요소에 영향을 미치는 작업, 뷰포트 내부에서 노출될 확률이 높은 작업을 최소하는 것이 좋다.useEffect
사용이 불가피하다면 useLayoutEffect
훅을 사용해보는 것 또한 좋다.폰트로 발생할 수 있는 문제는 두 가지
사용자 기기의 기본 폰트 이외에 다른 폰트로 웹페이지를 보여주고 싶다면 다음과 같은 점을 유념해야 한다.
font-family: optional
”: 폰트를 불러올 수 있는 방법은 5가지로 나뉜다.최대한 중요한 폰트의 다운로드를 우선순위에 밀어넣고, 이 우선순위를 활용했음에도 빠르게 로딩하는데 실패했다면 다음을 기약하고 기본 폰트를 노출하는 것이다.
반응형 웹사이트란 사용자 기기의 크기에 따라 자연스럽게 콘텐츠를 자연스럽게 노출할 수 있도록 다양한 요소를 콘텐츠의 기기에 의존하도록 만든 웹사이트를 일컫는다.
img {
width: 100%;
height: auto;
}
이 경우 누적 레이아웃 이동이 커지는 결과를 낳는다. 앞서 설정한 CSS 때문에 높이를 이미지가 완전히 다운로드되기 전까지는 알 수 없기 때문에 이미지의 높이를 높게 잡아뒀다가 이미지가 완전히 로딩 완료된 이후에 기기의 너비만큼 계산해서 마침내 이미지 크기만큼 자리 잡을 수 있게 된 것이다.
height:auto
기법은 반응형 웹사이트에서 최적화할 수 있는 기법으로 기기의 너비가 어떻게 되는 원본 이미지의 가로세로 비율이 일정해 사용자에게 최적의 이미지를 보여줄 수 있는 장점이 있다. 그러나 앞선 사례처럼 이미지의 높이를 명확하게 알지 못하기 때문에 레이아웃 이동이 크게 발생한다는 단점이 있다.
width:100%; height:auto
와 함께 원하는 비율로 지정하면 브라우저가 이미지를 로딩하기 전에 적절한 가로세로 비율을 계산해 이미지가 표시되는 만큼 면적을 할당해 둔다. 이는 aspect-ratio 속성 덕분인데, 이 속성은 이 속성은 브라우저의 유저 에이전트 스타일시트(브라우저가 기본으로 제공하는 스타일)에 포함돼 있으며, 이미지의 가로세로 비율을 자동으로 맞춰주는 역할을 한다.: TTFB는 브라우저가 웹페이지의 첫 번째 바이트를 수신하는데 걸리는 시간을 의미.
: FCP는 페이지가 로드되기 시작한 시점부터 페이지 콘텐츠의 일부가 화면에 렌더링될 때까지의 시간을 측정
개선 사항