ประสิทธิภาพการแสดงผล

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

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

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

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

หมายเหตุเกี่ยวกับอัตราการรีเฟรชของอุปกรณ์

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

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

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

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

เมื่อพิจารณาว่าจอแสดงผลทั่วไปจะรีเฟรช 60 ครั้งต่อวินาที การคํานวณคร่าวๆ จะแสดงให้เห็นว่าเบราว์เซอร์มีเวลา 16.66 มิลลิวินาทีในการสร้างแต่ละเฟรม แต่ในทางปฏิบัติ เบราว์เซอร์จะมีเวลารอของแต่ละเฟรม ดังนั้นงานทั้งหมดของคุณจึงต้องเสร็จภายใน 10 มิลลิวินาที เมื่อคุณไม่สามารถใช้งบประมาณนี้ อัตราเฟรมจะลดลงและเนื้อหาของหน้าเว็บจะกระตุกบนหน้าจอ ปรากฏการณ์นี้มักเรียกว่าการกระตุก

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

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

ไปป์ไลน์พิกเซล

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

ไปป์ไลน์พิกเซลแบบสมบูรณ์ที่มี 5 ขั้นตอน ได้แก่ JavaScript, สไตล์, เลย์เอาต์, การวาด และคอมโพสิต
ภาพแสดงไปป์ไลน์พิกเซลแบบเต็ม
  • JavaScript: โดยทั่วไปแล้ว JavaScript จะใช้เพื่อจัดการงานที่ส่งผลให้อินเทอร์เฟซผู้ใช้มีการเปลี่ยนแปลงที่มองเห็นได้ เช่น อาจเป็นฟังก์ชัน animate ของ jQuery, การจัดเรียงชุดข้อมูล หรือการเพิ่มองค์ประกอบ DOM ลงในหน้า อย่างไรก็ตาม คุณไม่จำเป็นต้องใช้ JavaScript เพื่อทริกเกอร์การเปลี่ยนแปลงภาพเสมอไป เนื่องจากภาพเคลื่อนไหว CSS, การเปลี่ยน CSS และ Web Animations API สามารถสร้างภาพเคลื่อนไหวในเนื้อหาหน้าเว็บได้
  • การคํานวณสไตล์: กระบวนการนี้เป็นการหาว่ากฎ CSS ใดมีผลกับองค์ประกอบ HTML ใดโดยอิงตามตัวเลือกที่ตรงกัน ตัวอย่างเช่น .headline เป็นตัวอย่างตัวเลือก CSS ที่มีผลกับองค์ประกอบ HTML ใดก็ได้ที่มีค่าแอตทริบิวต์ class ซึ่งมีคลาส headline จากนั้นเมื่อทราบกฎแล้ว ระบบจะใช้กฎดังกล่าวและคำนวณสไตล์สุดท้ายสำหรับองค์ประกอบแต่ละรายการ
  • เลย์เอาต์: เมื่อเบราว์เซอร์ทราบว่ากฎใดมีผลกับองค์ประกอบหนึ่งๆ ก็จะเริ่มคำนวณเรขาคณิตของหน้าเว็บได้ เช่น พื้นที่ที่องค์ประกอบแต่ละรายการใช้ และตำแหน่งที่ปรากฏบนหน้าจอ รูปแบบเลย์เอาต์ของเว็บหมายความว่าองค์ประกอบหนึ่งอาจส่งผลต่อองค์ประกอบอื่นๆ ตัวอย่างเช่น โดยทั่วไปแล้ว ความกว้างขององค์ประกอบ <body> จะส่งผลต่อขนาดขององค์ประกอบย่อยตั้งแต่ต้นจนจบในลําดับชั้น ดังนั้นเบราว์เซอร์จึงต้องดำเนินการที่ซับซ้อน
  • ระบายสี: การระบายสีคือกระบวนการเติมพิกเซล ซึ่งเกี่ยวข้องกับการวาดข้อความ สี รูปภาพ เส้นขอบ เงา และองค์ประกอบภาพอื่นๆ ทั้งหมดหลังจากคำนวณเลย์เอาต์ในหน้าแล้ว โดยปกติแล้วภาพวาดจะวาดบนพื้นผิวหลายชั้น ซึ่งมักเรียกว่าเลเยอร์
  • คอมโพสิต: เนื่องจากชิ้นส่วนของหน้าเว็บอาจวาดในเลเยอร์หลายเลเยอร์ จึงต้องนำไปใช้กับหน้าจอตามลำดับที่ถูกต้องเพื่อให้หน้าเว็บแสดงผลตามที่คาดไว้ ซึ่งสำคัญอย่างยิ่งสำหรับองค์ประกอบที่ซ้อนทับกัน เนื่องจากความผิดพลาดอาจส่งผลให้องค์ประกอบหนึ่งปรากฏอยู่ด้านบนของอีกองค์ประกอบหนึ่งอย่างไม่ถูกต้อง

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

