[HTML/CSS] Web vitals

자두·2021년 11월 28일
0

HTML-CSS

목록 보기
14/14
post-thumbnail

Web vitals

: 품질 지표에 대한 통합적 지침을 제시

Chrome UX Report : 실제 Chrome 사용자가 경험하는대로, 각 Web Vital에 대해 사이트의 성능을 빠르게 평가할 수 있음

🙄 Core Web Vitals

: 핵심 사용자 경험 요구사항. 모든 웹 경험에서 중요한 사용자 경험의 공통 집합

Untitled

https://developers-kr.googleblog.com/2020/05/Introducing-Web-Vitals.html

로딩 경험

  • Largest Contentful Paint(LCP) : 인식되는 로드 속도를 측정하는 항목. 페이지의 주요 콘텐츠가 로드되었을 가능성이 높은 시점에 페이지 로드 타임라인에 점을 표시
  • 페이지가 처음으로 로드를 시작한 시점을 기준으로 뷰포트 내에 있는 가장 큰 이미지 또는 텍스트 블록의 렌더링 시간을 보고
  • 우수한 사용자 경험을 제공하려면 사이트의 최대 콘텐츠풀 페인트가 2.5초 이하여야 함
  • 페이지의 메인 콘텐츠가 로드되었을 가능성이 있을 때 페이지 로드 타임라인에 해당 시점을 표시하므로 사용자가 감지하는 로드 속도를 측정할 수 있는 중요한 사용자 중심 메트릭
  • LCP에 대해 고려되는 요소 유형
    • <img> 요소

    • <svg> 요소 내부의 <image>

    • <video> 요소(포스터 이미지 사용)

    • url() 함수를 통해 로드된 배경 이미지가 있는 요소(CSS 그라데이션과는 대조적임)

    • 텍스트 노드 또는 기타 인라인 수준 텍스트 하위 요소를 포함하는 블록 수준 요소

      : 처음부터 단순하게 작업을 진행하기 위해 의도적으로 요소 제한

  • 요소의 크기 : 일반적으로 뷰포트 내에서 사용자에게 표시되는 크기 요소가 뷰포트 외부로 확장되거나, 요소가 잘리거나, 보이지 않는 오버플로가 있는 경우 해당 부분은 요소 크기에 포함되지 않음 텍스트 요소의 경우 텍스트 노드의 크기만 고려 모든 요소에 대해 CSS를 통해 적용된 여백, 안쪽 여백, 테두리는 고려되지 않음 👉 모든 텍스트 노드가 가장 가까운 블록 수준 상위 요소에만 속함. 사양 측면에서 각 텍스트 노드는 포함하는 블록을 생성하는 요소에 속함

상호 작용

  • First Input Delay(FID) : 응답성을 측정하는 항목. 사용자가 페이지와 처음 상호 작용하려고 할 때 느끼는 경험을 정량화함
    • 클릭, 탭 및 키 누름과 같은 개별 작업의 입력 이벤트에만 초점을 맞춤
  • 때문에 로드 반응성을 측정하기 위한 중요 사용자 중심 메트릭임
  • FID 점수가 낮을수록 좋음. 최초 입력 지연 값이 100ms여야 "양호" 임계값에 최소 기준으로 적절할 수 있음
  • 일반적으로 입력 지연(입력 대기 시간이라고도 함)은 브라우저의 메인 스레드가 앱에서 로드한 대규모 JavaScript 파일을 구문 분석하고 실행하기 때문에 사용자에게 응답할 수 없어서 발생
    • 이벤트 처리에서 "지연" 부분만 측정
    • 이벤트 처리 시간 자체나 브라우저에서 이벤트 핸들러를 실행한 후 UI를 업데이트하는 데 걸리는 시간은 측정하지 않음
  • ⬇ 리소스에 대한 네트워크 요청 수행 후, 다운로드가 완료된 메인 스레드에서 처리되는 페이지 Untitled
    • 메인 스레드는 일시적으로 사용 중인 상태가 됨

    • FID는 FCP와 TTI(time to interactive) 사이의 일부 콘텐츠를 렌더링했지만 아직 안정적으로 상호작용할 수 없는 상태

      Untitled

  • 다음 요소들은 메인 스레드에서 진행 중인 작업이 완료될 때까지 대기해야 함
    • 텍스트 필드, 체크박스, 라디오 버튼( <input> , <textarea> )
    • 선택 드롭다운( <select> )
    • 링크( <a> )
  • 최초 입력 지연을 측정하는 이유
    • 최초 입력 지연은 사이트의 응답성에 대한 사용자의 첫인상이 될 것이며, 사이트의 품질과 신뢰성에 대한 전반적인 인상을 형성하는 데 중요함
    • 오늘날 웹에서 볼 수 있는 가장 큰 상호 작용 문제는 페이지 로드 중에 발생
      • 사이트의 최초 사용자 상호 작용을 개선하는 데 중점을 두는 것이 웹의 전반적인 상호 작용을 개선하는 데 가장 큰 영향
  • RAIL 모델 중 R(반응성)에 중점을 둠

