Front-End Performance 2021: การวางแผนและเมตริก

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

สารบัญ

1. เตรียมตัวให้พร้อม: การวางแผนและการวัดผล
   วัฒนธรรมประสิทธิภาพ, Core Web Vitals, โปรไฟล์ประสิทธิภาพ, CrUX, Lighthouse, FID, TTI, CLS, อุปกรณ์
2. การตั้งเป้าหมายที่สมจริง
   งบประมาณประสิทธิภาพ เป้าหมายประสิทธิภาพ เฟรมเวิร์ก RAIL งบประมาณ 170KB/30KB
3. การกำหนดสภาพแวดล้อม
   การเลือกเฟรมเวิร์ก, ต้นทุนประสิทธิภาพพื้นฐาน, Webpack, การพึ่งพา, CDN, สถาปัตยกรรมส่วนหน้า, CSR, SSR, CSR + SSR, การเรนเดอร์สแตติก, การเรนเดอร์ล่วงหน้า, รูปแบบ PRPL
4. การเพิ่มประสิทธิภาพสินทรัพย์
   Brotli, AVIF, WebP, รูปภาพที่ตอบสนอง, AV1, การโหลดสื่อที่ปรับเปลี่ยนได้, การบีบอัดวิดีโอ, แบบอักษรเว็บ, แบบอักษร Google
5. สร้างการเพิ่มประสิทธิภาพ
   โมดูล JavaScript, รูปแบบโมดูล/โนโมดูล, การสั่นต้นไม้, การแยกโค้ด, การยกขอบเขต, Webpack, การให้บริการที่แตกต่างกัน, ผู้ปฏิบัติงานบนเว็บ, WebAssembly, กลุ่ม JavaScript, React, SPA, ความชุ่มชื้นบางส่วน, การนำเข้าจากการโต้ตอบ, บุคคลที่สาม, แคช
6. การเพิ่มประสิทธิภาพการจัดส่ง
   โหลดช้า, ผู้สังเกตการณ์ทางแยก, เลื่อนการแสดงผลและถอดรหัส, CSS ที่สำคัญ, การสตรีม, คำแนะนำทรัพยากร, การเปลี่ยนเลย์เอาต์, พนักงานบริการ
7. เครือข่าย, HTTP/2, HTTP/3
   เย็บกระดาษ OCSP, ใบรับรอง EV/DV, บรรจุภัณฑ์, IPv6, QUIC, HTTP/3
8. การทดสอบและการตรวจสอบ
   เวิร์กโฟลว์การตรวจสอบ, เบราว์เซอร์พร็อกซี่, หน้า 404, ข้อความแจ้งความยินยอมของคุกกี้ GDPR, CSS การวินิจฉัยประสิทธิภาพ, การเข้าถึง
9. ชนะอย่างรวดเร็ว
10. ทุกอย่างในหน้าเดียว
11. ดาวน์โหลดรายการตรวจสอบ (PDF, Apple Pages, MS Word)
12. สมัครรับจดหมายข่าวทางอีเมลของเราเพื่อไม่ให้พลาดคำแนะนำต่อไป

เตรียมตัวให้พร้อม: การวางแผนและการวัดผล

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

1. สร้างวัฒนธรรมการแสดง
   ในหลายองค์กร นักพัฒนาส่วนหน้ารู้ว่าปัญหาพื้นฐานทั่วไปคืออะไร และควรใช้กลยุทธ์ใดในการแก้ไขปัญหา อย่างไรก็ตาม ตราบใดที่ยังไม่มีการรับรองวัฒนธรรมการปฏิบัติงาน การตัดสินใจแต่ละครั้งจะกลายเป็นสนามรบของแผนกต่างๆ แบ่งองค์กรออกเป็นไซโล คุณต้องซื้อผู้มีส่วนได้ส่วนเสียทางธุรกิจ และเพื่อให้ได้มานี้ คุณต้องสร้างกรณีศึกษาหรือหลักฐานของแนวคิดเกี่ยวกับความเร็ว — โดยเฉพาะ Core Web Vitals ที่เราจะกล่าวถึงในรายละเอียดในภายหลัง — ตัวชี้วัดประโยชน์และตัวชี้วัดประสิทธิภาพหลัก ( KPIs ) ที่พวกเขาใส่ใจ

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

   หากปราศจากความสอดคล้องกันระหว่างทีมพัฒนา/ออกแบบและธุรกิจ/การตลาด ประสิทธิภาพจะไม่คงอยู่ในระยะยาว ศึกษาข้อร้องเรียนทั่วไปที่เข้ามาในฝ่ายบริการลูกค้าและทีมขาย ศึกษาการวิเคราะห์สำหรับอัตราตีกลับที่สูงและการลดลงของ Conversion สำรวจว่าการปรับปรุงประสิทธิภาพสามารถช่วยบรรเทาปัญหาทั่วไปเหล่านี้ได้อย่างไร ปรับอาร์กิวเมนต์ขึ้นอยู่กับกลุ่มผู้มีส่วนได้ส่วนเสียที่คุณกำลังพูดด้วย

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

   วิธีการเดินทาง? ในการพูดคุยของเธอเกี่ยวกับการสร้างประสิทธิภาพสำหรับระยะยาว Allison McKnight ได้แบ่งปันกรณีศึกษาที่ครอบคลุมถึงวิธีที่เธอช่วยสร้างวัฒนธรรมการแสดงที่ Etsy (สไลด์) เมื่อไม่นานมานี้ Tammy Everts ได้พูดถึงนิสัยของทีมที่มีประสิทธิภาพสูงทั้งในองค์กรขนาดเล็กและขนาดใหญ่

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

