ในงาน Google IO 2018 เราได้นำเสนอสรุปเครื่องมือ ไลบรารี และเทคนิคการเพิ่มประสิทธิภาพที่ช่วยให้การปรับปรุงประสิทธิภาพเว็บเป็นเรื่องง่าย ในที่นี้เราจะอธิบายโดยใช้แอป The Oodles Theater นอกจากนี้ เรายังจะพูดถึงการทดสอบการโหลดแบบคาดการณ์และโครงการริเริ่ม Guess.js ใหม่ด้วย
ในช่วงปีที่ผ่านมา เราทำงานกันอย่างหนักเพื่อหาวิธีทำให้เว็บเร็วขึ้นและมีประสิทธิภาพมากขึ้น ซึ่งนำไปสู่เครื่องมือ แนวทาง และไลบรารีใหม่ๆ ที่เราอยากจะแชร์ให้คุณทราบในบทความนี้ ในส่วนแรก เราจะแสดงเทคนิคการเพิ่มประสิทธิภาพบางอย่างที่เราใช้ในทางปฏิบัติ เมื่อพัฒนาแอป The Oodles Theater ในส่วนที่ 2 เราจะพูดถึงการทดสอบการโหลดแบบคาดการณ์และโครงการริเริ่มใหม่ของ Guess.js
ความจำเป็นในการวัดประสิทธิภาพ
อินเทอร์เน็ตมีขนาดใหญ่ขึ้นเรื่อยๆ ทุกปี หากเราตรวจสอบสถานะของเว็บ เราจะเห็นว่าหน้าเว็บค่ามัธยฐานในอุปกรณ์เคลื่อนที่มีขนาดประมาณ 1.5 MB โดยส่วนใหญ่เป็น JavaScript และรูปภาพ
ขนาดของเว็บไซต์ที่เพิ่มขึ้นประกอบกับปัจจัยอื่นๆ เช่น เวลาในการตอบสนองของเครือข่าย ข้อจำกัดของ CPU รูปแบบการบล็อกการแสดงผล หรือโค้ดของบุคคลที่สามที่ไม่จำเป็น ล้วนเป็นสาเหตุที่ทำให้ประสิทธิภาพกลายเป็นปริศนาที่ซับซ้อน
ผู้ใช้ส่วนใหญ่จัดอันดับความเร็วไว้ที่ด้านบนสุดของลำดับชั้น UX ของความต้องการ ซึ่งก็ไม่น่าแปลกใจนัก เพราะคุณทำอะไรไม่ได้มากนักจนกว่าหน้าเว็บจะโหลดเสร็จ คุณไม่สามารถ ดึงคุณค่าจากหน้าเว็บ หรือชื่นชมความสวยงามของหน้าเว็บได้
เราทราบว่าประสิทธิภาพเป็นสิ่งสำคัญสำหรับผู้ใช้ แต่ก็อาจรู้สึกเหมือนเป็นความลับในการค้นหา จุดเริ่มต้นของการเพิ่มประสิทธิภาพ โชคดีที่มีเครื่องมือที่จะช่วยคุณได้
Lighthouse - ฐานสำหรับเวิร์กโฟลว์ด้านประสิทธิภาพ
Lighthouse เป็นส่วนหนึ่งของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ที่ช่วยให้คุณตรวจสอบเว็บไซต์และให้คำแนะนำเกี่ยวกับวิธีปรับปรุงเว็บไซต์
เมื่อเร็วๆ นี้ เราได้เปิดตัว การตรวจสอบประสิทธิภาพใหม่ๆ มากมาย ซึ่งมีประโยชน์อย่างยิ่งในเวิร์กโฟลว์การพัฒนาในแต่ละวัน
มาดูวิธีใช้ประโยชน์จากฟีเจอร์เหล่านี้ในตัวอย่างการใช้งานจริงกัน แอป Oodles Theater ซึ่งเป็นเว็บแอปเดโมขนาดเล็ก ที่คุณสามารถลองใช้ Google Doodle แบบอินเทอร์แอกทีฟรายการโปรดของเรา รวมถึงเล่นเกมได้ด้วย
ในระหว่างการสร้างแอป เราต้องการให้แอปมีประสิทธิภาพมากที่สุด จุดเริ่มต้น ของการเพิ่มประสิทธิภาพคือรายงาน Lighthouse
ประสิทธิภาพเริ่มต้นของแอปตามที่เห็นในรายงาน Lighthouse นั้นแย่มาก ในเครือข่าย 3G ผู้ใช้ต้องรอ 15 วินาทีเพื่อให้แสดงผลครั้งแรกที่มีความหมาย หรือรอให้แอปโต้ตอบได้ Lighthouse ไฮไลต์ปัญหามากมายในเว็บไซต์ของเรา และคะแนนประสิทธิภาพโดยรวมที่23 ก็สะท้อนให้เห็นถึงปัญหานั้น
หน้าเว็บมีขนาดประมาณ 3.4 MB เราจึงจำเป็นต้องลดขนาด
ซึ่งเป็นจุดเริ่มต้นของความท้าทายด้านประสิทธิภาพครั้งแรกของเรา นั่นคือการค้นหาสิ่งที่เรานำออกได้ง่ายๆ โดยไม่ส่งผลต่อประสบการณ์โดยรวม
โอกาสในการเพิ่มประสิทธิภาพ
นำทรัพยากรที่ไม่จำเป็นออก
มีบางอย่างที่เห็นได้ชัดซึ่งนำออกได้อย่างปลอดภัย ได้แก่ ช่องว่างและความคิดเห็น
Lighthouse จะไฮไลต์โอกาสนี้ในการตรวจสอบ CSS และ JavaScript ที่ไม่ได้ย่อ เราใช้ Webpack สำหรับกระบวนการบิลด์ ดังนั้นหากต้องการลดขนาด เราจึงใช้ ปลั๊กอิน Uglify JS
การย่อขนาดเป็นงานที่พบได้ทั่วไป ดังนั้นคุณจึงควรหาโซลูชันสำเร็จรูปสำหรับกระบวนการบิลด์ที่คุณใช้
การตรวจสอบอีกอย่างที่มีประโยชน์ในพื้นที่นั้นคือเปิดใช้การบีบอัดข้อความ คุณไม่จำเป็นต้องส่งไฟล์ที่ไม่ได้บีบอัด และปัจจุบัน CDN ส่วนใหญ่รองรับการบีบอัดไฟล์
เราใช้ Firebase Hosting เพื่อโฮสต์โค้ด และ Firebase เปิดใช้ gzipping โดยค่าเริ่มต้น ดังนั้นการโฮสต์โค้ดใน CDN ที่เหมาะสมจึงทำให้เราได้ฟีเจอร์นี้มาโดยอัตโนมัติ
แม้ว่า gzip จะเป็นวิธีบีบอัดที่ได้รับความนิยมอย่างมาก แต่กลไกอื่นๆ เช่น Zopfli และ Brotli ก็เริ่มได้รับความนิยมเช่นกัน เบราว์เซอร์ส่วนใหญ่รองรับ Brotli และคุณสามารถใช้ไบนารี เพื่อบีบอัดชิ้นงานล่วงหน้าก่อนส่งไปยังเซิร์ฟเวอร์
ใช้นโยบายแคชที่มีประสิทธิภาพ
ขั้นตอนถัดไปของเราคือการตรวจสอบว่าเราจะไม่ส่งทรัพยากร 2 ครั้งหากไม่จำเป็น
การตรวจสอบนโยบายแคชที่ไม่มีประสิทธิภาพใน Lighthouse ช่วยให้เราทราบว่าเราสามารถเพิ่มประสิทธิภาพ กลยุทธ์การแคชเพื่อให้บรรลุเป้าหมายดังกล่าวได้ การตั้งค่าส่วนหัวการหมดอายุ max-age ในเซิร์ฟเวอร์ของเราช่วยให้มั่นใจได้ว่าเมื่อผู้ใช้เข้าชมซ้ำ ผู้ใช้จะใช้ทรัพยากรที่ดาวน์โหลดไว้ก่อนหน้านี้ซ้ำได้
ในอุดมคติ คุณควรตั้งเป้าหมายที่จะแคชทรัพยากรให้ได้มากที่สุดอย่างปลอดภัยเป็นระยะเวลานานที่สุดเท่าที่จะเป็นไปได้ และระบุโทเค็นการตรวจสอบเพื่อตรวจสอบทรัพยากรที่อัปเดตแล้วอีกครั้งอย่างมีประสิทธิภาพ
ลบโค้ดที่ไม่ได้ใช้งาน
จนถึงตอนนี้ เราได้นำส่วนที่เห็นได้ชัดของการดาวน์โหลดที่ไม่จำเป็นออกไปแล้ว แต่ส่วนที่เห็นได้ไม่ชัดล่ะ เช่น โค้ดที่ไม่ได้ใช้
บางครั้งเราก็ใส่โค้ดที่ไม่จำเป็นลงในแอป โดยเฉพาะอย่างยิ่งหากคุณทำงานกับแอปเป็นระยะเวลานาน ทีมหรือการอ้างอิงมีการเปลี่ยนแปลง และบางครั้งอาจมีไลบรารีที่ไม่มีการอ้างอิงเหลืออยู่ ซึ่งเราก็เคยเจอเหตุการณ์แบบนี้
ในช่วงแรก เราใช้ไลบรารีคอมโพเนนต์ Material เพื่อสร้างต้นแบบแอปอย่างรวดเร็ว ต่อมาเราได้เปลี่ยนไปใช้รูปลักษณ์ที่กำหนดเองมากขึ้นและลืมไลบรารีนั้นไปโดยสิ้นเชิง โชคดีที่การตรวจสอบความครอบคลุมของโค้ดช่วยให้เราค้นพบอีกครั้งในแพ็กเกจ
คุณสามารถดูสถิติความครอบคลุมของโค้ดใน DevTools ได้ทั้งสำหรับรันไทม์และเวลาในการโหลดของแอปพลิเคชัน คุณจะเห็นแถบสีแดงขนาดใหญ่ 2 แถบในภาพหน้าจอด้านล่าง ซึ่งแสดงว่าเราไม่ได้ใช้ CSS มากกว่า 95% และยังมี JavaScript อีกจำนวนมากด้วย
Lighthouse ยังพบปัญหานี้ในการตรวจสอบกฎ CSS ที่ไม่ได้ใช้ด้วย ซึ่งแสดงให้เห็นว่าอาจประหยัดได้ มากกว่า 400 KB เราจึงกลับไปที่โค้ดและนำทั้งส่วน JavaScript และ CSS ของไลบรารีนั้นออก
ซึ่งทำให้เราลดขนาดแพ็กเกจ CSS ลงได้ถึง 20 เท่า ซึ่งถือว่าดีมากสำหรับคอมมิตขนาดเล็กที่มีความยาว 2 บรรทัด
แน่นอนว่าการดำเนินการนี้ทำให้คะแนนประสิทธิภาพของเราเพิ่มขึ้น และยังทำให้เวลาในการโต้ตอบ ดีขึ้นมากด้วย
อย่างไรก็ตาม การเปลี่ยนแปลงเช่นนี้ทำให้การตรวจสอบเมตริกและคะแนนเพียงอย่างเดียวไม่เพียงพอ การนำโค้ดจริงออกมีความเสี่ยงเสมอ ดังนั้นคุณควรระวังการถดถอยที่อาจเกิดขึ้นอยู่เสมอ
เราไม่ได้ใช้โค้ดใน 95% แต่ก็ยังมีอีก 5% ที่ยังคงอยู่ ดูเหมือนว่าคอมโพเนนต์หนึ่งของเรา ยังคงใช้รูปแบบจากไลบรารีนั้นอยู่ ซึ่งก็คือลูกศรเล็กๆ ในแถบเลื่อน Doodle แต่เนื่องจากมีขนาดเล็กมาก เราจึงสามารถไปรวมสไตล์เหล่านั้นกลับเข้าไปในปุ่มด้วยตนเองได้
ดังนั้นหากคุณนำโค้ดออก โปรดตรวจสอบว่าคุณมีเวิร์กโฟลว์การทดสอบที่เหมาะสมเพื่อช่วย ป้องกันการถดถอยของภาพที่อาจเกิดขึ้น
หลีกเลี่ยงเพย์โหลดเครือข่ายปริมาณมาก
เราทราบดีว่าทรัพยากรขนาดใหญ่อาจทำให้การโหลดหน้าเว็บช้าลง ซึ่งอาจทำให้ผู้ใช้เสียเงินและส่งผลกระทบอย่างมากต่อแพ็กเกจอินเทอร์เน็ตของผู้ใช้ ดังนั้นจึงควรคำนึงถึงเรื่องนี้
Lighthouse ตรวจพบว่าเรามีปัญหาเกี่ยวกับเพย์โหลดเครือข่ายบางรายการโดยใช้การตรวจสอบเพย์โหลดเครือข่ายขนาดใหญ่
ในที่นี้ เราพบว่ามีโค้ดมากกว่า 3 MB ที่ส่งลงมา ซึ่งถือว่ามีปริมาณมาก โดยเฉพาะบนอุปกรณ์เคลื่อนที่
ที่ด้านบนสุดของรายการนี้ Lighthouse ไฮไลต์ว่าเรามี JavaScript Vendor Bundle ซึ่งเป็นโค้ดที่ไม่ได้บีบอัดขนาด 2 MB ซึ่งเป็นปัญหาที่ webpack เน้นย้ำด้วย
ดังที่กล่าวไว้ว่า คำขอที่เร็วที่สุดคือคำขอที่ไม่ได้ส่ง
ในอุดมคติ คุณควรวัดมูลค่าของชิ้นงานทุกชิ้นที่แสดงต่อผู้ใช้ วัดประสิทธิภาพของชิ้นงานเหล่านั้น และพิจารณาว่าคุ้มค่าที่จะจัดส่ง พร้อมกับประสบการณ์เริ่มต้นหรือไม่ เนื่องจากบางครั้งระบบอาจเลื่อนการแสดงชิ้นงานเหล่านี้ออกไป หรือโหลดแบบ Lazy Loading หรือประมวลผลในช่วงเวลาที่ไม่มีการใช้งาน
ในกรณีของเรา เนื่องจากเราต้องจัดการกับ JavaScript Bundle จำนวนมาก เราจึงโชคดีเพราะชุมชน JavaScript มีเครื่องมือตรวจสอบ JavaScript Bundle มากมาย
เราเริ่มต้นด้วยเครื่องมือวิเคราะห์บันเดิลของ webpack ซึ่งแจ้งให้เราทราบว่าเราได้รวม การอ้างอิงที่ชื่อว่า unicode ซึ่งเป็น JavaScript ที่แยกวิเคราะห์แล้วขนาด 1.6 MB ซึ่งถือว่าค่อนข้างมาก
จากนั้นเราก็ไปที่โปรแกรมแก้ไขและใช้ ปลั๊กอินนำเข้าต้นทุนสำหรับ Visual Code เราก็สามารถ แสดงภาพต้นทุนของทุกโมดูลที่เรานำเข้าได้ ซึ่งช่วยให้เราทราบว่าคอมโพเนนต์ใดมีโค้ดที่อ้างอิงโมดูลนี้
จากนั้นเราก็เปลี่ยนไปใช้เครื่องมืออื่นคือ BundlePhobia ซึ่งเป็นเครื่องมือ ที่ช่วยให้คุณป้อนชื่อแพ็กเกจ NPM ใดก็ได้และดูขนาดที่คาดการณ์ไว้ของแพ็กเกจที่ย่อและ บีบอัดด้วย Gzip เราพบโมดูลสลักทางเลือกที่ดีที่เราใช้ ซึ่งมีขนาดเพียง 2.2 KB เราจึงเปลี่ยนไปใช้โมดูลดังกล่าว
ซึ่งส่งผลต่อประสิทธิภาพของเราเป็นอย่างมาก การเปลี่ยนแปลงนี้และโอกาสอื่นๆ ที่เราค้นพบในการลดขนาด JavaScript Bundle ทำให้เราประหยัดโค้ดไปได้ 2.1 MB
เราพบว่าโดยรวมแล้วดีขึ้น 65% เมื่อพิจารณาขนาดที่บีบอัดและลดขนาดของแพ็กเกจเหล่านี้ และเราพบว่ากระบวนการนี้คุ้มค่าที่จะทำจริงๆ
ดังนั้น โดยทั่วไปแล้ว ให้พยายามหลีกเลี่ยงการดาวน์โหลดที่ไม่จำเป็นในเว็บไซต์และแอป การทำรายการชิ้นงานและวัดผลกระทบต่อประสิทธิภาพจะสร้างความแตกต่างได้อย่างมาก ดังนั้นโปรดตรวจสอบชิ้นงานอย่างสม่ำเสมอ
ลดเวลาเริ่มต้นของ JavaScript ด้วยการแยกโค้ด
แม้ว่าเพย์โหลดเครือข่ายขนาดใหญ่อาจส่งผลกระทบอย่างมากต่อแอป แต่ก็ยังมีอีกสิ่งหนึ่งที่อาจส่งผลกระทบอย่างมากเช่นกัน นั่นก็คือ JavaScript
JavaScript คือชิ้นงานที่มีราคาแพงที่สุด ในอุปกรณ์เคลื่อนที่ หากคุณส่ง JavaScript จำนวนมาก การดำเนินการนี้อาจทำให้ผู้ใช้โต้ตอบกับคอมโพเนนต์ของอินเทอร์เฟซผู้ใช้ ได้ช้าลง ซึ่งหมายความว่าผู้ใช้สามารถแตะ UI โดยไม่มีการดำเนินการใดๆ ที่มีความหมายเกิดขึ้นจริง เราจึงต้องทำความเข้าใจว่าทำไม JavaScript ถึงมีค่าใช้จ่ายสูงมาก
นี่คือวิธีที่เบราว์เซอร์ประมวลผล JavaScript
ก่อนอื่นเราต้องดาวน์โหลดสคริปต์นั้น เรามีเครื่องมือ JavaScript ซึ่งจะต้องแยกวิเคราะห์ โค้ดนั้น ต้องคอมไพล์และเรียกใช้
ตอนนี้ระยะต่างๆ เหล่านี้ไม่ได้ใช้เวลานานนักในอุปกรณ์ระดับไฮเอนด์ เช่น เครื่องเดสก์ท็อปหรือแล็ปท็อป หรือแม้แต่โทรศัพท์ระดับไฮเอนด์ แต่ในโทรศัพท์มือถือทั่วไป กระบวนการนี้อาจใช้เวลานานกว่า 5-10 เท่า ซึ่งเป็นสิ่งที่ทำให้เกิดความล่าช้าในการโต้ตอบ เราจึงควรพยายามลดขนาดลง
เราจึงได้เพิ่มการตรวจสอบเวลาเริ่มต้นของ JavaScript ใหม่ลงใน Lighthouse เพื่อช่วยให้คุณค้นพบปัญหาเหล่านี้ในแอป
และในกรณีของแอป Oodle แอปนี้บอกเราว่าเราใช้เวลา 1.8 วินาทีในการบูต JavaScript สิ่งที่เราทำคือการนำเข้าแบบคงที่ในเส้นทางและคอมโพเนนต์ทั้งหมดของเราลงในแพ็กเกจ JavaScript แบบ Monolithic
เทคนิคหนึ่งในการหลีกเลี่ยงปัญหานี้คือการใช้การแยกโค้ด
การแยกโค้ดคือแนวคิดที่ว่าแทนที่จะให้ JavaScript แก่ผู้ใช้ทั้งพิซซ่า จะเกิดอะไรขึ้นหากคุณให้ผู้ใช้เพียงชิ้นเดียวในแต่ละครั้งตามที่ต้องการ
การแยกโค้ดสามารถใช้ได้ที่ระดับเส้นทางหรือระดับคอมโพเนนต์ โดยทำงานร่วมกับ React และ React Loadable, Vue.js, Angular, Polymer, Preact และไลบรารีอื่นๆ อีกมากมายได้เป็นอย่างดี
เราได้รวมการแยกโค้ดไว้ในแอปพลิเคชันของเรา โดยเปลี่ยนจากการนำเข้าแบบคงที่เป็นการนำเข้าแบบไดนามิก ซึ่งช่วยให้เราโหลดโค้ดแบบเลซีโหลดแบบไม่พร้อมกันได้ตามต้องการ
การเปลี่ยนแปลงนี้ส่งผลให้ทั้งขนาดของแพ็กเกจลดลงและเวลาเริ่มต้นของ JavaScript ลดลง ซึ่งลดเวลาในการโหลดลงเหลือ 0.78 วินาที ทำให้แอปเร็วขึ้น 56%
โดยทั่วไป หากคุณกำลังสร้างประสบการณ์การใช้งานที่ใช้ JavaScript เป็นหลัก โปรดตรวจสอบว่าได้ส่งเฉพาะโค้ดที่ผู้ใช้ต้องการ เท่านั้น
ใช้ประโยชน์จากแนวคิดต่างๆ เช่น การแยกโค้ด สำรวจแนวคิดต่างๆ เช่น การกำจัดโค้ดที่ไม่ได้ใช้ และดูที่ webpack-libs-optimizations เพื่อดูแนวคิดบางอย่างเกี่ยวกับวิธีลดขนาดไลบรารีหากคุณใช้ Webpack
ปรับขนาดภาพให้เหมาะสม
ในแอป Oodle เราใช้รูปภาพจำนวนมาก แต่ Lighthouse ไม่ได้ตื่นเต้นกับเรื่องนี้เท่าเรา ในความเป็นจริง เราไม่ผ่านการตรวจสอบที่เกี่ยวข้องกับรูปภาพทั้ง 3 รายการ
เราลืมเพิ่มประสิทธิภาพรูปภาพ ไม่ได้ปรับขนาดรูปภาพอย่างถูกต้อง และยังอาจได้รับประโยชน์จากการใช้รูปแบบรูปภาพอื่นๆ ด้วย
เราเริ่มต้นด้วยการเพิ่มประสิทธิภาพรูปภาพ
สำหรับการเพิ่มประสิทธิภาพแบบครั้งเดียว คุณสามารถใช้เครื่องมือแบบภาพ เช่น ImageOptim หรือ XNConvert
แนวทางที่อัตโนมัติมากขึ้นคือการเพิ่มขั้นตอนการเพิ่มประสิทธิภาพรูปภาพลงในกระบวนการบิลด์ด้วยไลบรารี เช่น imagemin
วิธีนี้จะช่วยให้มั่นใจได้ว่ารูปภาพที่เพิ่มในอนาคตจะได้รับการเพิ่มประสิทธิภาพโดยอัตโนมัติ CDN บางรายการ เช่น Akamai หรือโซลูชันของบุคคลที่สาม เช่น Cloudinary, Fastly หรือ Uploadcare มีโซลูชันการเพิ่มประสิทธิภาพรูปภาพที่ครอบคลุม ให้คุณใช้ ดังนั้นคุณจึงโฮสต์รูปภาพในบริการเหล่านั้นได้เช่นกัน
หากไม่ต้องการทำเช่นนั้นเนื่องจากค่าใช้จ่ายหรือปัญหาความหน่วง โปรเจ็กต์อย่าง Thumbor หรือ Imageflow มี ทางเลือกที่โฮสต์ด้วยตนเอง
PNG พื้นหลังของเราได้รับการแจ้งใน webpack ว่ามีขนาดใหญ่ ซึ่งก็เป็นเช่นนั้นจริงๆ หลังจากปรับขนาดให้ถูกต้องตามวิวพอร์ตและเรียกใช้ผ่าน ImageOptim เราก็ลดขนาดลงเหลือ 100 KB ซึ่งเป็นขนาดที่ยอมรับได้
การทำเช่นนี้กับรูปภาพหลายรูปในเว็บไซต์ช่วยให้เราลดขนาดหน้าเว็บโดยรวมลงได้อย่างมาก
ใช้รูปแบบที่เหมาะสมสำหรับเนื้อหาภาพเคลื่อนไหว
GIF อาจมีราคาแพงมาก ที่น่าแปลกใจคือแต่เดิมรูปแบบ GIF ไม่ได้มีไว้เป็นแพลตฟอร์มภาพเคลื่อนไหว ดังนั้น การเปลี่ยนไปใช้รูปแบบวิดีโอที่เหมาะสมกว่าจะช่วยให้คุณประหยัดพื้นที่ ขนาดไฟล์ได้มาก
ในแอป Oodle เราใช้ GIF เป็นลำดับการเปิดตัวในหน้าแรก Lighthouse ระบุว่าเราอาจประหยัดพื้นที่ได้มากกว่า 7 MB หากเปลี่ยนไปใช้รูปแบบวิดีโอที่มีประสิทธิภาพมากขึ้น คลิปมีขนาดประมาณ 7.3 MB ซึ่งมากเกินไปสำหรับเว็บไซต์ทั่วไป เราจึงเปลี่ยนคลิปเป็นองค์ประกอบวิดีโอที่มีไฟล์ต้นฉบับ 2 ไฟล์ ได้แก่ MP4 และ WebM เพื่อให้รองรับเบราว์เซอร์ได้มากขึ้น
เราใช้เครื่องมือ FFmpeg เพื่อแปลง GIF แบบเคลื่อนไหวเป็นไฟล์ MP4 รูปแบบ WebM ช่วยให้คุณประหยัดพื้นที่ได้มากยิ่งขึ้น โดย ImageOptim API สามารถทำการแปลงดังกล่าวให้คุณได้
ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4
เราลดน้ำหนักโดยรวมได้กว่า 80% ด้วยการแปลงนี้ ซึ่งทำให้เรา ลดขนาดลงเหลือประมาณ 1 MB
อย่างไรก็ตาม 1 MB ก็ยังเป็นทรัพยากรขนาดใหญ่ที่ต้องส่งผ่านสาย โดยเฉพาะสำหรับผู้ใช้ที่มีแบนด์วิดท์จำกัด โชคดีที่เราใช้ Effective Type API เพื่อดูว่าผู้ใช้มีแบนด์วิดท์ต่ำ และแสดงภาพ JPEG ที่มีขนาดเล็กกว่ามากแทนได้
อินเทอร์เฟซนี้ใช้เวลาในการรับส่งที่มีประสิทธิภาพและค่าการดาวน์เพื่อประมาณประเภทเครือข่าย ที่ผู้ใช้กำลังใช้อยู่ โดยจะแสดงผลสตริง "2G ช้า" "2G" "3G" หรือ "4G" ดังนั้น หากผู้ใช้ใช้เครือข่ายต่ำกว่า 4G เราจะแทนที่องค์ประกอบวิดีโอด้วยรูปภาพได้ ทั้งนี้ขึ้นอยู่กับค่านี้
if (navigator.connection.effectiveType) { ... }
แม้ว่าการดำเนินการนี้จะทำให้ประสบการณ์การใช้งานลดลงไปบ้าง แต่ก็ยังดีกว่าที่เว็บไซต์จะใช้งานไม่ได้เลยเมื่อมีการเชื่อมต่อที่ช้า
โหลดรูปภาพนอกหน้าจอแบบ Lazy Loading
แคโรเซล สไลเดอร์ หรือหน้าเว็บที่ยาวมากมักจะโหลดรูปภาพ แม้ว่าผู้ใช้จะยังไม่เห็นรูปภาพเหล่านั้นในหน้าเว็บก็ตาม
Lighthouse จะแจ้งลักษณะการทำงานนี้ในการตรวจสอบรูปภาพนอกหน้าจอ และคุณยังดูได้ด้วยตนเองในแผงเครือข่ายของเครื่องมือสำหรับนักพัฒนาเว็บ หากคุณเห็นรูปภาพจำนวนมากที่เข้ามาในขณะที่มีรูปภาพเพียงไม่กี่รูปที่แสดงในหน้าเว็บ หมายความว่าคุณอาจพิจารณาใช้ Lazy Load แทนได้
เบราว์เซอร์ยังไม่รองรับการโหลดแบบ Lazy โดยค่าเริ่มต้น เราจึงต้องใช้ 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 บอกให้เราทำคือหลีกเลี่ยงการส่งคำขอหลายครั้งที่มีค่าใช้จ่ายสูงไปยังต้นทาง
ในกรณีของแอป Oodle เราใช้ Google Fonts อย่างหนัก ทุกครั้งที่คุณวางชีตสไตล์ของ Google Fonts ลงในหน้าเว็บ ระบบจะเชื่อมต่อกับโดเมนย่อยสูงสุด 2 โดเมน และสิ่งที่ Lighthouse บอกเราคือหากเราสามารถวอร์มอัปการเชื่อมต่อดังกล่าวได้ เราจะประหยัดเวลาในการเชื่อมต่อครั้งแรกได้สูงสุด 300 มิลลิวินาที
การใช้ประโยชน์จาก link rel preconnect จะช่วยให้เราซ่อนเวลาในการตอบสนองของการเชื่อมต่อได้อย่างมีประสิทธิภาพ
โดยเฉพาะอย่างยิ่งกับ Google Fonts ซึ่งโฮสต์ CSS ของ Font Face ไว้ใน googleapis.com และโฮสต์ทรัพยากรแบบอักษรไว้ใน Gstatic ซึ่งอาจส่งผลกระทบอย่างมาก เราจึงใช้การเพิ่มประสิทธิภาพนี้และลดเวลาลงได้ 2-300 มิลลิวินาที
สิ่งถัดไปที่ Lighthouse แนะนำคือการโหลดคำขอที่สำคัญล่วงหน้า
<link rel=preload> มีประสิทธิภาพมาก โดยจะแจ้งให้เบราว์เซอร์ทราบว่าจำเป็นต้องใช้ทรัพยากรเป็นส่วนหนึ่งของการไปยังส่วนต่างๆ ในปัจจุบัน และพยายามให้เบราว์เซอร์ดึงข้อมูลโดยเร็วที่สุด
ตอนนี้ Lighthouse บอกเราว่าเราควรไปโหลดล่วงหน้าสำหรับทรัพยากรฟอนต์เว็บที่สำคัญ เนื่องจากเรากำลังโหลดฟอนต์เว็บ 2 รายการ
การโหลดล่วงหน้าในแบบอักษรบนเว็บจะมีลักษณะดังนี้ เมื่อระบุ rel=preload คุณจะส่ง as พร้อม
ประเภทแบบอักษร จากนั้นระบุประเภทแบบอักษรที่ต้องการโหลด เช่น woff2
ผลกระทบที่อาจเกิดขึ้นกับหน้าเว็บของคุณนั้นค่อนข้างชัดเจน
โดยปกติแล้ว หากไม่ได้ใช้ rel=preload ของลิงก์ และหากแบบอักษรบนเว็บมีความสําคัญต่อหน้าเว็บ สิ่งที่เบราว์เซอร์ต้องทําคือต้องดึงข้อมูล HTML ก่อน ต้องแยกวิเคราะห์ CSS และในภายหลัง เบราว์เซอร์จะดึงข้อมูลแบบอักษรบนเว็บ
การใช้ลิงก์ rel preload จะช่วยให้เบราว์เซอร์เริ่มดึงข้อมูลแบบอักษรบนเว็บเหล่านั้นได้เร็วขึ้นมากทันทีที่แยกวิเคราะห์ HTML ในกรณีของแอปเรา การดำเนินการนี้ช่วยลดเวลาในการแสดงข้อความโดยใช้แบบอักษรบนเว็บได้ 1 วินาที
แต่หากคุณจะลองโหลดแบบอักษรล่วงหน้าโดยใช้ Google Fonts ก็มีข้อควรระวังอยู่
URL ของ Google Fonts ที่เราระบุใน Font Face ในชีตสไตล์นั้นเป็นสิ่งที่ทีมแบบอักษรจะอัปเดตเป็นประจำ URL เหล่านี้อาจหมดอายุหรือได้รับการอัปเดตเป็นประจำ ดังนั้นสิ่งที่เราขอแนะนำให้คุณทำหากต้องการควบคุมประสบการณ์การโหลดแบบอักษรอย่างเต็มที่ คือการโฮสต์แบบอักษรเว็บด้วยตนเอง ซึ่งเป็นเรื่องดีเพราะจะช่วยให้คุณเข้าถึง ฟีเจอร์ต่างๆ เช่น rel=preload ของลิงก์
ในกรณีของเรา เราพบว่าเครื่องมือ Google Web Fonts Helper มีประโยชน์อย่างยิ่งในการช่วยเรานำแบบอักษรบนเว็บเหล่านั้นบางส่วนไปใช้แบบออฟไลน์และตั้งค่าแบบอักษรเหล่านั้นในเครื่อง ดังนั้นโปรดลองใช้เครื่องมือนี้
ไม่ว่าคุณจะใช้แบบอักษรบนเว็บเป็นส่วนหนึ่งของทรัพยากรที่สำคัญ หรือเป็น JavaScript ก็ตาม พยายามช่วยให้เบราว์เซอร์แสดงทรัพยากรที่สำคัญโดยเร็วที่สุด
เวอร์ชันทดลอง: คำแนะนำเกี่ยวกับลำดับความสำคัญ
วันนี้เรามีเรื่องพิเศษมาแชร์ให้คุณทราบ นอกเหนือจากฟีเจอร์ต่างๆ เช่น คำแนะนำเกี่ยวกับทรัพยากร รวมถึงการโหลดล่วงหน้าแล้ว เรายังได้พัฒนาฟีเจอร์เบราว์เซอร์เวอร์ชันทดลองใหม่ล่าสุดที่เรียกว่า คำแนะนำเกี่ยวกับลำดับความสำคัญ
ฟีเจอร์ใหม่นี้ช่วยให้คุณบอกเบราว์เซอร์ได้ว่าทรัพยากรมีความสําคัญมากน้อยเพียงใด โดยจะแสดงแอตทริบิวต์ใหม่ที่ชื่อ "ความสําคัญ" ซึ่งมีค่าเป็น "ต่ำ" "สูง" หรือ "อัตโนมัติ"
ซึ่งช่วยให้เราสื่อถึงการลดลำดับความสำคัญของทรัพยากรที่มีความสำคัญน้อยกว่า เช่น สไตล์ รูปภาพ หรือการเรียกใช้ Fetch API ที่ไม่สำคัญ เพื่อลดการแย่งชิง นอกจากนี้ เรายังเพิ่มลำดับความสำคัญของสิ่งต่างๆ ที่สำคัญกว่าได้ด้วย เช่น รูปภาพฮีโร่
ในกรณีของแอป Oodle ของเรา การดำเนินการนี้ทำให้เรามีที่เดียวที่สามารถปรับให้เหมาะสมได้
ก่อนที่เราจะเพิ่มการโหลดแบบ Lazy Loading ลงในรูปภาพ สิ่งที่เบราว์เซอร์ทำคือเรามีภาพสไลด์รูปภาพ ที่มีภาพดูเดิลทั้งหมด และเบราว์เซอร์จะดึงรูปภาพทั้งหมดตั้งแต่เริ่มต้น ของภาพสไลด์โดยให้ความสำคัญสูงตั้งแต่เนิ่นๆ แต่รูปภาพที่อยู่ตรงกลาง ของภาพสไลด์กลับเป็นรูปภาพที่สำคัญที่สุดสำหรับผู้ใช้ ดังนั้นสิ่งที่เราทำคือตั้งค่าความสำคัญ ของรูปภาพพื้นหลังเหล่านั้นให้ต่ำมาก ส่วนรูปภาพเบื้องหน้าให้สูงมาก ซึ่งส่งผลให้ ใช้เวลา 2 วินาทีในการโหลดผ่าน 3G ที่ช้า และทำให้เราดึงข้อมูลและแสดงรูปภาพเหล่านั้นได้อย่างรวดเร็ว ดังนั้นจึงเป็นประสบการณ์ที่ดีและน่าพึงพอใจ
เราหวังว่าจะได้นำฟีเจอร์นี้มาให้ใช้งานใน Canary ในอีกไม่กี่สัปดาห์ข้างหน้า โปรดติดตามข่าวสาร
มีกลยุทธ์การโหลดแบบอักษรเว็บ
การออกแบบที่ดีต้องมีแบบอักษรเป็นพื้นฐาน และหากคุณใช้แบบอักษรบนเว็บ คุณก็คงไม่ต้องการ บล็อกการแสดงข้อความ และแน่นอนว่าคุณคงไม่ต้องการแสดงข้อความที่มองไม่เห็น
เราไฮไลต์ข้อความนี้ใน Lighthouse แล้วตอนนี้ด้วยการตรวจสอบหลีกเลี่ยงข้อความที่มองไม่เห็นขณะที่เว็บฟอนต์กำลังโหลด
หากโหลดแบบอักษรบนเว็บโดยใช้บล็อก @font-face คุณจะปล่อยให้เบราว์เซอร์ตัดสินใจว่าจะทำอย่างไร หากใช้เวลานานในการดึงข้อมูลแบบอักษรบนเว็บนั้น เบราว์เซอร์บางตัวจะรอสูงสุด 3 วินาทีก่อนที่จะเปลี่ยนกลับไปใช้แบบอักษรของระบบ และจะเปลี่ยนไปใช้แบบอักษรนั้นเมื่อดาวน์โหลดเสร็จแล้ว
เราพยายามหลีกเลี่ยงข้อความที่มองไม่เห็นนี้ ดังนั้นในกรณีนี้ เราจะดูภาพดูเดิลคลาสสิกของสัปดาห์นี้ไม่ได้หากแบบอักษรบนเว็บใช้เวลานานเกินไป โชคดีที่ฟีเจอร์ใหม่ที่ชื่อว่า
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');
}
การแสดงแบบอักษรช่วยให้คุณตัดสินใจได้ว่าแบบอักษรบนเว็บจะแสดงผลหรือใช้แบบอักษรสำรองอย่างไร โดยขึ้นอยู่กับระยะเวลาที่ใช้ในการสลับ
ในกรณีนี้ เราใช้การสลับการแสดงผลแบบอักษร Swap จะกำหนดระยะเวลาบล็อกแบบ 0 วินาทีให้กับ Font Face และระยะเวลา Swap ที่ไม่มีที่สิ้นสุด ซึ่งหมายความว่าเบราว์เซอร์จะวาดข้อความของคุณทันที ด้วยแบบอักษรสำรองหากแบบอักษรใช้เวลาในการโหลดนาน และจะสลับเมื่อฟอนต์ พร้อมใช้งาน
ในกรณีของแอปของเรา ข้อดีคือเราสามารถแสดงข้อความที่มีความหมายบางอย่างได้ตั้งแต่เนิ่นๆ และเปลี่ยนไปใช้แบบอักษรบนเว็บเมื่อพร้อมใช้งาน
โดยทั่วไปแล้ว หากคุณใช้แบบอักษรบนเว็บเหมือนกับเว็บไซต์ส่วนใหญ่ ให้ใช้กลยุทธ์การโหลดแบบอักษรบนเว็บที่ดี
มีฟีเจอร์แพลตฟอร์มเว็บมากมายที่คุณใช้เพื่อเพิ่มประสิทธิภาพประสบการณ์การโหลดแบบอักษรได้ แต่ก็ควรดูที่เก็บสูตรแบบอักษรบนเว็บของ Zach Leatherman ด้วย เพราะเป็นที่เก็บที่ยอดเยี่ยมมาก
ลดสคริปต์ที่บล็อกการแสดงผล
นอกจากนี้ ยังมีส่วนอื่นๆ ของแอปพลิเคชันที่เราสามารถส่งต่อในห่วงโซ่การดาวน์โหลดได้เร็วขึ้นเพื่อมอบ ประสบการณ์ของผู้ใช้ขั้นพื้นฐานอย่างน้อยบางส่วนได้เร็วขึ้นเล็กน้อย
ในแถบไทม์ไลน์ของ Lighthouse คุณจะเห็นว่าในช่วง 2-3 วินาทีแรกที่ทรัพยากรทั้งหมดกำลังโหลด ผู้ใช้จะไม่เห็นเนื้อหาใดๆ
การดาวน์โหลดและประมวลผลสไตล์ชีตภายนอกกำลังบล็อกกระบวนการแสดงผลไม่ให้ มีความคืบหน้าใดๆ
เราสามารถลองเพิ่มประสิทธิภาพเส้นทางการแสดงผลที่สำคัญโดยการส่งรูปแบบบางอย่างให้เร็วขึ้นเล็กน้อย
หากเราดึงรูปแบบที่รับผิดชอบการแสดงผลครั้งแรกนี้และแทรกลงใน HTML เบราว์เซอร์จะแสดงผลได้ทันทีโดยไม่ต้องรอให้สไตล์ชีตภายนอก มาถึง
ในกรณีของเรา เราใช้โมดูล NPM ที่ชื่อ Critical เพื่อแทรกเนื้อหาที่สำคัญใน index.html ในขั้นตอนการสร้าง
แม้ว่าโมดูลนี้จะช่วยเราทำงานหนักๆ ไปได้มาก แต่ก็ยังคงมีเรื่องที่ต้องจัดการอยู่บ้างเพื่อให้ การทำงานนี้เป็นไปอย่างราบรื่นในเส้นทางต่างๆ
หากคุณไม่ระมัดระวังหรือโครงสร้างเว็บไซต์มีความซับซ้อนมาก การ นำรูปแบบประเภทนี้มาใช้ก็อาจเป็นเรื่องยากมากหากคุณไม่ได้วางแผนสำหรับ สถาปัตยกรรม App Shell ตั้งแต่แรก
ด้วยเหตุนี้ การพิจารณาประสิทธิภาพตั้งแต่เนิ่นๆ จึงสำคัญอย่างยิ่ง หากไม่ได้ออกแบบเพื่อประสิทธิภาพตั้งแต่เริ่มต้น ก็มีโอกาสสูงที่จะพบปัญหาเมื่อทำในภายหลัง
ในที่สุดความเสี่ยงของเราก็คุ้มค่า เราสามารถทำให้แอปทำงานได้ และแอปก็เริ่มแสดงเนื้อหาได้เร็วขึ้นมาก ซึ่งช่วยปรับปรุงเวลาการแสดงผลที่มีความหมายครั้งแรกได้อย่างมาก
ผลลัพธ์
นั่นคือรายการการเพิ่มประสิทธิภาพจำนวนมากที่เราใช้กับเว็บไซต์ มาดู ผลลัพธ์กัน นี่คือลักษณะการโหลดแอปของเราในอุปกรณ์เคลื่อนที่ขนาดกลางบนเครือข่าย 3G ก่อนและหลังการเพิ่มประสิทธิภาพ
คะแนนประสิทธิภาพของ Lighthouse เพิ่มขึ้นจาก 23 เป็น 91 ถือว่ามีความคืบหน้าด้านความเร็ว ที่ดีทีเดียว การเปลี่ยนแปลงทั้งหมดนี้เกิดจากการที่เราตรวจสอบและทำตามรายงาน Lighthouse อย่างต่อเนื่อง หากต้องการดูว่าเราได้ปรับปรุงทั้งหมดในทางเทคนิคอย่างไร โปรดดูที่เก็บของเรา โดยเฉพาะอย่างยิ่ง PR ที่อยู่ในที่เก็บดังกล่าว
ประสิทธิภาพเชิงคาดการณ์ - ประสบการณ์ของผู้ใช้ที่อิงตามข้อมูล
เราเชื่อว่าแมชชีนเลิร์นนิงเป็นโอกาสที่น่าตื่นเต้นสำหรับอนาคตในหลายๆ ด้าน แนวคิดหนึ่งที่เราหวังว่าจะจุดประกายการทดลองเพิ่มเติมในอนาคตคือข้อมูลจริงสามารถเป็นแนวทางในการสร้างประสบการณ์ของผู้ใช้ได้
ปัจจุบันเราตัดสินใจโดยพลการหลายอย่างเกี่ยวกับสิ่งที่ผู้ใช้อาจต้องการหรือจำเป็นต้องใช้ ดังนั้น สิ่งใดที่ควรค่าแก่การดึงข้อมูลล่วงหน้า โหลดล่วงหน้า หรือแคชล่วงหน้า หากเราคาดการณ์ได้ถูกต้อง เราจะจัดสรรทรัพยากรจำนวนเล็กน้อยให้ แต่การขยายขนาดให้ครอบคลุมทั้งเว็บไซต์นั้นเป็นเรื่องยาก
เรามีข้อมูลที่พร้อมใช้งานเพื่อแจ้งการเพิ่มประสิทธิภาพในปัจจุบันให้ดียิ่งขึ้น การใช้ Reporting API ของ Google Analytics เราสามารถดูหน้าถัดไปที่ได้รับความนิยมสูงสุดและเปอร์เซ็นต์การออก สำหรับ URL ใดๆ ในเว็บไซต์ของเราได้ จึงสรุปได้ว่าเราควรจัดลําดับความสําคัญของทรัพยากรใด
หากเรารวมสิ่งนี้เข้ากับโมเดลความน่าจะเป็นที่ดี เราจะหลีกเลี่ยงการสิ้นเปลืองข้อมูลของผู้ใช้ด้วยการ ดึงข้อมูลเนื้อหามากเกินไป เราสามารถใช้ประโยชน์จากข้อมูล Google Analytics ดังกล่าว รวมถึงใช้แมชชีนเลิร์นนิงและโมเดลต่างๆ เช่น Markov Chain หรือโครงข่ายประสาทเทียม เพื่อนำโมเดลดังกล่าวไปใช้
เรายินดีที่จะประกาศเปิดตัวโครงการใหม่ที่ชื่อว่า 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