WebPageTest'i kullanarak düzen kararsızlığı sorunlarını tespit etme ve düzeltmeyle ilgili bir adım adım açıklamalı kılavuz.
WebPageTest'te kümülatif düzen değişikliğini (CLS) ölçme hakkında daha önce yazmıştım. CLS, tüm düzen değişikliklerinin bir toplamıdır. Bu nedenle, bu yayında daha ayrıntılı bir inceleme yaparak bir sayfadaki her düzen değişikliğini incelemenin, kararsızlığa neyin neden olabileceğini anlamaya ve sorunları düzeltmeye çalışmanın ilginç olacağını 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 işlem, giriş etkinliklerinden önce gelmeyen bir düzen kayması 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 tek bir çok küçük kayma vardı.
Değişikliğin zamanını ve önemini bilmek, değişime neyin neden olmuş olabileceğini belirlemenize yardımcı olur. Daha fazla test yapmak için laboratuvar ortamı sunan WebPageTest'e dönelim.
WebPageTest'te düzen kaymalarını ölçme
WebPageTest'te CLS'yi ölçmeye benzer şekilde, düzen değişikliklerini tek tek ölçmek için özel bir metrik gerekir. Neyse ki Chrome 77 kararlı hale geldiği için bu işlem artık daha kolay. Layout Instability API varsayılan olarak etkindir. Bu nedenle, bu JS snippet'ini Chrome 77'deki herhangi bir web sitesinde çalıştırabilir ve hemen sonuç alabilirsiniz. WebPageTest'te varsayılan Chrome tarayıcıyı kullanabilir ve komut satırı işaretleri veya Canary kullanımıyla ilgili endişelenmenize gerek kalmaz.
Bu nedenle, WebPageTest için özel bir metrik oluşturacak şekilde bu komut dosyasını 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 promise, dizinin kendisi yerine dizinin JSON temsiline çözümlenir. Bunun nedeni, özel metriklerin yalnızca dize veya sayı gibi ilkel veri türleri üretebilmesidir.
Test için kullanacağım web sitesi, web barındırma sağlayıcılarının gerçek yükleme performansını karşılaştırmak için oluşturduğum ismyhostfastyet.com sitesidir.
Düzen kararsızlığının nedenlerini belirleme
Sonuçlar bölümünde, LayoutShifts özel metriğinin şu değeri olduğunu görebiliriz:
[
{
"name": "",
"entryType": "layout-shift",
"startTime": 3087.2349999990547,
"duration": 0,
"value": 0.3422101449275362,
"hadRecentInput": false,
"lastInputTime": 0
}
]
Özetlemek gerekirse, 3087 ms'de% 34,2 oranında tek bir düzen kayması gerçekleşiyor. Sorunu tespit etmek için WebPageTest'in film şeridi görünümünü kullanalım.
Film şeridinde yaklaşık 3. saniyeye geldiğimizde, %34'lük düzen değişikliğinin tam olarak nedenini görebiliriz: renkli tablo. Web sitesi, JSON dosyasını asynkron olarak getirir ve ardından bir tabloda oluşturur. Tablo başlangıçta boş olduğundan, sonuçlar yüklendiğinde tablonun doldurulmasını beklemek kaymaya neden oluyor.
Ancak avantajlar bunlarla sınırlı değil. Sayfa yaklaşık 4,3 saniyede görsel olarak tamamlandığında, "Barındırıcım henüz hızlı mı?" sayfasının <h1>
'sinin aniden göründüğünü görebiliriz. Bunun nedeni, sitenin bir web yazı tipi kullanması ve oluşturmayı optimize etmek için herhangi bir adım atmamış olmasıdır. Bu durumda sayfa düzeni değişmiyor gibi görünse de başlığı okumak için bu kadar uzun süre beklemek kötü bir kullanıcı deneyimidir.
Düzen kararsızlığını düzeltme
Asenkron olarak oluşturulan tablonun, görüntü alanının üçte birinin kaymasına neden olduğunu bildiğimize göre bu sorunu düzeltme zamanı geldi. JSON sonuçları gerçekten yüklenene kadar tablonun içeriğini bilmiyoruz ancak DOM oluşturulduğunda düzenin nispeten kararlı olması için tabloyu bir tür yer tutucu veri ile doldurabiliriz.
Yer tutucu veri oluşturmak için kullanılacak kod aşağıda verilmiştir:
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 veriler, sıralanmadan önce rastgele oluşturulur. Metin için görsel yer tutucular oluşturmak amacıyla "█" karakterinin rastgele sayıda tekrarını ve üç ana değerin rastgele oluşturulmuş dağılımını içerir. Ayrıca, verilerin henüz tam olarak yüklenmediğini açıkça belirtmek için tablodaki tüm renklerin doygunluğunu azaltan bazı stiller de ekledim.
Kullandığınız yer tutucuların görünümü, düzenin kararlılığı açısından önemli değildir. Yer tutucuların amacı, kullanıcılara içeriğin geleceği ve sayfanın bozuk olmadığı konusunda güvence vermektir.
JSON verileri yüklenirken yer tutucular aşağıdaki gibi görünür:
Web yazı tipi sorununu çözmek çok daha kolaydır. Sitede Google yazı tipleri kullanıldığı için CSS isteğine display=swap
mülkünü göndermemiz yeterlidir. Hepsi bu kadar. Fonts API, yazı tipi beyanında font-display: swap
stilini ekleyerek tarayıcının metni hemen yedek yazı tipinde oluşturmasını sağlar. Çözümün dahil edildiği ilgili işaretleme aşağıda verilmiştir:
<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ığı derecesini ölçmek için bir önceki ve sonraki karşılaştırma oluşturabiliriz:
[
{
"name": "",
"entryType": "layout-shift",
"startTime": 3070.9349999997357,
"duration": 0,
"value": 0.000050272187989256116,
"hadRecentInput": false,
"lastInputTime": 0
}
]
Özel metriğe göre, 3071 ms'de (yaklaşık olarak öncekiyle aynı zamanda) hâlâ bir sayfa düzeni kayması meydana geliyor ancak kaymanın önemi çok daha düşük: %0,005. Bu duruma katlanabilirim.
Film şeridinde, <h1>
yazı tipinin hemen bir sistem yazı tipine geçtiği ve kullanıcıların metni daha hızlı okuyabildiği de açıkça görülüyor.
Sonuç
Karmaşık web sitelerinde bu örnektekinden çok daha fazla düzen değişikliği yaşanabilir ancak düzeltme süreci aynıdır: WebPageTest'e düzen kararsızlığı metrikleri ekleyin, suçluları belirlemek için sonuçları görsel yükleme film şeridiyle çapraz referans yaparak karşılaştırın ve ekran alanını ayırmak için yer tutucular kullanarak bir düzeltme uygulayın.
(Bir şey daha) Gerçek kullanıcıların yaşadığı düzen kararsızlığını ölçme
Bir sayfayı optimize etmeden önce ve sonra WebPageTest'i çalıştırıp bir metrikte iyileşme görmek güzel bir şeydir ancak asıl önemli olan, kullanıcı deneyiminin gerçekten iyileşmesidir. Siteyi daha iyi hale getirmeye çalışmamızın nedeni de bu değil mi?
Bu nedenle, geleneksel web performansı metriklerimizle birlikte gerçek kullanıcıların düzen kararsızlığı deneyimlerini de ölçmeye başlamamız çok faydalı olacaktır. Sahadan gelen veriler, sorunların nerede olduğunu ve çözümlerimizin olumlu bir fark yaratıp yaratmadığını bize bildirdiğinden bu, optimizasyon geri bildirim döngüsünün önemli bir parçasıdır.
Kendi düzen kararsızlığı verilerinizi toplamanın yanı sıra, milyonlarca web sitesindeki gerçek kullanıcı deneyimlerinden elde edilen kümülatif düzen kayması verilerini içeren Chrome Kullanıcı Deneyimi Raporu'na göz atın. Bu rapor, sizin (veya rakiplerinizin) nasıl performans gösterdiğini öğrenmenize olanak tanır. Ayrıca, web'deki düzen kararsızlığının durumunu keşfetmek için de kullanabilirsiniz.