모던 리액트 deep dive 스터디 - 12장 발표 정리

 

모던 리액트 deep dive 스터디 - 12장 발표 정리

 

 

 

 

 

 

주제: 12장. 모든 웹 개발자가 관심을 가져야 할 핵심 웹 지표 (775p ~ 812p)

 

---

핵심 웹 지표

 

- 최대 콘텐츠풀 페인트(LCP)

- 최초 입력 지연(FID)

- 누적 레이아웃 이동(CLS)

 

- 최초 바이트까지의 시간(TTFB)

- 최초 콘텐츠풀 시간(FCP)

 

 

---

 

1. 최대 콘텐츠풀 페인트(LCP)

 

페이지가 처음으로 로드를 시작한 시점부터 뷰포트 내부에서 가장 큰 이미지 또는 텍스트를 렌더링하는 데 걸리는 시간

 

 

큰 이미지와 텍스트 (가장 큰 요소로 고려됨)

• <img>
• <svg> 내부의 <image>
• poster 속성을 사용하는 <video>
• url()을 통해 불러온 배경 이미지가 있는 요소
• 텍스트와 같이 인라인 텍스트 요소를 포함하고 있는 블록 레벨 요소 (<p>, <div>...)

 

크기가 크더라도 뷰포트 영역 밖에 있다면 해당 영역의 크기는 고려되지 않음

 

 

사용자에게 노출되는 부분만 로딩된다면 페이지 로딩이 완료된다고 느낄 껏이다.

이런 속도를 객관적으로 판단하기 위한 지표

 

 

좋은 점수는 2.5초 내, 보통은 4초 이내

 

 

⚒️ 개선 방법

 

1. 최대 콘텐츠풀 페인트 예상 영역에 이미지가 아닌 문자열 넣기

이미지보단 텍스트가 빠를 수 밖에 없다.

 

2. 이미지 사용시 <img>, <video>의 poster 사용

background-image는 리소스가 느려 좋지 못한 영향을 미친다.

 

3. 이미지 무손실 압축해서 사용

 

4. loading=lazy는 LCP에 도움되지 않음

 

5. fadein 같은 애니메이션은 LCP에 악영향

 

6. useEffect같은 코드로 LCP영역의 노출을 제어하면 악영향, 서버에서 미리 빌드된 채로 그리는 것이 좋다.

 

7. LCP 리소스는 직접 호스팅, 다른 출처에서 이미지를 가져오는 경우 네트워크 커넥션을 다시 수행해야하는 등 좋지 않은 영향을 끼친다.

 

 

---

 

2. 최초 입력 지연(FID)

사용자가 얼마나 빠르게 웹페이지와의 상호작용에 대한 응답을 받을 수 있는지 측정하는 지표

 

 

타이핑, 터치(클릭), 펀치 투 줌, 스크롤 등

 

 

구글이 정의한 사용자 경험 RAIL중 Response에 해당

 

- 사용자의 입력에 대한 반응 속도 50ms 미만으로 이벤트를 처리할 것

 

 

자바스크립트 메인 스레드가 처리해야 하는 작업이 많을수록 FID는 느려진다.

 

 

좋은 점수: 100ms 이내

보통: 300ms 이내

 

 

⚒️ 개선 방법

 

 

실행에 오래 걸리는 긴 작업 분리

 

1. 서버에서 처리해도 되는 작업이라면 서버에서 처리

 

2. 긴 작업은 여러 개로 분리 (최초 로딩에 필요한지 않은 것은 나중에 로딩 ex. 사용자 액션 이후에 불려야하는 것)

 

3. 자바스크립트 코드 최소화

 

4. 외부 자바스크립트 코드 지연 불러오기

 

defer: 다른 리소스와 함께 병렬 다운로드, 페이지가 완전히 로딩된 이후에 마지막에 실행

 

async: 다른 리소스와 함께 병렬 다운로드, 다운로드 완료 후 바로 실행

 

외부 자바스크립트 코드는 가능하면 async, 더 가능하다면 defer 사용해서 지연

 

 

---

3. 누적 레이아웃 이동(CLS)

페이지의 생명주기 동안 발생하는 모든 예기치 않은 이동에 대한 지표를 계산

 

 

