การแก้ไขความไม่เสถียรของเลย์เอาต์

คำแนะนำในการใช้ WebPageTest เพื่อระบุและแก้ไขปัญหาความเสถียรของเลย์เอาต์

Rick Viscomi

ในโพสต์ก่อนหน้านี้ เราได้เขียนเกี่ยวกับการวัด Cumulative Layout Shift (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 แต่โชคดีที่ตอนนี้กระบวนการนี้ง่ายขึ้นเนื่องจาก Chrome 77 เป็นเวอร์ชันเสถียรแล้ว Layout Instability API จะเปิดใช้โดยค่าเริ่มต้น คุณจึงสามารถเรียกใช้สnippet JS นั้นในเว็บไซต์ใดก็ได้ภายใน Chrome 77 และรับผลลัพธ์ได้ทันที ใน 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% ที่ความเร็ว 3, 087 มิลลิวินาที เพื่อช่วยระบุตัวการ เรามาลองใช้มุมมองภาพสไลด์ของ WebPageTest

2 เซลล์ในแถบแสดงตัวอย่างภาพ ซึ่งแสดงภาพหน้าจอก่อนและหลังการเปลี่ยนแปลงเลย์เอาต์
2 เซลล์ในแถบแสดงตัวอย่างภาพ ซึ่งแสดงภาพหน้าจอก่อนและหลังการเปลี่ยนแปลงเลย์เอาต์

หากเลื่อนไปยังเส้นที่ประมาณ 3 วินาทีของแถบฟิล์มแสดงสาเหตุของการเปลี่ยนแปลงเลย์เอาต์ 34% ซึ่งก็คือตารางสีสันสดใส เว็บไซต์จะดึงข้อมูลไฟล์ JSON แบบไม่พร้อมกัน จากนั้นแสดงผลเป็นตาราง ตารางจะว่างเปล่าในตอนแรก การรอให้ตารางเต็มเมื่อโหลดผลลัพธ์จึงทำให้เกิดการเปลี่ยนแปลง

ส่วนหัวของแบบอักษรของเว็บปรากฏจากที่ใดเลย
ส่วนหัวแบบอักษรเว็บปรากฏขึ้นอย่างไม่ทราบที่มา

ยังไม่หมดเพียงเท่านี้ เมื่อหน้าเว็บเสร็จสมบูรณ์ในเวลาประมาณ 4.3 วินาที เราจะเห็นว่า <h1> ของหน้า "โฮสต์ของฉันเร็วหรือยัง" ปรากฏขึ้นทันที ปัญหานี้เกิดขึ้นเนื่องจากเว็บไซต์ใช้แบบอักษรเว็บและไม่ได้ดำเนินการใดๆ เพื่อเพิ่มประสิทธิภาพการแสดงผล แม้เลย์เอาต์จะไม่เปลี่ยนไปเมื่อเกิดเหตุการณ์นี้ขึ้น แต่ผู้ใช้ก็ยังได้รับประสบการณ์การใช้งานที่ไม่ดี การต้องรอหนังสือนานมาก

การแก้ไขความผันผวนของเลย์เอาต์

เมื่อทราบว่าตารางที่สร้างขึ้นแบบไม่พร้อมกันทําให้วิวพอร์ตเลื่อนไป 1 ใน 3 ของพื้นที่ทำงาน ก็ได้เวลาแก้ไขปัญหาแล้ว เราจะไม่ทราบเนื้อหาของตารางจนกว่าระบบจะโหลดผลลัพธ์ 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'));

ระบบจะสร้างข้อมูลตัวยึดตำแหน่งแบบสุ่มก่อนจัดเรียง ซึ่งประกอบด้วยอักขระ "█" ที่ซ้ำกันตามจำนวนแบบสุ่มเพื่อสร้างตัวยึดตำแหน่งภาพสำหรับข้อความและการแจกแจงค่าหลัก 3 ค่าที่สร้างขึ้นแบบสุ่ม นอกจากนี้ เรายังเพิ่มสไตล์บางอย่างเพื่อลดความอิ่มตัวของสีทั้งหมดในตารางเพื่อให้ชัดเจนว่าระบบยังไม่ได้โหลดข้อมูลจนเต็ม

ลักษณะของตัวยึดตําแหน่งที่คุณใช้ไม่ส่งผลต่อความเสถียรของเลย์เอาต์ วัตถุประสงค์ของตัวยึดตำแหน่งคือให้ผู้ใช้มั่นใจว่าเนื้อหากำลังจะมาและหน้าเว็บไม่เสียหาย

ตัวยึดตำแหน่งจะมีลักษณะดังนี้ขณะโหลดข้อมูล 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 อีกครั้งแล้ว เราจะสร้างการเปรียบเทียบก่อนและหลังเพื่อแสดงภาพความแตกต่างและวัดระดับความผันผวนของเลย์เอาต์ใหม่ได้ ดังนี้

ภาพสไลด์ของ WebPageTest ที่แสดงทั้ง 2 เว็บไซต์ที่โหลดอยู่เคียงข้างกันโดยมีและไม่มีการเพิ่มประสิทธิภาพเลย์เอาต์
แถบแสดงตัวอย่างของ WebPageTest ที่แสดงการโหลดเว็บไซต์ทั้ง 2 แห่งควบคู่กันโดยมีและไม่มีการเพิ่มประสิทธิภาพเลย์เอาต์
[
  {
    "name": "",
    "entryType": "layout-shift",
    "startTime": 3070.9349999997357,
    "duration": 0,
    "value": 0.000050272187989256116,
    "hadRecentInput": false,
    "lastInputTime": 0
  }
]

จากข้อมูลของเมตริกที่กำหนดเอง ยังมีการเปลี่ยนแปลงเลย์เอาต์เกิดขึ้นที่เวลา 3, 071 มิลลิวินาที (เป็นเวลาเดียวกับก่อนหน้านี้) แต่ความรุนแรงของการเปลี่ยนแปลงจะน้อยลงมากซึ่งก็คือ 0.005% ฉันก็ใช้ชีวิตได้ด้วยสิ่งนี้

นอกจากนี้ ฟลิม์สตริปยังแสดงให้เห็นอย่างชัดเจนว่าแบบอักษร <h1> เปลี่ยนกลับไปใช้แบบอักษรของระบบทันที ซึ่งช่วยให้ผู้ใช้อ่านได้เร็วขึ้น

บทสรุป

เว็บไซต์ที่ซับซ้อนอาจมีการเลื่อนเลย์เอาต์มากกว่าในตัวอย่างนี้ แต่กระบวนการแก้ไขจะยังคงเหมือนเดิม นั่นคือ เพิ่มเมตริกความผันผวนของเลย์เอาต์ลงใน WebPageTest, ตรวจสอบผลลัพธ์กับแถบสไลด์ภาพการโหลดเพื่อระบุสาเหตุ และติดตั้งใช้งานการแก้ไขโดยใช้ตัวยึดตำแหน่งเพื่อจองพื้นที่บนหน้าจอ

(อีกเรื่องหนึ่ง) การวัดความผันผวนของเลย์เอาต์ที่ผู้ใช้จริงพบ

การที่สามารถเรียกใช้ WebPageTest บนหน้าเว็บทั้งก่อนและหลังการเพิ่มประสิทธิภาพ และได้เห็นการปรับปรุงเมตริก แต่สิ่งที่สำคัญจริงๆ ก็คือประสบการณ์ของผู้ใช้จะดีขึ้นกว่าเดิมจริง นั่นคือเหตุผลที่เราพยายามทำให้เว็บไซต์ดีขึ้นตั้งแต่แรก

ดังนั้นสิ่งที่ยอดเยี่ยมคือหากเราเริ่มวัดประสบการณ์ความผันผวนของเลย์เอาต์ของผู้ใช้จริงควบคู่ไปกับเมตริกประสิทธิภาพเว็บแบบดั้งเดิม ข้อมูลนี้เป็นส่วนสําคัญของลูปความคิดเห็นเกี่ยวกับการเพิ่มประสิทธิภาพ เนื่องจากข้อมูลภาคสนามช่วยให้เราทราบถึงปัญหาและดูว่าวิธีแก้ไขของเราส่งผลในเชิงบวกหรือไม่

นอกจากการเก็บรวบรวมข้อมูลความผันผวนของเลย์เอาต์ของคุณเองแล้ว โปรดดูรายงานประสบการณ์ของผู้ใช้ Chrome ซึ่งมีข้อมูลการเปลี่ยนแปลงเลย์เอาต์แบบสะสมจากประสบการณ์ของผู้ใช้จริงในเว็บไซต์หลายล้านแห่ง ซึ่งจะช่วยให้คุณทราบประสิทธิภาพของคุณ (หรือคู่แข่ง) หรือใช้เพื่อสำรวจสถานะความผันผวนของเลย์เอาต์ในเว็บ