1. เป้าหมาย: เร็วกว่าคู่แข่งที่เร็วที่สุดของคุณอย่างน้อย 20%
   จากการวิจัยทางจิตวิทยา หากคุณต้องการให้ผู้ใช้รู้สึกว่าเว็บไซต์ของคุณเร็วกว่าเว็บไซต์ของคู่แข่ง คุณจะต้องเร็วกว่า อย่างน้อย 20% ศึกษาคู่แข่งหลักของคุณ รวบรวมตัวชี้วัดว่าพวกเขาทำงานอย่างไรบนมือถือและเดสก์ท็อป และตั้งเกณฑ์ที่จะช่วยให้คุณแซงหน้าพวกเขา เพื่อให้ได้ผลลัพธ์และเป้าหมายที่ถูกต้อง ก่อนอื่นต้องแน่ใจว่าได้เห็นภาพประสบการณ์ของผู้ใช้อย่างละเอียดโดยศึกษาการวิเคราะห์ของคุณ จากนั้น คุณสามารถเลียนแบบประสบการณ์ของเปอร์เซ็นไทล์ที่ 90 สำหรับการทดสอบได้

   คุณสามารถใช้ Chrome UX Report ( CrUX ชุดข้อมูล RUM สำเร็จรูป วิดีโอแนะนำโดย Ilya Grigorik และคำแนะนำโดยละเอียดโดย Rick Viscomi) หรือ Treo เครื่องมือตรวจสอบ RUM ขับเคลื่อนโดยรายงาน Chrome UX ข้อมูลถูกรวบรวมจากผู้ใช้เบราว์เซอร์ Chrome ดังนั้นรายงานจะเป็นแบบเฉพาะสำหรับ Chrome แต่รายงานเหล่านี้จะช่วยให้คุณมีการกระจายประสิทธิภาพที่ละเอียดถี่ถ้วน ที่สำคัญที่สุดคือคะแนน Core Web Vitals สำหรับผู้เยี่ยมชมที่หลากหลาย โปรดทราบว่าชุดข้อมูล CrUX ใหม่จะออกใน วันอังคารที่สองของแต่ละเดือน

   หรือคุณสามารถใช้:

   • เครื่องมือเปรียบเทียบรายงาน Chrome UX ของ Addy Osmani
   • Speed ​​Scorecard (ยังมีตัวประมาณผลกระทบด้านรายได้)
   • การเปรียบเทียบการทดสอบประสบการณ์ผู้ใช้จริงหรือ
   • SiteSpeed ​​CI (อิงจากการทดสอบสังเคราะห์)

   หมายเหตุ : หากคุณใช้ Page Speed ​​Insights หรือ Page Speed ​​Insights API (ไม่ ไม่มีการเลิกใช้งาน!) คุณจะได้รับข้อมูลประสิทธิภาพ CrUX สำหรับหน้าใดหน้าหนึ่ง แทนที่จะเป็นเพียงการรวม ข้อมูลนี้อาจมีประโยชน์มากขึ้นในการกำหนดเป้าหมายด้านประสิทธิภาพสำหรับเนื้อหา เช่น "หน้า Landing Page" หรือ "รายการผลิตภัณฑ์" และหากคุณใช้ CI เพื่อทดสอบงบประมาณ คุณต้องแน่ใจว่าสภาพแวดล้อมที่ทดสอบของคุณตรงกับ CrUX หากคุณใช้ CrUX ในการกำหนดเป้าหมาย ( ขอบคุณ Patrick Meenan! )

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

   

   

   บางครั้งคุณอาจต้องการเจาะลึกลงไปอีกเล็กน้อย โดยการรวมข้อมูลที่มาจาก CrUX กับข้อมูลอื่นๆ ที่คุณต้องดำเนินการอย่างรวดเร็วในจุดที่เกิดการชะลอตัว จุดบอด และความไร้ประสิทธิภาพ - สำหรับคู่แข่งของคุณหรือสำหรับโครงการของคุณ ในงานของเขา แฮร์รี่ โรเบิร์ตส์ใช้สเปรดชีตภูมิประเทศความเร็วไซต์ ซึ่งเขาใช้ในการแบ่งประสิทธิภาพตามประเภทเพจหลัก และติดตามว่าเมตริกหลักต่างๆ แตกต่างกันอย่างไร คุณสามารถดาวน์โหลดสเปรดชีตเป็น Google ชีต, Excel, เอกสาร OpenOffice หรือ CSV

   

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

   

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

   ต้องการทรัพยากรเพื่อเริ่มต้น?

   • Addy Osmani ได้เขียนบทความโดยละเอียดเกี่ยวกับวิธีเริ่มต้นการจัดทำงบประมาณประสิทธิภาพ วิธีวัดผลกระทบของคุณลักษณะใหม่ และจุดเริ่มต้นเมื่อคุณใช้งบประมาณเกิน
   • คู่มือของ Lara Hogan เกี่ยวกับวิธีการออกแบบด้วยงบประมาณด้านประสิทธิภาพสามารถให้คำแนะนำที่เป็นประโยชน์แก่นักออกแบบได้
   • Harry Roberts ได้เผยแพร่คู่มือการตั้งค่า Google ชีตเพื่อแสดงผลกระทบของสคริปต์ของบุคคลที่สามที่มีต่อประสิทธิภาพ โดยใช้ Request Map
   • เครื่องคำนวณงบประมาณด้านประสิทธิภาพของ Jonathan Fielding เครื่องคำนวณงบประมาณที่สมบูรณ์แบบของ Katie Hempenius และแคลอรี่ของเบราว์เซอร์สามารถช่วยในการสร้างงบประมาณได้ (ขอบคุณ Karolina Szczur สำหรับการเตือนล่วงหน้า)
   • ในหลายบริษัท งบประมาณด้านประสิทธิภาพไม่ควรเป็นแรงบันดาลใจ แต่ควรนำไปใช้ได้จริง เพื่อเป็นสัญญาณบ่งชี้เพื่อหลีกเลี่ยงไม่ให้ผ่านจุดใดจุดหนึ่ง ในกรณีนั้น คุณสามารถเลือกจุดข้อมูลที่เลวร้ายที่สุดในช่วงสองสัปดาห์ที่ผ่านมาเป็นเกณฑ์ แล้วนำจุดข้อมูลนั้นออกจากจุดนั้น งบประมาณประสิทธิภาพ แสดงกลยุทธ์เพื่อให้บรรลุผลในทางปฏิบัติในทางปฏิบัติ
   • อีกทั้งทำให้ทั้งงบประมาณประสิทธิภาพและประสิทธิภาพปัจจุบัน มองเห็นได้ โดยการตั้งค่าแดชบอร์ดพร้อมกราฟขนาดการสร้างการรายงาน มีเครื่องมือมากมายที่ช่วยให้คุณบรรลุเป้าหมายดังกล่าว: แดชบอร์ด SiteSpeed.io (โอเพ่นซอร์ส) SpeedCurve และ Caliber เป็นเพียงไม่กี่เครื่องมือ และคุณสามารถหาเครื่องมือเพิ่มเติมบน perf.rocks

   

   เมื่อคุณมีงบประมาณแล้ว ให้รวมไว้ในขั้นตอนการสร้างของคุณด้วย Webpack Performance Hints and Bundlesize, Lighthouse CI, PWMetrics หรือ Sitespeed CI เพื่อบังคับใช้งบประมาณในคำขอดึงและจัดทำประวัติคะแนนในความคิดเห็นของ PR

   หากต้องการเปิดเผยงบประมาณด้านประสิทธิภาพให้กับทั้งทีม ให้รวมงบประมาณประสิทธิภาพใน Lighthouse ผ่าน Lightwallet หรือใช้ LHCI Action สำหรับการผสานรวม Github Actions อย่างรวดเร็ว และถ้าคุณต้องการสิ่งที่กำหนดเอง คุณสามารถใช้ webPagetest-charts-api ซึ่งเป็น API ของปลายทางเพื่อสร้างแผนภูมิจากผลลัพธ์ WebPagetest

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

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

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

   ตามที่ Patrick Meenan แนะนำ คุณควร วางแผนลำดับการโหลดและการแลกเปลี่ยน ระหว่างกระบวนการออกแบบ หากคุณจัดลำดับความสำคัญแต่เนิ่นๆ ว่าส่วนใดมีความสำคัญมากกว่า และกำหนดลำดับที่ส่วนเหล่านั้นควรปรากฏ คุณจะรู้ด้วยว่าสิ่งใดที่อาจล่าช้าได้ ตามหลักการแล้ว ลำดับดังกล่าวจะสะท้อนถึงลำดับการนำเข้า CSS และ JavaScript ของคุณ ดังนั้นการจัดการระหว่างกระบวนการสร้างจะง่ายขึ้น นอกจากนี้ ให้พิจารณาว่าประสบการณ์การมองเห็นควรเป็นอย่างไรในสถานะ "ระหว่าง" ในขณะที่กำลังโหลดหน้าเว็บ (เช่น เมื่อยังไม่ได้โหลดแบบอักษรของเว็บ)

   เมื่อคุณได้สร้างวัฒนธรรมการปฏิบัติงานที่แข็งแกร่งในองค์กรของคุณแล้ว ให้ตั้งเป้าว่าจะต้อง เร็วกว่าตัวตนเดิมของคุณ 20% เพื่อรักษาลำดับความสำคัญไว้เมื่อเวลาผ่านไป ( ขอบคุณ Guy Podjarny! ) แต่ให้คำนึงถึงประเภทและพฤติกรรมการใช้งานที่แตกต่างกันของลูกค้าของคุณ (ซึ่ง Tobias Baldauf เรียกว่า cadence และ cohorts) พร้อมกับปริมาณการใช้บอทและผลกระทบตามฤดูกาล

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

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

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

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

   • เมตริกตาม ปริมาณจะวัดจำนวนคำขอ น้ำหนัก และคะแนนประสิทธิภาพ เหมาะสำหรับการเตือนและตรวจสอบการเปลี่ยนแปลงเมื่อเวลาผ่านไป ไม่ดีสำหรับการทำความเข้าใจประสบการณ์ของผู้ใช้
   • เมตริก Milestone ใช้สถานะในช่วงอายุของกระบวนการโหลด เช่น Time To First Byte และ Time To Interactive เหมาะสำหรับการอธิบายประสบการณ์ของผู้ใช้และการตรวจสอบ ไม่ดีนักสำหรับการรู้ว่าเกิดอะไรขึ้นระหว่างเหตุการณ์สำคัญ
   • การวัดการแสดงผล จะให้ค่าประมาณความเร็วในการแสดงเนื้อหา (เช่น เวลา เริ่มการเรนเดอ ร์ ดัชนีความเร็ว ) ดีสำหรับการวัดและปรับแต่งประสิทธิภาพการเรนเดอร์ แต่ไม่ดีสำหรับการวัดเมื่อเนื้อหา สำคัญ ปรากฏขึ้นและสามารถโต้ตอบได้
   • ตัววัดแบบกำหนดเองจะ วัดเหตุการณ์เฉพาะ เหตุการณ์ที่กำหนดเองสำหรับผู้ใช้ เช่น Twitter's Time To First Tweet และ PinnerWaitTime ของ Pinterest ดีสำหรับการอธิบายประสบการณ์ผู้ใช้อย่างแม่นยำ ไม่ดีสำหรับการปรับขนาดตัวชี้วัดและเปรียบเทียบกับคู่แข่ง

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

   • เวลาในการโต้ตอบ (TTI)
     จุดที่เลย์เอาต์มี เสถียรภาพ มองเห็นคีย์เว็บฟอนต์ และเธรดหลักพร้อมใช้งานเพียงพอที่จะจัดการกับอินพุตของผู้ใช้ โดยพื้นฐานแล้วจะเป็นเครื่องหมายเวลาที่ผู้ใช้สามารถโต้ตอบกับ UI ได้ ตัวชี้วัดที่สำคัญสำหรับการทำความเข้าใจว่าผู้ใช้ ต้องรอนาน เพียงใดเพื่อใช้เว็บไซต์โดยไม่เกิดความล่าช้า Boris Schapira ได้เขียนโพสต์โดยละเอียดเกี่ยวกับวิธีการวัด TTI อย่างน่าเชื่อถือ
   • First Input Delay (FID) หรือการ ตอบสนองต่ออินพุต
     เวลาที่ผู้ใช้โต้ตอบกับไซต์ของคุณเป็นครั้งแรกจนถึงเวลาที่เบราว์เซอร์ สามารถตอบสนองต่อ การโต้ตอบนั้นได้จริง ช่วยเสริม TTI ได้เป็นอย่างดีเนื่องจากอธิบายส่วนที่ขาดหายไปของรูปภาพ: จะเกิดอะไรขึ้นเมื่อผู้ใช้โต้ตอบกับไซต์จริง ตั้งใจให้เป็นตัวชี้วัด RUM เท่านั้น มีไลบรารี JavaScript สำหรับวัด FID ในเบราว์เซอร์
   • Largest Contentful Paint (LCP)
     ทำเครื่องหมายจุดในไทม์ไลน์การโหลดหน้าเว็บเมื่อ เนื้อหาสำคัญ ของหน้าน่าจะโหลดขึ้น สมมติฐานคือองค์ประกอบที่สำคัญที่สุดของหน้าคือองค์ประกอบที่ใหญ่ที่สุดที่มองเห็นได้ในวิวพอร์ตของผู้ใช้ หากองค์ประกอบแสดงทั้งด้านบนและด้านล่างครึ่งหน้าล่าง จะถือว่าเฉพาะส่วนที่มองเห็นได้เท่านั้นที่เกี่ยวข้อง
   • เวลาบล็อคทั้งหมด ( TBT )
     ตัวชี้วัดที่ช่วยวัดปริมาณ ความรุนแรงของการที่หน้าไม่มีการโต้ตอบ ก่อนที่จะมีการโต้ตอบที่เชื่อถือได้ (นั่นคือ เธรดหลักไม่มีงานใดๆ ที่ทำงานเกิน 50 มิลลิวินาที ( งานยาว ) เป็นเวลาอย่างน้อย 5 วินาที) เมตริกจะวัดระยะเวลาทั้งหมดระหว่างการระบายสีครั้งแรกกับ Time to Interactive (TTI) ที่เธรดหลักถูกบล็อกนานพอที่จะป้องกันการตอบสนองอินพุต ไม่น่าแปลกใจเลยที่ TBT ที่ต่ำเป็นตัวบ่งชี้ที่ดีสำหรับประสิทธิภาพที่ดี (ขอบคุณ อาร์เทม ฟิล)
   • การเปลี่ยนแปลงเค้าโครงสะสม ( CLS )
     เมตริกเน้นว่าผู้ใช้พบ การเปลี่ยนแปลงรูปแบบ ที่ไม่คาดคิดบ่อยเพียงใด ( reflows ) เมื่อเข้าถึงไซต์ โดยจะตรวจสอบองค์ประกอบ ที่ไม่เสถียร และผลกระทบต่อประสบการณ์โดยรวม คะแนนยิ่งน้อยยิ่งดี
   • ดัชนีความเร็ว
     วัดความเร็วที่เนื้อหาของหน้าถูกเติมด้วยสายตา ยิ่งคะแนนต่ำยิ่งดี คะแนนดัชนีความเร็วคำนวณตาม ความเร็วของความคืบหน้าของภาพ แต่เป็นเพียงค่าที่คำนวณได้ นอกจากนี้ยังมีความละเอียดอ่อนต่อขนาดวิวพอร์ต ดังนั้นคุณต้องกำหนดช่วงของการกำหนดค่าการทดสอบที่ตรงกับผู้ชมเป้าหมายของคุณ โปรดทราบว่า LCP มีความสำคัญน้อยลงเมื่อกลายเป็นตัวชี้วัดที่เกี่ยวข้องมากขึ้น ( ขอบคุณ Boris, Artem! )
   • เวลา CPU ที่ใช้ไป
     ตัวชี้วัดที่แสดง ความถี่ และ ระยะเวลา ที่เธรดหลักถูกบล็อก การทำงานกับการวาดภาพ การแสดงผล การเขียนสคริปต์ และการโหลด เวลา CPU ที่สูงเป็นตัวบ่งชี้ที่ชัดเจนของประสบการณ์ที่ แย่ เช่น เมื่อผู้ใช้พบกับความล่าช้าที่เห็นได้ชัดเจนระหว่างการกระทำและการตอบสนอง ด้วย WebPageTest คุณสามารถเลือก "Capture Dev Tools Timeline" บนแท็บ "Chrome" เพื่อแสดงรายละเอียดของเธรดหลักขณะทำงานบนอุปกรณ์ใดๆ ก็ตามที่ใช้ WebPageTest
   • ค่าใช้จ่าย CPU ระดับส่วนประกอบ
     เช่นเดียวกับ เวลา CPU ที่ใช้ ตัววัดนี้เสนอโดย Stoyan Stefanov สำรวจ ผลกระทบของ JavaScript บน CPU แนวคิดคือการใช้จำนวนคำสั่ง CPU ต่อส่วนประกอบเพื่อทำความเข้าใจผลกระทบต่อประสบการณ์โดยรวมโดยแยกส่วน สามารถใช้งานได้โดยใช้ Puppeteer และ Chrome
   • ดัชนีความผิดหวัง
     แม้ว่าเมตริกหลายตัวที่แสดงด้านบนจะอธิบายเมื่อมีเหตุการณ์หนึ่งเกิดขึ้น FrustrationIndex ของ Tim Vereecke จะพิจารณา ช่องว่าง ระหว่างเมตริกแทนที่จะดูทีละรายการ จะพิจารณาเหตุการณ์สำคัญที่ผู้ใช้ปลายทางรับรู้ เช่น มองเห็นชื่อเรื่อง มองเห็นเนื้อหาแรก มองเห็นได้ชัดเจน และหน้าดูพร้อม และคำนวณคะแนนซึ่งระบุระดับความหงุดหงิดขณะโหลดหน้า ยิ่งช่องว่างมากเท่าไร โอกาสที่ผู้ใช้จะหงุดหงิดก็ยิ่งมากขึ้นเท่านั้น อาจเป็น KPI ที่ดีสำหรับประสบการณ์ผู้ใช้ Tim ได้เผยแพร่โพสต์โดยละเอียดเกี่ยวกับ FrustrationIndex และวิธีการทำงาน
   • ผลกระทบของน้ำหนักโฆษณา
     หากไซต์ของคุณขึ้นอยู่กับรายได้ที่เกิดจากการโฆษณา จะเป็นประโยชน์ในการติดตามน้ำหนักของโค้ดที่เกี่ยวข้องกับโฆษณา สคริปต์ของ Paddy Ganti สร้าง URL สองรายการ (หนึ่งรายการปกติและอีกรายการหนึ่งบล็อกโฆษณา) ให้สร้างการเปรียบเทียบวิดีโอผ่าน WebPageTest และรายงานเดลต้า
   • ตัวชี้วัดความเบี่ยงเบน
     ตามที่วิศวกรของ Wikipedia ระบุไว้ ข้อมูล ความแปรปรวน ที่มีอยู่ในผลลัพธ์ของคุณสามารถแจ้งให้คุณทราบว่าเครื่องมือของคุณมีความน่าเชื่อถือเพียงใด และคุณควรให้ความสนใจเท่าใดต่อการเบี่ยงเบนและส่วนนอก ความแปรปรวนมากเป็นตัวบ่งชี้ถึงการปรับเปลี่ยนที่จำเป็นในการตั้งค่า นอกจากนี้ยังช่วยให้เข้าใจว่าบางหน้าวัดได้ยากกว่าหรือไม่ เช่น เนื่องจากสคริปต์ของบุคคลที่สามทำให้เกิดการเปลี่ยนแปลงที่สำคัญ อาจเป็นความคิดที่ดีที่จะติดตามเวอร์ชันของเบราว์เซอร์เพื่อทำความเข้าใจการกระแทกของประสิทธิภาพเมื่อมีการเปิดตัวเบราว์เซอร์เวอร์ชันใหม่
   • เมตริกที่กำหนดเอง
     เมตริกที่กำหนดเองถูกกำหนดโดยความต้องการทางธุรกิจและประสบการณ์ของลูกค้า คุณต้องระบุพิกเซลที่ สำคัญ สคริปต์ ที่สำคัญ CSS ที่จำเป็น และเนื้อหาที่ เกี่ยวข้อง และวัดว่าส่งไปยังผู้ใช้ได้เร็วเพียงใด คุณสามารถตรวจสอบ Hero Rendering Times หรือใช้ Performance API เพื่อทำเครื่องหมายการประทับเวลาเฉพาะสำหรับกิจกรรมที่สำคัญสำหรับธุรกิจของคุณ นอกจากนี้ คุณยังสามารถรวบรวมเมตริกที่กำหนดเองด้วย WebPagetest โดยเรียกใช้ JavaScript ตามอำเภอใจเมื่อสิ้นสุดการทดสอบ

   โปรดทราบว่า First Meaningful Paint (FMP) ไม่ปรากฏในภาพรวมด้านบน ใช้เพื่อให้ข้อมูลเชิงลึกว่าเซิร์ฟเวอร์ส่งออกข้อมูลได้เร็วเพียง ใด โดยทั่วไปแล้ว Long FMP จะระบุว่า JavaScript บล็อกเธรดหลัก แต่อาจเกี่ยวข้องกับปัญหาแบ็คเอนด์/เซิร์ฟเวอร์เช่นกัน อย่างไรก็ตาม เมตริกนี้เลิกใช้งานแล้วเมื่อเร็วๆ นี้ เนื่องจากดูเหมือนว่าจะไม่ถูกต้องในประมาณ 20% ของกรณีทั้งหมด มันถูกแทนที่ด้วย LCP อย่างมีประสิทธิภาพซึ่งมีความน่าเชื่อถือมากกว่าและให้เหตุผลง่ายกว่า ไม่รองรับใน Lighthouse อีกต่อไป ตรวจสอบเมตริกและคำแนะนำประสิทธิภาพที่เน้นผู้ใช้เป็นศูนย์กลางล่าสุดอีกครั้ง เพื่อให้แน่ใจว่าคุณอยู่ในหน้าที่ปลอดภัย ( ขอบคุณ Patrick Meenan )

   

   Steve Souders มีคำอธิบายโดยละเอียดเกี่ยวกับเมตริกเหล่านี้จำนวนมาก สิ่งสำคัญคือต้องสังเกตว่าแม้ว่า Time-To-Interactive จะถูกวัดโดยการเรียกใช้การตรวจสอบอัตโนมัติใน สภาพแวดล้อมห้องปฏิบัติการ ที่เรียกว่า First Input Delay แสดงถึงประสบการณ์ของผู้ใช้ จริง โดยที่ผู้ใช้ จริง ประสบกับความล่าช้าที่เห็นได้ชัดเจน โดยทั่วไป คุณควรวัดและติดตามทั้งคู่เสมอ

   เมตริกที่ต้องการอาจแตกต่างกันไปตามบริบทของแอปพลิเคชัน เช่น สำหรับ UI ของ Netflix TV การตอบสนองของคีย์ การใช้หน่วยความจำและ TTI มีความสำคัญมากกว่า และสำหรับวิกิพีเดีย การเปลี่ยนแปลงภาพแรก/สุดท้าย และเมตริกเวลาที่ใช้ CPU มีความสำคัญมากกว่า

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

