WebPageTest'i kullanarak düzen kararsızlığı sorunlarını belirleme ve düzeltme hakkında adım adım açıklama.
Daha önceki bir yayında, WebPageTest'te Cumulative Layout Shift'in (CLS) ölçülmesi hakkında yazmıştım. CLS, tüm düzen kaymalarının bir toplamıdır. Bu nedenle, bu yayında daha derinlemesine inceleme yapmanın ve kararsızlığa neyin neden olabileceğini anlamak için sayfadaki her bir düzen kaymasını incelemenin ve aslında 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, giriş etkinliklerinden önce gelmeyen bir dizi düzen kayması 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 değişiklik yapılmıştır.
Değişimin zamanını ve şiddetini bilmek, değişime neyin neden olabileceğini daraltmaya yardımcı olur. Daha fazla test yapmak için laboratuvar ortamı olarak WebPageTest'e dönelim.
WebPageTest'te düzen kaymalarını ölçme
WebPageTest'te CLS'yi ölçmeye benzer şekilde, tek tek düzen kaymalarını ölçmek için özel bir metrik gerekir. Neyse ki Chrome 77 kararlı sürümüne geçildiğinden bu işlem artık daha kolay. Düzen Kararsızlığı API'si varsayılan olarak etkindir. Bu nedenle, Chrome 77'deki herhangi bir web sitesinde bu JS snippet'ini çalıştırabilir ve sonuçları hemen alabilirsiniz. WebPageTest'te varsayılan Chrome tarayıcıyı kullanabilir, komut satırı işaretleri veya Canary'yi kullanma konusunda endişelenmenize gerek kalmaz.
Bu nedenle, WebPageTest için özel bir metrik oluşturmak üzere 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 söz, dizinin kendisi yerine dizinin JSON gösterimiyle çözümlenir. Bunun nedeni, özel metriklerin yalnızca dizeler veya sayılar gibi temel veri türleri oluşturabilmesidir.
Test için kullanacağım web sitesi, web barındırıcıların gerçek dünyadaki yükleme performansını karşılaştırmak için oluşturduğum ismyhostfastyet.com.
Düzen kararsızlığının nedenlerini belirleme
Sonuçlarda LayoutShifts özel metriğinin şu değere sahip olduğunu görebiliriz:
[
{
"name": "",
"entryType": "layout-shift",
"startTime": 3087.2349999990547,
"duration": 0,
"value": 0.3422101449275362,
"hadRecentInput": false,
"lastInputTime": 0
}
]
Özetle, 3087 ms'de% 34,2 oranında tek bir düzen kayması meydana geliyor. Suçluyu belirlemeye yardımcı olması için WebPageTest'in film şeridi görünümünü kullanalım.
Film şeridinde yaklaşık 3. saniyeye kaydırdığımızda% 34'lük düzen kaymasının nedeninin renkli tablo olduğunu net bir şekilde görüyoruz. Web sitesi, bir JSON dosyasını eşzamansız olarak getirir ve ardından tabloya dönüştürür. Tablo başlangıçta boş olduğundan sonuçlar yüklendiğinde tablonun doldurulması bekleniyor. Bu nedenle kayma oluşuyor.
Ancak bu kadarla sınırlı değil. Sayfa yaklaşık 4,3 saniyede görsel olarak tamamlandığında, "Is my host fast yet?" sayfasının <h1> öğesinin aniden göründüğünü görüyoruz. 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üzenin değiştiği görünmez ancak başlığı okumak için bu kadar uzun süre beklemek yine de 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 öğrendiğimize göre artık bu sorunu düzeltme zamanı. JSON sonuçları gerçekten yüklenene kadar tablonun içeriğini bilemeyiz ancak DOM oluşturulduğunda düzenin nispeten sabit olması için tabloyu bir tür yer tutucu verilerle doldurabiliriz.
Yer tutucu veriler oluşturmak için aşağıdaki kodu kullanın:
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 üzere rastgele sayıda tekrarlanan "█" karakterini ve üç ana değerin rastgele oluşturulmuş dağılımını içerir. Ayrıca, verilerin henüz tam olarak yüklenmediğini belirtmek için tablodaki tüm renkleri doygunluktan arındıran bazı stiller 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ğini ve sayfanın bozuk olmadığını bildirmektir.
JSON verileri yüklenirken yer tutucuların görünümü aşağıdaki gibidir:
Web yazı tipi sorununu gidermek artık çok daha kolay. Sitede Google Yazı Tipleri kullanıldığı için CSS isteğinde yalnızca display=swap özelliğini iletmemiz gerekir. Hepsi bu kadar. Fonts API, yazı tipi bildirimine font-display: swap stilini ekleyerek tarayıcının metni hemen yedek yazı tipiyle oluşturmasını sağlar. Düzeltmenin yer aldığı 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'te yeniden çalıştırdıktan sonra, farkı görselleştirmek ve yeni düzen kararsızlığı derecesini ölçmek için ö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, 3.071 ms'de (öncekiyle yaklaşık aynı zamanda) hala bir düzen kayması meydana geliyor ancak kaymanın şiddeti çok daha düşük: %0,005. Buna katlanabilirim.
Film şeridinden de <h1> yazı tipinin hemen bir sistem yazı tipine geri döndüğü ve kullanıcıların bunu daha hızlı okuyabildiği anlaşılıyor.
Sonuç
Karmaşık web sitelerinde bu örnektekinden çok daha fazla düzen kayması yaşanabilir ancak düzeltme süreci aynıdır: Düzen kararsızlığı metriklerini WebPageTest'e ekleyin, sonuçları görsel yükleme film şeridiyle çapraz referanslayarak sorunlu öğeleri belirleyin ve ekran alanını ayırmak 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
Bir sayfada optimizasyondan önce ve sonra WebPageTest'i çalıştırıp bir metriğin iyileştiğini görmek güzel olsa da asıl önemli olan kullanıcı deneyiminin gerçekten iyileşmesidir. Sitenin daha iyi olması için çabalamamızın nedeni de bu değil mi?
Bu nedenle, geleneksel web performansı metriklerimizin yanı sıra gerçek kullanıcıların düzen kararsızlığı deneyimlerini de ölçmeye başlamamız iyi olacaktır. Sahadan alınan veriler, sorunların nerede olduğunu ve düzeltmelerimizin olumlu bir fark yaratıp yaratmadığını bize bildirdiği için 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 da göz atın. Bu araç, sizin (veya rakiplerinizin) nasıl performans gösterdiğini öğrenmenize ya da web'deki düzen kararsızlığının durumunu keşfetmenize olanak tanır.