إصلاح عدم ثبات التنسيق

جولة إرشادية حول استخدام WebPageTest لتحديد مشاكل عدم ثبات التنسيق وإصلاحها

Rick Viscomi

في مشاركة سابقة، كتبتُ عن قياس متغيّرات التصميم التراكمية (CLS) في WebPageTest. بما أنّ CLS هي عبارة عن تجميع لكل متغيّرات التصميم، أردت في هذه المشاركة أن أتعمّق أكثر وأفحص كل متغيّر تصميم فردي على الصفحة لمحاولة فهم الأسباب المحتملة لعدم الاستقرار ومحاولة حلّ المشاكل.

قياس تغييرات التصميم

باستخدام 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
  }
]

في هذا المثال، حدث تغيير صغير جدًا بنسبة% 0.01 عند 210 ملي ثانية.

من المفيد معرفة وقت حدوث التغيير ومدى تأثيره للمساعدة في تحديد الأسباب المحتملة. لنرجع إلى WebPageTest للحصول على بيئة اختبار لإجراء المزيد من الاختبارات.

قياس متغيّرات التصميم في WebPageTest

على غرار قياس CLS في WebPageTest، سيتطلّب قياس متغيّرات التصميم الفردية مقياسًا مخصّصًا. لحسن الحظ، أصبحت العملية أسهل الآن بعد أن أصبح الإصدار 77 من Chrome ثابتًا. يتم تفعيل Layout Instability API تلقائيًا، لذا من المفترض أن تتمكّن من تنفيذ مقتطف JavaScript هذا على أي موقع إلكتروني ضمن الإصدار 77 من Chrome والحصول على النتائج على الفور. في WebPageTest، يمكنك استخدام متصفّح Chrome التلقائي بدون الحاجة إلى القلق بشأن علامات سطر الأوامر أو استخدام Canary.

لذا، لنعدّل هذا النص البرمجي لإنشاء مقياس مخصّص لأداة 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
  }
]

باختصار، يحدث تغيير واحد في التصميم بنسبة% 34.2 عند 3087 ملي ثانية. للمساعدة في تحديد السبب، لنستخدِم عرض شريط الصور في WebPageTest.

عند الانتقال إلى علامة الثانية الثالثة تقريبًا في شريط الصور، نرى بالضبط سبب حدوث تغيير في التنسيق بنسبة% 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 Fonts، ما علينا سوى إدخال السمة display=swap في طلب CSS. هذا كل ما لدينا. ستضيف Fonts API النمط 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 الذي يتضمّن بيانات "مقياس CLS" من تجارب المستخدمين الفعليين على ملايين المواقع الإلكترونية. تتيح لك هذه الأداة معرفة مستوى أدائك (أو أداء منافسيك)، أو يمكنك استخدامها لاستكشاف حالة عدم ثبات التنسيق على الويب.