1. วัดผลและเพิ่มประสิทธิภาพ Core Web Vitals
   มาเป็นเวลานาน ตัวชี้วัดประสิทธิภาพค่อนข้างเป็นเทคนิค โดยเน้นที่มุมมองทางวิศวกรรมว่าเซิร์ฟเวอร์ตอบสนองเร็วเพียงใด และเบราว์เซอร์โหลดเร็วเพียงใด ตัวชี้วัดมีการเปลี่ยนแปลงตลอดหลายปีที่ผ่านมา — พยายามหาวิธีที่จะบันทึกประสบการณ์ของผู้ใช้ จริง มากกว่าการกำหนดเวลาของเซิร์ฟเวอร์ ในเดือนพฤษภาคม 2020 Google ได้ประกาศ Core Web Vitals ซึ่งเป็นชุดเมตริกประสิทธิภาพที่เน้นผู้ใช้ใหม่ โดยแต่ละรายการจะนำเสนอแง่มุมที่แตกต่างกันของประสบการณ์ผู้ใช้

   สำหรับแต่ละรายการ Google แนะนำช่วงเป้าหมายความเร็วที่ยอมรับได้ อย่างน้อย 75% ของการดูหน้าเว็บทั้งหมด ควรเกิน ช่วงที่ดี เพื่อผ่านการประเมินนี้ เมตริกเหล่านี้ได้รับความสนใจอย่างรวดเร็ว และเมื่อ Core Web Vitals กลายเป็นสัญญาณการจัดอันดับสำหรับ Google Search ในเดือนพฤษภาคม 2021 ( การอัปเดตอัลกอริธึมการจัดอันดับ Page Experience ) บริษัทหลายแห่งหันความสนใจไปที่คะแนนประสิทธิภาพของตน

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

   • Largest Contentful Paint ( LCP ) < 2.5 วินาที
     วัดการ โหลด หน้า และรายงานเวลาแสดงผลของ รูปภาพหรือบล็อกข้อความที่ใหญ่ที่สุด ที่มองเห็นได้ภายในวิวพอร์ต ดังนั้น LCP ได้รับผลกระทบจากทุกสิ่งที่ขัดขวางการแสดงข้อมูลสำคัญ — ไม่ว่าจะเป็นเวลาตอบสนองของเซิร์ฟเวอร์ที่ช้า, การบล็อก CSS, JavaScript บนเครื่องบิน (บุคคลที่หนึ่งหรือบุคคลที่สาม), การโหลดฟอนต์ของเว็บ, การดำเนินการเรนเดอร์หรือระบายสีที่มีราคาแพง, ขี้เกียจ -โหลดรูปภาพ หน้าจอโครงกระดูก หรือการแสดงผลฝั่งไคลเอ็นต์
     
     เพื่อประสบการณ์ที่ดี LCP ควรเกิดขึ้น ภายใน 2.5 วินาทีนับ จากที่หน้าเริ่มโหลดครั้งแรก ซึ่งหมายความว่าเราต้องแสดงส่วนแรกที่มองเห็นได้ของหน้าเว็บโดยเร็วที่สุด ซึ่งจะต้องใช้ CSS ที่สำคัญที่ปรับแต่งสำหรับแต่ละเทมเพลต จัดการ <head> -order และดึงเนื้อหาที่สำคัญล่วงหน้า (เราจะพูดถึงในภายหลัง)

     สาเหตุหลักที่ทำให้คะแนน LCP ต่ำมักเกิดจากรูปภาพ ในการส่ง LCP ใน <2.5 วินาทีบน Fast 3G ซึ่งโฮสต์บนเซิร์ฟเวอร์ที่ได้รับการปรับแต่งมาอย่างดี ทั้งหมดเป็นแบบสแตติกโดยไม่มีการเรนเดอร์ฝั่งไคลเอ็นต์และด้วยภาพที่มาจาก CDN อิมเมจเฉพาะ หมายความว่า ขนาดภาพตามทฤษฎีสูงสุดอยู่ที่ประมาณ 144KB เท่านั้น นั่นเป็นสาเหตุที่รูปภาพที่ตอบสนองมีความสำคัญ รวมถึงการโหลดรูปภาพที่สำคัญล่วงหน้าล่วงหน้า (ด้วย preload )

     เคล็ดลับด่วน : หากต้องการทราบสิ่งที่ถือว่าเป็น LCP บนหน้าเว็บ ใน DevTools คุณสามารถวางเมาส์เหนือป้าย LCP ใต้ "การกำหนดเวลา" ในแผงประสิทธิภาพ ( ขอบคุณ Tim Kadec !)

   • First Input Delay ( FID ) < 100ms.
     วัดการ ตอบสนอง ของ UI เช่น ระยะเวลาที่เบราว์เซอร์ยุ่ง กับงานอื่นๆ ก่อนที่มันจะตอบสนองต่อเหตุการณ์การป้อนข้อมูลของผู้ใช้ที่ไม่ต่อเนื่อง เช่น การแตะหรือการคลิก ได้รับการออกแบบมาเพื่อบันทึกความล่าช้าที่เกิดจากเธรดหลักไม่ว่าง โดยเฉพาะอย่างยิ่งในระหว่างการโหลดหน้าเว็บ
     
     เป้าหมายคืออยู่ภายใน 50-100ms สำหรับทุกการโต้ตอบ ในการไปถึงจุดนั้น เราจำเป็นต้องระบุงานที่ยาว (บล็อกเธรดหลักเป็นเวลา >50 มิลลิวินาที) และแยกส่วน แยกโค้ดเป็นกลุ่มเป็นหลายๆ ชิ้น ลดเวลาดำเนินการ JavaScript เพิ่มประสิทธิภาพการดึงข้อมูล เลื่อนการดำเนินการสคริปต์ของบุคคลที่สาม ย้าย JavaScript ไปยังเธรดพื้นหลังด้วย Web Worker และใช้การไฮเดรชั่นแบบก้าวหน้าเพื่อลดต้นทุนการคืนสภาพใน SPA

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

   • การเปลี่ยนแปลงเค้าโครงสะสม ( CLS ) < 0.1
     วัด ความเสถียรทางสายตา ของ UI เพื่อให้แน่ใจว่ามีการโต้ตอบที่ราบรื่นและเป็นธรรมชาติ กล่าวคือ ผลรวมของคะแนนการเปลี่ยนเลย์เอาต์แต่ละรายการสำหรับการเปลี่ยนเลย์เอาต์ที่ไม่คาดคิดทุกครั้งที่เกิดขึ้นในช่วงอายุของเพจ การเปลี่ยนเลย์เอาต์แต่ละรายการเกิดขึ้นทุกครั้งที่องค์ประกอบที่มองเห็นได้เปลี่ยนตำแหน่งบนเพจ คะแนนขึ้นอยู่กับขนาดของเนื้อหาและระยะทางที่เคลื่อนย้าย
     
     ดังนั้นทุกครั้งที่มีกะปรากฏขึ้น — เช่น เมื่อฟอนต์สำรองและฟอนต์เว็บมีการวัดฟอนต์ที่แตกต่างกัน หรือโฆษณา การฝัง หรือ iframes มาช้า หรือขนาดรูปภาพ/วิดีโอไม่ได้รับการสงวนไว้ หรือ CSS ที่ล่าช้าในการทาสีใหม่ หรือการเปลี่ยนแปลงถูกแทรกโดย JavaScript ตอนปลาย — มันมีผลกระทบต่อคะแนน CLS ค่าที่แนะนำสำหรับประสบการณ์ที่ดีคือ CLS < 0.1

   เป็นที่น่าสังเกตว่า Core Web Vitals ควรจะพัฒนาเมื่อเวลาผ่านไป ด้วย วัฏจักรรายปีที่คาดการณ์ ได้ สำหรับการอัปเดตในปีแรก เราอาจคาดหวังให้ First Contentful Paint ได้รับการโปรโมตเป็น Core Web Vitals, เกณฑ์ FID ที่ลดลง และการสนับสนุนที่ดีขึ้นสำหรับแอปพลิเคชันหน้าเดียว เราอาจเห็นการตอบสนองต่ออินพุตของผู้ใช้หลังจากที่โหลดได้รับน้ำหนักมากขึ้น พร้อมกับข้อควรพิจารณาด้านความปลอดภัย ความเป็นส่วนตัว และการเข้าถึง (!)

   ที่เกี่ยวข้องกับ Core Web Vitals มีแหล่งข้อมูลและบทความที่เป็นประโยชน์มากมายที่ควรค่าแก่การพิจารณา:

   • ลีดเดอร์บอร์ด Web Vitals ช่วยให้คุณเปรียบเทียบคะแนนของคุณกับการแข่งขันบนมือถือ แท็บเล็ต เดสก์ท็อป และบน 3G และ 4G
   • Core SERP Vitals ซึ่งเป็นส่วนขยายของ Chrome ที่แสดง Core Web Vitals จาก CrUX ในผลการค้นหาของ Google
   • Layout Shift GIF Generator ที่แสดงภาพ CLS ด้วย GIF แบบง่าย (มีให้ในบรรทัดคำสั่งด้วย)
   • ไลบรารี web-vitals สามารถรวบรวมและส่ง Core Web Vitals ไปยัง Google Analytics, Google Tag Manager หรือจุดสิ้นสุดการวิเคราะห์อื่นๆ
   • วิเคราะห์ Web Vitals ด้วย WebPageTest ซึ่ง Patrick Meenan สำรวจว่า WebPageTest เปิดเผยข้อมูลเกี่ยวกับ Core Web Vitals อย่างไร
   • การเพิ่มประสิทธิภาพด้วย Core Web Vitals ซึ่งเป็นวิดีโอความยาว 50 นาทีด้วย Addy Osmani ซึ่งเขาเน้นย้ำถึงวิธีปรับปรุง Core Web Vitals ในกรณีศึกษาอีคอมเมิร์ซ
   • Cumulative Layout Shift in Practice และ Cumulative Layout Shift ในโลกแห่งความเป็นจริงเป็นบทความที่ครอบคลุมโดย Nic Jansma ซึ่งครอบคลุมแทบทุกอย่างเกี่ยวกับ CLS และความสัมพันธ์กับเมตริกหลัก เช่น อัตราตีกลับ เวลาเซสชัน หรือ Rage Clicks
   • สิ่งที่บังคับให้ Reflow พร้อมภาพรวมของคุณสมบัติหรือเมธอด เมื่อมีการร้องขอ/เรียกใช้ใน JavaScript ที่จะทริกเกอร์เบราว์เซอร์ให้คำนวณสไตล์และเลย์เอาต์แบบซิงโครนัส
   • CSS Triggers แสดงว่าคุณสมบัติ CSS ใดที่เรียก Layout, Paint และ Composite
   • การแก้ไขความไม่เสถียรของเลย์เอาต์เป็นแนวทางในการใช้ WebPageTest เพื่อระบุและแก้ไขปัญหาความไม่เสถียรของเลย์เอาต์
   • Cumulative Layout Shift, The Layout Instability Metric, อีกหนึ่งคำแนะนำโดยละเอียดโดย Boris Schapira บน CLS, วิธีคำนวณ, วิธีวัดและวิธีปรับให้เหมาะสม
   • วิธีปรับปรุง Core Web Vitals ซึ่งเป็นคำแนะนำโดยละเอียดโดย Simon Hearne เกี่ยวกับเมตริกแต่ละรายการ (รวมถึง Web Vitals อื่นๆ เช่น FCP, TTI, TBT) เมื่อใดและจะวัดได้อย่างไร

   ดังนั้น Core Web Vitals เป็น ตัวชี้วัดที่ดีที่สุด หรือไม่? ไม่ค่อยเท่าไหร่ มีการเปิดเผยในโซลูชันและแพลตฟอร์ม RUM ส่วนใหญ่แล้ว รวมถึง Cloudflare, Treo, SpeedCurve, Calibre, WebPageTest (ในมุมมองฟิล์มแล้ว), Newrelic, Shopify, Next.js, เครื่องมือ Google ทั้งหมด (PageSpeed ​​Insights, Lighthouse + CI, Search คอนโซล ฯลฯ ) และอื่น ๆ อีกมากมาย

   อย่างไรก็ตาม ตามที่ Katie Sylor-Miller อธิบาย ปัญหาหลักบางประการของ Core Web Vitals คือการขาดการสนับสนุนข้ามเบราว์เซอร์ เราไม่ได้วัดวงจรชีวิตที่สมบูรณ์ของประสบการณ์ของผู้ใช้จริง ๆ แถมยังยากที่จะเชื่อมโยงการเปลี่ยนแปลงใน FID และ CLS กับผลลัพธ์ทางธุรกิจ

   เนื่องจากเราควรคาดหวังว่า Core Web Vitals จะพัฒนาขึ้น ดูเหมือนว่าสมเหตุสมผลเสมอที่จะ รวม Web Vitals เข้ากับเมตริกที่ปรับแต่งเองเพื่อให้เข้าใจถึงจุดที่คุณยืนอยู่ในแง่ของประสิทธิภาพได้ดียิ่งขึ้น

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

   ทั่วโลกในปี 2020 ตาม IDC 84.8% ของโทรศัพท์มือถือที่จัดส่งทั้งหมดเป็นอุปกรณ์ Android ผู้บริโภคโดยเฉลี่ยจะอัปเกรดโทรศัพท์ของตนทุกๆ 2 ปี และในรอบการเปลี่ยนทดแทนโทรศัพท์ในสหรัฐฯ คือ 33 เดือน โทรศัพท์ที่ขายดีที่สุดโดยเฉลี่ยทั่วโลกจะมีราคาต่ำกว่า 200 ดอลลาร์

   อุปกรณ์ที่เป็นตัวแทนก็คืออุปกรณ์ Android ที่ มีอายุอย่างน้อย 24 เดือน โดยมีราคาอยู่ที่ $200 หรือน้อยกว่า ซึ่งทำงานบน 3G ที่ช้า, 400ms RTT และการถ่ายโอน 400kbps เพื่อให้มองโลกในแง่ร้ายขึ้นเล็กน้อย แน่นอนว่าสิ่งนี้อาจแตกต่างกันมากสำหรับบริษัทของคุณ แต่นั่นเป็นการประมาณค่าที่ใกล้เคียงเพียงพอสำหรับลูกค้าส่วนใหญ่ที่มีอยู่ อันที่จริง อาจเป็นความคิดที่ดีที่จะพิจารณาสินค้าขายดีในปัจจุบันของ Amazon สำหรับตลาดเป้าหมายของคุณ ( ขอบคุณ Tim Kadlec, Henri Helvetica และ Alex Russell สำหรับคำแนะนำ! )

   

   อุปกรณ์ทดสอบอะไรให้เลือก? สิ่งที่เข้ากันได้ดีกับโปรไฟล์ที่ระบุไว้ข้างต้น เป็นตัวเลือกที่ดีในการเลือก Moto G4/G5 Plus ที่เก่ากว่าเล็กน้อย อุปกรณ์ Samsung ระดับกลาง (Galaxy A50, S8) อุปกรณ์ระดับกลางที่ดี เช่น Nexus 5X, Xiaomi Mi A3 หรือ Xiaomi Redmi Note 7 และอุปกรณ์ที่ช้าเช่น Alcatel 1X หรือ Cubot X19 อาจอยู่ในห้องปฏิบัติการอุปกรณ์แบบเปิด สำหรับการทดสอบกับอุปกรณ์ควบคุมความร้อนที่ช้ากว่า คุณยังสามารถซื้อ Nexus 4 ซึ่งมีราคาเพียง 100 ดอลลาร์

   นอกจากนี้ ให้ตรวจสอบชิปเซ็ตที่ใช้ในแต่ละอุปกรณ์และ อย่าใช้ชิปเซ็ตเดียวมากเกินไป : Snapdragon และ Apple สองสามรุ่นรวมถึง Rockchip ระดับล่าง Mediatek ก็เพียงพอแล้ว (ขอบคุณ Patrick!)

   หากคุณไม่มีอุปกรณ์ในมือ ให้จำลองประสบการณ์มือถือบนเดสก์ท็อปโดยการทดสอบบน เครือข่าย 3G ที่มีการควบคุม ปริมาณ (เช่น 300ms RTT, ลดลง 1.6 Mbps, เพิ่มขึ้น 0.8 Mbps) ด้วย CPU ที่ควบคุมปริมาณ (การชะลอตัว 5 เท่า) ในที่สุดก็เปลี่ยนไปใช้ 3G ปกติ, 4G ที่ช้า (เช่น 170ms RTT, 9 Mbps down, 9Mbps up) และ Wi-Fi เพื่อให้มองเห็นผลกระทบด้านประสิทธิภาพมากขึ้น คุณยังสามารถแนะนำ 2G วันอังคารหรือตั้งค่าเครือข่าย 3G/4G ที่มีการควบคุมปริมาณในสำนักงานของคุณเพื่อการทดสอบที่รวดเร็วยิ่งขึ้น

   โปรดทราบว่าบนอุปกรณ์พกพา เราควรคาดหวังการชะลอตัว 4×–5× เมื่อเทียบกับเครื่องเดสก์ท็อป อุปกรณ์พกพามี GPU, CPU, หน่วยความจำ และคุณลักษณะของแบตเตอรี่ต่างกัน นั่นเป็นเหตุผลสำคัญที่ต้องมีโปรไฟล์ที่ดีของอุปกรณ์ทั่วไปและทดสอบกับอุปกรณ์ดังกล่าวเสมอ



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

