เพิ่มประสิทธิภาพเว็บได้ง่ายๆ - รุ่น Google I/O 2018

ในงาน Google IO 2018 เราได้นำเสนอเครื่องมือ ไลบรารี และเทคนิคการเพิ่มประสิทธิภาพที่จะช่วยให้การปรับปรุงประสิทธิภาพเว็บง่ายขึ้น ที่นี่เราจะอธิบายโดยใช้แอป The Oodles Theater และพูดถึงการทดสอบการโหลดแบบคาดการณ์และโครงการริเริ่ม Guess.js ใหม่

Ewa Gasperowicz

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

ความจำเป็นด้านประสิทธิภาพ

อินเทอร์เน็ตมีขนาดใหญ่ขึ้นทุกปี หากตรวจสอบสถานะของเว็บ เราจะเห็นว่าหน้าเว็บค่ามัธยฐานในอุปกรณ์เคลื่อนที่มีน้ำหนักประมาณ 1.5 MB โดยส่วนใหญ่เป็น JavaScript และรูปภาพ

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

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

ลำดับชั้นของ UX
รูปที่ 1 ความเร็วสำคัญกับผู้ใช้เพียงใด (Speed Matters, Vol. 3)

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

Lighthouse - พื้นฐานสําหรับเวิร์กโฟลว์ด้านประสิทธิภาพ

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

เมื่อเร็วๆ นี้เราได้เปิดตัวการตรวจสอบประสิทธิภาพใหม่จำนวนมากที่มีประโยชน์อย่างยิ่งในเวิร์กโฟลว์การพัฒนาในแต่ละวัน

การตรวจสอบใหม่ของ Lighthouse
รูปที่ 2 การตรวจสอบ Lighthouse ใหม่

มาดูวิธีใช้ประโยชน์จากฟีเจอร์นี้กันจากตัวอย่างการใช้งานจริง นั่นคือแอป Oodles Theater ซึ่งเป็นเว็บแอปสาธิตเล็กๆ ให้คุณได้ลองใช้ Google Doodle แบบอินเทอร์แอกทีฟที่เราชื่นชอบและเล่นเกมสักเกมสองเกม

ขณะสร้างแอป เราต้องการทำให้แอปมีประสิทธิภาพมากที่สุด จุดเริ่มต้นของการเพิ่มประสิทธิภาพคือรายงาน Lighthouse

รายงาน Lighthouse สําหรับแอป Oodles
รูปที่ 3 รายงาน Lighthouse สําหรับแอป Oodles

ประสิทธิภาพเริ่มต้นของแอปตามที่แสดงในรายงาน Lighthouse นั้นแย่มาก ในเครือข่าย 3G ผู้ใช้ต้องรอ 15 วินาทีเพื่อให้ภาพวาดแรกที่มีความหมายปรากฏขึ้น หรือเพื่อให้แอปโต้ตอบได้ Lighthouse ชี้ให้เห็นปัญหามากมายในเว็บไซต์ของเรา และคะแนนประสิทธิภาพโดยรวมที่ 23 สะท้อนถึงปัญหาเหล่านั้น

หน้าเว็บมีน้ำหนักประมาณ 3.4 MB เราจึงต้องตัดเนื้อหาบางส่วนออก

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

โอกาสในการเพิ่มประสิทธิภาพ

นำทรัพยากรที่ไม่จำเป็นออก

สิ่งหนึ่งที่เห็นได้ชัดและนำออกได้โดยไม่มีปัญหาคือ เว้นวรรคและความคิดเห็น

ประโยชน์จากการลดขนาด
รูปที่ 4 ลดขนาดและบีบอัด JavaScript และ CSS

Lighthouse จะไฮไลต์โอกาสนี้ในการตรวจสอบ CSS และ JavaScript ที่ไม่มีการย่อ เราใช้ webpack สําหรับกระบวนการบิลด์ ดังนั้นเราจึงใช้ปลั๊กอิน Uglify JS เพื่อลดขนาด

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

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

เราใช้โฮสติ้งของ Firebase เพื่อโฮสต์โค้ดของเรา และ Firebase เปิดใช้การบีบอัดข้อมูลด้วย GZIP โดยค่าเริ่มต้น ดังนั้นการโฮสต์โค้ดใน CDN ที่สมเหตุสมผลก็ทำให้เราได้รับประโยชน์นี้โดยไม่มีค่าใช้จ่าย

