Memperbaiki ketidakstabilan tata letak

Panduan penggunaan WebPageTest untuk mengidentifikasi dan memperbaiki masalah ketidakstabilan tata letak.

Rick Viscomi

Dalam postingan sebelumnya, saya menulis tentang mengukur Pergeseran Tata Letak Kumulatif (CLS) di WebPageTest. CLS adalah gabungan dari semua pergeseran tata letak, jadi dalam postingan ini saya pikir akan menarik untuk mempelajari lebih dalam dan memeriksa setiap pergeseran tata letak individual pada halaman untuk mencoba memahami apa yang menyebabkan ketidakstabilan dan benar-benar mencoba memperbaiki masalahnya.

Mengukur pergeseran tata letak

Dengan Layout Instability API, kita bisa mendapatkan daftar semua peristiwa pergeseran tata letak di halaman:

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

Tindakan ini menghasilkan array pergeseran tata letak yang tidak didahului oleh peristiwa input:

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

Dalam contoh ini ada satu perubahan yang sangat kecil sebesar 0,01% pada 210 md.

Mengetahui waktu dan tingkat keparahan {i>shift<i} akan berguna untuk membantu mempersempit hal-hal yang mungkin menyebabkan perubahan tersebut. Mari kita kembali ke WebPageTest untuk lingkungan lab guna melakukan pengujian lainnya.

Mengukur pergeseran tata letak di WebPageTest

Serupa dengan mengukur CLS di WebPageTest, mengukur setiap pergeseran tata letak akan memerlukan metrik kustom. Untungnya, sekarang prosesnya menjadi lebih mudah setelah Chrome 77 menjadi stabil. Layout Instability API diaktifkan secara default, sehingga Anda seharusnya dapat mengeksekusi cuplikan JS tersebut di situs mana pun dalam Chrome 77 dan langsung mendapatkan hasilnya. Di WebPageTest, Anda dapat menggunakan browser Chrome default dan tidak perlu khawatir dengan tanda command line atau menggunakan Canary.

Jadi, mari kita ubah skrip tersebut untuk menghasilkan metrik kustom untuk 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 dalam skrip ini me-resolve ke representasi JSON dari array, bukan array itu sendiri. Hal ini karena metrik kustom hanya dapat menghasilkan jenis data primitif seperti string atau angka.

Situs yang akan saya gunakan untuk pengujian adalah ismyhostfastyet.com, situs yang saya buat untuk membandingkan performa pemuatan host web di dunia nyata.

Mengidentifikasi penyebab ketidakstabilan tata letak

Dalam hasil, kita dapat melihat metrik kustom LayoutShifts memiliki nilai ini:

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

Singkatnya, ada pergeseran tata letak tunggal sebesar 34,2% yang terjadi pada 3087 md. Untuk membantu mengidentifikasi penyebabnya, mari kita gunakan tampilan filmstrip WebPageTest.

Dua sel dalam setrip film, yang menampilkan screenshot sebelum dan sesudah pergeseran tata letak.

Scroll ke tanda ~3 detik dalam setrip film menunjukkan dengan tepat apa penyebab pergeseran tata letak 34%: tabel warna-warni. Situs mengambil file JSON secara asinkron, lalu merendernya ke tabel. Tabel ini awalnya kosong, jadi menunggu untuk mengisinya saat hasil dimuat akan menyebabkan pergeseran.

Header font web yang muncul entah dari mana.

Tapi tidak hanya itu. Saat halaman selesai secara visual pada ~4,3 detik, kita dapat melihat bahwa <h1> halaman "Apakah host saya cepat?" muncul entah dari mana. Hal ini terjadi karena situs menggunakan font web dan belum mengambil langkah apa pun untuk mengoptimalkan rendering. Tata letak tidak benar-benar tampak bergeser saat hal ini terjadi, tetapi pengalaman pengguna tetap buruk karena harus menunggu begitu lama untuk membaca judul.

Memperbaiki ketidakstabilan tata letak