최초 렌더링 이후에 UI를 변경시킬 동작들이 많다면 점수가 낮다. (useEffect 내...)

 

단, 사용자 액션으로 발생하는 레이아웃 이동은 점수에 영향을 주지 않음

 

스켈레톤 UI 같이 클라이언트에서 미리 노출이 예상되는 부분을 HTML로 자리 잡아 두는 것이 누적 레이아웃 지표에 도움이 된다.

 

 

좋은 점수: 0.1 이하 

보통: 0.25 이하

 

 

⚒️ 개선 방법

 

1. useEffect의 내부에서 뷰포트 내부에서 노출될 확률이 높은 작업은 최소화, 스켈레톤 UI

 

2. 만약 useEffect를 써야한다면, 제한적으로 useLayoutEffect 고려

 

3. 서버 사이드 렌더링이 좋은 영향

 

4. 폰트 로딩 최적화

 

의외로 폰트 또한 레이아웃 이동에 영향을 미침

 

FOUT: HTML 문서에서 지정한 폰트가 보이지 않고 대체 기본 폰트로 보이고 있다가 뒤늦게 폰트가 적용되는 현상

 

FOIT: HTML 문서에서 지정한 폰트가 보이지 않고, 기본 폰트도 없어서 텍스트가 없는 채로 있다가 뒤늦게 폰트가 로딩되면서 페이지에 렌더링되는 현상

 

- <link>의 preload 사용 (초기에 불러올 중요한 리소스로 명시)

 

- font-family

• auto(기본값): 브라우저가 폰트를 불러오는 방법을 결정
• block: 폰트가 로딩되기 전까지 렌더링 중단(최대 3초), 웹 폰트의 로딩 완료후 폰트 적용
• swap: FOUT 방식, 폴백 폰트로 글자 렌더링 후 완료되면 적용
• fallback: 100ms간 텍스트가 보이지 않고 그 이후 폴백 폰트로 렌더링, 이후 3초 안으로 폰트 로딩되면 전환 그렇지 않다면 폴백 폰트 사용
• optional: fallback과 매우 유사, 100ms간 텍스트가 보이지 않고 그 이후 폴백 폰트로 렌더링. 이후 0.1초 이내로 폰트가 다운로드돼 있거나 캐시돼 있지 않다면 폴백 폰트 사용. 브라우저가 네트워크 상태를 파악해 일정 기간 폰트 다운로드 못하면 연결 취소

 

5. 적절한 이미지 크기 설정

 

height: auto는 어떤 기기든 사용자에게 최적의 이미지를 보여줄 수 있다는 장점이 있지만 레이아웃 이동이 크게 발생한다는 단점이 있다.

 

• width, height 지정
• srecset 속성 (상황에 맞게 사용)

srcset= "image-1000.jpg 1000w, image-2000.jpg 2000w, image-3000.jpg 3000w"

 

---

 

핵심 웹 지표는 아니지만 성능 확인에 중요한 지표들

 

1. 최초 바이트까지의 시간(TTFB)

브라우저가 웹페이지의 첫 번째 바이트를 수신하는데 걸리는 시간.
페이지를 요청했을 때 요청이 완전히 완료되는 데 걸리는 시간을 측정하는 것이 아니라 최초의 응답이 오는 바이트까지가 얼마나 걸리는지를 측정하는 지표 (600ms 이내)

 

이 시간이 길수록 사용자에게 빈화면 노출시간이 길어진다.

 

 

2. 최초 콘텐츠풀 페인트(FCP)

페이지가 로드되기 시작한 시점부터 페이지 콘텐츠의 일부가 화면에 렌더링될 때까지의 시간
페이지에 접속한 뒤 텍스트, 이미지, svg 등이 뜨기 시작하는 시간

 

 

좋은 점수: 1.8초 이내

보통: 3.0초 이내

 

• 최초 바이트까지의 시간(TTFB) 개선
• 렌더링을 가로막는 리소스 최소화
• Above the Fold에 대한 최적화 (스크롤을 하지 않아도 보이는 영역)
• 페이지 리다이렉트 최소화
• DOM 크기 최소화 (DOM 노드는 1500개 미만, 깊이는 32단계, 부모 노드는 자식 노드를 60개 정도 까지만)