แม้ว่า gzip จะเป็นวิธีบีบอัดที่ได้รับความนิยมอย่างมาก แต่กลไกอื่นๆ เช่น Zopfli และ Brotli ก็ได้รับความนิยมเช่นกัน Brotli ได้รับการรองรับในเบราว์เซอร์ส่วนใหญ่ และคุณใช้ไบนารีเพื่อบีบอัดชิ้นงานล่วงหน้าก่อนที่จะส่งไปยังเซิร์ฟเวอร์ได้

ใช้นโยบายแคชที่มีประสิทธิภาพ

ขั้นตอนถัดไปคือการตรวจสอบว่าเราไม่ส่งทรัพยากรซ้ำหากไม่จำเป็น

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

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

นำโค้ดที่ไม่ได้ใช้ออก

จนถึงตอนนี้เราได้นำส่วนการดาวน์โหลดที่ไม่จำเป็นซึ่งเห็นได้ชัดออกแล้ว แต่ส่วนที่ไม่ชัดเจนมากนักล่ะ เช่น โค้ดที่ไม่ได้ใช้งาน

ความครอบคลุมของโค้ดในเครื่องมือสำหรับนักพัฒนาเว็บ
รูปที่ 5 ตรวจสอบการครอบคลุมโค้ด

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

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

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

Lighthouse ยังพบปัญหานี้ในการตรวจสอบกฎ CSS ที่ไม่ได้ใช้งานด้วย พบว่าอาจประหยัดพื้นที่ได้กว่า 400 KB เราจึงกลับไปที่โค้ดและนําทั้งส่วน JavaScript และ CSS ออกจากคลังนั้น

หากนำ MVC Adapter ออก สไตล์จะลดลงเหลือ 10KB
รูปที่ 6 หากนำอะแดปเตอร์ MVC ออก สไตล์จะลดลงเหลือ 10KB

ซึ่งทำให้กลุ่ม CSS ลดลง 20 เท่า ซึ่งถือว่าดีมากสำหรับคอมมิตสั้นๆ 2 บรรทัด

แน่นอนว่าคะแนนประสิทธิภาพของเราก็เพิ่มขึ้น และเวลาในการโต้ตอบก็ดีขึ้นมาก

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

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

ปุ่มใช้งานไม่ได้เนื่องจากไม่มีคลัง
รูปที่ 7 คอมโพเนนต์ 1 รายการยังใช้ไลบรารีที่ถูกนําออกอยู่

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

หลีกเลี่ยงเพย์โหลดเครือข่ายปริมาณมาก

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

Lighthouse ตรวจพบว่าเรามีปัญหาเกี่ยวกับเพย์โหลดเครือข่ายบางส่วนโดยใช้การตรวจสอบเพย์โหลดเครือข่ายขนาดใหญ่

ตรวจหาเพย์โหลดเครือข่ายปริมาณมาก
รูปที่ 8 ตรวจหาเพย์โหลดเครือข่ายปริมาณมาก

เราพบว่ามีโค้ดที่มีมูลค่ามากกว่า 3 MB กำลังส่งอยู่ ซึ่งถือว่ามากทีเดียวโดยเฉพาะบนอุปกรณ์เคลื่อนที่

ที่ด้านบนสุดของรายการนี้ Lighthouse ไฮไลต์ว่าเรามีกลุ่มผู้ให้บริการ JavaScript ที่เป็นโค้ดที่ไม่มีการบีบอัดขนาด 2 MB ปัญหานี้ยังเป็นสิ่งที่ webpack ชี้ให้เห็นด้วย

ดังคำกล่าวที่ว่า "คำขอที่เร็วที่สุดคือคำขอที่ไม่ได้ส่ง"

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

ในกรณีของเรา เราจัดการกับกลุ่ม JavaScript จำนวนมาก จึงโชคดีที่มีชุมชน JavaScript ที่มีชุดเครื่องมือตรวจสอบกลุ่ม JavaScript มากมาย

การตรวจสอบกลุ่ม JavaScript
รูปที่ 9 การตรวจสอบกลุ่ม JavaScript

