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

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

Addy Osmani

Ewa Gasperowicz

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ขั้นตอนถัดไปของเราคือเพื่อให้มั่นใจว่าเราจะไม่ส่งแหล่งข้อมูลซ้ำ 2 ครั้งหากไม่จำเป็น

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เราเริ่มต้นด้วย Webpack Bundle Analysisr ซึ่งแจ้งให้เราทราบว่าเรารวม Dependency ที่เรียกว่า unicode ซึ่งเป็น JavaScript ที่แยกวิเคราะห์แล้ว 1.6 MB ซึ่งค่อนข้างเยอะมาก

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ใช้ประโยชน์จากแนวคิดต่างๆ เช่น การแยกโค้ด สำรวจแนวคิดต่างๆ เช่น Tree Shaking และดูแนวคิดในการลดขนาดไลบรารีได้จากที่เก็บข้อมูล 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

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

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

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

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

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

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

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

Lighthouse จะแจ้งลักษณะการทำงานนี้ในการตรวจสอบรูปภาพนอกหน้าจอ และคุณยังดูได้ด้วยตนเองในแผงเครือข่ายของ DevTools หากเห็นรูปภาพจำนวนมากเข้ามาในขณะที่มีรูปภาพเพียงไม่กี่รูปที่แสดงในหน้าเว็บ แสดงว่าคุณอาจต้องพิจารณาใช้การโหลดแบบ 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 บอกให้เราทําคือหลีกเลี่ยงการไปและกลับหลายครั้งไปยังต้นทางใดๆ ซึ่งทําให้สิ้นเปลืองค่าใช้จ่าย

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

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

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

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

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

ตอนนี้ Lighthouse ได้แจ้งให้เราทราบว่าควรไปโหลดทรัพยากรสำหรับแบบอักษรของเว็บที่สำคัญไว้ล่วงหน้า เพราะเรากำลังโหลดแบบอักษรเว็บ 2 แบบ

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

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

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

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

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

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

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

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

ทดลอง: คำแนะนำลำดับความสำคัญ

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

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

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

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

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

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

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

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

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

หากคุณโหลดแบบอักษรเว็บโดยใช้บล็อกแบบอักษร คุณกำลังปล่อยให้เบราว์เซอร์ตัดสินใจว่าจะทำอย่างไรหากการดึงข้อมูลแบบอักษรเว็บนั้นใช้เวลานาน บางเบราว์เซอร์จะรอสูงสุด 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 วินาที และระยะเวลาการแลกเปลี่ยนแบบไม่จำกัด ซึ่งหมายความว่าเบราว์เซอร์จะวาดข้อความของคุณเกือบจะทันทีด้วยแบบอักษรสำรองหากแบบอักษรใช้เวลาโหลดนาน และระบบจะเปลี่ยนเมื่อแบบอักษรพร้อมใช้งาน

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

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

มีฟีเจอร์แพลตฟอร์มเว็บมากมายที่คุณใช้เพื่อเพิ่มประสิทธิภาพประสบการณ์การโหลดสำหรับแบบอักษรได้ แต่อย่าลืมดูที่เก็บสูตรอาหารของ Web Fonts ของ 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 หรือเครือข่ายประสาทเพื่อติดตั้งใช้งานโมเดลดังกล่าว

เรายินดีที่จะประกาศโครงการริเริ่มใหม่ที่มีชื่อว่า 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