レイアウト不安定性の修正

以前の投稿では、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
  }
]

この例では210 msで0.01 %の非常に小さなシフトがあった.
シフトの時間と重大性を知ることは、シフトを引き起こしたかもしれないことを絞り込むのを助けるのに役に立ちます.戻りましょうWebPageTest より多くのテストをするためにラボ環境のために.

におけるレイアウトシフトの測定

WebPageTestでの測定値と同様に、個々のレイアウトのシフトを測定するカスタムメトリックが必要になります.幸いにも、クロム77が安定している今、プロセスはより簡単です.レイアウト不安定APIはデフォルトで有効になっているので、あなたはChrome 77内のどんなウェブサイトでもそのJSスニペットを実行することができて、すぐに結果を得ることができなければなりません.WebPageTestでは、デフォルトのChromeブラウザを使用することができますし、コマンドラインフラグを心配したり、カナリアを使用する必要はありません.
では、スクリプトを修正して、WebPageTestのカスタムメトリックを生成します.

[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 , Webホストの実世界ローディング性能を比較するために構築したサイト.

レイアウト不安定性の原因の特定

にresults レイアウトのカスタムメトリックにはこの値があります.

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

要約すると,3087 msで34.2 %の単一のレイアウトシフトがある.犯人を特定するのを助けるためにfilmstrip view .

スクロールして、@ 3番目のマークをフィルムストリップには、正確にどのような34 %のレイアウトシフトの原因は、カラフルなテーブルを示しています.ウェブサイトが構築される方法は、JSONファイルを非同期で取得し、それをテーブルにレンダリングすることです.テーブルが最初に空であるので、結果がロードされるとき、それを記入するのを待つことはシフトを引き起こしています.

しかし、それはすべてではない.ページが視覚的に完了すると<h1> ページの“私のホストはまだ速いですか?”どこからともなく現れる.これは、サイトがWebフォントを使用しており、レンダリングを最適化するための任意の手順を取らないためです.レイアウトが実際には、これが起こるときにシフトして表示されませんが、まだ長いタイトルを読むのを待つ必要があります貧しいユーザーエクスペリエンスです.

レイアウト不安定性の修正

非同期に生成されたテーブルがビューポートの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'));

プレースホルダデータはソートされる前にランダムに生成されます.これには█私はまた、データが完全に読み込まれていないことを明らかにするためにテーブルからすべての色をdesaturateするいくつかのスタイルを追加しました.
あなたが使用するプレースホルダの外観は、コンテンツが来ているとユーザーがページが壊れていないことを保証するためのレイアウトの安定性のために重要ではありません.
ここでは、プレースホルダがJSONデータの読み込み中にどのように見えるかを示します.

Webフォントの問題に対処する方がずっと簡単です.サイトがGoogleフォントを使用しているので、私たちはdisplay=swap CSSリクエスト内のプロパティ.以上です.フォント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 , 3071 ms(以前とほぼ同じ時間)で起こっているレイアウトシフトはまだあります、しかし、シフトの重大度は非常により小さいです:0.005 %.私はこれで生きられる.
また、それはフィルムストリップから明らかです<h1> フォントはすぐにシステムのフォントに戻ると、ユーザーが早くそれを読むことができます.

結論

複雑なウェブサイトはおそらくこの例より多くのレイアウトシフトを経験するでしょう、しかし、レメディエーション・プロセスはまだ同じです:WebPageTestにレイアウト不安定性メトリクスを加えてください、そして、CrossReferenceは視覚的なローディングFilmstripによる結果を犯人を特定して、スクリーン不動産を予約するためにプレースホルダを使っている修正を実行します.

（もう一つのこと）

最適化の前と後にページにWebPageTestを走らせることができて、メートル法への改善を見ることができてうれしいです、しかし、本当に重要なことはユーザー経験が実際に良くなっているということです.我々が第一によりよくサイトを作るしようとしている理由でありませんか?
もし我々が我々の伝統的なWebパフォーマンスのメトリクスと一緒に実際のユーザーのレイアウト不安定性の経験を測定を開始する場合は何が素晴らしいだろう.これは最適なフィードバックループの重要な部分です.なぜなら、フィールドからのデータを使用することで、問題がどこにあるのか、そして私たちの修正がポジティブな違いになったのか、ということです.
独自のレイアウトの不安定性データを収集するに加えて、ウェブサイトの何百万もの実際のユーザー体験から累積レイアウトシフトデータが含まれています.それはあなたが(または競合他社)を実行している方法を見つけることができますか、またはウェブ上のレイアウト不安定性の状態を探索するために使用することができます.