เราเริ่มต้นด้วยเครื่องมือวิเคราะห์กลุ่ม webpack ซึ่งแจ้งให้เราทราบว่าเรารวมข้อกําหนดที่เรียกว่า unicode ซึ่งมี JavaScript ที่แยกวิเคราะห์แล้ว 1.6 MB ซึ่งค่อนข้างมาก

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

จากนั้นเราเปลี่ยนไปใช้เครื่องมืออื่นอย่าง BundlePhobia เครื่องมือนี้ช่วยให้คุณป้อนชื่อแพ็กเกจ NPM ใดก็ได้และดูขนาดโดยประมาณของไฟล์ที่ผ่านการย่อขนาดและบีบอัดไฟล์ gzip เราพบทางเลือกที่ดีสำหรับข้อบังคับของโมดูลที่เราใช้อยู่ ซึ่งมีน้ำหนักเพียง 2.2 KB เราจึงเปลี่ยนไปใช้ข้อบังคับนั้น

การดำเนินการนี้ส่งผลต่อประสิทธิภาพของเราอย่างมาก จากการเปลี่ยนแปลงนี้และการค้นพบโอกาสอื่นๆ ในการลดขนาดแพ็กเกจ JavaScript เราประหยัดโค้ดได้ 2.1 MB

เราพบว่าการปรับปรุงโดยรวมเพิ่มขึ้น 65% เมื่อพิจารณาขนาดที่บีบอัดและขนาดที่ลดขนาดแล้วของกลุ่มเหล่านี้ และพบว่ากระบวนการนี้คุ้มค่าอย่างยิ่ง

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

ลดเวลาในการเริ่มต้น JavaScript ด้วยการแยกโค้ด

แม้ว่าเพย์โหลดเครือข่ายขนาดใหญ่จะส่งผลต่อแอปของเราอย่างมาก แต่ยังมีอีกสิ่งหนึ่งที่ส่งผลอย่างมากเช่นกัน นั่นก็คือ JavaScript

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

นี่คือวิธีที่เบราว์เซอร์ประมวลผล JavaScript

การประมวลผล JavaScript
รูปที่ 10 การดำเนินการกับ JavaScript

ก่อนอื่นเราต้องดาวน์โหลดสคริปต์นั้น เรามีเครื่องมือสำหรับ JavaScript ซึ่งต้องแยกวิเคราะห์โค้ดนั้น คอมไพล์ และดำเนินการ

ตอนนี้ขั้นตอนเหล่านี้ใช้เวลาไม่นานในอุปกรณ์ระดับไฮเอนด์ เช่น คอมพิวเตอร์เดสก์ท็อปหรือแล็ปท็อป หรือแม้แต่โทรศัพท์ระดับไฮเอนด์ แต่บนโทรศัพท์มือถือระดับกลาง ขั้นตอนนี้อาจใช้เวลานานกว่า 5-10 เท่า การดำเนินการนี้ทำให้การโต้ตอบล่าช้า เราจึงต้องพยายามตัดวิดีโอนี้ให้สั้นลง

เราได้เปิดตัวการตรวจสอบเวลาเริ่มต้น JavaScript ใหม่ใน Lighthouse เพื่อช่วยให้คุณค้นพบปัญหาเหล่านี้เกี่ยวกับแอป

เวลาในการเริ่มต้น JavaScript
รูปที่ 11 การตรวจสอบเวลาในการเปิดเครื่องของ JavaScript

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

เทคนิคหนึ่งในการแก้ปัญหานี้คือการใช้การแยกโค้ด

การแยกโค้ดก็เหมือนกับพิซซ่า

การแยกโค้ดเป็นแนวคิดที่ว่าแทนที่จะให้ JavaScript แก่ผู้ใช้เป็นชิ้นใหญ่ๆ คุณจะทําอย่างไรหากให้ผู้ใช้ทีละชิ้นตามที่ต้องการ

การแยกโค้ดใช้ได้ที่ระดับเส้นทางหรือระดับคอมโพเนนต์ ทำงานร่วมกับ React และ React Loadable, Vue.js, Angular, Polymer, Preact และไลบรารีอื่นๆ อีกมากมายได้เป็นอย่างดี

