Front-End Performance 2021: การทดสอบและการตรวจสอบ

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

สารบัญ

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

การทดสอบและการตรวจสอบ

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

   คุณยังสามารถขับเคลื่อน WebPageTest จาก Google Spreadsheet และรวมคะแนนการช่วยสำหรับการเข้าถึง ประสิทธิภาพ และ SEO เข้าในการตั้งค่า Travis ของคุณด้วย Lighthouse CI หรือโดยตรงใน Webpack

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

   และถ้าคุณต้องการแก้จุดบกพร่องอย่างรวดเร็ว แต่กระบวนการสร้างของคุณดูเหมือนจะช้ามาก โปรดจำไว้ว่า "การลบช่องว่างและการจัดการสัญลักษณ์คิดเป็น 95% ของการลดขนาดในโค้ดย่อขนาดสำหรับ JavaScript ส่วนใหญ่ — ไม่ใช่การแปลงโค้ดที่ซับซ้อน คุณสามารถ เพียงปิดการใช้งานการบีบอัดเพื่อเพิ่มความเร็วให้กับ Uglify บิลด์ 3 ถึง 4 เท่า"

1. คุณได้ทดสอบในพร็อกซีเบราว์เซอร์และเบราว์เซอร์รุ่นเก่าหรือไม่
   การทดสอบใน Chrome และ Firefox นั้นไม่เพียงพอ ดูวิธีการทำงานของเว็บไซต์ของคุณในพร็อกซีเบราว์เซอร์และเบราว์เซอร์รุ่นเก่า ตัวอย่างเช่น UC Browser และ Opera Mini มีส่วนแบ่งการตลาดที่สำคัญในเอเชีย (มากถึง 35% ในเอเชีย) วัดความเร็วอินเทอร์เน็ตโดยเฉลี่ยในประเทศที่คุณสนใจ เพื่อหลีกเลี่ยงความประหลาดใจครั้งใหญ่ที่กำลังจะเกิดขึ้น ทดสอบด้วยการควบคุมปริมาณเครือข่าย และจำลองอุปกรณ์ที่มี DPI สูง BrowserStack นั้นยอดเยี่ยมสำหรับการทดสอบบนอุปกรณ์จริง จากระยะไกล และเสริมด้วยอุปกรณ์จริงสองสามเครื่องในสำนักงานของคุณด้วย — มันคุ้มค่า

1. คุณได้ทดสอบประสิทธิภาพของหน้า 404 ของคุณหรือไม่?
   ปกติแล้วเราจะไม่คิดซ้ำสองเมื่อพูดถึง 404 หน้า เมื่อไคลเอนต์ร้องขอหน้าที่ไม่มีอยู่บนเซิร์ฟเวอร์ เซิร์ฟเวอร์จะตอบสนองด้วยรหัสสถานะ 404 และหน้า 404 ที่เกี่ยวข้อง มันไม่มีอะไรมากขนาดนั้นหรอกเหรอ?

   ลักษณะสำคัญของการตอบสนอง 404 คือ ขนาดเนื้อหาการตอบสนอง จริงที่ถูกส่งไปยังเบราว์เซอร์ จากการวิจัย 404 หน้าโดย Matt Hobbs คำตอบ 404 ส่วนใหญ่มาจาก favicons ที่หายไป, คำขออัปโหลด WordPress, คำขอ JavaScript ที่ใช้งานไม่ได้, ไฟล์ Manifest รวมถึงไฟล์ CSS และฟอนต์ ทุกครั้งที่ลูกค้าร้องขอทรัพย์สินที่ไม่มีอยู่จริง พวกเขาจะได้รับการตอบกลับ 404 และบ่อยครั้งที่การตอบกลับนั้นมีขนาดใหญ่มาก

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

   

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

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

   แน่นอน ความยินยอมที่แท้จริงมีแนวโน้มที่จะเปลี่ยนผลกระทบของสคริปต์ที่มีต่อประสิทธิภาพโดยรวม ดังนั้นตามที่ Boris Schapira ระบุไว้ เราอาจต้องการศึกษาโปรไฟล์ประสิทธิภาพเว็บที่แตกต่างกันสองสามอย่าง:

   • ความยินยอมถูกปฏิเสธโดยสิ้นเชิง
   • ความยินยอมถูกปฏิเสธบางส่วน
   • ได้รับความยินยอมอย่างสมบูรณ์
   • ผู้ใช้ไม่ได้ดำเนินการตามข้อความยินยอม (หรือข้อความแจ้งถูกบล็อกโดยตัวบล็อกเนื้อหา)

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

   โดยทั่วไป การพิจารณา ประสิทธิภาพของป๊อปอัป นั้นคุ้มค่า เนื่องจากคุณจะต้องกำหนดออฟเซ็ตแนวนอนหรือแนวตั้งของเหตุการณ์เมาส์ และจัดตำแหน่งป๊อปอัปให้ถูกต้องให้สัมพันธ์กับจุดยึด Noam Rosenthal แบ่งปันการเรียนรู้ของทีม Wikimedia ในบทความ กรณีศึกษาประสิทธิภาพเว็บ: การแสดงตัวอย่างหน้า Wikipedia (มีให้ในรูปแบบวิดีโอและนาทีด้วย)

