ความท้าทายด้านประสิทธิภาพส่วนหน้า: ผู้ชนะและผลลัพธ์
เผยแพร่แล้ว: 2022-03-10เมื่อไม่กี่สัปดาห์ก่อน เราขอให้ผู้อ่านและชุมชนของเราใช้ทุกสิ่งที่พวกเขาทำได้เพื่อทำให้เว็บไซต์และโครงการของพวกเขาทำงานได้อย่างรวดเร็วอย่างเห็นได้ชัด วันนี้ เราตื่นเต้นมากที่จะได้อวดผลลัพธ์ของความท้าทายนี้ และประกาศผู้ชนะที่จะได้รับรางวัลอันยอดเยี่ยมอย่างแน่นอน!
รางวัลอะไรคุณถาม? ผู้ชนะจะได้รับเที่ยวบินไป-กลับลอนดอน ที่พักเต็มรูปแบบในโรงแรมสุดหรู ตั๋วเข้าชม SmashingConf London 2018 และสุดท้ายแต่ไม่ท้ายสุด เวิร์กช็อป Smashing ที่พวกเขาเลือก
ท้าทาย? ท้าทายอะไร?
งานนั้นไม่ง่ายอย่างที่คิด ผู้เข้าแข่งขันถูกขอให้ปรับปรุงประสิทธิภาพของเว็บไซต์ในขณะที่รักษาลักษณะที่ปรากฏในขั้นตอนสุดท้ายให้เหมือนกันทั้งก่อนและหลัง อนุญาตให้โหลดฟอนต์ต่างกัน และรีโฟลว์ก็ยอมรับได้ตราบเท่าที่ยังคงใช้ให้น้อยที่สุด
ขณะเลือกผู้โชคดี เราได้ตรวจสอบผลลัพธ์ที่นำเสนอโดย Lighthouse และ WebPageTest รวมถึงความซับซ้อนของเว็บไซต์ที่ผู้เข้าร่วมของเราเคยทำงานด้วย การลง สีที่มีความหมายครั้งแรก และ เวลาในการโต้ตอบ คือตัวชี้วัดที่สำคัญที่สุด
แต่ข้อเท็จจริงที่ยากพอสำหรับตอนนี้ เรารู้ว่าคุณอยากรู้อยากเห็นอยู่แล้ว และเราไม่ต้องการให้คุณต้องสงสัยอีกต่อไป นี่คือโครงการที่ชนะ
และผู้ชนะคือ…
ลีโอนาร์โด โลโซวิซ
เทคนิคการเพิ่มประสิทธิภาพที่นำเสนอในการส่งผลงานของ Leonardo ทั้งหมดเป็นแบบ DIY ออกแบบและดำเนินการตั้งแต่เริ่มต้น เขาเพิ่มการเพิ่มประสิทธิภาพทั้งหมดให้กับ PoP ซึ่งเป็นเฟรมเวิร์กโอเพนซอร์สเพื่อสร้างเว็บไซต์ และใช้ Agenda Urbana เพื่อทดสอบการปรับปรุงประสิทธิภาพในโครงการจริง
เรารู้สึกว่าการส่งนี้เข้าสู่จิตวิญญาณของความท้าทายอย่างแท้จริง โดยไม่เพียงแต่ปรับปรุงประสิทธิภาพของเว็บไซต์เดียว แต่ยังพยายามปรับปรุงกรอบงานที่ใช้กับเว็บไซต์จำนวนมาก ความจริงที่ว่า PoP ได้รับการสนับสนุนโดย WordPress หมายความว่า Leonardo อยู่ในสถานการณ์ที่คล้ายคลึงกันกับคนจำนวนมากที่ไม่สามารถทำบางสิ่งที่มีอยู่ในกรอบงาน JavaScript ตามที่เขาตั้งข้อสังเกต:
PoP สร้างขึ้นบน WordPress นั่นหมายความว่าเทคนิคการปรับให้เหมาะสมที่เป็นนวัตกรรมใหม่ๆ มากมายสำหรับเฟรมเวิร์ก Javascript เช่น การแยกโค้ดโดยใช้ Webpack หรือ Service Workers ผ่าน sw-precache นั้นไม่สามารถเข้าถึงได้ (อย่างน้อยก็ไม่มีวิธีแก้ปัญหาชั่วคราวขนาดใหญ่) ด้วยเหตุนี้ เทคนิคการเพิ่มประสิทธิภาพทั้งหมดที่อธิบายไว้ด้านล่างจึงเป็นแบบ DIY ทั้งหมด ออกแบบและใช้งานตั้งแต่เริ่มต้น
หากคุณสนใจที่จะเจาะลึกรายละเอียดสำคัญทั้งหมดเกี่ยวกับการยอมจำนนของเขา อย่าลังเลที่จะทำ เราทุกคนสนุกกับการอ่านรายละเอียดการปรับให้เหมาะสมของ Leonardo และรู้สึกว่าเขาเป็นผู้ชนะที่คู่ควรเนื่องจากมีงานจำนวนมากที่เข้าสู่รายการนี้
ผลงานทั้งหมด
เราพอใจมากกับคุณภาพของผลงานที่ส่งเข้ามา การเลือกผู้ชนะไม่ใช่เรื่องง่าย ขอบคุณทุกคนที่ส่งมา — ติดตามการทำงานที่ยอดเยี่ยม!
จอร์เก้น แวร์ไวจ์
Jorgen Verweij นำเสนอ Perplex Internetmarketing BV เว็บไซต์บริษัทของเขาในเวอร์ชันที่ได้รับการปรับปรุง ร่วมกับทีมที่ประกอบด้วย UX'er, front-end, และ back-end developer และผู้ดูแลระบบ เขาได้เริ่มต้นความพยายามในการแสดง
ผลลัพธ์ที่ได้คือการใช้งานที่ยอดเยี่ยมพร้อมผลลัพธ์ที่สมบูรณ์แบบในทุกส่วน: SpeedIndex ต่ำกว่าเป้าหมายที่ตั้งไว้ที่ 1250, เวลาในการโหลดน้อยกว่า 1 วินาที, เริ่มเรนเดอร์ในครึ่งวินาที, 100 ⁄ 100 PageSpeedscore และการตรวจสอบ Lighthouse ที่เกือบจะสมบูรณ์แบบ . เมื่อเทียบกับสถานการณ์แบบเก่า เวลาในการโหลดจะเร็วกว่าเกือบแปดเท่า รุ่งโรจน์! คุณสามารถอ่านรายละเอียดเพิ่มเติมเกี่ยวกับกระบวนการได้ในบทความที่ครอบคลุมซึ่ง Jorgen รวบรวมไว้
Marco Hengstenberg
Marco Hengstenberg ได้ส่งเว็บไซต์ตัวแทนการท่องเที่ยว Land in Sicht เวอร์ชันที่ได้รับการปรับปรุง เพื่อปรับปรุงประสิทธิภาพ Marco ใช้ลูกเล่นและเทคนิคเล็กๆ น้อยๆ มากมาย การโหลดล่วงหน้าของสไตล์ชีตหลักและการโหลดฟอนต์ที่สำคัญพร้อมการโหลดล่วงหน้าในเบราว์เซอร์ที่รองรับเป็นเพียงสองอย่างเท่านั้น นอกจากนี้ เขายังปรับโครงสร้าง HTML ใหม่ให้แบนราบ ความหมายและเข้าถึงได้มากที่สุด และลดปริมาณข้อมูลที่ถ่ายโอนในครั้งแรกเมื่อเข้าชมครั้งแรกจากเกือบ 3MB เป็น 1.3MB บนเดสก์ท็อป (และเนื่องจากการใช้ภาพที่ตอบสนองสำหรับภาพฮีโร่ น้อยกว่าบนหน้าจอแคบ)
เพื่อเพิ่มความคล่องตัวให้กับไซต์มากยิ่งขึ้น Marco ได้ลบ Bootstrap, jQuery และ Modernizr ออก ตั้งค่ากระบวนการสร้างด้วย Grunt และแนะนำ ServiceWorker ซึ่งทำให้ไซต์พร้อมใช้งานแบบออฟไลน์ด้วย ความพยายามนั้นคุ้มค่า: ผลลัพธ์คือ TTL ที่น่าทึ่งซึ่งลดลงจาก 32 วินาทีเป็น 2 วินาทีและลดลงเกือบ 50% ในคำขอ HTTP และการถ่ายโอนไบต์ (โปรดดูรายงาน Lighthouse, ZIP 251KB) การโหลดล่วงหน้าและการเรนเดอร์เริ่มต้นอย่างรวดเร็วช่วยในเรื่องเวลาในการโหลดที่รับรู้ การทำงานที่ดี!
Gabriel Mariani
เว็บไซต์ San Diego Christian College เป็นเว็บไซต์ที่ Gabriel Mariani ใช้ทักษะการแสดงของเขา เขาแบ่งกระบวนการเพิ่มประสิทธิภาพออกเป็นสี่ขั้นตอน อันดับแรก เขาครอบตัดรูปภาพทั้งหมดให้ได้ขนาดสูงสุดตามที่ต้องการจริง ๆ และสร้างรูปภาพในเวอร์ชันสำหรับอุปกรณ์พกพา จากนั้นเขาก็ทำให้รูปทั้งหมดขี้เกียจโหลด ขั้นตอนที่สองมุ่งเน้นไปที่ JavaScript และลบสคริปต์อินไลน์ทั้งหมดที่ไซต์ WordPress และธีมและปลั๊กอินของบุคคลที่สามมาพร้อมกับ จากนั้นเขาก็จัดคิวสคริปต์ให้มากที่สุดเท่าที่จะเป็นไปได้เพื่อให้ Autoptimize หยิบขึ้นมาและย่อ/รวมเป็นไฟล์เดียว
กาเบรียลยังลดจำนวนฟอนต์ที่ใช้และตั้งค่าฟอนต์ Google ให้โหลดแบบ async เพื่อให้ CSS พาธวิกฤตโหลดก่อน สุดท้ายแต่ไม่ท้ายสุด เขาได้กล่าวถึงปัญหาเล็กน้อยอื่นๆ เช่น การปรับแต่งปลั๊กอิน WordPress ดังนั้นพวกเขาจึงใช้ ajax แทน PHP สิ่งนี้ทำให้เขาสามารถเปิดใช้งานการแคชหน้าและเปิดใช้งาน CDN สำหรับไซต์ในที่สุด การเปลี่ยนไปใช้ HTTP/2 และ HTTPS เป็นขั้นตอนสุดท้าย ดู WebPageTest สำหรับผลลัพธ์ทั้งหมด ดี!
Alexander Zarges
Alexander Zarges พัฒนา Cloud Player ซึ่งเป็นเว็บแอปพลิเคชันหน้าเดียวที่ใช้ Angular 4 ซึ่งช่วยให้คุณสามารถค้นหาและเล่นแอป YouTube และ SoundCloud เวอร์ชันที่อัปเกรดใช้คอมไพเลอร์ล่วงหน้าของ Angular เพื่อให้มีเวลาเริ่มต้นประมาณ 2.9 วินาที (เทียบกับ 5.2 วินาทีเมื่อใช้คอมไพเลอร์แบบทันเวลา) หากคุณต้องการเจาะลึกลงไปในโค้ด ให้ตรวจสอบที่เก็บ GitHub ที่มาพร้อมกัน
Bradly Taunt
Bradley Taunt ใช้ความท้าทายของเราเป็นโอกาสในการทดลองกับเว็บไซต์ส่วนตัวของเขา เป็นพื้นฐานสำหรับการดำเนินการเพิ่มประสิทธิภาพ เขาใช้หน้าแรกและบทความที่มีรูปภาพจำนวนมาก เพื่อลดเวลาในการโหลดลงเหลือ 4.2 วินาทีสำหรับบทความ Bradley ตั้งค่าเริ่มต้นเป็น OS System Fonts ของผู้ใช้ แทนที่จะใช้แบบอักษรของเว็บ และอื่นๆ
สำหรับการเพิ่มประสิทธิภาพเพิ่มเติม เวอร์ชันที่ปรับให้เหมาะสมจะรวม CSS ที่สำคัญไว้ด้วยกัน ให้บริการรูปภาพที่ตอบสนอง และใช้การแคช CDN คุณสามารถดูรายละเอียดเบื้องหลังได้ในบล็อกโพสต์ที่ Bradley เขียนเกี่ยวกับวิธีที่เขาจัดการกับความท้าทาย
จอห์น บีลส์
John Beales ท้าทายตัวเองในการเพิ่มประสิทธิภาพให้กับ 4RoadService.com เมื่อเขาเริ่มต้น มีการเพิ่มประสิทธิภาพบางอย่างอยู่แล้ว ภาพนิ่งถูกเรียกใช้ผ่าน ImageOptim ตัวอย่างเช่น CSS และ JS ถูกย่อเล็กสุด พวกเขากำลังเรียกใช้ CDN ผ่าน CloudFlare และไซต์ใช้ตัวโหลดสไตล์แอปหน้าเดียวอยู่แล้ว XHR จึงดึงเนื้อหาใหม่เสมอและหน้านั้น ไม่เคยวาดใหม่ทั้งหมด
สำหรับความท้าทายนี้ John ได้เปิดใช้ Image Optimization และการบีบอัด WebP ใน Cloudflare ไซต์ที่อัปเดตในขณะนี้ใช้ HTTP/2 Server Push เพื่อส่งไฟล์ CSS และ JS หลักด้วยการโหลดเพจเริ่มต้นและอาศัย Guetzli สำหรับการบีบอัด JPEG ในการเพิ่มประสิทธิภาพการแคช เขาได้อัปเดต URL ของเนื้อหาสแตติกทั้งหมดเพื่อให้ URL เปลี่ยนแปลงเมื่อใดก็ตามที่เนื้อหาเปลี่ยนแปลง จากนั้นตั้งค่าเนื้อหาสแตติกทั้งหมดให้เป็นแคชเป็นเวลาหนึ่งปี สำหรับการแคชรูปภาพที่ได้รับการปรับปรุง John ยังอัปเดต URL ของรูปภาพที่ปรับขนาดแบบไดนามิกเพื่อให้ CloudFlare คิดว่าเป็นไฟล์รูปภาพแบบคงที่
ผลลัพธ์: สีที่มีความหมายชุดแรกลดลงจาก 2,220 ms เป็น 1,290 ms และ First Interactive จาก 5,480 ms เป็น 3,040 ms คุณสามารถดูผลการทดสอบไลท์บ็อกซ์และหน้าเว็บแบบเต็มได้ที่นี่
Shaun O'Connell
ผลงานของ Shaun O'Connel คืองานที่เขาทำบน kiwi.ruby.nz จุดมุ่งหมายคือเปลี่ยนเว็บไซต์การประชุมให้เป็น กปภ. เพื่อให้ผู้เข้าร่วมประชุมสามารถค้นหาข้อมูลทั้งหมดที่เกี่ยวข้องกับงานออฟไลน์ได้ บางสิ่งที่เขาทำ: แทนที่ iframe ของ Google Maps ทั่วไปด้วย Google Static Maps, ฟอนต์เซ็ตย่อยที่โฮสต์เอง, ย้าย CSS แบบอินไลน์เพื่อให้คำขอแรกมีขนาดไม่เกิน 14 KB, ลบการขึ้นต่อกัน, เพิ่ม pre-cache Service Workers และเพิ่ม Turbolinks เพื่อความรวดเร็ว การเปลี่ยนหน้า การทำเช่นนี้ทำให้เวลาในการแสดงผลเริ่มต้นลดลงจาก 3.9 วินาทีเป็น 0.3 วินาที
สำหรับรายละเอียดเพิ่มเติม โปรดดูที่ WebPageTests
รุสลัน จุลบาริสโซว์
Ruslan Julbarissow ส่งเว็บไซต์ zerofy.de ส่วนตัวของเขา เนื่องจากเขาทำงานปรับให้เหมาะสมได้ไม่นานก่อนที่จะมีการเผยแพร่การแข่งขัน โชคไม่ดีที่ไม่มีรายละเอียดก่อนผลลัพธ์ แต่ Ruslan ได้เขียนบันทึกที่ดีว่าการปรับแต่งของเขานำไปสู่ขนาดหน้า 1.6KB และ TTFB ที่ 197ms ได้อย่างไร นอกเหนือจากการแคช การลดขนาด GZIP และ jQuery ที่ปรับแต่งแล้ว เขายังโหลดฟอนต์หลังจากนั้นเพื่อหลีกเลี่ยงการบล็อกการเรนเดอร์ และด้วยการแทนที่ FontAwesome ด้วยชุดไอคอน 10 อันของ IcoMoon ที่ปรับแต่งเอง เขายังช่วยประหยัดได้อีก 130KB
เพื่อเพิ่มคะแนนดัชนีความเร็วและรับประสบการณ์ที่เร็วที่สุดเท่าที่จะเป็นไปได้ เขายังได้สร้างไฟล์ PHP แยกต่างหากซึ่งมีสไตล์ CSS ทั้งหมดที่ส่งผลต่อมุมมองครึ่งหน้าบน รายละเอียดที่ดี: สคริปต์ Barba.js ขนาดเล็กช่วยให้เขาสร้างการเปลี่ยนหน้าโดยไม่ต้องโหลดซ้ำทั้งเว็บไซต์
ขอบคุณทุกท่านที่ร่วมสนุก
วุ้ย ตอน นี้ มันค่อนข้างท้าทายจริงๆ! สำหรับบรรดาของคุณที่ชอบความท้าทายที่ดีและสมองจั๊กจี้เป็นบางครั้ง โปรดคอยติดตามการท้าทายครั้งต่อไป เราจะมาอีกในไม่ช้า - แน่นอน!