বিন্যাস অস্থিরতা ফিক্সিং

লেআউট অস্থিরতার সমস্যা চিহ্নিত করতে এবং ঠিক করতে WebPageTest ব্যবহার করার একটি ওয়াকথ্রু।

Rick Viscomi

আগের একটি পোস্টে আমি WebPageTest-এ Cumulative Layout Shift (CLS) পরিমাপ করার বিষয়ে লিখেছিলাম। সিএলএস হল সমস্ত লেআউট শিফটের একটি সমষ্টি, তাই এই পোস্টে আমি ভেবেছিলাম যে অস্থিরতার কারণ কী হতে পারে তা বোঝার চেষ্টা করার জন্য গভীরে ডুব দেওয়া এবং প্রতিটি পৃথক লেআউট শিফট পরিদর্শন করা আকর্ষণীয় হবে এবং আসলে সমস্যাটি সমাধান করার চেষ্টা করুন( s)।

লেআউট স্থানান্তর পরিমাপ

লেআউট অস্থিরতা 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
  }
]

এই উদাহরণে 210ms এ 0.01% একটি একক খুব ছোট শিফট ছিল।

শিফটের সময় এবং তীব্রতা জানা শিফটের কারণ কী হতে পারে তা সংকুচিত করতে সাহায্য করে। আরও পরীক্ষা করার জন্য ল্যাব পরিবেশের জন্য WebPageTest- এ ফিরে আসা যাক।

WebPageTest-এ লেআউট পরিবর্তন পরিমাপ করা

WebPageTest-এ CLS পরিমাপের মতো, পৃথক লেআউট শিফট পরিমাপের জন্য একটি কাস্টম মেট্রিক প্রয়োজন হবে। সৌভাগ্যবশত, Chrome 77 স্থিতিশীল হওয়ায় প্রক্রিয়াটি এখন সহজ। বিন্যাস অস্থিরতা API ডিফল্টরূপে সক্ষম করা আছে, তাই আপনি Chrome 77-এর মধ্যে যেকোন ওয়েবসাইটে সেই JS স্নিপেটটি কার্যকর করতে সক্ষম হবেন এবং অবিলম্বে ফলাফল পাবেন৷ ওয়েবপেজটেস্টে, আপনি ডিফল্ট ক্রোম ব্রাউজার ব্যবহার করতে পারেন এবং কমান্ড লাইন পতাকা বা ক্যানারি ব্যবহার করার বিষয়ে চিন্তা করতে হবে না।

তাহলে আসুন 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
  }
]

সংক্ষেপে বলা যায়, 3087ms এ ঘটছে 34.2% এর একটি একক লেআউট শিফট। অপরাধীকে শনাক্ত করতে সাহায্য করতে, আসুন WebPageTest এর ফিল্মস্ট্রিপ ভিউ ব্যবহার করি।

ফিল্মস্ট্রিপে দুটি কক্ষ, লেআউট শিফটের আগে এবং পরে স্ক্রিনশট দেখাচ্ছে৷

ফিল্মস্ট্রিপে ~3 সেকেন্ডের চিহ্নে স্ক্রোল করা আমাদের দেখায় যে 34% লেআউট পরিবর্তনের কারণ কী: রঙিন টেবিল। ওয়েবসাইটটি অ্যাসিঙ্ক্রোনাসভাবে একটি JSON ফাইল নিয়ে আসে, তারপর এটি একটি টেবিলে রেন্ডার করে। টেবিলটি প্রাথমিকভাবে খালি, তাই ফলাফলগুলি লোড হওয়ার সময় এটি পূরণ করার জন্য অপেক্ষা করা স্থানান্তর ঘটাচ্ছে৷

ওয়েব ফন্টের শিরোনাম কোথাও দেখা যাচ্ছে না।

কিন্তু যে সব না. যখন পৃষ্ঠাটি দৃশ্যত ~4.3 সেকেন্ডে সম্পূর্ণ হয়, তখন আমরা দেখতে পাব যে পৃষ্ঠাটির <h1> "আমার হোস্ট কি এখনও দ্রুত?" কোথাও দেখা যাচ্ছে না। এটি ঘটে কারণ সাইটটি একটি ওয়েব ফন্ট ব্যবহার করে এবং রেন্ডারিং অপ্টিমাইজ করার জন্য কোনো পদক্ষেপ নেয়নি৷ যখন এটি ঘটে তখন লেআউটটি প্রকৃতপক্ষে স্থানান্তরিত হয় বলে মনে হয় না, তবে শিরোনামটি পড়ার জন্য এতক্ষণ অপেক্ষা করার জন্য এটি এখনও একটি দুর্বল ব্যবহারকারীর অভিজ্ঞতা।

বিন্যাস অস্থিরতা ফিক্সিং

এখন আমরা জানি যে অ্যাসিঙ্ক্রোনাসভাবে তৈরি করা টেবিল ভিউপোর্টের এক-তৃতীয়াংশ স্থানান্তরিত করছে, এটি ঠিক করার সময়। JSON ফলাফলগুলি আসলে লোড না হওয়া পর্যন্ত আমরা টেবিলের বিষয়বস্তু জানি না, তবে আমরা এখনও কিছু ধরণের প্লেসহোল্ডার ডেটা দিয়ে টেবিলটি পূরণ করতে পারি যাতে DOM রেন্ডার করার সময় লেআউটটি নিজেই তুলনামূলকভাবে স্থিতিশীল থাকে।