Setelah kita tahu tabel yang dihasilkan secara asinkron menyebabkan sepertiga area pandang bergeser, kini saatnya memperbaikinya. Kita tidak mengetahui konten tabel sampai hasil JSON benar-benar dimuat, tetapi kita masih dapat mengisi tabel dengan beberapa jenis data placeholder sehingga tata letaknya sendiri relatif stabil saat DOM dirender.

Berikut adalah kode untuk menghasilkan data placeholder:

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'));

Data placeholder dihasilkan secara acak sebelum diurutkan. Kode ini mencakup karakter "█" yang diulang secara acak berkali-kali untuk membuat placeholder visual untuk teks dan distribusi yang dihasilkan secara acak dari tiga nilai utama. Saya juga menambahkan beberapa gaya untuk menurunkan saturasi semua warna dari tabel untuk memperjelas bahwa data belum dimuat sepenuhnya.

Tampilan placeholder yang Anda gunakan tidak memengaruhi stabilitas tata letak. Tujuan placeholder adalah untuk meyakinkan pengguna bahwa konten akan tersedia dan halaman tidak rusak.

Berikut adalah tampilan placeholder saat data JSON dimuat:

Tabel data dirender dengan data placeholder.

Mengatasi masalah font web jauh lebih sederhana. Karena situs menggunakan Google Fonts, kita hanya perlu meneruskan properti display=swap dalam permintaan CSS. Itu saja. Fonts API akan menambahkan gaya font-display: swap di deklarasi font, yang memungkinkan browser langsung merender teks dalam font penggantian. Berikut markup terkait dengan perbaikan yang disertakan:

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

Memverifikasi pengoptimalan

Setelah menjalankan kembali halaman melalui WebPageTest, kita dapat membuat perbandingan sebelum dan sesudah untuk memvisualisasikan perbedaan dan mengukur tingkat baru ketidakstabilan tata letak:

Strip film WebPageTest yang menampilkan kedua situs yang dimuat secara berdampingan dengan dan tanpa pengoptimalan tata letak.

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

Menurut metrik kustom, masih ada pergeseran tata letak yang terjadi pada waktu 3.071 md (sekitar waktu yang sama seperti sebelumnya), tetapi tingkat keparahan pergeseran tersebut jauh lebih kecil: 0,005%. Saya bisa memahaminya.

Dari setrip film, terlihat jelas bahwa font <h1> segera kembali ke font sistem, sehingga pengguna dapat membacanya lebih cepat.

Kesimpulan

Situs yang kompleks mungkin akan mengalami lebih banyak pergeseran tata letak daripada dalam contoh ini, tetapi proses perbaikannya tetap sama: tambahkan metrik ketidakstabilan tata letak ke WebPageTest, lakukan referensi silang hasilnya dengan filmstrip pemuatan visual untuk mengidentifikasi penyebabnya, dan terapkan perbaikan menggunakan placeholder untuk mencadangkan area layar.

(Satu hal lagi) Mengukur ketidakstabilan tata letak yang dialami oleh pengguna nyata

Sangat menyenangkan dapat menjalankan WebPageTest pada halaman sebelum dan setelah pengoptimalan dan melihat peningkatan pada metrik, tetapi yang benar-benar penting adalah pengalaman pengguna benar-benar menjadi lebih baik. Bukankah itu alasan kami mencoba meningkatkan kualitas situs sejak awal?

Jadi, akan lebih baik jika kita mulai mengukur pengalaman ketidakstabilan tata letak pengguna sungguhan beserta metrik performa web tradisional kita. Masukan ini merupakan bagian penting dari feedback loop pengoptimalan karena data dari lapangan memberi tahu kami lokasi masalah yang terjadi dan apakah perbaikan yang kami lakukan memberikan perbedaan yang positif.

Selain mengumpulkan data ketidakstabilan tata letak Anda sendiri, lihat Laporan UX Chrome, yang mencakup data Pergeseran Tata Letak Kumulatif dari pengalaman pengguna yang sebenarnya di jutaan situs. Laporan ini memungkinkan Anda mengetahui performa Anda (atau pesaing Anda), atau Anda dapat menggunakannya untuk mempelajari kondisi ketidakstabilan tata letak di seluruh web.