เรารวมการแยกโค้ดไว้ในแอปพลิเคชันของเรา โดยเปลี่ยนจากการนําเข้าแบบคงที่เป็นการนําเข้าแบบไดนามิก ซึ่งช่วยให้เราโหลดโค้ดแบบตามต้องการแบบแอซิงโครนัสได้

การแยกโค้ดด้วยการนําเข้าแบบไดนามิก
รูปที่ 13 การแยกโค้ดด้วยการนําเข้าแบบไดนามิก

ผลที่ได้คือทั้งการลดขนาดกลุ่ม และลดเวลาในการเริ่มต้น JavaScript เหลือเพียง 0.78 วินาที ทำให้แอปเร็วขึ้น 56%

โดยทั่วไป หากคุณกำลังสร้างประสบการณ์การใช้งานที่เน้น JavaScript เป็นหลัก โปรดตรวจสอบว่าได้ส่งเฉพาะโค้ดที่ผู้ใช้ต้องการเท่านั้น

ใช้ประโยชน์จากแนวคิดต่างๆ เช่น การแยกโค้ด สำรวจแนวคิดต่างๆ เช่น Tree Shaking และดูแนวคิดในการลดขนาดไลบรารีในรีพอส webpack-libs-optimizations หากใช้ webpack

ปรับขนาดภาพให้เหมาะสม

มุกตลกเกี่ยวกับประสิทธิภาพการโหลดรูปภาพ

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

เราลืมเพิ่มประสิทธิภาพรูปภาพ ไม่ได้ปรับขนาดรูปภาพให้ถูกต้อง และอาจได้ประโยชน์จากการใช้รูปแบบรูปภาพอื่นๆ

การตรวจสอบรูปภาพ
รูปที่ 14 การตรวจสอบรูปภาพด้วย Lighthouse

เราเริ่มด้วยการเพิ่มประสิทธิภาพรูปภาพ

สำหรับรอบการเพิ่มประสิทธิภาพแบบครั้งเดียว คุณสามารถใช้เครื่องมือภาพ เช่น ImageOptim หรือ XNConvert

แนวทางแบบอัตโนมัติมากขึ้นคือการเพิ่มขั้นตอนการเพิ่มประสิทธิภาพรูปภาพลงในกระบวนการสร้างด้วยไลบรารีอย่าง imagemin

วิธีนี้ช่วยให้มั่นใจได้ว่ารูปภาพที่เพิ่มในอนาคตจะได้รับการเพิ่มประสิทธิภาพโดยอัตโนมัติ CDN บางรายการ เช่น Akamai หรือโซลูชันของบุคคลที่สาม เช่น Cloudinary, Fastly หรือ Uploadcare มีโซลูชันการเพิ่มประสิทธิภาพรูปภาพที่ครอบคลุม คุณจึงโฮสต์รูปภาพในบริการเหล่านั้นได้ง่ายๆ

หากไม่ต้องการเนื่องจากปัญหาด้านต้นทุนหรือเวลาในการตอบสนอง โปรเจ็กต์อย่าง Thumbor หรือ Imageflow ก็มีทางเลือกในการโฮสต์ด้วยตนเอง

ก่อนและหลังการเพิ่มประสิทธิภาพ
รูปที่ 15 ก่อนและหลังการเพิ่มประสิทธิภาพ

ไฟล์ PNG พื้นหลังของเราถูกแจ้งว่ามีขนาดเกินใน webpack ซึ่งก็ถูกต้อง หลังจากปรับขนาดให้เหมาะกับวิวพอร์ตและส่งผ่าน ImageOptim แล้ว ไฟล์มีขนาดลดลงเหลือ 100 KB ซึ่งยอมรับได้

การทำซ้ำขั้นตอนนี้กับรูปภาพหลายรูปในเว็บไซต์ช่วยให้เราลดน้ำหนักหน้าเว็บโดยรวมได้อย่างมาก

ใช้รูปแบบที่เหมาะกับเนื้อหาภาพเคลื่อนไหว

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

