고정 레이아웃 불안정

이전 글에서 나는 WebPageTest에 쓴 적이 있다(CLS).CLS는 모든 레이아웃 변화의 집합이기 때문에 이 글에서 저는 페이지의 모든 단독 레이아웃 변화를 깊이 연구하고 검사하는 것이 재미있다고 생각합니다. 불안정한 원인을 이해하고 문제를 실제적으로 해결하려고 합니다.

레이아웃 오프셋 측정하기

레이아웃 불안정 API를 사용하면 페이지의 모든 레이아웃 이동 이벤트 목록을 얻을 수 있습니다.

new Promise(resolve => {
  new PerformanceObserver(list => {
    resolve(list.getEntries().filter(entry => !entry.hadRecentInput));
  }).observe({type: "layout-shift", buffered: true});
}).then(console.log);

그러면 다음과 같은 일련의 레이아웃 이동이 생성됩니다.

[
  {
    "name": "",
    "entryType": "layout-shift",
    "startTime": 210.78500000294298,
    "duration": 0,
    "value": 0.0001045969445437389,
    "hadRecentInput": false,
    "lastInputTime": 0
  }
]

이 예에서 210ms에 0.01%의 미세한 위치가 있다.
이런 변화의 시간과 심각성을 이해하는 것은 이런 변화의 원인을 줄이는 데 도움이 된다.실험실 환경에서 더 많은 테스트를 하기 위해 WebPageTest로 돌아가자.

WebPageTest의 레이아웃 변화 측정

WebPageTest에서 CLS를 측정하는 것과 유사하게 단일 레이아웃 변화를 측정하려면 사용자 정의 지표가 필요합니다.다행히도 Chrome 77이 안정적이어서 이 과정은 더욱 쉬워졌다.레이아웃 불안정 API는 기본적으로 사용되기 때문에 Chrome 77의 모든 사이트에서 JS 세션을 실행하고 즉시 결과를 얻을 수 있어야 합니다.WebPageTest에서는 명령줄 플래그를 걱정하거나 참새를 사용하지 않고 기본 Chrome 브라우저를 사용할 수 있습니다.
따라서 이 스크립트를 수정하여 WebPaGetTest에 대한 사용자 정의 지표를 생성합니다.

[LayoutShifts]
return new Promise(resolve => {
  new PerformanceObserver(list => {
    resolve(JSON.stringify(list.getEntries().filter(entry => !entry.hadRecentInput)));
  }).observe({type: "layout-shift", buffered: true});
});

이 스크립트의 약속은 그룹 자체가 아니라 그룹의 JSON 표시로 해석됩니다.사용자 정의 지표는 문자열이나 숫자 등 원시 데이터 형식만 생성할 수 있기 때문이다.
테스트에 사용할 사이트는 ismyhostfastyet.com 입니다. 이 사이트를 만든 것은 웹 호스트의 실제 부하 성능을 비교하기 위해서입니다.

배치가 불안정한 원인을 확정하다

results 에서는 LayoutShift 사용자 정의 메트릭에 다음 값이 표시됩니다.

[
  {
    "name": "",
    "entryType": "layout-shift",
    "startTime": 3087.2349999990547,
    "duration": 0,
    "value": 0.3422101449275362,
    "hadRecentInput": false,
    "lastInputTime": 0
  }
]

한 마디로 하면 3087ms에서 34.2%의 단일 레이아웃 편이가 발생했다.원흉을 식별하기 위해 WebPageTestfilmstrip view를 사용합니다.

영화 테이프에 약 3초의 표시를 굴리면 34%의 레이아웃 변화의 원인이 무엇인지 똑똑히 볼 수 있다. 바로 컬러 책상이다.웹 사이트의 구축 방식은 비동기적으로 JSON 파일을 가져와 표에 보여주는 것이다.이 테이블은 처음에 비어 있었기 때문에 결과를 불러올 때 채우기를 기다리면 자리를 옮길 수 있습니다.

하지만 이게 다가 아니야.페이지가 약 4.3초의 속도로 시각적으로 완성되었을 때, 우리는 페이지의 <h1> "내 호스트가 빨라요?"어디서 튀어나왔는지 모르겠다.이런 상황이 발생한 것은 이 사이트가 웹 글꼴을 사용했고 렌더링을 최적화하기 위한 어떠한 절차도 취하지 않았기 때문이다.이런 상황이 발생했을 때 레이아웃은 바뀌지 않은 것 같지만 이렇게 오래 기다려야 제목을 읽을 수 있기 때문에 사용자 체험은 여전히 매우 나쁘다.

고정 레이아웃 불안정

