लेआउट के अस्थिरता को ठीक करना

लेआउट में गड़बड़ी की समस्याओं का पता लगाने और उन्हें ठीक करने के लिए, WebPageTest का इस्तेमाल करने के बारे में कदम-दर-कदम निर्देश.

रिक विस्कॉमी

मैंने इससे पहले एक पोस्ट में WebPageTest में कुल लेआउट शिफ़्ट को मापने (सीएलएस) के बारे में लिखा था. सीएलएस, सभी लेआउट शिफ़्ट का एग्रीगेशन है. इसलिए, मुझे लगा कि इस पोस्ट में, किसी पेज पर हर अलग-अलग लेआउट शिफ़्ट की गहराई से जांच करना और उसकी वजह से होने वाले बदलाव को समझना और समस्या(समस्याओं) को ठीक करने की कोशिश करना दिलचस्प होगा.

लेआउट शिफ़्ट को मेज़र करना

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% का बहुत कम बदलाव हुआ.

बदलाव के समय और गंभीरता को जानना इस बदलाव की वजहों को कम करने में मदद करता है. चलिए ज़्यादा टेस्ट करने के लिए किसी लैब एनवायरमेंट के लिए WebPageTest पर जाते हैं.

WebPageTest में लेआउट शिफ़्ट को मेज़र करना

WebPageTest में सीएलएस को मेज़र करने की तरह ही, अलग-अलग लेआउट शिफ़्ट को मेज़र करने के लिए, एक कस्टम मेट्रिक की ज़रूरत होगी. अच्छी बात यह है कि Chrome 77 के स्थिर होने पर, यह प्रोसेस अब और भी आसान हो गई है. Layout Instability API डिफ़ॉल्ट रूप से चालू होता है. इसलिए, आपको Chrome 77 में मौजूद किसी भी वेबसाइट पर उस JS स्निपेट को चलाना होगा और तुरंत नतीजे मिलेंगे. WebPageTest में, आपके पास डिफ़ॉल्ट Chrome ब्राउज़र का इस्तेमाल करने का विकल्प है और आपको कमांड लाइन फ़्लैग करने या कैनरी का इस्तेमाल करने की चिंता करने की ज़रूरत नहीं है.

आइए, उस स्क्रिप्ट में बदलाव करके WebPageTest के लिए कस्टम मेट्रिक बनाते हैं:

[LayoutShifts]
return new Promise(resolve => {
  new PerformanceObserver(list => {
    resolve(JSON.stringify(list.getEntries().filter(entry => !entry.hadRecentInput)));
  }).observe({type: "layout-shift", buffered: true});
});

इस स्क्रिप्ट में दिया गया प्रॉमिस, अरे के बजाय, JSON फ़ॉर्मैट में प्रॉमिस को दिखाता है. इसकी वजह यह है कि कस्टम मेट्रिक, सिर्फ़ स्ट्रिंग या संख्याओं जैसे प्रिमिटिव डेटा टाइप बना सकती हैं.

जांच के लिए, मैं ismyhostfastyet.com वेबसाइट का इस्तेमाल करूं. यह साइट मैंने बनाई है, ताकि वेब होस्ट की साइट लोड होने की असल परफ़ॉर्मेंस की तुलना की जा सके.

लेआउट के अस्थिर होने की वजहों का पता लगाना

नतीजों में, हम देख सकते हैं कि LayoutShifts कस्टम मेट्रिक में यह वैल्यू है:

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

खास जानकारी देने के लिए, 3087 मि॰से॰ की स्क्रीन पर 34.2% का एक लेआउट शिफ़्ट है. अपराधी की पहचान करने में मदद करने के लिए, हम WebPageTest के फ़िल्मस्ट्रिप व्यू का इस्तेमाल करते हैं.

फ़िल्मस्ट्रिप में स्क्रोल करते हुए तीन सेकंड के हिस्से तक जाने पर, हमें पता चलता है कि 34% लेआउट शिफ़्ट की असल वजह क्या है: रंग-बिरंगी टेबल. वेबसाइट, JSON फ़ाइल को एसिंक्रोनस तरीके से फ़ेच करती है और फिर उसे टेबल में रेंडर करती है. शुरुआत में टेबल खाली थी, इसलिए नतीजे लोड होने पर उसे भरने का इंतज़ार करने की वजह से शिफ़्ट हो रही है.

बस यही नहीं. जब पेज ~4.3 सेकंड में विज़ुअल तौर पर पूरा हो जाता है, तो हमें पता चलता है कि "क्या मेरा होस्ट अब तक तेज़ है?" पेज का <h1> कहीं से भी दिखता है. ऐसा इसलिए होता है, क्योंकि साइट वेब फ़ॉन्ट का इस्तेमाल करती है और रेंडरिंग को ऑप्टिमाइज़ करने के लिए कोई कार्रवाई नहीं की जाती. ऐसा होने पर लेआउट में बदलाव नहीं दिखता, लेकिन टाइटल पढ़ने के लिए काफ़ी देर तक इंतज़ार करना अब भी एक खराब उपयोगकर्ता अनुभव है.

लेआउट की अस्थिरता को ठीक करना