ในแอป Oodle เราใช้ GIF เป็นลำดับอินโทรในหน้าแรก Lighthouse ระบุว่าเราอาจประหยัดพื้นที่ได้มากกว่า 7 MB ด้วยการเปลี่ยนไปใช้รูปแบบวิดีโอที่มีประสิทธิภาพมากขึ้น คลิปของเรามีน้ำหนักประมาณ 7.3 MB ซึ่งมากเกินกว่าที่เว็บไซต์ใดๆ จะรองรับได้ เราจึงเปลี่ยนเป็นองค์ประกอบวิดีโอที่มีไฟล์ต้นฉบับ 2 ไฟล์ ได้แก่ mp4 และ WebM เพื่อให้รองรับเบราว์เซอร์ได้มากขึ้น

แทนที่ GIF แบบเคลื่อนไหวด้วยวิดีโอ
รูปที่ 16 แทนที่ GIF แบบเคลื่อนไหวด้วยวิดีโอ

เราใช้เครื่องมือ FFmpeg เพื่อแปลง GIF แบบเคลื่อนไหวเป็นไฟล์ mp4 รูปแบบ WebM ช่วยประหยัดพื้นที่ได้มากกว่า โดย ImageOptim API จะทำการเปลี่ยนรูปแบบให้คุณ

ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4

เราลดน้ำหนักโดยรวมได้กว่า 80% จากการแปลงนี้ ซึ่งทำให้ไฟล์มีขนาดประมาณ 1MB

อย่างไรก็ตาม 1 MB เป็นทรัพยากรจำนวนมากที่จะส่งผ่านสายได้ โดยเฉพาะสำหรับผู้ใช้ที่มีแบนด์วิดท์จํากัด แต่โชคดีที่เราสามารถใช้ Effective Type API เพื่อทราบว่าผู้ใช้มีแบนด์วิดท์ต่ำ และแสดง JPEG ที่เล็กกว่ามากแทน

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

if (navigator.connection.effectiveType) { ... }

การดำเนินการนี้อาจทำให้ประสบการณ์การใช้งานลดลงไปบ้าง แต่อย่างน้อยเว็บไซต์ก็ใช้งานได้ในการเชื่อมต่อที่ช้า

โหลดรูปภาพนอกหน้าจอแบบ Lazy Loading

ภาพสไลด์ แถบเลื่อน หรือหน้าเว็บที่ยาวมากมักจะโหลดรูปภาพ แม้ว่าผู้ใช้จะไม่เห็นรูปภาพเหล่านั้นในหน้าเว็บในทันที

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

เบราว์เซอร์ยังไม่รองรับการโหลดแบบเลื่อนลงโดยค่าเริ่มต้น เราจึงต้องใช้ JavaScript เพื่อเพิ่มความสามารถนี้ เราใช้คลัง Lazysizes เพื่อเพิ่มลักษณะการโหลดแบบ Lazy Loading ลงในภาพปก Oodle

<!-- Import library -->
import lazysizes from 'lazysizes'  <!-- or -->
<script src="lazysizes.min.js"></script>

<!-- Use it -->

<img data-src="image.jpg" class="lazyload"/>
<img class="lazyload"
    data-sizes="auto"
    data-src="image2.jpg"
    data-srcset="image1.jpg 300w,
    image2.jpg 600w,
    image3.jpg 900w"/>

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

หลังจากการเปลี่ยนแปลงนี้ ระบบจะดึงข้อมูลรูปภาพตามคําขอ หากต้องการเจาะลึกหัวข้อนี้ ให้ไปที่ images.guide ซึ่งเป็นแหล่งข้อมูลที่มีประโยชน์และครอบคลุมมาก

ช่วยให้เบราว์เซอร์แสดงทรัพยากรสําคัญได้ตั้งแต่เนิ่นๆ

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

สิ่งที่อาจเป็นประโยชน์คือเราในฐานะผู้เขียนหน้าเว็บจะแจ้งให้เบราว์เซอร์ทราบว่าสิ่งใดสำคัญกับเราจริงๆ โชคดีที่ในช่วง 2-3 ปีที่ผ่านมา ผู้ให้บริการเบราว์เซอร์ได้เพิ่มฟีเจอร์ต่างๆ เพื่อช่วยเราในเรื่องนี้ เช่น คำแนะนำแหล่งข้อมูล เช่น link rel=preconnect หรือ preload หรือ prefetch

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

มาดูว่า Lighthouse แนะนําให้เราใช้ฟีเจอร์บางอย่างเหล่านี้อย่างมีประสิทธิภาพได้อย่างไร

