Düzen kararsızlığı sorunlarını tanımlamak ve düzeltmek için WebPageTest'i kullanmayla ilgili adım adım açıklamalı kılavuz.
Daha önceki bir yayında, WebPageTest'te Cumulative Layout Shift'i (CLS) ölçme hakkında bilgi vermiştim. CLS, tüm düzen kaymalarının toplamıdır; bu nedenle bu gönderide, bu kararsızlığın nedenini anlamak için bir sayfadaki her düzen kaymasını ayrıntılı olarak incelemek ve sorunları gerçekten düzeltmeye çalışmak yararlı olabilir diye düşündüm.
Düzen kaymalarını ölçme
Layout Instability API'yi kullanarak bir sayfadaki tüm düzen kayması etkinliklerinin listesini alabiliriz:
new Promise(resolve => {
new PerformanceObserver(list => {
resolve(list.getEntries().filter(entry => !entry.hadRecentInput));
}).observe({type: "layout-shift", buffered: true});
}).then(console.log);
Bu, öncesinde giriş etkinlikleri olmayan bir düzen kaymaları dizisi oluşturur:
[
{
"name": "",
"entryType": "layout-shift",
"startTime": 210.78500000294298,
"duration": 0,
"value": 0.0001045969445437389,
"hadRecentInput": false,
"lastInputTime": 0
}
]
Bu örnekte 210 ms'de% 0,01'lik çok küçük bir kayma gerçekleşmiştir.
Değişimin zamanını ve ciddiyetini bilmek, bu değişime neden olabilecek unsurları daraltmaya yardımcı olabilir. Daha fazla test yapmak üzere bir laboratuvar ortamı için WebPageTest'e geri dönelim.
WebPageTest'te düzen kaymalarını ölçme
WebPageTest'te CLS ölçümüne benzer şekilde, bağımsız düzen kaymalarını ölçmek için özel bir metrik gerekir. Neyse ki Chrome 77 kararlı bir şekilde çalıştığından işlem artık daha kolay. Layout Instability API'si varsayılan olarak etkindir. Dolayısıyla, bu JS snippet'ini Chrome 77 sürümünde herhangi bir web sitesinde çalıştırıp sonuçları hemen alabilmeniz gerekir. WebPageTest'te, varsayılan Chrome tarayıcısını kullanabilir ve komut satırı işaretleri veya Canary'yi kullanma konusunda endişelenmeniz gerekmez.
Şimdi bu komut dosyasını WebPageTest için özel bir metrik oluşturacak şekilde değiştirelim:
[LayoutShifts]
return new Promise(resolve => {
new PerformanceObserver(list => {
resolve(JSON.stringify(list.getEntries().filter(entry => !entry.hadRecentInput)));
}).observe({type: "layout-shift", buffered: true});
});
Bu komut dosyasındaki vaat, dizinin kendisi yerine dizinin JSON gösterimine çözümlenir. Bunun nedeni, özel metriklerin yalnızca dize veya sayı gibi temel veri türleri oluşturabilmesidir.
Test için kullanacağım web sitesi, web barındırıcılarının gerçek dünyadaki yükleme performansını karşılaştırmak üzere oluşturduğum ismyhostfastyet.com sitesi.
Düzen kararsızlığının nedenlerini belirleme
Sonuçlarda, LayoutShifts özel metriğinin şu değere sahip olduğunu görüyoruz:
[
{
"name": "",
"entryType": "layout-shift",
"startTime": 3087.2349999990547,
"duration": 0,
"value": 0.3422101449275362,
"hadRecentInput": false,
"lastInputTime": 0
}
]
Özetlemek gerekirse, 3087 ms'de gerçekleşen% 34,2 oranında tek bir düzen kayması vardır. Suçluyu belirlemeye yardımcı olması için WebPageTest'in film şeridi görünümünü kullanalım.
Film şeridindeki yaklaşık 3 saniyelik alana gidildiğinde% 34'lük düzen kaymasının tam olarak nedeninin ne olduğu, renkli tablo olduğunu görüyoruz. Web sitesi eşzamansız olarak bir JSON dosyası getirir ve bu dosyayı tabloya oluşturur. Tablo başlangıçta boştur, bu nedenle sonuçlar yüklenirken tablonun doldurulmasını beklemek kaymaya neden olmaktadır.
Hepsi bu kadar değil. Sayfa yaklaşık 4, 3 saniyede görsel olarak tamamlandığında "Is my Host fast yet?" (Barındırıcım henüz hızlı mı?) sayfasının <h1> hiç bir yerde görünmediğini görebiliriz. Bunun nedeni, sitenin bir web yazı tipi kullanması ve oluşturmayı optimize etmek için herhangi bir adım atmamasıdır. Bu durumda düzen gerçekte kayıyormuş gibi görünmüyor, ancak başlığı okumak için bu kadar uzun süre beklemek zorunda kalmak yine de kötü bir kullanıcı deneyimine neden oluyor.
Düzen kararsızlığını düzeltme
Artık eşzamansız olarak oluşturulan tablonun, görüntü alanının üçte birinin kaymasına neden olduğunu bildiğimize göre, bunu düzeltmenin zamanı geldi. JSON sonuçları gerçekten yüklenene kadar tablonun içeriğini bilmiyoruz ancak tabloyu bir tür yer tutucu verileriyle doldurabiliriz. Böylece, DOM oluşturulurken düzenin kendisi nispeten kararlı olur.
Yer tutucu verileri oluşturmak için gereken kod şudur:
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'));
Yer tutucu verileri sıralanmadan önce rastgele oluşturulur. Metin için görsel yer tutucular oluşturmak üzere rastgele bir sayıda tekrarlanan "█" karakterini ve üç ana değerin rastgele oluşturulmuş bir dağıtımını içerir. Ayrıca, verilerin henüz tam olarak yüklenmediğini göstermek için tablodaki tüm renklerin solgunlaşmasını sağlayan bazı stiller de ekledik.
Kullandığınız yer tutucuların görünümü, düzen kararlılığı açısından önemli değildir. Yer tutucuların amacı, kullanıcılara içeriğin geldiği ve sayfanın bozuk olmadığı konusunda güvence vermektir.
JSON verileri yüklenirken yer tutucular şu şekilde görünür:
Web yazı tipi sorununun çözümü çok daha basittir. Sitede Google Fonts kullanıldığı için CSS isteğinde display=swap özelliğini iletmemiz yeterlidir. Hepsi bu kadar. Fonts API, yazı tipi bildirimine font-display: swap stilini ekleyerek tarayıcının metni hemen yedek yazı tipinde oluşturabilmesini sağlar. İlgili düzeltmeyi içeren işaretlemeyi burada bulabilirsiniz:
<link href="https://fonts.googleapis.com/css?family=Chivo:900&display=swap" rel="stylesheet">
Optimizasyonları doğrulama
Sayfayı WebPageTest üzerinden yeniden çalıştırdıktan sonra, farkı görselleştirmek ve yeni düzen kararsızlık derecesini ölçmek için bir öncesi ve sonrası karşılaştırması oluşturabiliriz:
[
{
"name": "",
"entryType": "layout-shift",
"startTime": 3070.9349999997357,
"duration": 0,
"value": 0.000050272187989256116,
"hadRecentInput": false,
"lastInputTime": 0
}
]
Özel metriğe göre hâlâ 3071 ms'de gerçekleşen bir düzen kayması (önceki durumla hemen hemen aynı) ancak kaymanın önem derecesi çok daha küçüktür: %0, 005. Bununla birlikte yaşayabilirim.
Film şeridinden, <h1> yazı tipinin hemen bir sistem yazı tipine taşındığı ve kullanıcıların bu yazıyı daha erken okuyabileceği açıkça görülüyor.
Sonuç
Karmaşık web sitelerinde muhtemelen bu örnektekine kıyasla çok daha fazla düzen değişikliği yaşanacaktır, ancak düzeltme süreci aynı şekilde devam eder: WebPageTest'e düzen kararsızlığı metrikleri ekleyin, sorumluları belirlemek için sonuçları görsel yükleme film şeridiyle karşılaştırın ve ekran alanını rezerve etmek için yer tutucuları kullanarak düzeltme uygulayın.
(Bir şey daha) Gerçek kullanıcıların yaşadığı düzen kararsızlığını ölçme
WebPageTest'i optimizasyondan önce ve sonra bir sayfada çalıştırıp bir metrikte iyileşme görebilmek güzel, ancak asıl önemli olan kullanıcı deneyiminin gerçekten daha iyi hale gelmesidir. Her şeyden önce siteyi daha iyi hale getirmeye çabamızın nedeni bu değil mi?
Bu nedenle, geleneksel web performansı metriklerimizle birlikte gerçek kullanıcıların düzen kararsızlığı deneyimlerini ölçmeye başlamak harika olur. Bu, optimizasyon geri bildirim döngüsünün önemli bir parçasıdır çünkü sahadan elde edilen verilere sahip olmak, sorunların nerede olduğunu ve düzeltmelerimizin olumlu bir fark sağlayıp sağlamadığını bize gösterir.
Düzen kararsızlığı verilerinizi toplamanın yanı sıra, milyonlarca web sitesindeki gerçek kullanıcı deneyimlerinden elde edilen Cumulative Layout Shift verilerini içeren Chrome Kullanıcı Deneyimi Raporu'na da göz atın. Bu araç, sizin (veya rakiplerinizin) nasıl performans gösterdiğinizi öğrenmenize veya web'de düzensizlik durumunu incelemek için kullanabilirsiniz.