ในงาน Google IO 2018 เราได้นำเสนอสรุปเครื่องมือ ไลบรารี และเทคนิคการเพิ่มประสิทธิภาพที่ช่วยให้การปรับปรุงประสิทธิภาพของเว็บง่ายขึ้น ในที่นี้ เราจะอธิบายโดยใช้แอป The Oodles Theater นอกจากนี้ เรายังพูดถึงการทดสอบการโหลดแบบคาดการณ์และความคิดริเริ่มใหม่ของ Guess.js ด้วย
ในช่วงปีที่ผ่านมา เรายุ่งมากกับการพยายามหาวิธีทำให้เว็บทำงานได้เร็วขึ้นและมีประสิทธิภาพมากขึ้น ซึ่งนำไปสู่เครื่องมือ แนวทาง และไลบรารีใหม่ๆ ที่เราอยากแชร์กับคุณในบทความนี้ ในส่วนแรก เราจะแสดงเทคนิคการเพิ่มประสิทธิภาพบางอย่างที่เราใช้ในทางปฏิบัติเมื่อพัฒนาแอป Oodles Theater ในส่วนที่ 2 เราจะพูดถึงการทดสอบการโหลดแบบคาดการณ์และความคิดริเริ่มใหม่ของ Guess.js
ความต้องการด้านประสิทธิภาพ
อินเทอร์เน็ตมีขนาดใหญ่ขึ้นเรื่อยๆ ทุกปี หากเราตรวจสอบสถานะของเว็บ เราจะเห็นว่าหน้าเว็บโดยเฉลี่ยในอุปกรณ์เคลื่อนที่มีขนาดประมาณ 1.5 MB โดยส่วนใหญ่เป็น JavaScript และรูปภาพ
ขนาดเว็บไซต์ที่เพิ่มขึ้น ประกอบกับปัจจัยอื่นๆ เช่น เวลาในการตอบสนองของเครือข่าย ข้อจำกัดของ CPU รูปแบบการบล็อกการแสดงผล หรือโค้ดของบุคคลที่สามที่มากเกินไป ล้วนส่งผลให้เกิดปัญหาด้านประสิทธิภาพที่ซับซ้อน
ผู้ใช้ส่วนใหญ่ให้คะแนนความเร็วเป็นอันดับสูงสุดในลำดับชั้น UX ของความต้องการ ซึ่งก็ไม่น่าแปลกใจนัก เพราะคุณจะทำอะไรไม่ได้มากจนกว่าหน้าเว็บจะโหลดเสร็จ คุณไม่สามารถรับคุณค่าจากหน้าเว็บ คุณไม่สามารถชื่นชมความสวยงามของหน้าเว็บได้
เราทราบดีว่าประสิทธิภาพเป็นสิ่งสำคัญสำหรับผู้ใช้ แต่การค้นหาจุดเริ่มต้นในการเพิ่มประสิทธิภาพก็อาจดูเป็นเรื่องลึกลับ แต่โชคดีที่มีเครื่องมือที่ช่วยคุณได้ตลอดเส้นทาง
Lighthouse - ฐานสำหรับเวิร์กโฟลว์ด้านประสิทธิภาพ
Lighthouse เป็นส่วนหนึ่งของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ที่ช่วยให้คุณตรวจสอบเว็บไซต์และให้คำแนะนำเกี่ยวกับวิธีปรับปรุงเว็บไซต์ให้ดียิ่งขึ้น
เมื่อเร็วๆ นี้เราได้เปิดตัวการตรวจสอบประสิทธิภาพใหม่จำนวนมากซึ่งมีประโยชน์อย่างยิ่งในเวิร์กโฟลว์การพัฒนาในชีวิตประจำวัน
มาดูวิธีใช้ประโยชน์จากฟีเจอร์เหล่านี้ในตัวอย่างที่ใช้งานได้จริงกัน แอป Oodles Theater เป็นเว็บแอปสาธิตขนาดเล็กที่คุณสามารถลองเล่น Google Doodle แบบอินเทอร์แอกทีฟที่เราชื่นชอบ และยังเล่นเกมได้ 1-2 เกมด้วย
ขณะสร้างแอป เราต้องการให้แอปมีประสิทธิภาพมากที่สุดเท่าที่จะเป็นไปได้ จุดเริ่มต้นของการเพิ่มประสิทธิภาพคือรายงาน Lighthouse
ประสิทธิภาพเริ่มต้นของแอปตามที่เห็นในรายงาน Lighthouse นั้นแย่มาก ในเครือข่าย 3G ผู้ใช้ต้องรอ 15 วินาทีเพื่อให้ First Meaningful Paint หรือแอปเริ่มโต้ตอบได้ Lighthouse ไฮไลต์ปัญหามากมายในเว็บไซต์ของเรา และคะแนนประสิทธิภาพโดยรวมที่ 23 ก็สะท้อนให้เห็นถึงปัญหานั้นอย่างชัดเจน
หน้าเว็บมีน้ำหนักประมาณ 3.4 MB เราจึงจำเป็นต้องลดขนาดลงอย่างมาก
นี่เป็นจุดเริ่มต้นของความท้าทายด้านประสิทธิภาพครั้งแรกของเรา นั่นคือการค้นหาสิ่งที่เรานำออกได้ง่ายๆ โดยไม่ส่งผลกระทบต่อประสบการณ์โดยรวม
โอกาสในการเพิ่มประสิทธิภาพ
นำแหล่งข้อมูลที่ไม่จำเป็นออก
มีบางสิ่งที่เห็นได้ชัดว่านำออกได้อย่างปลอดภัย นั่นคือช่องว่างและความคิดเห็น
Lighthouse จะไฮไลต์โอกาสนี้ในการตรวจสอบ CSS และ JavaScript ที่ไม่ได้ลดขนาด เราใช้ webpack สำหรับกระบวนการบิลด์ ดังนั้นเพื่อให้ได้การลดขนาด เราจึงใช้ปลั๊กอิน Uglify JS
การลดขนาดเป็นงานที่พบบ่อย คุณจึงควรหาโซลูชันสำเร็จรูปสำหรับกระบวนการบิลด์ที่ใช้ได้
การตรวจสอบที่มีประโยชน์อีกอย่างหนึ่งในพื้นที่นั้นคือเปิดใช้การบีบอัดข้อความ ไม่มีเหตุผลที่จะส่งไฟล์ที่ไม่มีการบีบอัด และ CDN ส่วนใหญ่ก็รองรับการบีบอัดไฟล์อยู่แล้วในปัจจุบัน
เราใช้โฮสติ้งของ Firebase เพื่อโฮสต์โค้ด และ Firebase จะเปิดใช้ gzipping โดยค่าเริ่มต้น ดังนั้นด้วยข้อดีของการโฮสต์โค้ดบน CDN ที่เหมาะสม เราจึงได้ใช้ฟีเจอร์นี้ฟรี
แม้ว่า gzip จะเป็นวิธีบีบอัดที่ได้รับความนิยมอย่างมาก แต่กลไกอื่นๆ เช่น Zopfli และ Brotli ก็ได้รับความนิยมมากขึ้นเช่นกัน Brotli ได้รับการสนับสนุนในเบราว์เซอร์ส่วนใหญ่ และคุณสามารถใช้ไบนารีเพื่อบีบอัดเนื้อหาก่อนส่งไปยังเซิร์ฟเวอร์ได้
ใช้นโยบายแคชที่มีประสิทธิภาพ
ขั้นตอนถัดไปคือการตรวจสอบว่าเราจะไม่ส่งทรัพยากรซ้ำหากไม่จำเป็น
การตรวจสอบนโยบายแคชที่ไม่มีประสิทธิภาพใน Lighthouse ช่วยให้เราสังเกตเห็นว่าเราสามารถเพิ่มประสิทธิภาพกลยุทธ์การแคชเพื่อให้บรรลุเป้าหมายดังกล่าวได้ การตั้งค่าส่วนหัวการหมดอายุ max-age ในเซิร์ฟเวอร์ช่วยให้มั่นใจได้ว่าเมื่อผู้ใช้เข้าชมซ้ำจะสามารถใช้ทรัพยากรที่ดาวน์โหลดไว้ก่อนหน้านี้ซ้ำได้
คุณควรตั้งเป้าหมายที่จะแคชทรัพยากรให้มากที่สุดเท่าที่จะทำได้อย่างปลอดภัยเป็นระยะเวลานานที่สุด และระบุโทเค็นสำหรับตรวจสอบความถูกต้องเพื่อตรวจสอบความถูกต้องของทรัพยากรที่อัปเดตอีกครั้งอย่างมีประสิทธิภาพ
นำโค้ดที่ไม่ได้ใช้ออก
จนถึงตอนนี้ เราได้นำส่วนที่ชัดเจนของการดาวน์โหลดที่ไม่จำเป็นออกไปแล้ว แต่ส่วนที่ไม่ชัดเจนล่ะ เช่น โค้ดที่ไม่ได้ใช้
บางครั้งเราใส่โค้ดที่ไม่จำเป็นจริงๆ ไว้ในแอป กรณีนี้มักเกิดขึ้นหากคุณทำงานกับแอปเป็นเวลานาน ทีมหรือทรัพยากร Dependency มีการเปลี่ยนแปลง และบางครั้งไลบรารีที่ไม่มีการอ้างอิงก็ถูกทิ้งไว้ นั่นคือสิ่งที่เกิดขึ้นกับเราจริงๆ
ในช่วงแรกเราใช้ไลบรารี Material Components เพื่อสร้างต้นแบบแอปอย่างรวดเร็ว เมื่อเวลาผ่านไป เราเปลี่ยนไปใช้รูปลักษณ์ที่กำหนดเองมากขึ้นและลืมไลบรารีนั้นไปเลย โชคดีที่การตรวจสอบการครอบคลุมของโค้ดช่วยให้เราค้นพบโค้ดดังกล่าวอีกครั้งในแพ็กเกจ
คุณสามารถตรวจสอบสถิติการครอบคลุมของโค้ดได้ใน DevTools ทั้งสำหรับรันไทม์และเวลาในการโหลดของแอปพลิเคชัน คุณจะเห็นแถบสีแดงขนาดใหญ่ 2 แถบในภาพหน้าจอด้านล่าง เรามี CSS ที่ไม่ได้ใช้มากกว่า 95% และ JavaScript จำนวนมากด้วย
Lighthouse ยังพบปัญหานี้ในการตรวจสอบกฎ CSS ที่ไม่ได้ใช้ด้วย ซึ่งแสดงให้เห็นว่ามีโอกาสประหยัดได้ มากกว่า 400 KB เราจึงกลับไปที่โค้ดและนำทั้งส่วน JavaScript และ CSS ของไลบรารีนั้นออก
ซึ่งทำให้แพ็กเกจ CSS ของเราลดลง 20 เท่า ซึ่งถือว่าดีมากสำหรับคอมมิตสั้นๆ เพียง 2 บรรทัด
แน่นอนว่าคะแนนประสิทธิภาพของเราเพิ่มขึ้น และเวลาในการตอบสนองก็ดีขึ้นมากด้วย
อย่างไรก็ตาม การเปลี่ยนแปลงเช่นนี้ไม่เพียงพอที่จะตรวจสอบเมตริกและคะแนนเพียงอย่างเดียว การนำโค้ดจริงออกมีความเสี่ยงเสมอ ดังนั้นคุณจึงควรระวังการถดถอยที่อาจเกิดขึ้น
โค้ดของเราไม่ได้ใช้ใน 95% แต่ยังมีอีก 5% ที่ยังคงอยู่ ปรากฏว่ามีคอมโพเนนต์หนึ่งของเราที่ยังใช้สไตล์จากไลบรารีนั้นอยู่ ซึ่งก็คือลูกศรเล็กๆ ในแถบเลื่อน Doodle แต่เนื่องจากเป็นโปรเจ็กต์ขนาดเล็ก เราจึงสามารถเข้าไปเพิ่มสไตล์เหล่านั้นกลับเข้าไปในปุ่มได้ด้วยตนเอง
ดังนั้น หากคุณนำโค้ดออก โปรดตรวจสอบว่าคุณมีเวิร์กโฟลว์การทดสอบที่เหมาะสมเพื่อช่วยป้องกันการถดถอยของภาพที่อาจเกิดขึ้น
หลีกเลี่ยงเพย์โหลดเครือข่ายขนาดใหญ่
เราทราบดีว่าทรัพยากรขนาดใหญ่อาจทำให้การโหลดหน้าเว็บช้าลง เพราะอาจทำให้ผู้ใช้เสียเงินและส่งผลกระทบอย่างมากต่อแพ็กเกจอินเทอร์เน็ต จึงเป็นเรื่องสำคัญมากที่ต้องคำนึงถึงเรื่องนี้
Lighthouse ตรวจพบว่าเรามีปัญหาเกี่ยวกับเพย์โหลดเครือข่ายบางรายการโดยใช้การตรวจสอบเพย์โหลดเครือข่ายขนาดใหญ่
เราพบว่ามีโค้ดขนาดมากกว่า 3 MB ที่ส่งลงมา ซึ่งถือว่าค่อนข้างมาก โดยเฉพาะในอุปกรณ์เคลื่อนที่
ที่ด้านบนสุดของรายการนี้ Lighthouse ไฮไลต์ว่าเรามีแพ็กเกจผู้ให้บริการ JavaScript ที่มีโค้ดที่ไม่ได้บีบอัดขนาด 2 MB ปัญหานี้ยังเป็นปัญหาที่ webpack ไฮไลต์ด้วย
ดังคำกล่าวที่ว่า คำขอที่เร็วที่สุดคือคำขอที่ไม่ได้สร้างขึ้น
คุณควรวัดมูลค่าของเนื้อหาทุกรายการที่แสดงต่อผู้ใช้ วัดประสิทธิภาพของเนื้อหาเหล่านั้น และตัดสินใจว่าคุ้มค่าที่จะส่งไปพร้อมกับประสบการณ์การใช้งานครั้งแรกหรือไม่ เนื่องจากบางครั้งชิ้นงานเหล่านี้อาจเลื่อนออกไป หรือโหลดแบบ Lazy Loading หรือประมวลผลในช่วงที่ไม่มีการใช้งาน
ในกรณีของเรา เนื่องจากเราต้องจัดการกับแพ็กเกจ JavaScript จำนวนมาก เราจึงโชคดีที่ชุมชน JavaScript มีชุดเครื่องมือตรวจสอบแพ็กเกจ JavaScript ที่หลากหลาย
เราเริ่มต้นด้วยเครื่องมือวิเคราะห์แพ็กเกจ webpack ซึ่งแจ้งให้เราทราบว่าเราได้รวมทรัพยากร Dependency ที่ชื่อว่า unicode ซึ่งเป็น JavaScript ที่แยกวิเคราะห์แล้วขนาด 1.6 MB ซึ่งถือว่าค่อนข้างมาก
จากนั้นเราก็ไปที่เครื่องมือแก้ไขและใช้ปลั๊กอิน Import Cost สำหรับ Visual Code เพื่อให้เห็นภาพต้นทุนของทุกโมดูลที่เรานำเข้า ซึ่งช่วยให้เราค้นพบว่าคอมโพเนนต์ใดมีโค้ดที่อ้างอิงโมดูลนี้
จากนั้นเราจึงเปลี่ยนไปใช้เครื่องมืออื่น นั่นคือ BundlePhobia ซึ่งเป็นเครื่องมือที่ช่วยให้คุณป้อนชื่อแพ็กเกจ NPM และดูขนาดที่ลดลงและบีบอัดด้วย gzip โดยประมาณได้ เราพบทางเลือกที่ดีสำหรับโมดูล Slug ที่เราใช้อยู่ซึ่งมีขนาดเพียง 2.2 KB เราจึงเปลี่ยนไปใช้โมดูลนั้น
ซึ่งส่งผลต่อประสิทธิภาพของเราอย่างมาก การเปลี่ยนแปลงนี้และการค้นพบโอกาสอื่นๆ ในการลดขนาดแพ็กเกจ JavaScript ช่วยให้เราประหยัดโค้ดได้ 2.1 MB
เราพบว่าประสิทธิภาพโดยรวมดีขึ้น 65% เมื่อพิจารณาขนาดที่บีบอัดด้วย gzip และลดขนาดของแพ็กเกจเหล่านี้ และเราพบว่าการทำเช่นนี้เป็นกระบวนการที่คุ้มค่าจริงๆ
ดังนั้น โดยทั่วไปแล้ว ให้พยายามกำจัดการดาวน์โหลดที่ไม่จำเป็นในเว็บไซต์และแอปของคุณ การทำรายการชิ้นงานและวัดผลกระทบด้านประสิทธิภาพจะสร้างความแตกต่างได้อย่างมาก ดังนั้นโปรดตรวจสอบชิ้นงานเป็นประจำ
ลดเวลาในการเปิดเครื่อง JavaScript ด้วยการแยกโค้ด
แม้ว่าเพย์โหลดเครือข่ายขนาดใหญ่จะส่งผลกระทบอย่างมากต่อแอปของเรา แต่ก็ยังมีอีกสิ่งหนึ่งที่ส่งผลกระทบอย่างมากเช่นกัน นั่นคือ JavaScript
JavaScript เป็นเนื้อหาที่มีค่าใช้จ่ายสูงที่สุด ในอุปกรณ์เคลื่อนที่ หากคุณส่งแพ็กเกจ JavaScript ขนาดใหญ่ อาจทำให้ผู้ใช้โต้ตอบกับคอมโพเนนต์อินเทอร์เฟซผู้ใช้ได้ช้าลง ซึ่งหมายความว่าผู้ใช้อาจแตะ UI โดยที่ไม่มีอะไรเกิดขึ้นจริง ดังนั้นเราจึงต้องเข้าใจว่าทำไม JavaScript จึงมีต้นทุนสูงมาก
นี่คือวิธีที่เบราว์เซอร์ประมวลผล JavaScript
ก่อนอื่นเราต้องดาวน์โหลดสคริปต์นั้น เรามีเครื่องมือ JavaScript ซึ่งต้องแยกวิเคราะห์โค้ดนั้น จากนั้นจึงคอมไพล์และเรียกใช้โค้ด
ขั้นตอนเหล่านี้ใช้เวลาไม่นานนักในอุปกรณ์ระดับไฮเอนด์ เช่น คอมพิวเตอร์เดสก์ท็อปหรือแล็ปท็อป หรือแม้แต่โทรศัพท์ระดับไฮเอนด์ แต่ในโทรศัพท์มือถือระดับกลาง กระบวนการนี้อาจใช้เวลานานกว่า 5-10 เท่า ซึ่งเป็นสิ่งที่ทำให้การโต้ตอบล่าช้า เราจึงต้องพยายามลดขนาดของไฟล์นี้
เราได้เปิดตัวการตรวจสอบเวลาบูต JavaScript ใหม่ใน Lighthouse เพื่อช่วยให้คุณค้นพบปัญหาเหล่านี้ในแอป
และในกรณีของแอป Oodle นั้น เราพบว่าเราใช้เวลา 1.8 วินาทีในการบูต JavaScript สิ่งที่เกิดขึ้นคือเรานำเข้าเส้นทางและคอมโพเนนต์ทั้งหมดแบบคงที่ลงในแพ็กเกจ JavaScript แบบโมโนลิธิกรายการเดียว
เทคนิคหนึ่งในการแก้ปัญหานี้คือการใช้การแยกโค้ด
การแยกโค้ดคือแนวคิดที่ว่า แทนที่จะให้ JavaScript ทั้งหมดแก่ผู้ใช้ จะดีกว่าไหมหากคุณให้ JavaScript แก่ผู้ใช้ทีละส่วนตามที่ต้องการ
การแยกโค้ดสามารถใช้ได้ที่ระดับเส้นทางหรือระดับคอมโพเนนต์ ซึ่งทำงานได้ดีกับ React และ React Loadable, Vue.js, Angular, Polymer, Preact และไลบรารีอื่นๆ อีกหลายรายการ
เราได้รวมการแยกโค้ดไว้ในแอปพลิเคชัน โดยเปลี่ยนจากการนำเข้าแบบคงที่ไปเป็นการนำเข้าแบบไดนามิก ซึ่งช่วยให้เราโหลดโค้ดแบบ Lazy Loading แบบอะซิงโครนัสได้ตามต้องการ
ผลลัพธ์ที่ได้คือขนาดของ Bundle ลดลง และเวลาในการบูต 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
เราลดน้ำหนักโดยรวมได้มากกว่า 80% ด้วยการแปลงนี้ ซึ่งทำให้ขนาดไฟล์ลดลงเหลือประมาณ 1 MB
อย่างไรก็ตาม 1 MB ก็ยังเป็นทรัพยากรขนาดใหญ่ที่ต้องส่งผ่านสาย โดยเฉพาะสำหรับผู้ใช้ที่มีแบนด์วิดท์จำกัด โชคดีที่เราสามารถใช้ Effective Type API เพื่อให้ทราบว่าผู้ใช้มีแบนด์วิดท์ต่ำ และแสดง JPEG ที่มีขนาดเล็กลงมากแทนได้
อินเทอร์เฟซนี้ใช้ค่าเวลาไปกลับ (RTT) ที่มีประสิทธิภาพและค่าการดาวน์โหลดเพื่อประมาณประเภทเครือข่ายที่ผู้ใช้กำลังใช้งาน โดยจะแสดงผลสตริง, 2G ช้า, 2G, 3G หรือ 4G ดังนั้น หากผู้ใช้ใช้เครือข่ายที่ต่ำกว่า 4G เราสามารถแทนที่องค์ประกอบวิดีโอด้วยรูปภาพได้โดยอิงตามค่านี้
if (navigator.connection.effectiveType) { ... }
ซึ่งอาจทำให้ประสบการณ์การใช้งานลดลงเล็กน้อย แต่อย่างน้อยเว็บไซต์ก็ใช้งานได้แม้จะมีการเชื่อมต่อที่ช้า
รูปภาพที่อยู่นอกหน้าจอแบบ Lazy Load
ภาพสไลด์ แถบเลื่อน หรือหน้าเว็บที่ยาวมากมักจะโหลดรูปภาพ แม้ว่าผู้ใช้จะมองไม่เห็นรูปภาพเหล่านั้นในหน้าเว็บทันทีก็ตาม
Lighthouse จะแจ้งเตือนลักษณะการทำงานนี้ในการตรวจสอบรูปภาพนอกหน้าจอ และคุณยังดูได้ด้วยตนเองในแผงเครือข่ายของเครื่องมือสำหรับนักพัฒนาเว็บ หากคุณเห็นรูปภาพจำนวนมากที่กำลังโหลดเข้ามาในขณะที่มีเพียงไม่กี่รูปที่แสดงในหน้าเว็บ แสดงว่าคุณอาจพิจารณาใช้การโหลดแบบ Lazy Loading แทนได้
เบราว์เซอร์ยังไม่รองรับการโหลดแบบ 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 Fonts ลงในหน้าเว็บ ระบบจะเชื่อมต่อโดเมนย่อยสูงสุด 2 รายการ และสิ่งที่ Lighthouse บอกเราก็คือ หากเราสามารถอุ่นเครื่องการเชื่อมต่อนั้นได้ เราจะประหยัดเวลาในการเชื่อมต่อครั้งแรกได้ถึง 300 มิลลิวินาที
การใช้ประโยชน์จาก link rel preconnect จะช่วยให้เราปกปิดเวลาในการตอบสนองของการเชื่อมต่อได้อย่างมีประสิทธิภาพ
โดยเฉพาะอย่างยิ่งกับบริการอย่าง Google Fonts ซึ่ง CSS ของแบบอักษรโฮสต์อยู่บน googleapis.com และทรัพยากรแบบอักษรโฮสต์อยู่บน Gstatic ซึ่งอาจส่งผลกระทบอย่างมาก เราจึงใช้การเพิ่มประสิทธิภาพนี้และลดเวลาลงได้ 2-3 ร้อยมิลลิวินาที
สิ่งถัดไปที่ Lighthouse แนะนำคือให้เราโหลดคำขอคีย์ล่วงหน้า
<link rel=preload> มีประสิทธิภาพมาก โดยจะแจ้งให้เบราว์เซอร์ทราบว่าจำเป็นต้องใช้ทรัพยากรเป็นส่วนหนึ่งของการนำทางปัจจุบัน และพยายามให้เบราว์เซอร์ดึงข้อมูลทรัพยากรดังกล่าวโดยเร็วที่สุด
Lighthouse กำลังบอกเราว่าเราควรโหลดทรัพยากรแบบอักษรเว็บที่สำคัญไว้ล่วงหน้า เนื่องจากเรากำลังโหลดแบบอักษรเว็บ 2 แบบ
การโหลดแบบอักษรเว็บล่วงหน้าจะมีลักษณะดังนี้ โดยระบุ rel=preload คุณส่ง as พร้อมประเภทแบบอักษร จากนั้นระบุประเภทแบบอักษรที่ต้องการโหลด เช่น woff2
ผลกระทบที่อาจเกิดขึ้นกับหน้าเว็บของคุณนั้นค่อนข้างชัดเจน
โดยปกติแล้ว หากไม่ใช้ link rel preload และเว็บฟอนต์มีความสำคัญต่อหน้าเว็บ สิ่งที่เบราว์เซอร์ต้องทำคือดึงข้อมูล HTML ก่อน จากนั้นจึงแยกวิเคราะห์ CSS และหลังจากนั้นอีกนานจึงจะดึงข้อมูลเว็บฟอนต์
การใช้ link rel preload ทันทีที่เบราว์เซอร์แยกวิเคราะห์ HTML ของคุณแล้ว เบราว์เซอร์จะเริ่มดึงข้อมูลแบบอักษรบนเว็บเหล่านั้นได้เร็วกว่ามาก ในกรณีของแอปของเรา วิธีนี้ช่วยลดเวลาที่ใช้ในการแสดงผลข้อความโดยใช้แบบอักษรบนเว็บได้ 1 วินาที
แต่การโหลดแบบอักษรล่วงหน้าโดยใช้ Google Fonts ไม่ได้ตรงไปตรงมาขนาดนั้น เพราะมีข้อควรระวังอยู่ข้อหนึ่ง
URL ของ Google Fonts ที่เราระบุในแบบอักษรในสไตล์ชีตเป็นสิ่งที่ทีม Fonts อัปเดตค่อนข้างสม่ำเสมอ URL เหล่านี้อาจหมดอายุหรือได้รับการอัปเดตเป็นประจำ ดังนั้นสิ่งที่เราขอแนะนำให้ทำหากคุณต้องการควบคุมประสบการณ์การโหลดแบบอักษรอย่างสมบูรณ์คือการโฮสต์เว็บฟอนต์ด้วยตนเอง ซึ่งเป็นเรื่องดีเพราะจะช่วยให้คุณเข้าถึงสิ่งต่างๆ เช่น link rel preload ได้
ในกรณีของเรา เราพบว่าเครื่องมือ Google Web Fonts Helper มีประโยชน์มากในการช่วยเราออฟไลน์แบบอักษรบนเว็บเหล่านั้นบางส่วนและตั้งค่าแบบอักษรเหล่านั้นในเครื่อง ดังนั้นลองดูเครื่องมือนั้น
ไม่ว่าคุณจะใช้แบบอักษรบนเว็บเป็นส่วนหนึ่งของทรัพยากรที่สำคัญ หรือใช้ JavaScript ก็ตาม ให้พยายามช่วยเบราว์เซอร์แสดงทรัพยากรที่สำคัญโดยเร็วที่สุด
เวอร์ชันทดลอง: คำแนะนำเกี่ยวกับลำดับความสำคัญ
เรามีเรื่องพิเศษที่จะแชร์กับคุณในวันนี้ นอกจากฟีเจอร์อย่างคำแนะนำเกี่ยวกับทรัพยากรและการโหลดล่วงหน้าแล้ว เรายังได้พัฒนาฟีเจอร์ใหม่ล่าสุดสำหรับเบราว์เซอร์ที่อยู่ระหว่างการทดลอง ซึ่งเราเรียกว่าคำแนะนำเกี่ยวกับลำดับความสำคัญ
ฟีเจอร์ใหม่นี้ช่วยให้คุณบอกใบ้เบราว์เซอร์ได้ว่าทรัพยากรมีความสำคัญเพียงใด โดยจะแสดงแอตทริบิวต์ใหม่ที่ชื่อว่า importance ซึ่งมีค่าเป็น low, high หรือ auto
ซึ่งช่วยให้เราสามารถลดลำดับความสำคัญของทรัพยากรที่มีความสำคัญน้อยลง เช่น รูปแบบ รูปภาพ หรือการเรียก API การดึงข้อมูลที่ไม่สำคัญ เพื่อลดการแย่งชิงทรัพยากร นอกจากนี้ เรายังเพิ่มลำดับความสำคัญของสิ่งสำคัญอื่นๆ ได้ด้วย เช่น รูปภาพหลัก
ในกรณีของแอป Oodle ของเรา สิ่งนี้ทำให้เราพบจุดที่สามารถเพิ่มประสิทธิภาพได้จริง
ก่อนที่เราจะเพิ่มการโหลดแบบ Lazy Loading ลงในรูปภาพ สิ่งที่เบราว์เซอร์ทำคือเรามีภาพสไลด์ที่มี Doodle ทั้งหมด และเบราว์เซอร์จะดึงข้อมูลรูปภาพทั้งหมดที่จุดเริ่มต้นของภาพสไลด์โดยมีลำดับความสำคัญสูงตั้งแต่เนิ่นๆ แต่รูปภาพที่อยู่ตรงกลางของภาพสไลด์กลับเป็นรูปภาพที่สำคัญที่สุดสำหรับผู้ใช้ สิ่งที่เราทำคือตั้งค่าความสำคัญของรูปภาพพื้นหลังเหล่านั้นให้ต่ำมาก และตั้งค่ารูปภาพเบื้องหน้าให้สูงมาก ซึ่งช่วยลดเวลาในการดึงข้อมูลและแสดงผลรูปภาพเหล่านั้นได้ถึง 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 วินาที และมีระยะเวลาการสลับแบบไม่จำกัด ซึ่งหมายความว่าเบราว์เซอร์จะแสดงข้อความทันทีด้วยแบบอักษรสำรองหากแบบอักษรใช้เวลาโหลดนาน และจะสลับเมื่อแบบอักษรพร้อมใช้งาน
ในกรณีของแอปเรา สิ่งที่ยอดเยี่ยมคือช่วยให้เราแสดงข้อความที่มีความหมายได้ตั้งแต่เนิ่นๆ และเปลี่ยนไปใช้แบบอักษรบนเว็บเมื่อพร้อม
โดยทั่วไปแล้ว หากคุณใช้แบบอักษรบนเว็บเหมือนกับที่เว็บไซต์ส่วนใหญ่ทำ ให้ใช้กลยุทธ์การโหลดแบบอักษรบนเว็บที่ดี
มีฟีเจอร์แพลตฟอร์มเว็บมากมายที่คุณสามารถใช้เพื่อเพิ่มประสิทธิภาพประสบการณ์การโหลดแบบอักษร แต่ลองดูที่เก็บสูตรแบบอักษรบนเว็บของ Zach Leatherman ด้วย เพราะมันยอดเยี่ยมมาก
ลดสคริปต์ที่บล็อกการแสดงผล
มีส่วนอื่นๆ ของแอปพลิเคชันที่เราสามารถพุชก่อนหน้านี้ในเชนการดาวน์โหลดเพื่อมอบประสบการณ์การใช้งานขั้นพื้นฐานแก่ผู้ใช้ได้เร็วขึ้นเล็กน้อย
ในแถบไทม์ไลน์ของ Lighthouse คุณจะเห็นว่าในช่วง 2-3 วินาทีแรกที่ทรัพยากรทั้งหมดกำลังโหลด ผู้ใช้จะมองไม่เห็นเนื้อหาใดๆ เลย
การดาวน์โหลดและการประมวลผลสไตล์ชีตภายนอกกำลังบล็อกกระบวนการแสดงผลของเราไม่ให้ดำเนินการต่อ
เราสามารถลองเพิ่มประสิทธิภาพเส้นทางการแสดงผลที่สำคัญได้โดยการส่งสไตล์บางส่วนให้เร็วขึ้นเล็กน้อย
หากเราดึงสไตล์ที่รับผิดชอบการแสดงผลเริ่มต้นนี้และแทรกไว้ใน HTML เบราว์เซอร์จะแสดงผลสไตล์เหล่านั้นได้ทันทีโดยไม่ต้องรอให้สไตล์ชีตภายนอกมาถึง
ในกรณีของเรา เราใช้โมดูล NPM ที่ชื่อว่า Critical เพื่อแทรกเนื้อหาที่สำคัญใน index.html ในบรรทัดเดียวกันระหว่างขั้นตอนการสร้าง
แม้ว่าโมดูลนี้จะช่วยเราได้มาก แต่ก็ยังคงเป็นเรื่องยากที่จะทำให้โมดูลนี้ทำงานได้อย่างราบรื่นในเส้นทางต่างๆ
หากคุณไม่ระมัดระวังหรือโครงสร้างเว็บไซต์ซับซ้อนมาก การใช้รูปแบบประเภทนี้อาจเป็นเรื่องยากมากหากคุณไม่ได้วางแผนสำหรับสถาปัตยกรรม App Shell ตั้งแต่ต้น
นี่จึงเป็นเหตุผลว่าทำไมการพิจารณาประสิทธิภาพตั้งแต่เนิ่นๆ จึงมีความสำคัญอย่างยิ่ง หากคุณไม่ได้ออกแบบเพื่อประสิทธิภาพตั้งแต่เริ่มต้น ก็มีโอกาสสูงที่คุณจะพบปัญหาในการดำเนินการในภายหลัง
ในที่สุดความเสี่ยงของเราก็คุ้มค่า เราจัดการให้แอปทำงานได้และเริ่มแสดงเนื้อหาได้เร็วขึ้นมาก ซึ่งช่วยปรับปรุงเวลา First Meaningful Paint ได้อย่างมาก
ผลลัพธ์
นั่นคือรายการการเพิ่มประสิทธิภาพที่ยาวเหยียดที่เรานำไปใช้กับเว็บไซต์ มาดูผลลัพธ์กัน นี่คือลักษณะที่แอปของเราโหลดบนอุปกรณ์เคลื่อนที่ขนาดกลางบนเครือข่าย 3G ทั้งก่อนและหลังการเพิ่มประสิทธิภาพ
คะแนนประสิทธิภาพของ Lighthouse เพิ่มขึ้นจาก 23 เป็น 91 ถือว่ามีความคืบหน้าที่ดีมากในแง่ของความเร็ว การเปลี่ยนแปลงทั้งหมดเกิดขึ้นจากการที่เราตรวจสอบและปฏิบัติตามรายงาน Lighthouse อย่างต่อเนื่อง หากต้องการดูวิธีที่เราใช้เทคนิคในการปรับปรุงทั้งหมด โปรดดูที่เก็บข้อมูลของเรา โดยเฉพาะ PR ที่อยู่ในนั้น
ประสิทธิภาพที่คาดการณ์ได้ - ประสบการณ์ของผู้ใช้ที่อิงตามข้อมูล
เราเชื่อว่าแมชชีนเลิร์นนิงเป็นโอกาสที่น่าตื่นเต้นสำหรับอนาคตในหลายๆ ด้าน แนวคิดหนึ่งที่เราหวังว่าจะจุดประกายให้เกิดการทดลองมากขึ้นในอนาคตคือข้อมูลจริงสามารถชี้นำประสบการณ์ของผู้ใช้ที่เรากำลังสร้างขึ้นได้จริงๆ
ปัจจุบัน เราทำการตัดสินใจตามอำเภอใจมากมายเกี่ยวกับสิ่งที่ผู้ใช้อาจต้องการหรือจำเป็นต้องใช้ ดังนั้นจึงควรดึงข้อมูลล่วงหน้า โหลดล่วงหน้า หรือการแคชล่วงหน้า (Pre-Caching) หากเราคาดเดาได้ถูกต้อง เราจะจัดลำดับความสำคัญของทรัพยากรจำนวนเล็กน้อยได้ แต่การปรับขนาดให้ครอบคลุมทั้งเว็บไซต์นั้นทำได้ยากมาก
จริงๆ แล้วเรามีข้อมูลที่ช่วยให้เราเพิ่มประสิทธิภาพได้ดีขึ้นในปัจจุบัน เมื่อใช้ 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 Doodle