สิ่งแรกที่ Lighthouse บอกให้เราทําคือหลีกเลี่ยงการไปและกลับหลายครั้งไปยังต้นทางใดๆ ซึ่งทําให้สิ้นเปลือง

หลีกเลี่ยงการเดินทางหลายเที่ยวไปและกลับจากต้นทางซึ่งทำให้สิ้นเปลือง
รูปที่ 17 หลีกเลี่ยงการเดินทางไป-กลับหลายครั้งที่มีค่าใช้จ่ายสูงไปยังต้นทางใดก็ได้

ในกรณีของแอป Oodle เราใช้ Google Fonts อย่างมาก เมื่อคุณวางสไตล์ชีต Google Font ลงในหน้าเว็บ ระบบจะเชื่อมต่อโดเมนย่อยได้สูงสุด 2 รายการ และสิ่งที่ Lighthouse บอกเราก็คือ หากอุ่นเครื่องการเชื่อมต่อได้ เราจะประหยัดเวลาในการเชื่อมต่อครั้งแรกได้สูงสุด 300 มิลลิวินาที

การใช้ rel=preconnect ของลิงก์ช่วยให้เรามาสก์เวลาในการตอบสนองของการเชื่อมต่อได้อย่างมีประสิทธิภาพ

โดยเฉพาะอย่างยิ่งกับบริการอย่าง Google Fonts ที่โฮสต์ CSS ของแบบอักษรใน googleapis.com และโฮสต์แหล่งข้อมูลแบบอักษรใน Gstatic ซึ่งอาจส่งผลอย่างมาก เราจึงใช้การเพิ่มประสิทธิภาพนี้และลดเวลาได้หลายร้อยมิลลิวินาที

สิ่งถัดไปที่ Lighthouse แนะนําคือให้โหลดคําขอคีย์ล่วงหน้า

โหลดคําขอคีย์ล่วงหน้า
รูปที่ 18 โหลดคำขอคีย์ล่วงหน้า

<link rel=preload> มีประสิทธิภาพมาก โดยจะแจ้งให้เบราว์เซอร์ทราบว่าต้องใช้ทรัพยากรเป็นส่วนหนึ่งของการนําทางปัจจุบัน และพยายามให้เบราว์เซอร์ดึงข้อมูลดังกล่าวโดยเร็วที่สุด

ตอนนี้ Lighthouse บอกเราว่าเราควรไปโหลดทรัพยากรแบบอักษรเว็บหลักล่วงหน้า เนื่องจากเรากําลังโหลดแบบอักษรเว็บ 2 แบบ

การโหลดล่วงหน้าในแบบอักษรเว็บมีลักษณะดังนี้ เมื่อระบุ rel=preload ให้ส่ง as พร้อมประเภทแบบอักษร จากนั้นระบุประเภทแบบอักษรที่พยายามโหลด เช่น woff2

ผลกระทบที่อาจเกิดขึ้นกับหน้าเว็บของคุณนั้นค่อนข้างชัดเจน

ผลกระทบของการโหลดทรัพยากรล่วงหน้า
รูปที่ 19 ผลของการโหลดทรัพยากรล่วงหน้า

โดยปกติแล้ว หากไม่ได้ใช้การโหลดล่วงหน้าของ rel ของลิงก์ และหากเว็บฟอนต์มีความสำคัญต่อหน้าเว็บ สิ่งแรกที่เบราว์เซอร์ต้องทำคือต้องดึงข้อมูล HTML, ต้องแยกวิเคราะห์ CSS และหลังจากนั้นอีกนาน เบราว์เซอร์ก็จะไปดึงข้อมูลเว็บฟอนต์

เมื่อใช้การโหลดล่วงหน้าของ rel ลิงก์ เบราว์เซอร์จะเริ่มดึงข้อมูลแบบอักษรเว็บเหล่านั้นได้เร็วขึ้นมากทันทีที่แยกวิเคราะห์ HTML ในกรณีของแอปของเรา การดำเนินการนี้ช่วยประหยัดเวลาในการเรนเดอร์ข้อความโดยใช้แบบอักษรเว็บได้ 1 วินาที