প্লেসহোল্ডার ডেটা জেনারেট করার কোড এখানে:

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 ফন্ট ব্যবহার করছে, তাই আমাদের শুধুমাত্র CSS অনুরোধে display=swap প্রপার্টি পাস করতে হবে। এতটুকুই। ফন্ট এপিআই ফন্ট ডিক্লারেশনে font-display: swap স্টাইল যুক্ত করবে, ব্রাউজারকে অবিলম্বে ফলব্যাক ফন্টে পাঠ্য রেন্ডার করতে সক্ষম করবে। এখানে ফিক্সের সাথে সংশ্লিষ্ট মার্কআপটি অন্তর্ভুক্ত রয়েছে:

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

অপ্টিমাইজেশান যাচাই করা হচ্ছে

WebPageTest এর মাধ্যমে পৃষ্ঠাটি পুনরায় চালু করার পরে, আমরা পার্থক্যটি কল্পনা করতে এবং লেআউটের অস্থিরতার নতুন মাত্রা পরিমাপের জন্য আগে এবং পরে তুলনা করতে পারি:

WebPageTest ফিল্মস্ট্রিপ লেআউট অপ্টিমাইজেশানের সাথে এবং ছাড়াই উভয় সাইট লোড হচ্ছে।

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

কাস্টম মেট্রিক অনুসারে, এখনও 3071ms (আগের মতো একই সময়ে) একটি লেআউট স্থানান্তর ঘটছে তবে শিফটের তীব্রতা অনেক কম: 0.005%। আমি এটা নিয়ে বাঁচতে পারি।

ফিল্মস্ট্রিপ থেকে এটাও স্পষ্ট যে <h1> ফন্টটি অবিলম্বে একটি সিস্টেম ফন্টে ফিরে আসছে, ব্যবহারকারীদের তাড়াতাড়ি এটি পড়তে সক্ষম করে।

উপসংহার

জটিল ওয়েবসাইটগুলি সম্ভবত এই উদাহরণের চেয়ে অনেক বেশি লেআউট পরিবর্তনের অভিজ্ঞতা পাবে, কিন্তু প্রতিকার প্রক্রিয়া এখনও একই: ওয়েবপেজটেস্টে লেআউট অস্থিরতা মেট্রিক্স যোগ করুন, অপরাধীদের সনাক্ত করতে ভিজ্যুয়াল লোডিং ফিল্মস্ট্রিপের সাথে ফলাফলগুলি ক্রস-রেফারেন্স করুন এবং এটি ব্যবহার করে একটি সমাধান বাস্তবায়ন করুন স্থানধারক পর্দা রিয়েল এস্টেট রিজার্ভ.

(আরও একটি জিনিস) বাস্তব ব্যবহারকারীদের দ্বারা অভিজ্ঞ লেআউট অস্থিরতা পরিমাপ

একটি অপ্টিমাইজেশনের আগে এবং পরে একটি পৃষ্ঠায় WebPageTest চালানো এবং একটি মেট্রিকের উন্নতি দেখতে পারাটা ভালো, কিন্তু আসলেই যেটা গুরুত্বপূর্ণ তা হল ব্যবহারকারীর অভিজ্ঞতা আসলে আরও ভালো হচ্ছে৷ তাই কি তাই নয় যে আমরা প্রথমে সাইটটিকে আরও ভালো করার চেষ্টা করছি?

তাই চমৎকার হবে যদি আমরা আমাদের ঐতিহ্যগত ওয়েব পারফরম্যান্স মেট্রিক্সের সাথে বাস্তব ব্যবহারকারীদের লেআউট অস্থিরতার অভিজ্ঞতা পরিমাপ করা শুরু করি। এটি অপ্টিমাইজেশান ফিডব্যাক লুপের একটি গুরুত্বপূর্ণ অংশ কারণ ফিল্ড থেকে ডেটা থাকা আমাদের বলে যে সমস্যাগুলি কোথায় এবং আমাদের সমাধানগুলি ইতিবাচক পার্থক্য করেছে কিনা৷

আপনার নিজস্ব লেআউট অস্থিরতা ডেটা সংগ্রহ করার পাশাপাশি, Chrome UX রিপোর্ট দেখুন, যাতে লক্ষ লক্ষ ওয়েবসাইটে প্রকৃত ব্যবহারকারীর অভিজ্ঞতা থেকে ক্রমবর্ধমান লেআউট শিফট ডেটা অন্তর্ভুক্ত রয়েছে৷ এটি আপনাকে (বা আপনার প্রতিযোগীরা) কীভাবে পারফর্ম করছে তা খুঁজে বের করার অনুমতি দেয়, অথবা আপনি ওয়েব জুড়ে লেআউট অস্থিরতার অবস্থা অন্বেষণ করতে এটি ব্যবহার করতে পারেন।