이제 우리는 비동기적으로 생성된 시계가 3분의 1의 시야 이동을 초래하여 그것을 복구할 때가 되었다는 것을 안다.JSON 결과가 실제로 불러오기 전까지는 테이블의 내용을 몰랐지만, DOM을 보여줄 때 레이아웃 자체가 상대적으로 안정적일 수 있도록 어떤 자리 표시자 데이터를 사용하여 테이블을 채울 수 있습니다.
다음은 자리 표시자 데이터를 생성하는 코드입니다.

function getRandomFiller(maxLength) {
  var filler = '█';
  var len = Math.ceil(Math.random() * maxLength);
  return new Array(len).fill(filler).join('');
}

function getRandomDistribution() {
  var fast = Math.random();
  var avg = (1 - fast) * Math.random();
  var slow = 1 - (fast + avg);
  return [fast, avg, slow];
}

// Temporary placeholder data.
window.data = [];
for (var i = 0; i < 36; i++) {
  var [fast, avg, slow] = getRandomDistribution();
  window.data.push({
    platform: getRandomFiller(10),
    client: getRandomFiller(5),
    n: getRandomFiller(1),
    fast,
    avg,
    slow
  });
}
updateResultsTable(sortResults(window.data, 'fast'));

자리 표시자 데이터는 정렬하기 전에 무작위로 생성됩니다.여기에는 "█"문자를 여러 번 무작위로 반복하여 텍스트에 시각적 자리 표시자를 만들고 세 개의 주요 값의 분포를 무작위로 생성합니다. 또한 테이블의 모든 색의 포화도를 낮추어 데이터가 아직 완전히 불러오지 않았음을 명확히 합니다.
사용자가 내용을 볼 수 있고 페이지가 파괴되지 않도록 하기 때문에 사용자가 사용하는 자리 표시자의 외관은 레이아웃 안정성에 있어서 중요하지 않습니다.
다음은 JSON 데이터를 로드할 때 자리 표시자의 모양입니다.

웹 글꼴 문제를 해결하는 것은 훨씬 간단하다.이 사이트는 구글 글꼴을 사용하기 때문에 CSS 요청에서만 display=swap 속성을 전달할 수 있습니다.그게 다야.글꼴 API는 글꼴 선언에 display: swap 스타일을 추가하여 브라우저에서 즉시 반환 글꼴로 텍스트를 표시할 수 있도록 합니다.다음은 수정이 포함된 적절한 태그입니다.

<link href="https://fonts.googleapis.com/css?family=Chivo:900&display=swap" rel="stylesheet">

검증 최적화

WebPageTest를 통해 페이지를 다시 실행하면 전후comparison의 시각적 차이를 생성하고 새로운 레이아웃의 불안정성을 측정할 수 있습니다.

[
  {
    "name": "",
    "entryType": "layout-shift",
    "startTime": 3070.9349999997357,
    "duration": 0,
    "value": 0.000050272187989256116,
    "hadRecentInput": false,
    "lastInputTime": 0
  }
]

custom metric에 따르면 3071ms에서도 배치 편이(대략 이전과 동일)가 발생하지만 편이의 심각성은 0.005% 보다 적다.받아들일 수 있어.
이 영화에서 <h1> 글꼴이 시스템 글꼴로 바로 내려가 사용자가 더 빨리 읽을 수 있도록 하고 있음을 똑똑히 볼 수 있다.

결론

본 사례에 비해 복잡한 사이트는 더 많은 레이아웃 변화를 겪을 수 있지만 복구 과정은 여전히 같다. 레이아웃 불안정 지표를 WebPageTest에 추가하고 결과와 시각적 로드된 영화 항목을 교차 인용하여 원흉을 식별하고 자리 표시자를 사용하여 화면 부동산을 보존하기 위해 복구를 실현한다.

한 가지 더

최적화 전후에 페이지에서 WebPageTest를 실행하고 지표의 개선을 볼 수 있어서 기쁘지만, 진정으로 중요한 것은 사용자 체험이 실제로 더욱 좋아지고 있다는 것이다.이것이 바로 우리가 사이트를 더욱 잘 만들어야 하는 이유 아닙니까?
따라서 만약에 우리가 실제 사용자의 레이아웃 불안정성 체험과 전통적인 웹 성능 지표를 측정하기 시작한다면 이것은 좋은 일이다.이것은 피드백 순환을 최적화하는 관건적인 부분이다. 왜냐하면 현장에서 온 데이터가 우리에게 문제가 어디에 있는지, 그리고 우리의 복구가 긍정적인 영향을 미쳤는지 알려주기 때문이다.
자신의 레이아웃 불안정 데이터를 수집하는 것 외에 수백만 사이트의 실제 사용자 체험에 대한 누적 레이아웃 변화 데이터를 볼 수 있습니다.이것은 웹 레이아웃의 불안정한 상태를 탐색할 수 있도록 합니다.