แต่การพยายามโหลดแบบอักษรล่วงหน้าโดยใช้ Google Fonts นั้นไม่ง่ายอย่างที่คิด เนื่องจากมีข้อควรระวังอยู่อย่างหนึ่ง

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

ในกรณีของเรา เราพบว่าเครื่องมือตัวช่วย Web Fonts ของ Google มีประโยชน์มากในการช่วยเราออฟไลน์ Web Fonts บางรายการและตั้งค่าในเครื่อง ดังนั้นโปรดลองใช้เครื่องมือดังกล่าว

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

ทดลองใช้: คำแนะนำเกี่ยวกับลําดับความสําคัญ

วันนี้เรามีเรื่องพิเศษมาแจ้งให้ทราบ นอกจากฟีเจอร์อย่างคำแนะนำทรัพยากรและการโหลดล่วงหน้าแล้ว เรายังพัฒนาฟีเจอร์ใหม่ล่าสุดสำหรับเบราว์เซอร์ที่ชื่อ "คำแนะนำลําดับความสําคัญ"

กำหนดลำดับความสำคัญของเนื้อหาที่แสดงตั้งแต่แรก
รูปที่ 20 คำแนะนำเกี่ยวกับลำดับความสำคัญ

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

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

ในกรณีของแอป Oodle ของเรา ข้อมูลนี้ช่วยให้เราเพิ่มประสิทธิภาพได้ในที่เดียว

กำหนดลำดับความสำคัญของเนื้อหาที่แสดงตั้งแต่แรก
รูปที่ 21 กำหนดลำดับความสำคัญสำหรับเนื้อหาที่แสดงตั้งแต่ต้น

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

เราหวังว่าจะให้บริการฟีเจอร์นี้ใน Canary ในอีก 2-3 สัปดาห์ข้างหน้า โปรดคอยติดตาม

มีกลยุทธ์การโหลดแบบอักษรเว็บ

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

ตอนนี้เราไฮไลต์ปัญหานี้ใน Lighthouse ด้วยการตรวจสอบหลีกเลี่ยงข้อความที่มองไม่เห็นขณะที่โหลดเว็บฟอนต์

หลีกเลี่ยงข้อความที่มองไม่เห็นขณะที่เว็บฟอนต์กำลังโหลด
รูปที่ 22 หลีกเลี่ยงข้อความที่มองไม่เห็นขณะที่เว็บฟอนต์กำลังโหลด

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

เราพยายามหลีกเลี่ยงข้อความที่มองไม่เห็นนี้ ดังนั้นในกรณีนี้ เราอาจไม่เห็นภาพวาด Doodle แบบคลาสสิกประจำสัปดาห์นี้หากเว็บแบบอักษรใช้เวลานานเกินไป แต่คุณควบคุมกระบวนการนี้ได้มากขึ้นด้วยฟีเจอร์ใหม่ที่เรียกว่า font-display

    @font-face {
      font-family: 'Montserrat';
      font-style: normal;
      font-display: swap;
      font-weight: 400;
      src: local('Montserrat Regular'), local('Montserrat-Regular'),
          /* Chrome 26+, Opera 23+, Firefox 39+ */
          url('montserrat-v12-latin-regular.woff2') format('woff2'),
            /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
          url('montserrat-v12-latin-regular.woff') format('woff');
    }

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

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

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

ผลลัพธ์การแสดงแบบอักษร
รูปที่ 23 ผลลัพธ์การแสดงแบบอักษร

โดยทั่วไปแล้ว หากคุณใช้แบบอักษรเว็บ (เช่นเดียวกับเว็บไซต์ส่วนใหญ่) ก็ควรมีกลยุทธ์การโหลดแบบอักษรเว็บที่ดี

แพลตฟอร์มเว็บมีฟีเจอร์มากมายที่คุณสามารถใช้เพื่อเพิ่มประสิทธิภาพประสบการณ์การโหลดแบบอักษร แต่อย่าลืมดูที่เก็บ Web Font Recipes ของ Zach Leatherman ด้วย เพราะดีมาก

ลดสคริปต์ที่บล็อกการแสดงผล

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

ในแถบไทม์ไลน์ของ Lighthouse คุณจะเห็นได้ว่าในช่วง 2-3 วินาทีแรกนี้เมื่อทรัพยากรทั้งหมดกำลังโหลด ผู้ใช้จะไม่เห็นเนื้อหาใดๆ เลย

