رفع بی ثباتی چیدمان

مروری بر استفاده از WebPageTest برای شناسایی و رفع مشکلات ناپایداری طرح.

Rick Viscomi

در پست قبلی در مورد اندازه گیری تغییر چیدمان تجمعی (CLS) در WebPageTest نوشتم. CLS مجموعه‌ای از همه تغییرات طرح‌بندی است، بنابراین در این پست فکر کردم جالب است که عمیق‌تر غواصی کنم و هر تغییر طرح‌بندی جداگانه را در یک صفحه بررسی کنم تا بفهمم چه چیزی می‌تواند باعث بی‌ثباتی شود و در واقع سعی کنم مشکل را برطرف کنم ( s).

اندازه گیری تغییرات چیدمان

با استفاده از 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 پایدار است، این روند آسان تر شده است. Layout Instability API به طور پیش‌فرض فعال است، بنابراین شما باید بتوانید آن قطعه JS را در هر وب‌سایتی در Chrome 77 اجرا کنید و فوراً نتایج را دریافت کنید. در WebPageTest، می‌توانید از مرورگر پیش‌فرض کروم استفاده کنید و نگران پرچم‌های خط فرمان یا استفاده از 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 استفاده کنیم.

دو سلول در نوار فیلم، اسکرین‌شات‌هایی را قبل و بعد از تغییر چیدمان نشان می‌دهند.

پیمایش به علامت ~ 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 بارگیری می‌شوند، مکان‌نماها چگونه به نظر می‌رسند:

جدول داده ها با داده های نگهدارنده مکان ارائه می شود.

پرداختن به مشکل فونت وب بسیار ساده تر است. از آنجایی که سایت از فونت های گوگل استفاده می کند، فقط باید ویژگی display=swap را در درخواست CSS ارسال کنیم. همین. Fonts API 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
  }
]

با توجه به معیارهای سفارشی ، هنوز یک تغییر چیدمان در 3071 میلی‌ثانیه (تقریباً همان زمان قبلی) وجود دارد، اما شدت تغییر بسیار کمتر است: 0.005%. من میتوانم با این زندگی کنم.

همچنین از نوار فیلم مشخص است که فونت <h1> بلافاصله به یک فونت سیستمی برمی‌گردد و به کاربران امکان می‌دهد زودتر آن را بخوانند.

نتیجه

احتمالاً وب‌سایت‌های پیچیده تغییرات طرح‌بندی بسیار بیشتری را نسبت به این مثال تجربه می‌کنند، اما روند اصلاح همچنان یکسان است: معیارهای بی‌ثباتی طرح‌بندی را به WebPageTest اضافه کنید، نتایج را با نوار فیلم بارگذاری تصویری ارجاع دهید تا مقصران را شناسایی کنید، و یک اصلاح را با استفاده از آن اجرا کنید. متغیرهایی برای رزرو صفحه نمایش املاک و مستغلات.

(یک چیز دیگر) اندازه گیری بی ثباتی طرح که توسط کاربران واقعی تجربه می شود

خوب است که بتوانید WebPageTest را روی یک صفحه قبل و بعد از بهینه سازی اجرا کنید و شاهد بهبود معیارها باشید، اما آنچه واقعاً مهم است این است که تجربه کاربر در واقع بهتر می شود. آیا به این دلیل نیست که در وهله اول سعی می کنیم سایت را بهتر کنیم؟

بنابراین آنچه عالی خواهد بود این است که ما شروع به اندازه گیری تجارب بی ثباتی چیدمان کاربران واقعی در کنار معیارهای عملکرد وب سنتی خود کنیم. این بخش مهمی از حلقه بازخورد بهینه‌سازی است، زیرا داشتن داده‌های میدانی به ما می‌گوید که مشکلات کجا هستند و آیا اصلاحات ما تفاوت مثبتی ایجاد کرده است.

علاوه بر جمع‌آوری داده‌های بی‌ثباتی طرح‌بندی، گزارش Chrome UX را بررسی کنید که شامل داده‌های تغییر چیدمان تجمعی از تجربیات واقعی کاربر در میلیون‌ها وب‌سایت است. این به شما امکان می دهد تا از عملکرد خود (یا رقبایتان) مطلع شوید، یا می توانید از آن برای بررسی وضعیت بی ثباتی چیدمان در سراسر وب استفاده کنید.