[https://web.dev/rail/](https://web.dev/rail/)

https://web.dev/rail/

  • FID는 실제 사용자가 필요하므로 실험실에서 측정할 수 없음
  • 총 차단 시간(Total Blocking Time, TBT) 메트릭은 측정 가능
  • 실험실에서 TBT를 개선하는 최적화는 사용자를 위한 FID 또한 개선함

페이지 콘텐츠의 시각적 안정성

  • Cumulative Layout Shift(CLS) : 시각적 안정성을 측정하는 항목. 눈에 보이는 페이지 콘텐츠의 예기치 않은 레이아웃 변화량을 정량화
  • 전체 수명 동안 발생하는 모든 예기치 않은 레이아웃 이동에 대해 가장 큰 레이아웃 이동 점수 버스트
  • CLS가 낮으면 우수한 사용자 경험을 보장하는 데 도움이 됨. 좋은 CLS 점수는 0.1이하여야 함
  • 레이아웃 이동은 시각적 요소가 렌더링된 프레임에서 다음 프레임으로 위치를 변경할 때마다 발생
  • 우수한 사용자 경험을 제공하려면 사이트의 CLS 점수가 0.1이하여야 함
  • 레이아웃 이동
    • 뷰포트 내의 가시적 요소가 두 프레임 사이에서 시작 위치가 변경될 때마다 layout-shift항목을 보고함

    • 기존 요소가 시작 위치를 변경할 때만 발생

      /*해당 움직임에 대한 impact fraction(영향분율)과 distacne fraction(거리분율)이라는 두 가지 측정값을 사용해 계산*/
      layout shift score = impact fraction * distance fraction
    • 영향분율 : 불안정 요소가 두 프레임 사이 뷰포트 영역에 미치는 영향을 측정

    • 거리분율 : 뷰포트를 기준으로 불안정 요소가 이동한 거리 측정

      프레임에서 *불안정 요소*가 수평 또는 수직으로 이동한 최대 거리를 뷰포트의 가장 큰 치수

      [https://web.dev/cls/#layout-shift-score](https://web.dev/cls/#layout-shift-score)

      https://web.dev/cls/#layout-shift-score

    • 위의 예에서 가장 큰 뷰포트 치수는 높이이고 불안정한 요소는 뷰포트 높이의 25%만큼 이동. 거리분율 = 0.25

      따라서 이 예에서 영향분율은 0.75이고 거리분율은 0.25이므로 레이아웃 이동 점수 = 0.75 * 0.25 = 0.1875 

  • CLS 측정 방법
    • 실험실이나 현장에서 측정 가능
    • 인공적인 환경에서 페이지를 로드하므로 페이지 로드 중에 발생하는 레이아웃 이동만 측정할 수 있음
    • 실제 사용자가 실제로 경험하는 것보다 작을 수 있음

👉 모두 중요한 사용자 중심의 결과를 포착, 현장에서 측정 가능, 이를 뒷받침해주는 실험실 진단 측정항목 등가 기준과 도구가 있음

🙄 Core Web Vitals 메트릭 및 임계값 기준

[https://web.dev/defining-core-web-vitals-thresholds/](https://web.dev/defining-core-web-vitals-thresholds/)

https://web.dev/defining-core-web-vitals-thresholds/

👉 완벽한 임계값은 없으며 때로는 여러 가지 합리적인 임계값 중 선택해야 할 수도 있음을 인지하면서 위의 기준을 가장 잘 충족하는 임계값을 선택하는 것

🙄 메트릭

: 정확하고 정량적으로 측정 가능한 객과적인 기준으로 성능을 이야기하는 것

Web Vitals 측정방법

  • 실험실 : 일관되고 통제된 환경에서 페이지 로드를 시뮬레이션하는 도구 사용
    • 새로운 기능이 프로덕션에 출시되기 전에는 실제 사용자의 성능 특성을 측정할 수 없기 때문에 성능 회귀를 방지하기 위해서는 출시 전 실험실에서 테스트하는 것이 가장 좋음
  • 현장(실제 사용자 모니터링) : 실제 사용자가 실제로 페이지를 로드하고 페이지와 상호 작용하는 경우
    • 사이트의 성능은 사용자의 장치 및 네트워크 상태는 물론, 사용자가 페이지와 상호작용하는지 여부에 따라 달라질 수 있음
    • 사이트가 사용자를 위해 어떻게 작동하는지 제대로 할 수 있는 유일한 방법은 해당 사용자가 사이트를 로드하고 상호작용할 때 사이트의 성능을 실제로 측정하는 것

👉 일반적으로 좋은 성능을 보장하기 위해서는 둘 다 활용하는 것이 좋음

🙄 Web Vitals javascript library

// Example of using web-vitals to measure & report CLS, FID, and LCP.
import {getCLS, getFID, getLCP} from 'web-vitals';
function reportToAnalytics(data) {
  const body = JSON.stringify(data);
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

getCLS((metric) => reportToAnalytics({cls: metric.value}));
getFID((metric) => reportToAnalytics({fid: metric.value}));
getLCP((metric) => reportToAnalytics({lcp: metric.value}));

개발할 때와 웹을 검색할 때, 모두 각 Core Web Vital의 상태에 쉽게 접근할 수 있도록 하는 것이 매우 중요

🙄 Core Web Vitals 개선하기 위한 필드 도구

웹 페이지의 품질을 개선하기 위한 자동화된 오픈 소스 도구

Google Chrome 브라우저에 직접 내장된 웹 개발자 도구 모음

웹페이지의 콘텐츠를 분석하여 페이지 속도를 향상하기 위한 추천사항을 제공

사이트의 검색 트래픽 및 실적을 측정하고, 문제를 해결하며, Google 검색결과에서 사이트가 돋보이게 할 수 있음

[https://web.dev/vitals/](https://web.dev/vitals/)

https://web.dev/vitals/

profile
블로그 이사했어요 https://ktmihs.tistory.com/

0개의 댓글