ลดโอกาสที่จะมีสไตล์ชีตที่บล็อกการแสดงผล
รูปที่ 24 ลดโอกาสที่จะมีสไตล์ชีตที่บล็อกการแสดงผล

การดาวน์โหลดและการประมวลผลสไตล์ชีตภายนอกกําลังบล็อกกระบวนการแสดงผลของเราไม่ให้ดําเนินการต่อ

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

หากเราดึงสไตล์ที่รับผิดชอบการแสดงผลเริ่มต้นนี้และแทรกไว้ใน HTML เบราว์เซอร์จะแสดงผลได้ทันทีโดยไม่ต้องรอให้สไตล์ชีตภายนอกมาถึง

ในกรณีของเรา เราใช้โมดูล NPM ชื่อ Critical เพื่อแทรกเนื้อหาที่สําคัญในหน้า index.html ในระหว่างขั้นตอนการสร้าง

แม้ว่าโมดูลนี้จะทํางานหนักส่วนใหญ่ให้เรา แต่ก็ยังทําให้ระบบทํางานได้อย่างราบรื่นในเส้นทางต่างๆ ได้ค่อนข้างยาก

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

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

ท้ายที่สุดแล้ว ความเสี่ยงของเราก็คุ้มค่า เราทําให้ใช้งานได้และแอปเริ่มแสดงเนื้อหาได้เร็วขึ้นมาก ซึ่งช่วยปรับปรุงเวลาการแสดงผลที่มีความหมายครั้งแรกได้อย่างมาก

ผลลัพธ์

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

คะแนนประสิทธิภาพของ Lighthouse เพิ่มขึ้นจาก 23 เป็น 91 นี่เป็นความคืบหน้าที่ดีมากในแง่ความเร็ว การเปลี่ยนแปลงทั้งหมดเกิดขึ้นจากการตรวจสอบและปฏิบัติตามรายงาน Lighthouse อย่างต่อเนื่อง หากต้องการดูว่าเราติดตั้งใช้งานการปรับปรุงทั้งหมดทางเทคนิคอย่างไร โปรดไปที่รีโปของเรา โดยเฉพาะ PR ที่อัปโหลดในนั้น

ประสิทธิภาพการคาดการณ์ - ประสบการณ์ของผู้ใช้ที่อิงตามข้อมูล

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

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

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

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

การรวมแอปโดยอิงตามข้อมูลสําหรับเว็บแอป
รูปที่ 25 การรวมกลุ่มที่อิงตามข้อมูลสําหรับเว็บแอป

เรายินดีที่จะประกาศโครงการริเริ่มใหม่ที่มีชื่อว่า Guess.js เพื่ออำนวยความสะดวกในการทดสอบนี้

Guess.js
รูปที่ 26 Guess.js

Guess.js เป็นโปรเจ็กต์ที่มุ่งเน้นประสบการณ์ของผู้ใช้ที่อิงตามข้อมูลสําหรับเว็บ เราหวังว่ารายงานนี้จะกระตุ้นให้เกิดการสำรวจการใช้ข้อมูลเพื่อปรับปรุงประสิทธิภาพของเว็บและอื่นๆ ทั้งหมดนี้ล้วนเป็นโอเพนซอร์สและพร้อมให้ใช้งานบน GitHub แล้ววันนี้ เครื่องมือนี้สร้างขึ้นโดย Minko Gechev, Kyle Matthews จาก Gatsby, Katie Hempenius และคนอื่นๆ อีกมากมายจากชุมชนโอเพนซอร์ส

ลองใช้ Guess.js แล้วบอกให้เราทราบว่าคุณคิดอย่างไร

สรุป

คะแนนและเมตริกมีประโยชน์ในการปรับปรุงความเร็วของเว็บ แต่เป็นเพียงวิธี ไม่ใช่เป้าหมาย

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

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

ขอขอบคุณเป็นพิเศษ Ward Peeters, Minko Gechev, Kyle Mathews, Katie Hempenius, Dom Farolino, Yoav Weiss, Susie Lu, Yusuke Utsunomiya, Tom Ankers, Lighthouse และ Google Doodles