WebPageTest を使用してレイアウトの不安定性の問題を特定して修正するチュートリアル。
前回の記事では、WebPageTest でCumulative Layout Shift(CLS)を測定する方法について説明しました。CLS はすべてのレイアウト シフトの集計値であるため、この投稿では、ページ上の個々のレイアウト シフトを詳しく調べて、不安定性の原因を特定し、問題を実際に修正してみることにしました。
レイアウト シフトの測定
Layout Instability 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 ミリ秒で 0.01% という非常に小さなシフトが 1 回発生しています。
シフトの時間と重大度を把握することは、シフトの原因を絞り込むのに役立ちます。ラボ環境でさらにテストを行うため、WebPageTest に戻りましょう。
WebPageTest でレイアウトのずれを測定する
WebPageTest で CLS を測定するのと同様、個々のレイアウト シフトを測定するにはカスタム指標が必要です。幸い、Chrome 77 が安定したため、このプロセスは簡単になりました。Layout Instability API はデフォルトで有効になっているため、Chrome 77 内の任意のウェブサイトでその JS スニペットを実行して、すぐに結果を取得できます。WebPageTest では、デフォルトの Chrome ブラウザを使用できるため、コマンドライン フラグや Canary の使用について心配する必要はありません。
では、そのスクリプトを変更して、WebPageTest のカスタム指標を生成しましょう。
[LayoutShifts]
return new Promise(resolve => {
new PerformanceObserver(list => {
resolve(JSON.stringify(list.getEntries().filter(entry => !entry.hadRecentInput)));
}).observe({type: "layout-shift", buffered: true});
});
このスクリプトの Promise は、配列自体ではなく、配列の JSON 表現に解決されます。これは、カスタム指標で生成できるデータ型が、文字列や数値などのプリミティブ データ型に限られているためです。
テストに使用するウェブサイトは ismyhostfastyet.com です。これは、ウェブホストの実際の読み込みパフォーマンスを比較するために作成したサイトです。
レイアウトの不安定性の原因を特定する
結果で、LayoutShifts カスタム指標の値を確認できます。
[
{
"name": "",
"entryType": "layout-shift",
"startTime": 3087.2349999990547,
"duration": 0,
"value": 0.3422101449275362,
"hadRecentInput": false,
"lastInputTime": 0
}
]
要約すると、3087 ミリ秒で 34.2% のレイアウト変更が 1 回発生しています。原因を特定するには、WebPageTest のフィルムストリップ ビューを使用します。
フィルムストリップの 3 秒あたりまでスクロールすると、34% のレイアウト シフトの原因がカラフルな表であることがはっきりとわかります。ウェブサイトは JSON ファイルを非同期で取得し、テーブルにレンダリングします。テーブルは最初は空であるため、結果の読み込み時にテーブルが入力されるまで待機すると、シフトが発生します。
それだけではありません。ページが完全に表示されるまでに 4.3 秒ほどかかり、その時点で「Is my host fast yet?」ページの <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'));
プレースホルダ データは、並べ替えの前にランダムに生成されます。この文字列には、テキストの視覚的なプレースホルダを作成するために「█」文字がランダムに複数回含まれており、3 つの主な値がランダムに生成された分布も含まれています。また、データがまだ完全に読み込まれていないことを明確にするために、テーブルのすべての色を彩度を下げて表示するスタイルも追加しました。
使用するプレースホルダの外観は、レイアウトの安定性には関係ありません。プレースホルダの目的は、コンテンツが表示されること、ページが機能していることをユーザーに示すことです。
JSON データの読み込み中は、プレースホルダは次のようになります。
ウェブフォントの問題に対処するのははるかに簡単です。このサイトでは Google Fonts を使用しているため、CSS リクエストで display=swap
プロパティを渡すだけで済みます。以上です。Fonts API は、フォント宣言に font-display: swap
スタイルを追加します。これにより、ブラウザは代替フォントでテキストをすぐにレンダリングできるようになります。修正を加えた対応するマークアップは次のとおりです。
<link href="https://fonts.googleapis.com/css?family=Chivo:900&display=swap" rel="stylesheet">
最適化の検証
WebPageTest でページを再実行すると、前後の比較を生成して違いを可視化し、レイアウトの不安定性の新しい程度を測定できます。
[
{
"name": "",
"entryType": "layout-shift",
"startTime": 3070.9349999997357,
"duration": 0,
"value": 0.000050272187989256116,
"hadRecentInput": false,
"lastInputTime": 0
}
]
カスタム指標によると、3, 071 ミリ秒(以前とほぼ同じ時間)でレイアウト シフトが発生していますが、シフトの重大度は 0.005% と大幅に低下しています。これで問題ありません。
フィルムストリップからも、<h1>
フォントがすぐにシステム フォントに戻り、ユーザーがすぐに読み取れることがわかります。
まとめ
複雑なウェブサイトでは、この例よりも多くのレイアウト シフトが発生する可能性がありますが、修正プロセスは同じです。WebPageTest にレイアウトの不安定性の指標を追加し、結果をビジュアル ローディング フィルムストリップと照らし合わせて原因を特定し、プレースホルダを使用して画面領域を予約する修正を実装します。
(もう 1 つ)実際のユーザーが経験するレイアウトの不安定さを測定する
最適化の前後でページに対して WebPageTest を実行し、指標の改善を確認することは良いことですが、本当に重要なのは、ユーザー エクスペリエンスが実際に改善されていることです。そもそも、サイトを改善しようとしているのはそのためではないでしょうか?
そのため、従来のウェブ パフォーマンス指標とともに、実際のユーザーのレイアウトの不安定なエクスペリエンスを測定できるようになれば、非常に有益です。これは最適化のフィードバック ループの重要な要素です。現場のデータがあれば、問題の場所や修正が効果的かどうかを把握できます。
独自のレイアウトの不安定性データを収集するだけでなく、Chrome UX レポートも確認してください。このレポートには、数百万ものウェブサイトでの実際のユーザー エクスペリエンスに基づく累積レイアウト シフトのデータが含まれています。これにより、自社(または競合他社)のパフォーマンスを確認したり、ウェブ全体のレイアウトの不安定な状態を調べたりできます。