ในงาน Google IO 2018 เราได้นำเสนอเครื่องมือ ไลบรารี และเทคนิคการเพิ่มประสิทธิภาพที่ช่วยให้ปรับปรุงประสิทธิภาพเว็บได้ง่ายขึ้น ที่นี่เราจะอธิบายโดยใช้แอป The Oodles Theater และพูดถึงการทดสอบการโหลดแบบคาดการณ์และโครงการริเริ่ม Guess.js ใหม่
ในช่วงปีที่ผ่านมา เราค่อนข้างยุ่งกับการหาวิธีทําให้เว็บเร็วขึ้นและมีประสิทธิภาพมากขึ้น ด้วยเหตุนี้ เราจึงพัฒนาเครื่องมือ แนวทาง และไลบรารีใหม่ๆ ที่จะแชร์กับคุณในบทความนี้ ในส่วนแรก เราจะแสดงเทคนิคการเพิ่มประสิทธิภาพบางส่วนที่เราใช้ในการปฏิบัติจริงเมื่อพัฒนาแอป Oodles Theater ส่วนที่สอง เราจะพูดถึงการทดสอบการโหลดแบบคาดการณ์และโครงการริเริ่ม Guess.js ใหม่
ความจำเป็นด้านประสิทธิภาพ
อินเทอร์เน็ตมีขนาดใหญ่ขึ้นทุกปี หากตรวจสอบสถานะของเว็บ เราจะเห็นว่าหน้าเว็บค่ามัธยฐานบนอุปกรณ์เคลื่อนที่มีน้ำหนักประมาณ 1.5 MB โดยส่วนใหญ่เป็น JavaScript และรูปภาพ
ขนาดที่เพิ่มขึ้นของเว็บไซต์ รวมถึงปัจจัยอื่นๆ เช่น เวลาในการตอบสนองของเครือข่าย ข้อจํากัดของ CPU รูปแบบการบล็อกการแสดงผล หรือโค้ดของบุคคลที่สามที่ไม่จําเป็น ล้วนเป็นปัจจัยที่ทําให้ประสิทธิภาพมีความซับซ้อน
ผู้ใช้ส่วนใหญ่ให้คะแนนความเร็วอยู่ในลำดับขั้นสูงสุดของ UX ตามความต้องการ เรื่องนี้ไม่น่าแปลกใจ เนื่องจากคุณจะทําอะไรไม่ได้มากนักจนกว่าหน้าเว็บจะโหลดเสร็จ คุณไม่สามารถรับคุณค่าจากหน้าเว็บ ชื่นชมความงามของหน้าเว็บ
![ลำดับชั้นของ UX](https://web.dev/static/articles/web-performance-made-easy/image/ux-hierarchy-piramide-9a38f1858336f.png?authuser=8&hl=th)
เราทราบดีว่าประสิทธิภาพนั้นสำคัญต่อผู้ใช้ แต่ก็อาจเป็นเรื่องยากที่จะค้นพบว่าควรเริ่มเพิ่มประสิทธิภาพที่ใด แต่โชคดีที่เรามีเครื่องมือที่จะช่วยคุณในกระบวนการนี้
Lighthouse - พื้นฐานสําหรับเวิร์กโฟลว์ด้านประสิทธิภาพ
Lighthouse เป็นส่วนหนึ่งของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ซึ่งช่วยให้คุณตรวจสอบเว็บไซต์และให้คำแนะนำเกี่ยวกับวิธีปรับปรุงเว็บไซต์ให้ดียิ่งขึ้น
เมื่อเร็วๆ นี้เราได้เปิดตัวการตรวจสอบประสิทธิภาพใหม่จำนวนมากที่มีประโยชน์อย่างยิ่งในเวิร์กโฟลว์การพัฒนาในแต่ละวัน
![การตรวจสอบใหม่ของ Lighthouse](https://web.dev/static/articles/web-performance-made-easy/image/new-lighthouse-audits-a5c01f6ee0cf4.png?authuser=8&hl=th)
มาดูวิธีใช้ประโยชน์จากฟีเจอร์นี้กันจากตัวอย่างการใช้งานจริง นั่นคือแอป Oodles Theater ซึ่งเป็นเว็บแอปสาธิตเล็กๆ ให้คุณได้ลองใช้ Google Doodle แบบอินเทอร์แอกทีฟที่เราชื่นชอบและเล่นเกมสักเกมสองเกม
ขณะสร้างแอป เราต้องการทำให้แอปมีประสิทธิภาพมากที่สุด จุดเริ่มต้นของการเพิ่มประสิทธิภาพคือรายงาน Lighthouse
![รายงาน Lighthouse สําหรับแอป Oodles](https://web.dev/static/articles/web-performance-made-easy/image/lighthouse-report-oodles-04ce89ae09ebc.png?authuser=8&hl=th)
ประสิทธิภาพเริ่มต้นของแอปตามที่แสดงในรายงาน Lighthouse นั้นแย่มาก ในเครือข่าย 3G ผู้ใช้ต้องรอ 15 วินาทีเพื่อให้ภาพวาดแรกที่มีความหมายปรากฏขึ้น หรือเพื่อให้แอปโต้ตอบได้ Lighthouse ชี้ให้เห็นปัญหามากมายในเว็บไซต์ของเรา และคะแนนประสิทธิภาพโดยรวมที่ 23 ก็สะท้อนถึงปัญหาเหล่านั้น
หน้าเว็บมีน้ำหนักประมาณ 3.4 MB เราจึงต้องตัดเนื้อหาบางส่วนออก
ปัญหาด้านประสิทธิภาพแรกของเราจึงเริ่มต้นขึ้น นั่นคือ การค้นหาสิ่งที่นำออกได้ง่ายๆ โดยไม่ส่งผลต่อประสบการณ์โดยรวม
โอกาสในการเพิ่มประสิทธิภาพ
นำทรัพยากรที่ไม่จำเป็นออก
สิ่งหนึ่งที่เห็นได้ชัดและนำออกได้โดยไม่มีปัญหาคือ เว้นวรรคและความคิดเห็น
![ประโยชน์จากการลดขนาด](https://web.dev/static/articles/web-performance-made-easy/image/gains-minification-209064021d2a2.png?authuser=8&hl=th)
Lighthouse จะไฮไลต์โอกาสนี้ในการตรวจสอบ CSS และ JavaScript ที่ไม่มีการย่อ เราใช้ webpack สําหรับกระบวนการบิลด์ ดังนั้นเราจึงใช้ปลั๊กอิน Uglify JS เพื่อลดขนาด
การทำให้ไฟล์มีขนาดเล็กลงเป็นงานที่พบได้ทั่วไป คุณจึงควรหาโซลูชันสำเร็จรูปสำหรับกระบวนการสร้างที่คุณใช้อยู่
การตรวจสอบที่มีประโยชน์อีกอย่างหนึ่งในพื้นที่ทำงานดังกล่าวคือเปิดใช้การบีบอัดข้อความ คุณไม่จำเป็นต้องส่งไฟล์ที่ไม่มีการบีบอัด และCDN ส่วนใหญ่รองรับการดำเนินการนี้อยู่แล้วในปัจจุบัน
เราใช้โฮสติ้งของ Firebase เพื่อโฮสต์โค้ดของเรา และ Firebase เปิดใช้การบีบอัดข้อมูลด้วย GZIP โดยค่าเริ่มต้น ดังนั้นการโฮสต์โค้ดใน CDN ที่สมเหตุสมผลก็ทำให้เราได้รับประโยชน์นี้โดยไม่มีค่าใช้จ่าย
แม้ว่า gzip จะเป็นวิธีบีบอัดที่ได้รับความนิยมอย่างมาก แต่กลไกอื่นๆ เช่น Zopfli และ Brotli ก็ได้รับความนิยมเช่นกัน Brotli ได้รับการรองรับในเบราว์เซอร์ส่วนใหญ่ และคุณใช้ไบนารีเพื่อบีบอัดชิ้นงานล่วงหน้าก่อนที่จะส่งไปยังเซิร์ฟเวอร์ได้
ใช้นโยบายแคชที่มีประสิทธิภาพ
ขั้นตอนถัดไปคือการตรวจสอบว่าเราไม่ส่งทรัพยากรซ้ำหากไม่จำเป็น
การตรวจสอบนโยบายแคชที่ไม่มีประสิทธิภาพใน Lighthouse ช่วยให้เราทราบว่าเราอาจเพิ่มประสิทธิภาพกลยุทธ์การแคชเพื่อให้บรรลุเป้าหมายดังกล่าวได้ การตั้งค่าส่วนหัวการหมดอายุ max-age ในเซิร์ฟเวอร์ช่วยให้มั่นใจได้ว่าผู้ใช้จะกลับมาใช้ทรัพยากรที่ดาวน์โหลดไว้ก่อนหน้านี้ได้
คุณควรแคชทรัพยากรให้ได้มากที่สุดอย่างปลอดภัยที่สุดเป็นระยะเวลานานที่สุดเท่าที่จะเป็นไปได้ และระบุโทเค็นการตรวจสอบเพื่อตรวจสอบทรัพยากรที่อัปเดตแล้วอีกครั้งอย่างมีประสิทธิภาพ
นำโค้ดที่ไม่ได้ใช้งานออก
จนถึงตอนนี้เราได้นำส่วนที่เป็นที่ชัดเจนของการดาวน์โหลดที่ไม่จำเป็นออกแล้ว แต่ส่วนที่ไม่ชัดเจนล่ะ เช่น โค้ดที่ไม่ได้ใช้งาน
![ความครอบคลุมของโค้ดในเครื่องมือสำหรับนักพัฒนาเว็บ](https://web.dev/static/articles/web-performance-made-easy/image/code-coverage-devtools-d9d9ad4c8416d.png?authuser=8&hl=th)
บางครั้งเราอาจใส่โค้ดที่ไม่จำเป็นไว้ในแอป ปัญหานี้จะเกิดขึ้นโดยเฉพาะอย่างยิ่งหากคุณทํางานกับแอปเป็นระยะเวลานาน ทีมหรือสิ่งที่ต้องพึ่งพามีการเปลี่ยนแปลง และบางครั้งมีไลบรารีที่ไม่มีเจ้าของเหลืออยู่ เช่นเดียวกับที่เราพบ
ในช่วงแรก เราใช้ไลบรารีคอมโพเนนต์เนื้อหาเพื่อสร้างต้นแบบแอปอย่างรวดเร็ว ต่อมาเราเปลี่ยนไปใช้รูปลักษณ์ที่ปรับแต่งเองมากขึ้นและลืมไลบรารีดังกล่าวไปเลย แต่โชคดีที่การตรวจสอบความครอบคลุมของโค้ดช่วยให้เราค้นพบโค้ดดังกล่าวอีกครั้งในแพ็กเกจ
คุณสามารถตรวจสอบสถิติการครอบคลุมโค้ดในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ได้ ทั้งสำหรับรันไทม์และเวลาในการโหลดของแอปพลิเคชัน คุณจะเห็นแถบสีแดงขนาดใหญ่ 2 แถบในภาพหน้าจอด้านล่าง เรามี CSS ที่ไม่ได้ใช้งานกว่า 95% และ JavaScript จำนวนมากด้วย
Lighthouse ยังพบปัญหานี้ในการตรวจสอบกฎ CSS ที่ไม่ได้ใช้งานด้วย พบว่าอาจประหยัดพื้นที่ได้กว่า 400 KB เราจึงกลับไปที่โค้ดและนําทั้งส่วน JavaScript และ CSS ออกจากคลังนั้น
![หากนำ MVC Adapter ออก สไตล์จะลดลงเหลือ 10 KB](https://web.dev/static/articles/web-performance-made-easy/image/if-drop-mvc-adapter-sty-f311da23542ff.png?authuser=8&hl=th)
ซึ่งทำให้กลุ่ม CSS ลดลง 20 เท่า ซึ่งถือว่าดีมากสำหรับคอมมิตสั้นๆ 2 บรรทัด
แน่นอนว่าคะแนนประสิทธิภาพของเราก็เพิ่มขึ้น และเวลาในการโต้ตอบก็ดีขึ้นมาก
อย่างไรก็ตาม การเปลี่ยนแปลงเช่นนี้ไม่เพียงพอที่จะตรวจสอบเมตริกและคะแนนเพียงอย่างเดียว การนําโค้ดจริงออกนั้นไม่มีความเสี่ยงใดๆ ทั้งสิ้น คุณจึงควรระวังการถดถอยที่อาจเกิดขึ้นเสมอ
รหัสของเราไม่ได้ใช้งาน 95% แต่ยังมี 5% ที่ยังใช้งานอยู่ ดูเหมือนว่าคอมโพเนนต์อย่างใดอย่างหนึ่งของเรายังคงใช้รูปแบบจากไลบรารีดังกล่าวอยู่ ซึ่งเป็นลูกศรเล็กๆ ในแถบเลื่อนภาพวาด แต่เนื่องจากมีจำนวนไม่มาก เราจึงสามารถใส่สไตล์เหล่านั้นกลับเข้าไปในปุ่มด้วยตนเองได้
![ปุ่มใช้งานไม่ได้เนื่องจากไม่มีคลัง](https://web.dev/static/articles/web-performance-made-easy/image/buttons-got-broken-missi-6e2d05b1a4f04.png?authuser=8&hl=th)
ดังนั้น หากคุณนําโค้ดออก โปรดตรวจสอบว่าคุณมีเวิร์กโฟลว์การทดสอบที่เหมาะสมเพื่อช่วยป้องกันภาพอาจย้อนกลับ
หลีกเลี่ยงเพย์โหลดเครือข่ายปริมาณมาก
เราทราบดีว่าทรัพยากรขนาดใหญ่อาจทำให้การโหลดหน้าเว็บช้าลง โฆษณาเหล่านี้อาจทำให้ผู้ใช้เสียค่าใช้จ่ายและส่งผลเสียอย่างมากต่อแพ็กเกจอินเทอร์เน็ตของผู้ใช้ ดังนั้นจึงต้องระมัดระวังเรื่องนี้เป็นอย่างมาก
Lighthouse ตรวจพบว่าเรามีปัญหาเกี่ยวกับเพย์โหลดเครือข่ายบางส่วนโดยใช้การตรวจสอบเพย์โหลดเครือข่ายขนาดใหญ่
![ตรวจหาเพย์โหลดเครือข่ายปริมาณมาก](https://web.dev/static/articles/web-performance-made-easy/image/detect-enormous-network-p-b417c0f85336d.png?authuser=8&hl=th)
เราพบว่ามีโค้ดที่มีมูลค่ามากกว่า 3 MB กำลังส่งอยู่ ซึ่งถือว่ามากทีเดียวโดยเฉพาะบนอุปกรณ์เคลื่อนที่
ที่ด้านบนสุดของรายการนี้ Lighthouse ไฮไลต์ว่าเรามีกลุ่มผู้ให้บริการ JavaScript ที่เป็นโค้ดที่ไม่มีการบีบอัดขนาด 2 MB ปัญหานี้ยังเป็นสิ่งที่ webpack ชี้ให้เห็นด้วย
ดังคำกล่าวที่ว่า "คำขอที่เร็วที่สุดคือคำขอที่ไม่ได้ส่ง"
โดยหลักการแล้ว คุณควรวัดมูลค่าของชิ้นงานแต่ละรายการที่แสดงต่อผู้ใช้ วัดประสิทธิภาพของชิ้นงานเหล่านั้น และตัดสินใจว่าควรส่งชิ้นงานเหล่านั้นพร้อมกับประสบการณ์เริ่มต้นหรือไม่ เนื่องจากบางครั้งชิ้นงานเหล่านี้อาจเลื่อนออกไป หรือโหลดแบบเลื่อนเวลา หรือประมวลผลระหว่างเวลาที่ไม่มีการใช้งาน
ในกรณีของเรา เราจัดการกับกลุ่ม JavaScript จำนวนมาก จึงโชคดีที่มีชุมชน JavaScript ที่มีชุดเครื่องมือตรวจสอบกลุ่ม JavaScript มากมาย
![การตรวจสอบกลุ่ม JavaScript](https://web.dev/static/articles/web-performance-made-easy/image/javascript-bundle-auditin-bb72c40c2152f.png?authuser=8&hl=th)
เราเริ่มต้นด้วยเครื่องมือวิเคราะห์กลุ่ม 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](https://web.dev/static/articles/web-performance-made-easy/image/javascript-processing-a88df8122641b.png?authuser=8&hl=th)
ก่อนอื่นเราต้องดาวน์โหลดสคริปต์นั้น เรามีเครื่องมือสำหรับ JavaScript ซึ่งต้องแยกวิเคราะห์โค้ดนั้น คอมไพล์ และดำเนินการ
ตอนนี้ขั้นตอนเหล่านี้ใช้เวลาไม่นานในอุปกรณ์ระดับไฮเอนด์ เช่น คอมพิวเตอร์เดสก์ท็อปหรือแล็ปท็อป หรือแม้แต่โทรศัพท์ระดับไฮเอนด์ แต่บนโทรศัพท์มือถือระดับกลาง ขั้นตอนนี้อาจใช้เวลานานกว่า 5-10 เท่า การดำเนินการนี้ทำให้การโต้ตอบล่าช้า เราจึงต้องพยายามตัดวิดีโอนี้ให้สั้นลง
เราได้เปิดตัวการตรวจสอบเวลาเริ่มต้น JavaScript ใหม่ใน Lighthouse เพื่อช่วยให้คุณค้นพบปัญหาเหล่านี้เกี่ยวกับแอป
![เวลาในการเริ่มต้น JavaScript](https://web.dev/static/articles/web-performance-made-easy/image/javascript-boot-time-d9ae37a556e82.png?authuser=8&hl=th)
และในกรณีของแอป Oodle ข้อมูลแจ้งว่าใช้เวลา 1.8 วินาทีในการบูต JavaScript สิ่งที่เกิดขึ้นคือเรานําเข้าเส้นทางและคอมโพเนนต์ทั้งหมดแบบคงที่ไว้ในกลุ่ม JavaScript แบบโมโนลิธิกกลุ่มเดียว
เทคนิคหนึ่งในการแก้ปัญหานี้คือการใช้การแยกโค้ด
![การแยกโค้ดก็เหมือนกับพิซซ่า](https://web.dev/static/articles/web-performance-made-easy/image/code-splitting-is-pizza-6008484e57adc.png?authuser=8&hl=th)
การแยกโค้ดเป็นแนวคิดที่ว่าแทนที่จะให้ JavaScript แก่ผู้ใช้เป็นชิ้นใหญ่ๆ คุณจะทําอย่างไรหากให้ผู้ใช้ทีละชิ้นตามที่ต้องการ
การแยกโค้ดใช้ได้ที่ระดับเส้นทางหรือระดับคอมโพเนนต์ ทำงานได้ดีกับ React และ React Loadable, Vue.js, Angular, Polymer, Preact และไลบรารีอื่นๆ อีกมากมาย
เรารวมการแยกโค้ดไว้ในแอปพลิเคชันของเรา โดยเปลี่ยนจากการนําเข้าแบบคงที่เป็นการนําเข้าแบบไดนามิก ซึ่งช่วยให้เราโหลดโค้ดแบบตามต้องการแบบแอซิงโครนัสได้
![การแยกโค้ดด้วยการนําเข้าแบบไดนามิก](https://web.dev/static/articles/web-performance-made-easy/image/code-splitting-dynamic-i-bef50644cc8ac.png?authuser=8&hl=th)
ผลที่ได้คือทั้งการลดขนาดกลุ่ม และลดเวลาในการเริ่มต้น JavaScript เหลือเพียง 0.78 วินาที ทำให้แอปเร็วขึ้น 56%
โดยทั่วไป หากคุณกำลังสร้างประสบการณ์การใช้งานที่เน้น JavaScript เป็นหลัก โปรดตรวจสอบว่าได้ส่งเฉพาะโค้ดที่ผู้ใช้ต้องการเท่านั้น
ใช้ประโยชน์จากแนวคิดต่างๆ เช่น การแยกโค้ด สำรวจแนวคิดต่างๆ เช่น Tree Shaking และดูแนวคิดในการลดขนาดไลบรารีได้จากที่เก็บข้อมูล webpack-libs-optimizations หากใช้ webpack
ปรับขนาดภาพให้เหมาะสม
![มุกตลกเกี่ยวกับประสิทธิภาพการโหลดรูปภาพ](https://web.dev/static/articles/web-performance-made-easy/image/image-loading-performance-82f3792c437f6.png?authuser=8&hl=th)
เราใช้รูปภาพจำนวนมากในแอป Oodle แต่ Lighthouse กลับไม่ค่อยสนใจเรื่องนี้เท่าเรา อันที่จริงแล้ว เราตรวจสอบไม่ผ่านทั้ง 3 รายการที่เกี่ยวข้องกับรูปภาพ
เราลืมเพิ่มประสิทธิภาพรูปภาพ ไม่ได้ปรับขนาดรูปภาพให้ถูกต้อง และอาจได้ประโยชน์จากการใช้รูปแบบรูปภาพอื่นๆ
![การตรวจสอบรูปภาพ](https://web.dev/static/articles/web-performance-made-easy/image/image-audits-719c8447f8aaf.png?authuser=8&hl=th)
เราเริ่มด้วยการเพิ่มประสิทธิภาพรูปภาพ
สำหรับรอบการเพิ่มประสิทธิภาพแบบครั้งเดียว คุณสามารถใช้เครื่องมือภาพ เช่น ImageOptim หรือ XNConvert
แนวทางแบบอัตโนมัติมากขึ้นคือการเพิ่มขั้นตอนการเพิ่มประสิทธิภาพรูปภาพลงในกระบวนการสร้างด้วยไลบรารีอย่าง imagemin
วิธีนี้ช่วยให้มั่นใจได้ว่ารูปภาพที่เพิ่มในอนาคตจะได้รับการเพิ่มประสิทธิภาพโดยอัตโนมัติ CDN บางรายการ เช่น Akamai หรือโซลูชันของบุคคลที่สาม เช่น Cloudinary, Fastly หรือ Uploadcare มีโซลูชันการเพิ่มประสิทธิภาพรูปภาพที่ครอบคลุม คุณจึงโฮสต์รูปภาพในบริการเหล่านั้นได้ง่ายๆ
หากไม่ต้องการเนื่องจากปัญหาด้านต้นทุนหรือเวลาในการตอบสนอง โปรเจ็กต์อย่าง Thumbor หรือ Imageflow ก็มีทางเลือกในการโฮสต์ด้วยตนเอง
![ก่อนและหลังการเพิ่มประสิทธิภาพ](https://web.dev/static/articles/web-performance-made-easy/image/before-after-optimizatio-45b3bbf20acca.png?authuser=8&hl=th)
ไฟล์ PNG พื้นหลังของเราถูกแจ้งว่ามีขนาดเกินใน webpack ซึ่งก็ถูกต้อง หลังจากปรับขนาดให้เหมาะกับวิวพอร์ตและส่งผ่าน ImageOptim แล้ว ไฟล์มีขนาดลดลงเหลือ 100 KB ซึ่งยอมรับได้
การทำซ้ำขั้นตอนนี้กับรูปภาพหลายรูปในเว็บไซต์ช่วยให้เราลดน้ำหนักหน้าเว็บโดยรวมได้อย่างมาก
ใช้รูปแบบที่เหมาะกับเนื้อหาภาพเคลื่อนไหว
GIF อาจมีราคาแพงมาก แต่คุณอาจแปลกใจที่ได้รู้ว่ารูปแบบ GIF ไม่ได้ตั้งใจให้เป็นแพลตฟอร์มภาพเคลื่อนไหวตั้งแต่แรก ดังนั้น การเปลี่ยนเป็นรูปแบบวิดีโอที่เหมาะสมกว่าจะช่วยให้คุณประหยัดพื้นที่ได้มากในแง่ของขนาดไฟล์
ในแอป Oodle เราใช้ GIF เป็นลำดับอินโทรในหน้าแรก Lighthouse ระบุว่าเราอาจประหยัดพื้นที่ได้มากกว่า 7 MB ด้วยการเปลี่ยนไปใช้รูปแบบวิดีโอที่มีประสิทธิภาพมากขึ้น คลิปของเรามีน้ำหนักประมาณ 7.3 MB ซึ่งมากเกินกว่าที่เว็บไซต์ใดๆ จะรับไหว เราจึงเปลี่ยนเป็นองค์ประกอบวิดีโอที่มีไฟล์ต้นฉบับ 2 ไฟล์ ได้แก่ mp4 และ WebM เพื่อให้รองรับเบราว์เซอร์ได้มากขึ้น
![แทนที่ GIF แบบเคลื่อนไหวด้วยวิดีโอ](https://web.dev/static/articles/web-performance-made-easy/image/replace-animated-gifs-vi-fc084e0a3fb4e.png?authuser=8&hl=th)
เราใช้เครื่องมือ 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 บอกให้เราทําคือหลีกเลี่ยงการไปและกลับหลายครั้งไปยังต้นทางใดๆ ซึ่งทําให้สิ้นเปลืองค่าใช้จ่าย
![หลีกเลี่ยงการเดินทางหลายเที่ยวไปและกลับจากต้นทางซึ่งทำให้สิ้นเปลือง](https://web.dev/static/articles/web-performance-made-easy/image/avoid-multiple-costly-ro-1349e14da4d4d.png?authuser=8&hl=th)
ในกรณีของแอป Oodle เราใช้ Google Fonts อย่างมาก เมื่อคุณวางสไตล์ชีต Google Font ลงในหน้าเว็บ ระบบจะเชื่อมต่อโดเมนย่อยได้สูงสุด 2 รายการ และสิ่งที่ Lighthouse บอกเราก็คือ หากอุ่นเครื่องการเชื่อมต่อได้ เราจะประหยัดเวลาในการเชื่อมต่อครั้งแรกได้สูงสุด 300 มิลลิวินาที
การใช้ข้อกำหนด rel=preconnect ของลิงก์ช่วยให้เรามาสก์เวลาในการตอบสนองของการเชื่อมต่อได้อย่างมีประสิทธิภาพ
โดยเฉพาะอย่างยิ่งกับบริการอย่าง Google Fonts ที่โฮสต์ CSS ของแบบอักษรใน googleapis.com และโฮสต์ทรัพยากรแบบอักษรใน Gstatic ซึ่งอาจส่งผลอย่างมาก เราจึงใช้การเพิ่มประสิทธิภาพนี้และลดเวลาได้หลายร้อยมิลลิวินาที
สิ่งถัดไปที่ Lighthouse แนะนําคือให้โหลดคําขอคีย์ล่วงหน้า
![โหลดคําขอคีย์ล่วงหน้า](https://web.dev/static/articles/web-performance-made-easy/image/preload-key-requests-a2751a962b7e2.png?authuser=8&hl=th)
<link rel=preload>
มีประสิทธิภาพมาก โดยจะแจ้งให้เบราว์เซอร์ทราบว่าต้องใช้ทรัพยากรเป็นส่วนหนึ่งของการนําทางปัจจุบัน และพยายามให้เบราว์เซอร์ดึงข้อมูลดังกล่าวโดยเร็วที่สุด
ตอนนี้ Lighthouse บอกเราว่าเราควรโหลดทรัพยากรแบบอักษรเว็บหลักไว้ล่วงหน้า เนื่องจากเราโหลดแบบอักษรเว็บ 2 แบบ
การโหลดล่วงหน้าในแบบอักษรเว็บมีลักษณะดังนี้ เมื่อระบุ rel=preload
ให้ส่ง as
พร้อมประเภทแบบอักษร จากนั้นระบุประเภทแบบอักษรที่พยายามโหลด เช่น woff2
ผลกระทบที่อาจเกิดขึ้นกับหน้าเว็บนั้นค่อนข้างชัดเจน
![ผลกระทบของการโหลดทรัพยากรล่วงหน้า](https://web.dev/static/articles/web-performance-made-easy/image/impact-preloading-resour-d6cf8908f75e3.png?authuser=8&hl=th)
โดยปกติแล้ว หากไม่ได้ใช้การโหลดล่วงหน้าของ rel ของลิงก์ และหากแบบอักษรเว็บมีความสำคัญต่อหน้าเว็บ สิ่งแรกที่เบราว์เซอร์ต้องทำคือต้องดึงข้อมูล HTML, ต้องแยกวิเคราะห์ CSS และหลังจากนั้นอีกนาน เบราว์เซอร์ก็จะดึงข้อมูลแบบอักษรเว็บ
เมื่อใช้การโหลดล่วงหน้าของ rel ลิงก์ เบราว์เซอร์จะเริ่มดึงข้อมูลแบบอักษรเว็บเหล่านั้นได้เร็วขึ้นมากทันทีที่แยกวิเคราะห์ HTML ในกรณีของแอปของเรา การดำเนินการนี้ช่วยประหยัดเวลาในการเรนเดอร์ข้อความโดยใช้แบบอักษรเว็บได้ 1 วินาที
แต่การพยายามโหลดแบบอักษรล่วงหน้าโดยใช้ Google Fonts นั้นไม่ง่ายอย่างที่คิด เนื่องจากมีข้อควรระวังอยู่อย่างหนึ่ง
URL ของแบบอักษร Google ที่เราระบุในแบบอักษรในสไตล์ชีตเป็น URL ที่ทีมแบบอักษรอัปเดตเป็นประจำ URL เหล่านี้อาจหมดอายุหรือมีการอัปเดตเป็นประจํา ดังนั้นสิ่งที่เราแนะนําให้คุณทําหากต้องการควบคุมประสบการณ์การโหลดแบบสมบูรณ์คือโฮสต์แบบเว็บฟอนต์ด้วยตนเอง ซึ่งจะมีประโยชน์มากเนื่องจากช่วยให้คุณเข้าถึงสิ่งต่างๆ เช่น การโหลดล่วงหน้าของ rel ของลิงก์
ในกรณีของเรา เราพบว่าเครื่องมือตัวช่วย Web Fonts ของ Google มีประโยชน์มากในการช่วยเราออฟไลน์ Web Fonts บางรายการและตั้งค่าในเครื่อง ดังนั้นโปรดลองใช้เครื่องมือดังกล่าว
ไม่ว่าคุณจะใช้แบบอักษรเว็บเป็นส่วนหนึ่งของทรัพยากรสําคัญหรือเป็น JavaScript ก็ตาม ให้พยายามช่วยให้เบราว์เซอร์แสดงทรัพยากรสําคัญโดยเร็วที่สุด
ทดลองใช้: คำแนะนำเกี่ยวกับลําดับความสําคัญ
วันนี้เรามีเรื่องพิเศษมาแจ้งให้ทราบ นอกจากฟีเจอร์อย่างคำแนะนำทรัพยากรและการโหลดล่วงหน้าแล้ว เรายังพัฒนาฟีเจอร์ใหม่ล่าสุดสำหรับเบราว์เซอร์ที่ชื่อ "คำแนะนำลําดับความสําคัญ"
![กำหนดลำดับความสำคัญของเนื้อหาที่แสดงตั้งแต่แรก](https://web.dev/static/articles/web-performance-made-easy/image/set-priority-the-initial-a002f3faeabf3.png?authuser=8&hl=th)
นี่เป็นฟีเจอร์ใหม่ที่ให้คุณบอกเบราว์เซอร์ว่าทรัพยากรสำคัญเพียงใด โดยจะแสดงแอตทริบิวต์ใหม่ "ความสำคัญ" ที่มีค่าเป็นต่ำ สูง หรืออัตโนมัติ
ซึ่งช่วยให้เราลดลำดับความสำคัญของทรัพยากรที่ไม่สำคัญ เช่น สไตล์ รูปภาพ หรือการเรียก API ที่ไม่สำคัญ เพื่อลดการแย่งกันใช้ทรัพยากร นอกจากนี้ เรายังเพิ่มลำดับความสำคัญของสิ่งที่สำคัญกว่า เช่น รูปภาพหลัก
ในกรณีของแอป Oodle ของเรา การดำเนินการนี้ช่วยให้เราเพิ่มประสิทธิภาพได้ในที่เดียว
![กำหนดลำดับความสำคัญของเนื้อหาที่แสดงตั้งแต่แรก](https://web.dev/static/articles/web-performance-made-easy/image/set-priority-the-initial-b31819a78b75c.png?authuser=8&hl=th)
ก่อนที่เราจะเพิ่มการโหลดแบบเลื่อนลงช้าให้กับรูปภาพ สิ่งที่เบราว์เซอร์ทำคือ เรามีภาพสไลด์ที่มีภาพวาดทั้งหมดของเรา และเบราว์เซอร์ดึงข้อมูลรูปภาพทั้งหมดที่จุดเริ่มต้นของภาพสไลด์โดยให้ความสำคัญสูงตั้งแต่เนิ่นๆ แต่รูปภาพที่อยู่ตรงกลางของภาพสไลด์กลับมีความสำคัญต่อผู้ใช้มากที่สุด สิ่งที่เราทําคือตั้งค่าความสําคัญของรูปภาพพื้นหลังเป็น "ต่ำมาก" และรูปภาพเบื้องหน้าเป็น "สูงมาก" ผลที่ได้คือเวลาในการโหลด 2 วินาทีบนเครือข่าย 3G ที่ช้า และความเร็วในการดึงข้อมูลและแสดงผลรูปภาพเหล่านั้น คุณได้รับประสบการณ์ที่ดี
เราหวังว่าจะให้บริการฟีเจอร์นี้ใน Canary ในอีก 2-3 สัปดาห์ข้างหน้า โปรดคอยติดตาม
มีกลยุทธ์การโหลดแบบอักษรเว็บ
การจัดรูปแบบตัวอักษรเป็นพื้นฐานของการออกแบบที่ดี และหากคุณใช้แบบอักษรเว็บ คุณไม่ควรบล็อกการแสดงผลข้อความ และไม่ควรแสดงข้อความที่มองไม่เห็น
ตอนนี้เราไฮไลต์ปัญหานี้ใน Lighthouse ด้วยการตรวจสอบหลีกเลี่ยงข้อความที่มองไม่เห็นขณะที่โหลดเว็บฟอนต์
![หลีกเลี่ยงข้อความที่มองไม่เห็นขณะที่เว็บฟอนต์กำลังโหลด](https://web.dev/static/articles/web-performance-made-easy/image/avoid-invisible-text-whil-d461292533245.png?authuser=8&hl=th)
หากคุณโหลดแบบอักษรเว็บโดยใช้บล็อกแบบอักษร คุณกำลังปล่อยให้เบราว์เซอร์ตัดสินใจว่าจะทำอย่างไรหากการดึงข้อมูลแบบอักษรเว็บนั้นใช้เวลานาน บางเบราว์เซอร์จะรอสูงสุด 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 วินาที และระยะเวลาการแลกเปลี่ยนแบบไม่จำกัด ซึ่งหมายความว่าเบราว์เซอร์จะวาดข้อความของคุณเกือบจะทันทีด้วยแบบอักษรสำรองหากแบบอักษรใช้เวลาโหลดนาน และระบบจะเปลี่ยนเมื่อแบบอักษรพร้อมใช้งาน
ในกรณีของแอปของเรา เหตุผลที่การอัปเดตนี้ยอดเยี่ยมคือทำให้เราแสดงข้อความที่มีความหมายได้ตั้งแต่เนิ่นๆ และเปลี่ยนไปใช้แบบอักษรเว็บเมื่อพร้อม
![ผลลัพธ์การแสดงแบบอักษร](https://web.dev/static/articles/web-performance-made-easy/image/font-display-outcome-a014081404b38.png?authuser=8&hl=th)
โดยทั่วไปแล้ว หากคุณใช้แบบอักษรเว็บ (เช่นเดียวกับเว็บไซต์ส่วนใหญ่) ก็ควรมีกลยุทธ์การโหลดแบบอักษรเว็บที่ดี
แพลตฟอร์มเว็บมีฟีเจอร์มากมายที่คุณสามารถใช้เพื่อเพิ่มประสิทธิภาพประสบการณ์การโหลดแบบอักษร แต่อย่าลืมดูที่เก็บ Web Font Recipes ของ Zach Leatherman ด้วย เพราะดีมาก
ลดสคริปต์ที่บล็อกการแสดงผล
มีแอปพลิเคชันส่วนอื่นๆ ที่เราอาจส่งในเชนการดาวน์โหลดได้เร็วขึ้นเพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานขั้นพื้นฐานอย่างน้อยที่สุดก่อนเวลาดังกล่าว
ในแถบไทม์ไลน์ของ Lighthouse คุณจะเห็นได้ว่าในช่วง 2-3 วินาทีแรกนี้เมื่อทรัพยากรทั้งหมดกำลังโหลด ผู้ใช้จะไม่เห็นเนื้อหาใดๆ เลย
![ลดโอกาสที่จะมีสไตล์ชีตที่บล็อกการแสดงผล](https://web.dev/static/articles/web-performance-made-easy/image/reduce-render-blocking-st-ee605dfe41336.png?authuser=8&hl=th)
การดาวน์โหลดและประมวลผลสไตล์ชีตภายนอกกําลังบล็อกกระบวนการแสดงผลของเราไม่ให้ดําเนินการต่อ
เราอาจลองเพิ่มประสิทธิภาพเส้นทางการแสดงผลที่สำคัญด้วยการส่งสไตล์บางรายการให้เร็วขึ้นเล็กน้อย
หากเราดึงสไตล์ที่รับผิดชอบการแสดงผลเริ่มต้นนี้และแทรกไว้ใน HTML เบราว์เซอร์จะแสดงผลได้ทันทีโดยไม่ต้องรอให้สไตล์ชีตภายนอกมาถึง
ในกรณีของเรา เราใช้โมดูล NPM ชื่อ Critical เพื่อแทรกเนื้อหาที่สําคัญในหน้า index.html ในระหว่างขั้นตอนการสร้าง
แม้ว่าโมดูลนี้จะทํางานหนักส่วนใหญ่ให้เรา แต่ก็ยังทําให้ระบบทํางานได้อย่างราบรื่นในเส้นทางต่างๆ ได้ค่อนข้างยาก
หากคุณไม่ระมัดระวังหรือโครงสร้างเว็บไซต์มีความซับซ้อนมาก การนํารูปแบบนี้มาใช้อาจเป็นเรื่องยากมากหากคุณไม่ได้วางแผนสถาปัตยกรรม App Shell ตั้งแต่ต้น
ด้วยเหตุนี้ คุณจึงต้องคำนึงถึงประสิทธิภาพตั้งแต่เนิ่นๆ หากไม่ได้ออกแบบเพื่อประสิทธิภาพตั้งแต่เริ่มต้น คุณก็มีโอกาสสูงที่จะพบปัญหาในภายหลัง
ท้ายที่สุดแล้ว ความเสี่ยงของเราก็คุ้มค่า เราทําให้ใช้งานได้และแอปเริ่มแสดงเนื้อหาได้เร็วขึ้นมาก ซึ่งช่วยปรับปรุงเวลาการแสดงผลที่มีความหมายครั้งแรกได้อย่างมาก
ผลลัพธ์
นี่เป็นรายการการเพิ่มประสิทธิภาพที่ยาวมากที่เรานำมาใช้กับเว็บไซต์ มาดูผลลัพธ์กัน นี่คือวิธีที่แอปของเราโหลดในอุปกรณ์เคลื่อนที่ขนาดกลางบนเครือข่าย 3G ก่อนและหลังการเพิ่มประสิทธิภาพ
คะแนนประสิทธิภาพของ Lighthouse เพิ่มขึ้นจาก 23 เป็น 91 นี่เป็นความคืบหน้าที่ดีมากในแง่ความเร็ว การเปลี่ยนแปลงทั้งหมดเกิดขึ้นจากการตรวจสอบและปฏิบัติตามรายงาน Lighthouse อย่างต่อเนื่อง หากต้องการดูว่าเราติดตั้งใช้งานการปรับปรุงทั้งหมดทางเทคนิคอย่างไร โปรดไปที่รีโปของเรา โดยเฉพาะ PR ที่อัปโหลดในนั้น
ประสิทธิภาพการคาดการณ์ - ประสบการณ์ของผู้ใช้ที่อิงตามข้อมูล
เราเชื่อว่าแมชชีนเลิร์นนิงเป็นโอกาสที่น่าตื่นเต้นสำหรับอนาคตในหลายด้าน แนวคิดหนึ่งที่เราหวังว่าจะจุดประกายการทดสอบเพิ่มเติมในอนาคตคือข้อมูลจริงสามารถช่วยชี้แนะประสบการณ์ของผู้ใช้ที่เรากำลังสร้างได้
ปัจจุบันเราตัดสินใจอย่างอิสระหลายอย่างเกี่ยวกับสิ่งที่ผู้ใช้อาจต้องการหรือจําเป็น และจึงตัดสินใจว่าควรมีการเรียกข้อมูลล่วงหน้า โหลดล่วงหน้า หรือแคชล่วงหน้าหรือไม่ หากเดาถูก เราจะจัดลําดับความสําคัญของทรัพยากรจํานวนเล็กน้อยได้ แต่การปรับขนาดให้ครอบคลุมทั้งเว็บไซต์นั้นทําได้ยากมาก
เรามีข้อมูลที่จะใช้เป็นข้อมูลในการเพิ่มประสิทธิภาพได้ดียิ่งขึ้นในปัจจุบัน เมื่อใช้ Reporting API สําหรับ Google Analytics เราดูหน้ายอดนิยมหน้าถัดไปและเปอร์เซ็นต์การออกสําหรับ URL ใดก็ได้ในเว็บไซต์ของเรา จึงสรุปได้ว่าควรให้ความสําคัญกับทรัพยากรใด
เมื่อรวมข้อมูลนี้เข้ากับโมเดลความน่าจะเป็นที่ดี เราจะหลีกเลี่ยงการสิ้นเปลืองข้อมูลของผู้ใช้ด้วยการโหลดเนื้อหาล่วงหน้ามากเกินไป เราใช้ประโยชน์จากข้อมูล Google Analytics ดังกล่าวได้ รวมถึงใช้แมชชีนเลิร์นนิงและโมเดลต่างๆ เช่น เชน Markov หรือเครือข่ายประสาทเพื่อติดตั้งใช้งานโมเดลดังกล่าว
![การรวมแอปตามข้อมูลสําหรับเว็บแอป](https://web.dev/static/articles/web-performance-made-easy/image/data-driven-bundling-web-3843c496c6e42.png?authuser=8&hl=th)
เรายินดีที่จะประกาศโครงการริเริ่มใหม่ที่มีชื่อว่า Guess.js เพื่ออำนวยความสะดวกในการทดสอบนี้
![Guess.js](https://web.dev/static/articles/web-performance-made-easy/image/guessjs-8f7d906237584.png?authuser=8&hl=th)
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