3. คุณเก็บ CSS การวินิจฉัยประสิทธิภาพหรือไม่
   แม้ว่าเราจะรวมการตรวจสอบทุกประเภทเพื่อให้แน่ใจว่าโค้ดที่ไม่มีประสิทธิภาพได้รับการปรับใช้ แต่มักจะมีประโยชน์ที่จะทราบแนวคิดสั้นๆ เกี่ยวกับผลไม้ที่ค้างอยู่ต่ำซึ่งสามารถแก้ไขได้ง่าย สำหรับสิ่งนั้น เราสามารถใช้ CSS การวินิจฉัยประสิทธิภาพที่ยอดเยี่ยมของ Tim Kadlec (ได้รับแรงบันดาลใจจากตัวอย่างข้อมูลของ Harry Roberts ซึ่งไฮไลต์รูปภาพที่โหลดแบบ Lazy Loading, รูปภาพที่ไม่มีขนาด, รูปภาพรูปแบบเดิมและสคริปต์ซิงโครนัส

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

   /* Performance Diagnostics CSS */ /* via Harry Roberts. https://twitter.com/csswizardry/status/1346477682544951296 */ img[loading=lazy] { outline: 10px solid red; }

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

   เมื่อพูดถึง Fast Time to Interactive โดยปกติเราหมายถึงตัวบ่งชี้ว่าผู้ใช้สามารถโต้ตอบกับหน้าเว็บได้ เร็ว เพียงใดโดยคลิกหรือแตะที่ลิงก์และปุ่ม บริบทแตกต่างกันเล็กน้อยกับโปรแกรมอ่านหน้าจอ ในกรณีดังกล่าว Time to Interactive ที่รวดเร็วหมายถึง เวลา ผ่านไปนานเท่าใดจนกว่าโปรแกรมอ่านหน้าจอ จะประกาศการนำทาง ในหน้าที่กำหนด และผู้ใช้โปรแกรมอ่านหน้าจอสามารถกดแป้นพิมพ์เพื่อโต้ตอบได้จริง

   Leonie Watson ได้พูดคุยเปิดหูเปิดตาเกี่ยวกับประสิทธิภาพการช่วยสำหรับการเข้าถึง และโดยเฉพาะอย่างยิ่งผลกระทบที่การโหลดช้ามีต่อความล่าช้าในการประกาศโปรแกรมอ่านหน้าจอ โปรแกรมอ่านหน้าจอใช้ในการประกาศที่รวดเร็วและการนำทางอย่างรวดเร็ว ดังนั้นอาจมีความอดทนน้อยกว่าผู้ใช้ที่มองเห็น

   หน้าขนาดใหญ่และการจัดการ DOM ด้วย JavaScript จะทำให้การประกาศโปรแกรมอ่านหน้าจอล่าช้า พื้นที่ที่ยังไม่ได้สำรวจซึ่งใช้ความสนใจและการทดสอบเป็นโปรแกรมอ่านหน้าจอมีอยู่ในทุกแพลตฟอร์ม (Jaws, NVDA, Voiceover, Narrator, Orca)

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

   ดูการใช้โซลูชัน RUM เพื่อตรวจสอบการเปลี่ยนแปลงในประสิทธิภาพเมื่อเวลาผ่านไป สำหรับเครื่องมือทดสอบโหลดแบบ unit-test-alike แบบอัตโนมัติ คุณสามารถใช้ k6 กับ scripting API ได้ นอกจากนี้ ให้ดูที่ SpeedTracker, Lighthouse และ Calibre

สารบัญ

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