ในงาน Google IO 2018 เราได้นำเสนอสรุปเครื่องมือ ห้องสมุด และเทคนิคการเพิ่มประสิทธิภาพที่ช่วยให้การปรับปรุงประสิทธิภาพเว็บเป็นเรื่องง่ายขึ้น ในที่นี้เราจะอธิบายเกี่ยวกับการใช้แอป Oodles Theater นอกจากนี้ เรายังพูดถึงการทดลองด้วยการโหลดแบบคาดการณ์และโครงการริเริ่ม Guess.js ใหม่ด้วย
ตลอดปีที่ผ่านมา เราต่างพยายามคิดหาวิธีที่จะทำให้เว็บทำงานได้เร็วขึ้นและมีประสิทธิภาพมากขึ้น ซึ่งนำไปสู่เครื่องมือ วิธีการ และคลังใหม่ๆ ที่เราอยากแชร์กับคุณในบทความนี้ ในส่วนแรก เราจะแสดงเทคนิคการเพิ่มประสิทธิภาพบางอย่างที่เราใช้ในเชิงปฏิบัติเมื่อพัฒนาแอป Oodles Theatre ในส่วนที่ 2 เราจะพูดถึงการทดสอบด้วยการโหลดแบบคาดการณ์และโครงการริเริ่ม Guess.js ใหม่
ความต้องการด้านประสิทธิภาพ
อินเทอร์เน็ตนั้นหนักขึ้นและหนักขึ้นทุกปี หากตรวจสอบสถานะของเว็บ เราจะเห็นว่าหน้าค่ามัธยฐานของอุปกรณ์เคลื่อนที่มีน้ำหนักประมาณ 1.5 MB ซึ่งส่วนใหญ่เป็น JavaScript และรูปภาพ
ขนาดของเว็บไซต์ที่เติบโตขึ้นเรื่อยๆ ร่วมกับปัจจัยอื่นๆ เช่น เวลาในการตอบสนองของเครือข่าย ข้อจำกัดของ CPU รูปแบบการบล็อกการแสดงผล หรือโค้ดของบุคคลที่สามที่ไม่จำเป็น
ผู้ใช้ส่วนใหญ่ให้คะแนนความเร็วว่าอยู่ในระดับที่สูงที่สุดในลำดับชั้น UX ตามความต้องการของตน นี่ไม่น่าแปลกใจ เพราะคุณไม่สามารถดำเนินการได้หลายอย่างจนกว่าหน้าเว็บจะโหลดเสร็จ คุณไม่สามารถดึงคุณค่าจากหน้าเว็บได้ต้องชื่นชมความงามของหน้าไม่ได้
เราทราบดีว่าประสิทธิภาพนั้นสำคัญต่อผู้ใช้ แต่ก็รู้สึกเหมือนกันที่รู้ว่าควรเริ่มต้นเพิ่มประสิทธิภาพที่จุดไหน แต่ก็ยังมีเครื่องมือที่ช่วยคุณได้
Lighthouse - ฐานสำหรับเวิร์กโฟลว์ด้านประสิทธิภาพ
Lighthouseเป็นส่วนหนึ่งของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ที่ช่วยให้คุณตรวจสอบเว็บไซต์และให้คำแนะนำเกี่ยวกับวิธีปรับปรุง
เมื่อเร็วๆ นี้เราได้เปิดตัวการตรวจสอบประสิทธิภาพแบบใหม่หลายรายการ ซึ่งมีประโยชน์มากในเวิร์กโฟลว์การพัฒนาทุกวัน
มาดูตัวอย่างวิธีใช้ประโยชน์จากฟีเจอร์เหล่านี้กับตัวอย่างที่ใช้งานได้จริงกัน แอป Oodles Theatre เป็นเว็บแอปสาธิตเล็กๆ ที่คุณสามารถลองใช้ Google Doodle แบบอินเทอร์แอกทีฟที่เราชื่นชอบและเล่นเกมสักเกม 1-2 เกมได้
ขณะสร้างแอป เราอยากจะดูแลให้แอปนี้มีประสิทธิภาพสูงสุด จุดเริ่มต้นของการเพิ่มประสิทธิภาพคือรายงาน Lighthouse
ประสิทธิภาพเบื้องต้นของแอปตามที่แสดงในรายงาน Lighthouse นั้นค่อนข้างแย่ บนเครือข่าย 3G ผู้ใช้ต้องรอ 15 วินาทีเพื่อให้การแสดงผลที่มีความหมายครั้งแรก หรือทำให้แอปมีการโต้ตอบ Lighthouse ไฮไลต์ปัญหามากมายในเว็บไซต์ของเรา และคะแนนประสิทธิภาพโดยรวมอยู่ที่ 23 คะแนนก็เหมือนกับ
หน้าเว็บมีน้ำหนักประมาณ 3.4 MB เราจำเป็นต้องลดปริมาณไขมันลงอย่างมาก
จึงเป็นจุดเริ่มต้นของความท้าทายด้านประสิทธิภาพแรก นั่นคือ หาสิ่งที่เรานำออกได้ง่ายๆ โดยไม่กระทบต่อประสบการณ์โดยรวม
โอกาสในการเพิ่มประสิทธิภาพ
นำทรัพยากรที่ไม่จำเป็นออก
มีสิ่งที่เห็นได้ชัดเจนซึ่งสามารถนำออกไปแล้วได้ เช่น การเว้นวรรคและความคิดเห็น
Lighthouse ไฮไลต์โอกาสนี้ไว้ในการตรวจสอบ CSS และ JavaScript ที่ยังไม่ได้ปรับปรุง เราใช้ Webpack สำหรับกระบวนการสร้าง เราจึงใช้ปลั๊กอิน Uglify JS เพื่อทำการลดขนาด
การลดขนาดเป็นงานที่พบได้บ่อย คุณจึงควรหาโซลูชันสำเร็จรูปสำหรับกระบวนการสร้างที่ใช้
การตรวจสอบที่มีประโยชน์อีกอย่างหนึ่งในพื้นที่ทำงานคือเปิดใช้การบีบอัดข้อความ ไม่มีเหตุผลที่จะต้องส่งไฟล์ที่ไม่ได้บีบอัด และ CDN ส่วนใหญ่จะรองรับวิธีการนี้ตั้งแต่แรกเริ่ม
เราใช้โฮสติ้งของ Firebase เพื่อโฮสต์โค้ด และ Firebase เปิดใช้ gzipping โดยค่าเริ่มต้น ดังนั้นตามหลักในการโฮสต์โค้ดของเราใน CDN ที่สมเหตุสมผลทำให้เราได้แบบนั้นฟรี
แม้ว่า gzip จะเป็นวิธีการบีบอัดที่นิยมใช้กันมาก แต่กลไกอื่นๆ เช่น Zopfli และ Brotli ก็ได้รับความสนใจเช่นกัน Brotli รองรับเบราว์เซอร์ส่วนใหญ่ และคุณสามารถใช้ไบนารีเพื่อบีบอัดเนื้อหาล่วงหน้าก่อนที่จะส่งไปยังเซิร์ฟเวอร์
ใช้นโยบายแคชที่มีประสิทธิภาพ
ขั้นตอนถัดไปคือตรวจสอบว่าเราจะไม่ส่งทรัพยากรซ้ำ 2 ครั้งหากไม่จำเป็น
การตรวจสอบนโยบายแคชที่ไม่มีประสิทธิภาพใน Lighthouse ช่วยให้เราสังเกตเห็นว่าเราสามารถเพิ่มประสิทธิภาพกลยุทธ์การแคชเพื่อให้ได้ผลลัพธ์เช่นนั้นได้ ด้วยการตั้งค่าส่วนหัวการหมดอายุของอายุสูงสุดในเซิร์ฟเวอร์ของเรา ผู้ใช้จะนำแหล่งข้อมูลที่เคยดาวน์โหลดมาก่อนกลับมาใช้ซ้ำได้ทุกครั้งที่เข้าชมซ้ำ
โดยหลักการแล้ว คุณควรมุ่งแคชทรัพยากรให้ปลอดภัยให้มากที่สุดในระยะเวลาที่นานที่สุด และให้โทเค็นสำหรับตรวจสอบความถูกต้องเพื่อการตรวจสอบทรัพยากรที่อัปเดตอีกครั้งอย่างมีประสิทธิภาพ
ลบโค้ดที่ไม่ได้ใช้
ตอนนี้เราได้ลบส่วนที่ชัดเจนของการดาวน์โหลดที่ไม่จำเป็นออกไป แล้วส่วนที่ไม่ชัดเจนนักล่ะ เช่น โค้ดที่ไม่ได้ใช้
บางครั้งเราจะใส่โค้ดของแอปซึ่งไม่จำเป็นจริงๆ กรณีเช่นนี้เกิดขึ้นโดยเฉพาะอย่างยิ่งหากคุณใช้งานแอปเป็นเวลานาน ทีมหรือทรัพยากร Dependency ของคุณจะเปลี่ยนไป และบางครั้งไลบรารีที่ไม่มีเจ้าของก็ถูกทิ้งไว้ และนั่นคือสิ่งที่เกิดขึ้นกับเรา
ช่วงแรกเราใช้ไลบรารีคอมโพเนนต์ Materials เพื่อสร้างต้นแบบแอปขึ้นมาอย่างรวดเร็ว ในช่วงแรกเราเปลี่ยนไปใช้รูปลักษณ์ที่กำหนดเองและเราลืมไปเลยว่าไลบรารีนั้นมีอะไรบ้าง โชคดีที่การตรวจสอบการครอบคลุมของโค้ดช่วยให้เราค้นพบโค้ดดังกล่าวได้อีกครั้งในแพ็กเกจ
คุณสามารถตรวจสอบสถิติการครอบคลุมของโค้ดได้ในเครื่องมือสำหรับนักพัฒนาเว็บ ทั้งในส่วนของรันไทม์และเวลาในการโหลดแอปพลิเคชัน คุณจะเห็นแถบสีแดงขนาดใหญ่ 2 แถบในภาพหน้าจอด้านล่าง เรามี CSS ที่ไม่มีการใช้งานมากกว่า 95% และยังมี JavaScript จำนวนมากอีกด้วย
Lighthouse ยังพบปัญหานี้ในการตรวจสอบกฎ CSS ที่ไม่ได้ใช้งาน หน้าจอแสดงให้เห็นว่าสามารถประหยัดพื้นที่ ได้มากกว่า 400 KB เราจึงกลับไปที่โค้ด และนำส่วน JavaScript และ CSS ของไลบรารีนั้นออก
ซึ่งทำให้แพ็กเกจ CSS ของเราลดลงถึง 20 เท่า ซึ่งถือว่าดีสำหรับสัญญาผูกมัดขนาด 2 บรรทัดเล็กๆ
แน่นอนว่าวิธีนี้ทำให้คะแนนประสิทธิภาพของเราสูงขึ้น และ Time to Interactive ดีขึ้นมากด้วย
อย่างไรก็ตาม การเปลี่ยนแปลงเช่นนี้จะทำให้คุณตรวจสอบเมตริกและคะแนนเพียงอย่างเดียวไม่เพียงพอ การนำโค้ดจริงออกไม่มีความเสี่ยงใดๆ ดังนั้นคุณควรคอยระวังการถดถอยที่อาจเกิดขึ้น
โค้ดของเราไม่มีการใช้งานเป็นเวลา 95% แต่ยังคงมีอยู่ 5% นี้ เห็นได้ชัดว่าคอมโพเนนต์หนึ่งของเรายังใช้สไตล์จากคลังนั้นอยู่ ซึ่งก็คือลูกศรเล็กๆ ในแถบเลื่อนของ Doodle แต่เนื่องจากมีขนาดเล็ก เราจึงสามารถใส่รูปแบบดังกล่าวกลับเข้าไปในปุ่มด้วยตนเองได้
ดังนั้นหากคุณนำโค้ดออก ก็เพียงแค่เตรียมเวิร์กโฟลว์การทดสอบที่เหมาะสมไว้เพื่อช่วยป้องกันภาพถดถอยที่อาจเกิดขึ้นได้
หลีกเลี่ยงเพย์โหลดเครือข่ายปริมาณมาก
เราทราบว่าทรัพยากรขนาดใหญ่อาจทำให้หน้าเว็บโหลดได้ช้าลง ทำให้ผู้ใช้ของเราเสียค่าใช้จ่ายและอาจส่งผลกระทบอย่างมากต่อแผนการใช้งานข้อมูล ดังนั้นคุณต้องคำนึงถึงเรื่องนี้ให้ดี
Lighthouse ตรวจพบว่าเรามีปัญหากับเพย์โหลดของเครือข่ายบางรายการโดยใช้การตรวจสอบเพย์โหลดเครือข่ายขนาดใหญ่
จากตรงนี้ เราพบว่าเรามีโค้ดกว่า 3 MB ที่เรากำลังจะจัดส่งไป ซึ่งค่อนข้างมากโดยเฉพาะอย่างยิ่งบนอุปกรณ์เคลื่อนที่
ที่ด้านบนสุดของรายการนี้ Lighthouse ได้ไฮไลต์ว่าเรามีแพ็กเกจผู้ให้บริการ JavaScript ที่มีขนาด 2 เมกะไบต์ของโค้ดที่ไม่ได้บีบอัด ซึ่งเป็นปัญหาที่ไฮไลต์โดย Webpack
อย่างที่ใครๆ ก็ทำกัน คำขอที่เร็วที่สุดคือคำขอที่เรายังไม่ได้สร้าง
ตามหลักการแล้ว คุณควรวัดมูลค่าของชิ้นงานทุกรายการที่แสดงต่อผู้ใช้ วัดประสิทธิภาพของเนื้อหาเหล่านั้น และสอบถามว่าคุ้มค่ากับการจัดส่งหลังเริ่มใช้งานจริงหรือไม่ เนื่องจากบางครั้งเนื้อหาเหล่านี้อาจมีการหน่วงเวลา โหลดแบบ Lazy Loading หรือประมวลผลในช่วงที่ไม่มีการใช้งาน
ในกรณีของเรา เนื่องจากเรากำลังรับมือกับกลุ่ม JavaScript จำนวนมาก เราจึงโชคดีเพราะชุมชน JavaScript มีชุดเครื่องมือตรวจสอบกลุ่ม JavaScript ที่สมบูรณ์
เราเริ่มต้นด้วยเครื่องมือวิเคราะห์ชุด Webpack ซึ่งแจ้งให้ทราบว่าเราได้รวมทรัพยากร Dependency ที่เรียกว่า Unicode ซึ่งเป็น JavaScript ที่แยกวิเคราะห์แล้วขนาด 1.6 MB ซึ่งถือว่าค่อนข้างเยอะมาก
จากนั้นเราได้ไปที่ตัวแก้ไขของเราและใช้ปลั๊กอินนำเข้าค่าใช้จ่ายสำหรับโค้ดแบบภาพ เราสามารถแสดงภาพค่าใช้จ่ายของทุกโมดูลที่เรานำเข้าได้ ซึ่งทำให้เราทราบว่าคอมโพเนนต์ใด มีโค้ดที่อ้างอิงถึงโมดูลนี้
จากนั้นก็เปลี่ยนไปใช้เครื่องมืออื่นที่ชื่อว่า BundlePhobia เครื่องมือนี้ช่วยให้คุณสามารถป้อนชื่อของแพ็กเกจ NPM และดูว่าขนาดที่ย่อเล็กสุดและ gzip จะมีขนาดเท่าใด เราพบทางเลือกที่ดีสำหรับโมดูลทากที่เราใช้ ซึ่งมีน้ำหนักเพียง 2.2 KB เราเลยเปลี่ยนไป
กลยุทธ์นี้ส่งผลกระทบอย่างมากต่อประสิทธิภาพของเรา ระหว่างการเปลี่ยนแปลงครั้งนี้กับการค้นพบโอกาสอื่นๆ ในการลดขนาดไฟล์ JavaScript เราได้ประหยัดโค้ดไป 2.1MB
โดยรวมแล้วเราเห็นการปรับปรุงถึง 65% เมื่อคุณคำนึงถึงขนาดของแพ็กเกจเหล่านี้ที่บีบอัดและบีบอัดแล้ว และเราพบว่ากระบวนการนี้คุ้มค่ามาก ที่จะนำไปทำเป็นกระบวนการ
ดังนั้นโดยทั่วไป ให้พยายามกำจัดการดาวน์โหลดที่ไม่จำเป็นในเว็บไซต์และแอป สร้างพื้นที่โฆษณาของชิ้นงานและวัดผลกระทบด้านประสิทธิภาพที่สร้างความแตกต่างได้อย่างมาก ดังนั้น โปรดตรวจสอบชิ้นงานอย่างสม่ำเสมอ
ลดเวลาในการเปิดเครื่อง JavaScript ด้วยการแยกโค้ด
แม้ว่าเพย์โหลดของเครือข่ายขนาดใหญ่อาจส่งผลกระทบอย่างมากต่อแอปของเรา แต่ยังมีอีกสิ่งหนึ่งที่มีผลอย่างมาก ซึ่งก็คือ JavaScript
JavaScript เป็นเนื้อหาที่แพงที่สุดของคุณ ในอุปกรณ์เคลื่อนที่ หากคุณส่ง JavaScript จำนวนมากออกไป อาจทำให้ผู้ใช้โต้ตอบกับคอมโพเนนต์อินเทอร์เฟซผู้ใช้ได้ช้าลง นั่นหมายความว่าสามารถแตะ UI ได้โดยที่ ไม่ได้มีความหมายอะไรเกิดขึ้นจริง เราจึงต้องเข้าใจว่าทำไม JavaScript จึงมีต้นทุนสูง
นี่เป็นวิธีที่เบราว์เซอร์ประมวลผล JavaScript
ก่อนอื่นเราต้องดาวน์โหลดสคริปต์ เรามีเครื่องมือ JavaScript ที่ต้องแยกวิเคราะห์โค้ด ต้องคอมไพล์และเรียกใช้
ในระยะนี้ สิ่งต่างๆ เหล่านี้ไม่ได้ใช้เวลานานเลยในอุปกรณ์ระดับไฮเอนด์ อย่างเครื่องเดสก์ท็อปหรือแล็ปท็อป หรือแม้กระทั่งโทรศัพท์ระดับไฮเอนด์ แต่ในมือถือค่ามัธยฐาน ขั้นตอนนี้อาจใช้เวลานานกว่า 5-10 เท่า จึงเป็นสิ่งที่ทำให้การโต้ตอบล่าช้า เราจึงต้องพยายามลดการโต้ตอบนี้
เพื่อช่วยให้คุณพบปัญหาเหล่านี้กับแอป เราจึงแนะนำการตรวจสอบเวลาเปิดเครื่อง JavaScript ใหม่ใน Lighthouse
ในกรณีของแอป Oodle แอปบอกว่าเรามีเวลา 1.8 วินาทีที่ใช้ในการบูต JavaScript สิ่งที่เกิดขึ้นคือเรานำเข้าแบบคงที่ในเส้นทางและคอมโพเนนต์ทั้งหมดลงในแพ็กเกจ JavaScript แบบโมโนลิธเพียงชุดเดียว
เทคนิคหนึ่งในการแก้ปัญหานี้คือการใช้การแยกโค้ด
การแยกโค้ดเป็นความคิดนี้ แทนที่จะให้ JavaScript เท่ากับปริมาณพิซซ่าทั้งก้อนแก่ผู้ใช้ หากคุณให้ JavaScript เพียงครั้งละ 1 ชิ้น
การแยกโค้ดทำได้ที่ระดับเส้นทางหรือระดับคอมโพเนนต์ โดยสามารถทำงานร่วมกับ React และ React Loadable, Vue.js, Angular, Polymer, Preact และไลบรารีอื่นๆ ได้อีกมากมาย
เรานำโค้ดมาใช้แยกลงในแอปพลิเคชันของเรา และเปลี่ยนจากการนำเข้าแบบคงที่เป็นการนำเข้าแบบไดนามิก ซึ่งทำให้เราสามารถโหลดโค้ดแบบ Lazy Loading แบบไม่พร้อมกันได้ตามต้องการ
ผลกระทบจากการที่ซอฟต์แวร์นี้มีขนาดเล็กลงของชุด Bundle และยังทำให้เวลาในการเปิดเครื่อง JavaScript ลดลงด้วย ใช้เวลาไม่เกิน 0.78 วินาที ทำให้แอปเร็วขึ้น 56%
โดยทั่วไป หากคุณกำลังสร้างการใช้งานที่ใช้ JavaScript มาก อย่าลืมส่งโค้ดไปยังผู้ใช้ที่ต้องการเท่านั้น
ใช้ประโยชน์จากแนวคิดต่างๆ เช่น การแยกโค้ด สำรวจแนวคิดต่างๆ เช่น การเขย่าต้นไม้ และดูไอเดีย webpack-libs-optimizations เพื่อดูวิธีตัดขนาดไลบรารีลงหากใช้ Webpack
เพิ่มประสิทธิภาพรูปภาพ
เราใช้รูปภาพจำนวนมากในแอป Oodle น่าเสียดายที่ Lighthouse ไม่ค่อยสนใจเรื่องนี้ น้อยกว่าที่เราเห็นอยู่มาก แต่เราไม่ผ่านการตรวจสอบเกี่ยวกับรูปภาพทั้ง 3 ครั้ง
เราลืมเพิ่มประสิทธิภาพรูปภาพ ไม่ได้ปรับขนาดรูปภาพอย่างถูกต้อง และเราอาจได้ประโยชน์จากการใช้รูปภาพรูปแบบอื่นๆ
เราเริ่มจากการเพิ่มประสิทธิภาพให้รูปภาพ
สำหรับการเพิ่มประสิทธิภาพแบบครั้งเดียว คุณสามารถใช้เครื่องมือแบบภาพ เช่น ImageOptim หรือ XNConvert
วิธีการที่เป็นแบบอัตโนมัติมากขึ้นคือการเพิ่มขั้นตอนการเพิ่มประสิทธิภาพรูปภาพลงในกระบวนการสร้างโดยใช้ไลบรารี เช่น imagemin
วิธีนี้จะช่วยให้มั่นใจได้ว่ารูปภาพที่เพิ่มในอนาคตจะได้รับการเพิ่มประสิทธิภาพโดยอัตโนมัติ CDN บางแห่ง เช่น Akamai หรือโซลูชันของบุคคลที่สาม เช่น ระบบคลาวด์ Fastly หรือ Uploadcare มอบโซลูชันการเพิ่มประสิทธิภาพรูปภาพที่ครอบคลุม คุณจึงฝากรูปภาพในบริการดังกล่าวได้ง่ายๆ ด้วย
หากไม่ต้องการดำเนินการดังกล่าวเนื่องจากปัญหาด้านค่าใช้จ่ายหรือเวลาในการตอบสนอง โปรเจ็กต์อย่าง Thumbor หรือ Imageflow จะมีทางเลือกที่โฮสต์ด้วยตนเอง
มีการแจ้งว่า PNG พื้นหลังของเราใน Webpack ว่าใหญ่ ซึ่งก็เป็นเช่นนั้น หลังจากที่ปรับขนาดให้ถูกต้องในวิวพอร์ตและใช้ผ่าน ImageOptim แล้ว ขนาดเราลงไปที่ 100 KB ซึ่งถือว่ายอมรับได้
การกล่าวซ้ำๆ กับรูปภาพหลายๆ รูปในเว็บไซต์ของเรานั้นช่วยให้เราลดน้ำหนักหน้าเว็บโดยรวมลงได้อย่างมาก
ใช้รูปแบบที่เหมาะสมสำหรับเนื้อหาภาพเคลื่อนไหว
GIF อาจมีราคาแพงมาก น่าประหลาดใจที่รูปแบบ GIF ไม่ได้ตั้งใจให้เป็นแพลตฟอร์มภาพเคลื่อนไหวตั้งแต่แรก ดังนั้น การเปลี่ยนไปใช้รูปแบบวิดีโอที่เหมาะสมยิ่งขึ้นจะช่วยประหยัดขนาดไฟล์ได้มาก
ในแอป Oodle เราใช้ GIF เป็นลำดับบทนำในหน้าแรก Lighthouse ระบุว่าเราสามารถประหยัดพื้นที่ได้ถึง 7 MB ด้วยการเปลี่ยนไปใช้รูปแบบวิดีโอที่มีประสิทธิภาพมากขึ้น คลิปของเราให้น้ำหนักประมาณ 7.3 เมกะไบต์ ซึ่งมากเกินไปสำหรับเว็บไซต์ทั่วไป เราจึงเปลี่ยนคลิปให้เป็นองค์ประกอบวิดีโอที่มีไฟล์ต้นฉบับ 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% จาก Conversion นี้ ทำให้ข้อมูลของเราลดลงเหลือประมาณ 1 MB
อย่างไรก็ตาม ขนาด 1MB ก็เป็นทรัพยากรขนาดใหญ่สำหรับการดันสายไฟลง โดยเฉพาะสำหรับผู้ใช้ที่ใช้แบนด์วิดท์ที่จำกัด โชคดีที่เราสามารถใช้ Effective Type API ทราบว่าใช้แบนด์วิดท์ต่ำ และใช้ JPEG ที่เล็กลงมากแทน
อินเทอร์เฟซนี้ใช้ค่าเวลาการรับส่งและค่าการดาวน์ที่มีประสิทธิภาพในการประเมินประเภทเครือข่ายที่ผู้ใช้ใช้ แต่จะส่งคืนสตริง 2G, 2G, 3G หรือ 4G ที่ช้า ดังนั้นจะขึ้นอยู่กับค่านี้ หากผู้ใช้ต่ำกว่า 4G เราอาจแทนที่องค์ประกอบวิดีโอด้วยรูปภาพ
if (navigator.connection.effectiveType) { ... }
ทำให้ประสบการณ์การใช้งานบางอย่างถูกลบออกไปได้เล็กน้อย แต่อย่างน้อยเว็บไซต์ก็สามารถใช้งานได้เมื่อมีการเชื่อมต่อที่ช้า
โหลดรูปภาพนอกหน้าจอแบบ Lazy Loading
ภาพสไลด์ แถบเลื่อน หรือหน้าเว็บที่ยาวมากๆ มักจะโหลดรูปภาพ แม้ว่าผู้ใช้จะไม่เห็นรูปภาพเหล่านั้นบนหน้าเว็บโดยทันทีก็ตาม
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"/>
Lazysize เป็นโซลูชันที่ชาญฉลาดเพราะไม่เพียงติดตามการเปลี่ยนแปลงระดับการเข้าถึงขององค์ประกอบเท่านั้น แต่ยังดึงข้อมูลองค์ประกอบที่อยู่ใกล้การแสดงผลไว้ล่วงหน้าเพื่อให้ผู้ใช้ได้รับประสบการณ์ที่ดีที่สุด
และยังมีการผสานรวม IntersectionObserver ที่ไม่บังคับ ซึ่งทำให้การค้นหาระดับการเข้าถึงมีประสิทธิภาพมาก
หลังจากการเปลี่ยนแปลงครั้งนี้ ระบบจะดึงข้อมูลรูปภาพของเราแบบออนดีมานด์ หากต้องการเจาะลึกยิ่งขึ้นเกี่ยวกับหัวข้อดังกล่าว โปรดดู images.guide ซึ่งเป็นแหล่งข้อมูลที่มีประโยชน์และครอบคลุมมาก
ช่วยให้เบราว์เซอร์นำส่งทรัพยากรที่สำคัญได้เร็วขึ้น
ไบต์แต่ละไบต์ที่ส่งไปยังเบราว์เซอร์จะมีระดับความสำคัญไม่เท่ากัน และเบราว์เซอร์จะรู้เรื่องนี้ เบราว์เซอร์จำนวนมากมีการเรียนรู้เพื่อตัดสินใจว่าควรดึงข้อมูลอะไรก่อน ดังนั้นบางครั้ง CSS จึงต้องดึงข้อมูล 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 อาจสร้างผลกระทบอย่างมาก เราจึงใช้การเพิ่มประสิทธิภาพนี้ และได้ลดไป 2-3 มิลลิวินาที
สิ่งต่อไปที่ Lighthouse แนะนำคือเราโหลดคำขอคีย์ล่วงหน้า
<link rel=preload> มีประสิทธิภาพอย่างยิ่ง โดยจะแจ้งเบราว์เซอร์ว่าจำเป็นต้องใช้ทรัพยากรเป็นส่วนหนึ่งของการนำทางในปัจจุบัน และจะพยายามให้เบราว์เซอร์ดึงข้อมูลโดยเร็วที่สุด
ตอนนี้ Lighthouse ได้แจ้งให้เราทราบว่าเราควรโหลดทรัพยากรแบบอักษรสำหรับเว็บที่สำคัญล่วงหน้า เนื่องจากเรากำลังโหลดแบบอักษรสำหรับเว็บ 2 แบบ
การโหลดล่วงหน้าในแบบอักษรของเว็บจะมีลักษณะดังนี้ เมื่อระบุ rel=preload คุณจะส่งประเภทแบบอักษรใน as แล้วระบุประเภทแบบอักษรที่พยายามโหลด เช่น woff2
ผลกระทบที่อาจมีต่อหน้าเว็บของคุณนั้นค่อนข้างชัดเจน
โดยปกติถ้าไม่ต้องใช้ลิงก์ rel โหลดล่วงหน้า ถ้าแบบอักษรเว็บมีความสำคัญต่อหน้าเว็บของคุณ สิ่งที่เบราว์เซอร์ต้องทำคือก่อนอื่นจะต้องดึงข้อมูล HTML ทำการแยกวิเคราะห์ CSS และสุดท้ายหลังจากนั้น แบบอักษรนั้นก็จะดึงข้อมูลและดึงข้อมูลแบบอักษรเว็บของคุณได้
การใช้การโหลดล่วงหน้าของลิงก์ rel ทันทีที่เบราว์เซอร์แยกวิเคราะห์ HTML ของคุณ เบราว์เซอร์จะเริ่มดึงแบบอักษรเว็บเหล่านั้นขึ้นมาก่อนหน้านี้มาก ในกรณีของแอป เราประหยัดเวลาในการแสดงผลข้อความโดยใช้แบบอักษรสำหรับเว็บได้ไป 2 ฝั่ง
ตอนนี้ก็คงไม่ง่ายนักหากจะลองโหลดแบบอักษรล่วงหน้าโดยใช้ Google Fonts มี Gote ตัวหนึ่ง
URL ของ Google Font ที่เราระบุบนแบบอักษรในสไตล์ชีตของเรานั้นเป็นสิ่งที่ทีมแบบอักษรจะอัปเดตเป็นประจำ URL เหล่านี้จะหมดอายุหรือได้รับการอัปเดตเป็นประจำ ดังนั้นสิ่งที่เราแนะนำให้ทำหากคุณต้องการควบคุมประสบการณ์ในการโหลดแบบอักษรอย่างสมบูรณ์คือการโฮสต์แบบอักษรสำหรับเว็บด้วยตัวเอง วิธีนี้ดีมากเพราะจะให้คุณเข้าถึงสิ่งต่างๆ เช่น การโหลดลิงก์ rel ล่วงหน้า
ในกรณีนี้ เราพบว่าเครื่องมือ Google Web Fonts Help มีประโยชน์มากในการช่วยเราออฟไลน์แบบอักษรเว็บเหล่านั้นและตั้งค่าในเครื่อง ดังนั้นให้ลองใช้เครื่องมือนี้
ไม่ว่าคุณจะใช้แบบอักษรเว็บเป็นส่วนหนึ่งของทรัพยากรที่สำคัญ หรือเป็น JavaScript ให้พยายามช่วยให้เบราว์เซอร์มอบทรัพยากรที่สำคัญของคุณโดยเร็วที่สุด
ทดลอง: คำแนะนำสำคัญ
เรามีสิ่งพิเศษที่จะแชร์กับคุณในวันนี้ นอกจากฟีเจอร์อย่างคำแนะนำด้านทรัพยากรและการโหลดล่วงหน้าแล้ว เรายังพัฒนาฟีเจอร์ทดลองเบราว์เซอร์แบบใหม่ที่เราเรียกว่าคำแนะนำที่มีลำดับความสำคัญสูงด้วย
นี่เป็นฟีเจอร์ใหม่ที่ให้คุณแนะนำเบราว์เซอร์ว่าทรัพยากรมีความสำคัญ โดยแสดงแอตทริบิวต์ใหม่ - ความสำคัญ โดยมีค่าต่ำ สูง หรืออัตโนมัติ
ซึ่งทำให้เราสามารถสื่อถึงการลดลำดับความสำคัญของทรัพยากรที่สำคัญน้อยกว่า เช่น รูปแบบที่ไม่สำคัญ รูปภาพ หรือการเรียก API เพื่อลดการช่วงชิงได้ นอกจากนี้ เรายังสามารถเพิ่มลำดับความสำคัญ ของสิ่งที่มีความสำคัญกว่า เช่น รูปภาพหลัก
ในกรณีของแอป Oodle จุดนี้นำไปสู่จุดหนึ่งที่เราสามารถเพิ่มประสิทธิภาพได้จริง
ก่อนที่เราจะเพิ่มการโหลดแบบ Lazy Loading ลงในรูปภาพ เบราว์เซอร์ใช้ทำอะไรอยู่ เรามีภาพสไลด์นี้พร้อมกับ Doodle ทั้งหมด และเบราว์เซอร์กำลังดึงรูปภาพทั้งหมดในช่วงเริ่มต้นของภาพสไลด์โดยมีลำดับความสำคัญสูงก่อน แต่เป็นรูปภาพที่อยู่ตรงกลาง ของภาพสไลด์ที่สำคัญที่สุดสำหรับผู้ใช้ ดังนั้นสิ่งที่เราทำคือเรากำหนดความสำคัญของภาพพื้นหลังเหล่านั้นไว้ที่ต่ำมาก ภาพเบื้องหน้าเป็นสูงมาก และสิ่งที่สิ่งนี้ส่งผล 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 Font Recipes ของ Zach Leatherman ได้ด้วย เพราะฟีเจอร์นี้ยอดเยี่ยมจริงๆ
ลดสคริปต์ที่บล็อกการแสดงผล
ยังมีส่วนอื่นๆ ของแอปพลิเคชันที่เราสามารถส่งต่อในช่วงก่อนหน้าของห่วงโซ่การดาวน์โหลด เพื่อมอบประสบการณ์ของผู้ใช้เบื้องต้นอย่างน้อยอีกสักเล็กน้อย
ในแถบไทม์ไลน์ของ Lighthouse คุณจะเห็นว่าในช่วง 2-3 วินาทีแรกเมื่อโหลดทรัพยากรทั้งหมด ผู้ใช้จะไม่เห็นเนื้อหาใดๆ เลย
การดาวน์โหลดและการประมวลผลสไตล์ชีตภายนอกจะทำให้กระบวนการแสดงผลของเราคืบหน้าไปไม่ได้
เราจะลองเพิ่มประสิทธิภาพเส้นทางการแสดงผลวิกฤติได้โดยการแสดงบางรูปแบบได้เร็วขึ้นเล็กน้อย
ถ้าเราดึงรูปแบบที่เป็นผู้รับผิดชอบในการแสดงผลเริ่มต้นนี้และแทรกในบรรทัดใน HTML ของเรา เบราว์เซอร์จะสามารถแสดงผลได้ทันทีโดยไม่ต้องรอให้สไตล์ชีตภายนอกมาถึง
ในกรณีของเรา เราใช้โมดูล NPM ที่ชื่อ Critical เพื่อแทรกเนื้อหาสำคัญไว้ใน index.html ระหว่างขั้นตอนการสร้าง
แม้ว่าโมดูลนี้จะช่วยจัดการภาระงานหนักๆ ส่วนใหญ่ให้กับเรา แต่ก็ยังเป็นเรื่องยากอยู่บ้างที่จะทำให้การทำงานนี้เป็นไปอย่างราบรื่นในเส้นทางต่างๆ
หากคุณไม่ระมัดระวังหรือโครงสร้างเว็บไซต์ซับซ้อนมาก ก็อาจเป็นเรื่องยากที่จะเริ่มใช้รูปแบบประเภทนี้หากคุณไม่ได้วางแผนสำหรับสถาปัตยกรรม App Shell ตั้งแต่ต้น
ด้วยเหตุนี้ การคำนึงถึงประสิทธิภาพตั้งแต่เนิ่นๆ จึงเป็นสิ่งสำคัญ หากคุณไม่ได้ออกแบบให้เหมาะกับประสิทธิภาพมาตั้งแต่ต้น ก็มีโอกาสสูงที่คุณจะพบปัญหาในภายหลัง
สุดท้ายแล้วความเสี่ยงเราก็ได้รับผลสำเร็จ เราก็สามารถทำให้สำเร็จได้และแอปก็เริ่มส่งเนื้อหาเร็วขึ้นมาก ซึ่งช่วยปรับปรุงระยะเวลาการแสดงผลที่มีความหมายครั้งแรกได้อย่างมาก
ผลลัพธ์
นี่เป็นรายการการเพิ่มประสิทธิภาพจำนวนมากที่เราใช้กับไซต์ของเรา เรามาดูผลลัพธ์กัน นี่เป็นวิธีที่แอปของเราโหลดบนอุปกรณ์เคลื่อนที่ขนาดกลางบนเครือข่าย 3G ทั้งก่อนและหลังการเพิ่มประสิทธิภาพ
คะแนนประสิทธิภาพของ Lighthouse เพิ่มขึ้นจาก 23 เป็น 91 ถือเป็นความคืบหน้าที่ค่อนข้างดี ในแง่ของความเร็ว การเปลี่ยนแปลงทั้งหมดเกิดจากการที่เราตรวจสอบและติดตามการรายงานของ Lighthouse อย่างต่อเนื่อง หากต้องการทราบว่าในทางเทคนิคแล้วเรานำการปรับปรุงทั้งหมดไปใช้อย่างไร ก็ดูที่เก็บของเราได้ โดยเฉพาะอย่างยิ่งในฝ่ายประชาสัมพันธ์ของเรา
ประสิทธิภาพตามการคาดการณ์ - ประสบการณ์ของผู้ใช้โดยอิงตามข้อมูล
เราเชื่อว่าแมชชีนเลิร์นนิงแสดงถึงโอกาสอันน่าตื่นเต้นสำหรับอนาคตในหลายๆ ด้าน แนวคิดหนึ่งที่เราหวังว่าจะทำให้มีการทดลองมากขึ้นในอนาคต คือข้อมูลจริงสามารถชี้นำประสบการณ์ของผู้ใช้ที่เราสร้างขึ้นได้จริงๆ
ทุกวันนี้เราตัดสินใจเองมากมายเกี่ยวกับสิ่งที่ผู้ใช้อาจต้องการหรือจำเป็นต้องใช้ ดังนั้นจึงควรค่าแก่การดึงข้อมูลล่วงหน้า การโหลดล่วงหน้า หรือการแคชล่วงหน้า ถ้าเราเดาถูก เราจะสามารถจัดลำดับความสำคัญ ของทรัพยากรจำนวนน้อยได้ แต่การจะปรับขนาดให้เหมาะกับทั้งเว็บไซต์นั้นทำได้ยากมาก
จริงๆ แล้วเรามีข้อมูลซึ่งสามารถแจ้งการเพิ่มประสิทธิภาพของเราได้ดีขึ้น การใช้ 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