• เครื่องมือทดสอบสังเคราะห์ รวบรวม ข้อมูลห้องปฏิบัติการ ในสภาพแวดล้อมที่ทำซ้ำได้ด้วยการตั้งค่าอุปกรณ์และเครือข่ายที่กำหนดไว้ล่วงหน้า (เช่น Lighthouse , Calibre , WebPageTest ) และ
• เครื่องมือ Real User Monitoring ( RUM ) ประเมินการโต้ตอบของผู้ใช้อย่างต่อเนื่องและรวบรวม ข้อมูลภาคสนาม (เช่น SpeedCurve , New Relic — เครื่องมือนี้มีการทดสอบสังเคราะห์ด้วย)

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

โดยการแตะเข้าไปใน RUM API ที่มีอยู่แล้วภายใน เช่น Navigation Timing, Resource Timing, Paint Timing, Long Tasks เป็นต้น เครื่องมือทดสอบสังเคราะห์และ RUM จะทำให้ภาพรวมของประสิทธิภาพในแอปพลิเคชันของคุณสมบูรณ์ คุณสามารถใช้ Calibre, Treo, SpeedCurve, mPulse และ Boomerang, Sitespeed.io ซึ่งทั้งหมดนี้เป็นตัวเลือกที่ยอดเยี่ยมสำหรับการตรวจสอบประสิทธิภาพ นอกจากนี้ ด้วยส่วนหัวของ Server Timing คุณยังสามารถตรวจสอบประสิทธิภาพแบ็คเอนด์และฟรอนต์เอนด์ได้ในที่เดียว

