중요한 네트워크 성능

나는 느린 사이트를 싫어한다.그것들은 사용하기에 매우 짜증나고, 일하기도 매우 낙담한다.그런데'느리다'는 게 뭘 의미하죠?그것은 과거에 문서가 불러오기를 기다리고 있었다.그런 다음 페이지가 준비될 때까지 기다립니다.그러나 현재 이렇게 많은 비동기 모드를 사용했는데, 우리는 어떻게'느린'모드를 정의합니까?
W3C는 이 문제를 새로운 Event Timing와 Element Timing API로 해결하고 있으며, 성능 저하가 웹 페이지에 영향을 미칠 수 있는 다양한 방식을 설명하기 위해 새로운 웹 중요 지표를 정의해 왔다.구글은 심지어 이런 인터넷의 중요한 지표를 검색 순위 요인으로 사용한다!
웹 사이트의 속도와 페이지 순위를 유지하기 위해 그것들을 어떻게 응용하는지 봅시다.

1. 최대 함유 도료(LCP)
일부 사이트는 불러오는 속도가 매우 빨라 보이지만, 모든 의미 있는 내용은 여전히 불러오기를 기다리고 있다.이런 모델은 페이지의 로드 성능 숫자를 보기에 매우 좋아 보이지만, 사용자들은 여전히 사이트의 운행이 느리다고 느낀다.
최대 내용 그리기(LCP)는 페이지가 시작된 후 가장 의미 있는 내용 블록을 불러오는 시간입니다.최대값은 요소의 픽셀 크기로 측정되므로 UI에서 많은 공간을 차지하는 모든 것이 가능합니다.이것은 아마도 큰 그림, 글 한 토막, 또는 매우 짜증나는 광고일 것이다.
UI "프레임"을 기본 문서에 표시하고 비동기적으로 컨텐트를 로드하는 웹 페이지만 LCP 점수가 낮습니다.흥미로운 사실은 우리가 최근audited the web performance of Google search에 그들과 내연한 거의 모든 내용이 원본 문서에 있다는 것이다!
Learn more about the Largest Contentful Paint

2. 누적 배치 횟수(CLS)
끊임없이 새로운 내용을 바꾸고, 새로운 내용을 그리고, 네가 읽으려는 내용을 밀어내는 초라한 웹 페이지들은, 레이아웃에 많은 변화가 생길 것이다.페이지에 추가된 새 요소가 다른 요소의 위치를 이동할 때마다 레이아웃이 변경됩니다.네가 읽고 싶은 그 단락의 광고처럼.널 봐, 뉴욕타임스.
CLS(누적 레이아웃 이동)는 페이지에서 발생하는 모든 레이아웃의 합계입니다.비동기적인 내용이 많을 때 레이아웃이 많이 바뀌고 CLS가 높습니다.
AJAX 호출과 클라이언트를 통해 웹 페이지 내용의 대부분을 비동기적으로 문서에 불러오는 것을 보여줄 때 보통 이런 상황이 발생한다.제3자 광고는 전형적인 위법자다.
Learn more about the Cumulative Layout Shift .

3. 첫 번째 입력 지연(FID)
얄미운 자바스크립트, 추적 픽셀, 자산 의존성 웹 페이지를 대량으로 불러오는 데는 브라우저가 많은 일을 해야 한다.이 자산 중의 모든 항목은 반드시 발견되고 다운로드하며 해석하고 응용해야 한다. 이것은 어려운 작업이다!만약 사용자가 처음으로 당신의 페이지를 사용하려고 시도할 때, 브라우저가 이 일을 하느라 바쁘다면, 브라우저는 매우 느리게 느낄 것이다.
First Input Delay(FID)는 사용자가 처음으로 페이지와 상호작용을 시도할 때 페이지가 바쁜 상태를 갖는 시간을 말한다.이것은 이벤트 처리 프로그램 코드에 대한 도량이 아니라 브라우저가 바빠서 이벤트 처리 시간을 지연시키는 것이다.사용자가 단추를 누르려고 할 때 브라우저가 대량의 자바스크립트를 분석하느라 바쁘면 큰 FID가 나타납니다.
개발자는 보통 화면을 불러오는 것을 통해 이 문제를 해결합니다. 이것은 첫 번째 입력을 늦추는 것이지 문제를 해결하는 것이 아닙니다. 너무 많은 것을 불러오는 것입니다.
Learn more about the First Input Delay

당신의 네트워크 명맥을 측정하다
기왕 우리가 이러한 중요한 지표 배후의 개념을 알게 된 이상 우리는 어떻게 그것들을 평가해야 합니까?그것들은 모두 원소 시간 계산 API의 규범 초안을 바탕으로 하는데, 이 규범은 아직 잘 채택되지 않았다.크롬 (Blink 기반 브라우저) 은 현재 이 기능을 지원하기 때문에 일부 사용자들에게 이 지표를 얻기 시작할 수 있습니다.

try {
    new PerformanceObserver(entryList => {
      entryList.getEntries().forEach(console.log)
    }).observe({ type: "layout-shift", buffered: true });

    new PerformanceObserver(entryList => {
      entryList.getEntries().forEach(console.log)
    }).observe({ type: "largest-contentful-paint", buffered: true });

    new PerformanceObserver(entryList => {
      entryList.getEntries().forEach(console.log)
    }).observe({ type: "first-input", buffered: true });
}
catch(e) { /* API is not supported */ }

모든 유형의 측정은 그 자체의 한계와 특수한 조건을 가지고 있다.예를 들어 ”layout-shift”를 처리하기 위해서 우리는 수신된 모든 값에 대해 화합을 구해야 한다. 왜냐하면 우리는 누적 레이아웃의 편이를 측정하고 있기 때문이다.우리는 또한 레이아웃 변화가 사용자의 입력으로 인해 일어난 것인지 고려해야 한다. 사용자의 입력은 이 항목에 추가된 사용자 정의 속성 중의 하나이다

let cumulativeLayoutShift = 0;
function handleLayoutShift(entry) {
  if (!entry.hadRecentInput) {
    cumulativeLayoutShift += entry.value;
  }
}

위의 링크는 모든 지표의 각종 실현과 요구를 포함하고 있다.이 지표를 포획하고 보존하는 방법과 보고하는 방법을 결정해야 합니다.
또는 도량을 요청하면 당신을 위해 이 점을 할 수 있습니다!Request Metrics is the fastest, simplest, and cheapest way to understand real user web performance . 그것은 이러한 지표와 일련의 유용한 데이터를 포획하여 진정으로 중요한 내용으로 추출할 수 있다.월당 10달러만 있으면 됩니다.
이것은 자신이 이러한 이동을 추적하는 API보다 훨씬 쉽다.
빨리 가자.