คุณอาจเคยได้ยินคำว่า "แรสเตอร์" ที่ใช้ร่วมกับ "ระบายสี" สาเหตุเป็นเพราะการวาดภาพเป็นงาน 2 อย่าง ได้แก่

  1. การสร้างรายการการเรียกให้วาด
  2. การเติมพิกเซล

การดำเนินการหลังนี้เรียกว่า "การแรสเตอร์" ดังนั้นเมื่อใดก็ตามที่คุณเห็นบันทึกการวาดใน DevTools ให้ถือว่ามีการแรสเตอร์ ในสถาปัตยกรรมบางอย่าง การสร้างรายการการเรียกให้วาดและการแรสเตอร์จะดำเนินการในเธรดที่แตกต่างกัน แต่คุณในฐานะนักพัฒนาแอปไม่สามารถควบคุมกระบวนการดังกล่าวได้

คุณไม่จำเป็นต้องแก้ไขทุกส่วนของไปป์ไลน์ในทุกเฟรมเสมอไป อันที่จริงแล้ว ไปป์ไลน์จะทำงานตามปกติสำหรับเฟรมหนึ่งๆ เมื่อคุณทำการเปลี่ยนแปลงภาพด้วย JavaScript, CSS หรือ WebAnimations API ได้ 3 วิธี

1. JS / CSS > สไตล์ > เลย์เอาต์ > ระบายสี > คอมโพสิต

ไปป์ไลน์พิกเซลแบบสมบูรณ์โดยไม่มีขั้นตอนใดขาดหายไป

หากคุณเปลี่ยนพร็อพเพอร์ตี้ "เลย์เอาต์" เช่น พร็อพเพอร์ตี้ที่เปลี่ยนเรขาคณิตขององค์ประกอบ เช่น ความกว้าง ความสูง หรือตําแหน่ง (เช่น พร็อพเพอร์ตี้ left หรือ top ของ CSS) เบราว์เซอร์จะต้องตรวจสอบองค์ประกอบอื่นๆ ทั้งหมดและ "จัดเรียงใหม่" หน้าเว็บ จะต้องทาสีพื้นที่ที่ได้รับผลกระทบใหม่ และจะต้องประกอบองค์ประกอบที่ทาสีแล้วเข้าด้วยกันอีกครั้ง

2. JS / CSS > สไตล์ > ทาสี > คอมโพสิต

ไปป์ไลน์พิกเซลที่ข้ามขั้นตอนเลย์เอาต์

หากคุณเปลี่ยนพร็อพเพอร์ตี้ "paint-only" สำหรับองค์ประกอบใน CSS เช่น พร็อพเพอร์ตี้ background-image, color หรือ box-shadow คุณไม่จำเป็นต้องทำขั้นตอนเลย์เอาต์เพื่อบันทึกการอัปเดตภาพในหน้า การละเว้นขั้นตอนการจัดวาง (หากเป็นไปได้) จะช่วยหลีกเลี่ยงงานการจัดวางที่อาจทําให้สิ้นเปลืองค่าใช้จ่ายและอาจทำให้เกิดเวลาในการตอบสนองที่สูงมากในการผลิตเฟรมถัดไป

3. JS / CSS > สไตล์ > คอมโพสิท

ไปป์ไลน์พิกเซลที่ข้ามขั้นตอนเลย์เอาต์และการทาสี

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

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

มาเจาะลึกส่วนต่างๆ ของไปป์ไลน์กัน เราจะดูปัญหาที่พบได้ทั่วไป รวมถึงวิธีวินิจฉัยและแก้ไข

การเพิ่มประสิทธิภาพการแสดงผลของเบราว์เซอร์

ภาพหน้าจอหลักสูตร Udacity

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

หลักสูตรนี้เป็นหลักสูตรฟรีที่นำเสนอผ่าน Udacity และคุณสามารถเรียนได้ทุกเมื่อ