अब जब हम जानते हैं कि एसिंक्रोनस रूप से जनरेट की गई टेबल की वजह से व्यूपोर्ट का एक-तिहाई हिस्सा शिफ़्ट हो रहा है, तो इसे ठीक करने का समय आ गया है. JSON के नतीजे लोड होने तक, हमें टेबल का कॉन्टेंट नहीं पता होता. हालांकि, हम टेबल में कुछ तरह का प्लेसहोल्डर डेटा डाल सकते हैं. इससे, डीओएम के रेंडर होने पर लेआउट एक जैसा बना रहता है.

प्लेसहोल्डर डेटा जनरेट करने के लिए कोड यहां दिया गया है:

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

क्रम से लगाए जाने से पहले, प्लेसहोल्डर डेटा रैंडम तरीके से जनरेट होता है. इसमें "█" वर्ण को बिना किसी खास संख्या में बार-बार दोहराया जाता है, ताकि टेक्स्ट के लिए विज़ुअल प्लेसहोल्डर और तीन मुख्य वैल्यू को किसी भी क्रम में जनरेट किया जा सके. मैंने टेबल के सभी रंगों को फीका करने के लिए कुछ स्टाइल भी जोड़े हैं, ताकि यह साफ़ हो सके कि डेटा अभी पूरी तरह से लोड नहीं हुआ है.

इस्तेमाल किए जाने वाले प्लेसहोल्डर के दिखने से, लेआउट की स्थिरता पर कोई असर नहीं पड़ता. प्लेसहोल्डर का मकसद उपयोगकर्ताओं को यह पक्का करना होता है कि कॉन्टेंट आया जा रहा है और पेज में बदलाव नहीं हुआ है.

JSON डेटा लोड होने के दौरान प्लेसहोल्डर ऐसा दिखता है:

वेब फ़ॉन्ट की समस्या को हल करना बहुत आसान है. साइट में Google फ़ॉन्ट का इस्तेमाल किया जा रहा है. इसलिए, हमें सीएसएस के अनुरोध में सिर्फ़ display=swap प्रॉपर्टी को पास करना होगा. बस इतना ही। फ़ॉन्ट एपीआई, फ़ॉन्ट के एलान में 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
  }
]

कस्टम मेट्रिक के हिसाब से, अब भी 3071 मि॰से॰ (करीब पहले के बराबर) पर लेआउट शिफ़्ट हो रहा है. हालांकि, शिफ़्ट की गंभीरता बहुत कम है: 0.005%. मैं इसके साथ रह सकती हूं.

फ़िल्मस्ट्रिप से यह भी साफ़ पता चलता है कि <h1> फ़ॉन्ट तुरंत वापस सिस्टम फ़ॉन्ट पर सेट हो रहा है, ताकि उपयोगकर्ता उसे जल्दी पढ़ सकें.

नतीजा

कॉम्प्लेक्स वेबसाइटों में, इस उदाहरण के मुकाबले शायद ज़्यादा लेआउट शिफ़्ट होंगे. हालांकि, समस्या को ठीक करने की प्रोसेस अब भी पहले जैसी ही है: WebPageTest में लेआउट से न बदलने वाली मेट्रिक जोड़ना, नतीजों को विज़ुअल लोड होने वाली फ़िल्मस्ट्रिप के साथ क्रॉस-रेफ़रंस करना, और खराबियों की पहचान करने के लिए प्लेसहोल्डर का इस्तेमाल करके सुधार लागू करना.

(एक और बात) असल उपयोगकर्ताओं के अनुभव के आधार पर लेआउट में होने वाले उतार-चढ़ाव को मापना

ऑप्टिमाइज़ेशन से पहले और बाद में किसी पेज पर WebPageTest चलाना और किसी मेट्रिक में सुधार देखना अच्छा है, लेकिन असल में यह तो मायने रखता है कि उपयोगकर्ता अनुभव असल में बेहतर हो रहा है. क्या ऐसा नहीं है कि हम पहले ही साइट को बेहतर बनाने की कोशिश कर रहे हैं?

इसलिए, सबसे अच्छा तब होगा, जब हम वेब परफ़ॉर्मेंस की पारंपरिक मेट्रिक के साथ-साथ असल उपयोगकर्ताओं के लेआउट में हो रहे बदलावों को भी मापना शुरू करें. यह ऑप्टिमाइज़ेशन फ़ीडबैक लूप का एक अहम हिस्सा है, क्योंकि फ़ील्ड से डेटा मिलने से हमें पता चलता है कि समस्याएं कहां हैं और क्या हमारे सुधारों से सकारात्मक असर पड़ा है.

लेआउट से जुड़े अपने डेटा को इकट्ठा करने के अलावा, Chrome UX रिपोर्ट देखें. इसमें लाखों वेबसाइटों पर, लोगों के अनुभव से जुड़ा कुल लेआउट शिफ़्ट डेटा शामिल है. इसकी मदद से, यह पता लगाया जा सकता है कि आपका (या आपके जैसे दूसरे कारोबारों) की परफ़ॉर्मेंस कैसी है. इसके अलावा, इसका इस्तेमाल करके यह पता लगाया जा सकता है कि वेब पर आपका लेआउट कितना खराब है.