หมายเหตุ : การเลือกตัวควบคุมระดับเครือข่ายนั้นปลอดภัยกว่าเสมอ ภายนอกเบราว์เซอร์ เช่น DevTools มีปัญหาในการโต้ตอบกับการพุช HTTP/2 เนื่องจากวิธีการใช้งาน ( ขอบคุณ Yoav, Patrick !) สำหรับ Mac OS เราสามารถใช้ Network Link Conditioner, สำหรับ Windows Windows Traffic Shaper, สำหรับ Linux netem และสำหรับ FreeBSD dummynet

เนื่องจากมีแนวโน้มว่าคุณจะทำการทดสอบใน Lighthouse โปรดทราบว่าคุณสามารถ:

• ใช้ Lighthouse CI เพื่อติดตามคะแนน Lighthouse เมื่อเวลาผ่านไป (ค่อนข้างน่าประทับใจ)
• เรียกใช้ Lighthouse ใน GitHub Actions เพื่อรับรายงาน Lighthouse ควบคู่ไปกับทุก PR
• เรียกใช้การตรวจสอบประสิทธิภาพของ Lighthouse ในทุกหน้าของไซต์ (ผ่าน Lightouse Parade) โดยบันทึกเอาต์พุตเป็น CSV
• ใช้เครื่องคำนวณคะแนน Lighthouse และน้ำหนักเมตริกของ Lighthouse หากคุณต้องการดูรายละเอียดเพิ่มเติม
• Lighthouse พร้อมใช้งานสำหรับ Firefox เช่นกัน แต่ภายใต้ประทุนนั้นใช้ PageSpeed ​​Insights API และสร้างรายงานตาม Chrome 79 User-Agent ที่ไม่มีส่วนหัว

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

   

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

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

สารบัญ

1. เตรียมตัวให้พร้อม: การวางแผนและการวัดผล
2. การตั้งเป้าหมายที่สมจริง
3. การกำหนดสภาพแวดล้อม
4. การเพิ่มประสิทธิภาพสินทรัพย์
5. สร้างการเพิ่มประสิทธิภาพ
6. การเพิ่มประสิทธิภาพการจัดส่ง
7. เครือข่าย, HTTP/2, HTTP/3
8. การทดสอบและการตรวจสอบ
9. ชนะอย่างรวดเร็ว
10. ทุกอย่างในหน้าเดียว
11. ดาวน์โหลดรายการตรวจสอบ (PDF, Apple Pages, MS Word)
12. สมัครรับจดหมายข่าวทางอีเมลของเราเพื่อไม่ให้พลาดคำแนะนำต่อไป