DIL: 모던 리액트 딥 다이브, 7주차-2

스터디: 월간 CS, https://github.com/monthly-cs/2024-03-modern-react-deep-dive
오늘 진행: 개인공부

---

DIL-week7-2_2024-04-16

| DIL 주차 | 범위 | 내용 | 오늘차 진도 | | -------- | ---------- | --------------------------------------------------------------------------------------- | ----------- | | 7주차 | 12장, 13장 | 모든 웹 개발자가 관심을 가져야 할 핵심 웹 지표, 웹 페이지의 성능을 측정하는 다양한 방법 | 781~788p |

오늘 읽은 내용을 markdown으로 간단히 메모
읽은 시간: 총 1시간

---

모든 웹 개발자가 관심을 가져야 할 핵심 웹 지표

예제

• LCP는 페이지 로딩에 따라 변화하는 지표다.
• LCP는 사용자 디바이스 크기에 따라 값이 달라질 수 있다.

기준 점수

• 지표 점수 측정: (1)JS API 호출 (2)도구 활용

  https://web.dev/articles/lcp?hl=ko#what-is-lcp 💡 Key Point: LCP includes any unload time from the previous page, connection setup time, redirect time, and Time To First Byte (TTFB), which can all be significant when measured in the field and can lead to differences between field and lab measurements.

개선 방안

• 텍스트 굿

이미지 노출 방법별 성능

| 요소 | preload 여부 | | ---------------------- | ------------ | | <img>, <picture> | O | | <svg> 내부의 <img> | X | | <video>의 poster | O | | background image | X |

• <img>, <picture>
  • 브라우저의 preload 스캐너에 의해서 먼저 발견되어 요청 들어감. HTML을 파싱하는 단계를 차단하지 않고, preload가 필요한 리소스를 찾아 로딩하는 브라우저 기능.
• <svg> 내부의 <img>
  • (크롬 102버전)svg만 로딩된 상태에서도 LCP가 완료된 것으로 간주하는 버그있었음
  • preload x
• <video>의 poster
  • video 요소를 재생하거나 탐색하기 전까지 노출되는 요소 (썸네일일)
  • video가 viewport에 걸린다면은 (LCP 영향) => poster를 넣어주자
    • 나중에 poster가 없다면 실제 로딩후 첫 프레임을 리소스로 사용하는 것이 있을 예정
    • yes preload
• background image
  • CSS의 리소스는 항상 느리다
  • DOM을 그릴 준비가 될 때까지, 리소스 요청을 미루기 때문
  • not preload

그 밖에 조심해야 할 사항

• 무손실 압 축! 최소한의 용량!
• loading=lazy는 LCP에 영향있는 리소스에는 사용 no no
• fadein 애니메이션도 LCP에 포함
• 클라이언트에서 빌드하지 말것~

  // LCP는 리액트 코드를 파싱하고 읽은 담에, API 요청/응답 후
  useEffect(() => {
    (async function loadData() {
      const result = await fetchData("https://api.takes-time.com");
      if (result.ok) {
        setShow(true);
      }
    })();
  });
  

• 가능하면~? LCP 리소스는 => 같은 도메인에서 가져오는 것이 좋다
  • cross origin의 이미지 최적화 서비스를 사용할 시, loading=lazy와 마찬가지로 최적화에 별로 좋지 않다~

FID, First Input Delay

| FID, 최초 입력 지연 | 기준 결과 | | ------------------- | --------- | | >100ms | 좋음 | | >300ms | 보통 | | ≤300ms | 나쁨 |

정의

• FID가 악화되는 이유~
  • 브라우저의 메인 스레드가 바쁘다. (다른 작업 처리 중)
    • 대규모 랜더링
    • 대규모 javascript 파일을 분석 & 실행
• 반응성에 해당하는 사용자 입력: 클릭, 터치, 타이핑 등 개별 입력 작업

RAIL

• Response: 사용자에 입력에 대한 반응 속도. 50ms <- FID가 여기 해당
• Animation: 애니메이션 각 프레임을 10ms
• Idle: 페이지가 50ms 내에 사용자 입력에 응답
• Load: 5초 내에 콘텐츠를 전달하고 인터렉션 준비

INP, Interaction to Next Paint

https://web.dev/blog/inp-cwv-march-12
2024년 3월에 Core web vital에 FID를 대체하여 추가됨 (FID is deprecated) Today, we're announcing that INP will officially become a Core Web Vital and replace FID on March 12 of this year, and that FID will be deprecated in this transition.

• 니 사이트 PageSpeed Insights 통과하냐~

---

읽으면 좋은 레퍼런스

• https://web.dev/articles/defining-core-web-vitals-thresholds?hl=en
• Cloudinary: 이미지 최적화 서비스 (크기, 포맷, 압축)
  • https://cloudinary.com/ip/gr-sea-gg-brand-home-base?utm_source=google&utm_medium=search&utm_campaign=goog_selfserve_brand_wk22_replicate_core_branded_keyword&utm_term=1329&campaignid=17601148700&adgroupid=141182782954&keyword=cloudinary&device=c&matchtype=e&adposition=&gad_source=1&gclid=CjwKCAjww_iwBhApEiwAuG6ccNyQhRJY3ISGbve8DQkca0989oUulgozh3ZVlbDcflWftMFLe67LlRoCdI8QAvD_BwE
  • https://console.cloudinary.com/pm/c-15c83121473acc71e5bf4cd045bdf7/getting-started
• CrUX Chrome 사용자 환경 보고서 // 공식 데이터 세트
  • https://developer.chrome.com/docs/crux?hl=ko