พบกับ Thor Render Engine: สร้างเพจที่เร็วปานสายฟ้าแลบ
เผยแพร่แล้ว: 2019-03-18ลิงค์ด่วน
- ผลกระทบของหน้าโหลดช้า
- รายละเอียดเบื้องหลัง Thor Render Engine™
- การปรับโครงสร้าง HTML
- รีแฟคเตอร์จาวาสคริปต์
- รีแฟคเตอร์ CSS
- การตอบสนองของ CSS
- ตัวอย่างการทดสอบความเร็ว
- เปรียบเทียบความเร็วหน้า
- เพลิดเพลินกับหน้าโหลดที่เร็วขึ้น
ฉันชื่อ Piotr Dolistowski ผู้อำนวยการอาวุโสฝ่ายวิศวกรรมของ Instapage ฉันเป็นหัวหน้าฝ่ายเทคนิคของบริษัทในวอร์ซอว์ ประเทศโปแลนด์ รวมถึงการประสานงานโครงการและการจัดการคน ทุกอย่างในบทความวันนี้เป็นผลโดยตรงจากความพยายามของทีมของฉันในการสร้างระบบแสดงผลหน้าเว็บที่เร็วขึ้นสำหรับลูกค้า Instapage
ไม่มีความลับสำหรับนักการตลาดดิจิทัลที่ความเร็วในการโหลดหน้าเว็บมีผลโดยตรงต่อการมีส่วนร่วมของผู้ใช้และอัตราตีกลับ Google และบริษัทอื่นๆ ได้ทำให้ Page Speed เป็นจุดเน้นสำหรับใครก็ตามที่ทำงานด้านการตลาดดิจิทัลมาเป็นเวลาอย่างน้อย 2-3 ปี ดังนั้นจึงไม่ใช่เรื่องใหม่สำหรับปี 2019
เราได้แสดงคุณลักษณะนี้หลายครั้งแล้ว แต่การวิจัยของ Google แสดงให้เห็นว่าสำหรับหน้าเว็บที่โหลดช้า การมีส่วนร่วมของผู้ใช้จะลดลงในขณะที่อัตราตีกลับเพิ่มขึ้น:
นี่คือเหตุผลที่ทีมงานของเราทำงานอย่างไม่รู้จักเหน็ดเหนื่อยเพื่อนำ Thor Render Engine™ มาให้คุณ เอ็นจิ้นการเรนเดอร์คือเครื่องมือสร้างเพจใหม่ของเราและเป็นส่วนหนึ่งของประสบการณ์การใช้งานเพจที่ตอบสนองอย่างเต็มที่ของเรา ซึ่งช่วยให้มั่นใจว่าหน้า Landing Page หลังการคลิกของคุณโหลดเร็วอย่างเหลือเชื่อโดยที่คุณไม่ต้องออกแรงใดๆ
ก่อนที่เราจะลงลึกในรายละเอียดของระบบการเรนเดอร์ใหม่ของ Instapage เรามาทบทวนว่าทำไมหน้า Landing Page ที่โหลดช้าหลังการคลิกจึงส่งผลเสียต่อการแปลง
หน้าเว็บที่โหลดช้ามีผลกระทบกับการแปลง
หน้าโหลดช้าแค่ไหน? ความล่าช้าทุก ๆ วินาทีในการโหลดหน้าเว็บบนมือถือทำให้คอนเวอร์ชั่นลดลง:
การแปล: ผู้ใช้ออนไลน์ไม่มีความอดทนในการรอหน้าโหลดนานนัก ดังนั้นหากไม่โหลดในเร็วๆ นี้ พวกเขาจะออกจากหน้านี้ สิ่งนี้จะเพิ่มอัตราตีกลับ ลดการมีส่วนร่วมของผู้ใช้ ส่งผลเสียต่อประสบการณ์ของผู้ใช้โดยรวม และสุดท้ายจะจำกัดการแปลง
Akamai มีข้อมูลเชิงลึกต่อไปนี้หลังจากรวบรวมข้อมูลการเข้าชมของผู้ใช้ 10,000 ล้านครั้งจากผู้ค้าปลีกออนไลน์ชั้นนำ:
- ผู้บริโภคครึ่งหนึ่งเลือกดูสินค้าและบริการบนสมาร์ทโฟน ในขณะที่มีเพียง 1 ใน 5 เท่านั้นที่ซื้อผ่านมือถือจริงๆ
- ความล่าช้า 100 มิลลิวินาทีในการโหลดเว็บไซต์อาจทำให้อัตราการแปลงลดลง 7%
- ความล่าช้าสองวินาทีในการโหลดหน้าเว็บจะเพิ่มอัตราการตีกลับถึง 103%
- 53% ของผู้เข้าชมไซต์บนอุปกรณ์เคลื่อนที่จะออกจากหน้าที่ใช้เวลาในการโหลดนานกว่าสามวินาที
- อัตราตีกลับของผู้ซื้อโทรศัพท์มือถือสูงที่สุด ในขณะที่ผู้ซื้อแท็บเล็ตมีอัตราตีกลับต่ำที่สุด
ดังนั้น คุณจะแน่ใจได้อย่างไรว่าหน้า Landing Page หลังการคลิกโหลดเร็ว PageSpeed Insights ของ Google สามารถช่วยได้ แต่เท่าไหร่?
PageSpeed Insights ของ Google รายงานประสิทธิภาพของเพจ โดยแสดงว่าเพจนั้นเร็ว ปานกลาง หรือช้าทั้งบนอุปกรณ์มือถือและเดสก์ท็อป นอกจากนี้ยังให้คำแนะนำเกี่ยวกับวิธีปรับปรุงหน้านั้น:
แต่ถ้าคุณไม่มีพื้นฐานทางเทคนิค ข้อมูลเชิงลึกเกี่ยวกับความเร็วของหน้าเว็บอาจทำให้คุณสับสนได้ การทำความเข้าใจว่าเมตริก First Contentful Paint (FCP) และ First Input Delay (FID) ใดที่อาจมองข้ามคุณไป
เข้าสู่ Thor Render Engine™ ของ Instapage
รายละเอียดเบื้องหลัง Thor Render Engine™
เราพัฒนา Thor Render Engine™ เพื่อให้แน่ใจว่าหน้า Landing Page หลังการคลิกของ Instapage ทั้งหมดโหลดเร็ว
นี่หมายถึงการเขียนหน้า Landing Page หลังการคลิกใหม่ทั้งหมดในทุกๆ ด้าน — การเปลี่ยนโครงสร้าง HTML, JavaScript และ CSS Refactoring และ CSS Responsiveness เพื่อให้แน่ใจว่าทุกอย่างในส่วนหลังของหน้าอนุญาตให้โหลดได้ทันที
ส่วนที่ดีที่สุดของการเปลี่ยนแปลงทั้งหมดนี้ก็คือ คุณไม่จำเป็นต้องทำอะไรเลย เพราะ Thor Render Engine™ ทำงานอยู่เบื้องหลังอย่างเงียบ ๆ เพื่อทำให้เพจของคุณรวดเร็วทันใจ
เรามาแยกย่อยการเปลี่ยนแปลงเพื่อดูว่าเราได้ทำอะไรเพื่อให้หน้าโหลดเร็วขึ้น
โครงสร้าง HTML
มีหลายสิ่งหลายอย่างที่ทำให้ระบบแสดงผลหน้าเว็บเร็วขึ้นจากจุดยืนของ HTML โดยเริ่มจากการจัดลำดับความสำคัญของทรัพยากร
การจัดลำดับความสำคัญของทรัพยากร
เราได้ลอกหน้า Landing Page หลังการคลิกออกจากโค้ดจำนวนมากที่ไม่ได้ใช้ คลุมเครือ หรือไม่เหมาะสม ทำให้ได้มาร์กอัปที่ชัดเจนและแสดงผลได้รวดเร็ว
โครงสร้าง HTML ใหม่รับประกันว่าทรัพยากรทั้งหมดจะโหลดตามลำดับที่ถูกต้อง สไตล์เพจ (ยกเว้นสไตล์ฟอนต์) ถูกเพิ่มในส่วนหัว เพราะหลังจากนั้น เพจจะโหลดเร็วกว่าการใช้สไตล์ชีต CSS
การตอบสนองไม่ต้องการเบรกพอยต์เพิ่มเติมใน CSS หรือ JavaScript เนื่องจากหน้าเว็บจะโหลดเร็วและดูดีโดยไม่ต้องใช้โค้ดเพิ่มเติม ยิ่งกว่านั้น สคริปต์ทั้งหมดจะอยู่ที่ด้านล่างของเนื้อหาของหน้า จึงไม่ปิดกั้นการแสดงหน้า สคริปต์และทรัพยากรที่สำคัญ (เช่น แบบอักษร) ใช้ความสามารถในการโหลดล่วงหน้าของเบราว์เซอร์ ซึ่งหมายความว่าจะไม่ถูกบล็อกในขณะที่แสดงผลหน้าเว็บ นอกจากนี้ ไม่มีการวาง JavaScript แบบซิงโครนัสไว้ในแท็กส่วนหัวของหน้า
รูปภาพและวิดีโอขี้เกียจโหลด
แม้ว่ารูปภาพและวิดีโอจะไม่ได้บล็อกการแสดงผล แต่เมื่อมีหลายรายการในหน้า แบนด์วิดท์อาจถูกบล็อกด้วยคำขอที่มากเกินไป โดยเฉพาะอย่างยิ่งกับรูปภาพขนาดใหญ่ ซึ่งอาจนำไปสู่ประสบการณ์การใช้งานที่ไม่ดี เนื่องจากรูปภาพในครึ่งหน้าบนจะถูกโหลดพร้อมกันกับรูปภาพในครึ่งหน้าล่าง ซึ่งผู้เข้าชมจะมองไม่เห็น
ในการแก้ปัญหา เราได้แนะนำการเพิ่มประสิทธิภาพต่อไปนี้:
- รูปภาพครึ่งหน้าบนจะโหลดด้วยลำดับความสำคัญที่สูงกว่า — การดาวน์โหลดจะเริ่มต้นทันที เพื่อให้มองเห็นได้ก่อนที่หน้าเว็บจะได้รับการโต้ตอบ
- รูปภาพและวิดีโอในครึ่งหน้าล่างโหลดอย่างเชื่องช้า — การดาวน์โหลดจะทริกเกอร์เมื่อผู้ใช้เลื่อนดู กล่องสีเทาใช้เป็นตัวยึดสำหรับรูปภาพที่ยังไม่โหลด
- เพื่อป้องกันไม่ให้ผู้ใช้เห็นช่องสีเทาเหล่านี้ รูปภาพจะถูกโหลดเมื่อเลื่อนเข้าไปในวิวพอร์ต แต่เมื่อเลื่อนไปที่ระยะ 400px ไปจนถึงวิวพอร์ตด้านล่าง เมื่อพวกเขาเข้าสู่วิวพอร์ต พวกเขาจะถูกโหลดแล้ว
- กฎเดียวกันนี้ใช้กับวิดีโอ ที่โหลดใน iframe
ในการทำให้สิ่งนี้เกิดขึ้น เราใช้ประโยชน์จาก API ที่ล้ำสมัยของ IntersectionObserver ซึ่งทำให้การโหลดแบบขี้เกียจมีประสิทธิภาพสูงสุดด้วยขนาดโค้ดที่เล็ก:
รีแฟคเตอร์จาวาสคริปต์
รีแฟกเตอร์ JavaScript รวมการปรับแต่งต่อไปนี้:
- สถาปัตยกรรมแบบแยกส่วน: โค้ด JavaScript ทั้งหมดบนหน้า Landing Page หลังการคลิกเกี่ยวข้องกับคุณลักษณะของวิดเจ็ตเฉพาะ เราแบ่งโค้ดออกเป็นหลายๆ กลุ่ม แต่ละกลุ่มมีโค้ดสำหรับคุณลักษณะเฉพาะ ดังนั้น เมื่อผู้ใช้ออกแบบเพจที่มีแต่รูปภาพและลิงก์ จะไม่มีการโหลดโค้ดสำหรับวิดเจ็ตแบบฟอร์มหรือป๊อปอัพ ทำให้โหลดเพจได้รวดเร็ว
- น้ำหนักเบามาก: เราลบไลบรารีเก่าออกและออกแบบสถาปัตยกรรมโค้ดทั้งหมดใหม่ ซึ่งทำให้เราสามารถลดขนาด JavaScript ทั้งหมดบนเพจจากมากกว่า 1MB เหลือประมาณ 200kB (ซึ่งน้อยกว่า 5 เท่า!) ในขณะที่เพจทั่วไปจะโหลดน้อยกว่า 100kB ขอบคุณ modularization ที่อธิบายไว้ข้างต้น
- Async ทั้งหมด: เนื่องจาก JavaScript บล็อกการแสดงผล เราจึงย้ายการนำเข้าสคริปต์ทั้งหมดไปที่ด้านล่างของแท็ก BODY สิ่งนี้ทำให้เบราว์เซอร์สามารถแสดงผลเต็มหน้าก่อนที่สคริปต์จะถูกดำเนินการเพื่อให้ผู้เข้าชมเห็นเนื้อหาที่มีความหมายก่อนหน้านี้ สคริปต์ที่มีการโต้ตอบจะโหลดและดำเนินการหลังจากที่เริ่มโต้ตอบกับส่วนนั้นของหน้าเท่านั้น สิ่งนี้มอบประสบการณ์ที่ดีมากโดยเฉพาะบนอุปกรณ์พกพาที่มีประสิทธิภาพต่ำกว่าและมักมีการเชื่อมต่ออินเทอร์เน็ตที่ไม่ดี
รีแฟคเตอร์ CSS
นอกจากนี้ เรายังเขียนสไตล์ชีต CSS ใหม่ทั้งหมด โดยลบโค้ดของบุคคลที่สามที่ไม่จำเป็น เพื่อให้สไตล์ชีตของเราใช้ซ้ำได้ อ่านง่าย และน้ำหนักเบา นอกจากนี้ เราใช้คลาส CSS ทั่วไปเพื่อนำโค้ด CSS กลับมาใช้ซ้ำให้ได้มากที่สุด
นอกจากนี้ เรายังได้ติดตั้งแอนิเมชันแบบ CSS เท่านั้นด้วยการเร่งความเร็ว GPU การเปลี่ยนแปลงที่สำคัญที่สุดใน CSS stack ของเราคือการนำหน่วยสัมพัทธ์ “rem” มาใช้แทนพิกเซล ด้วยเหตุนี้ หน้า Landing Page หลังการคลิกจึงปรับขนาดได้อย่างราบรื่นบนอุปกรณ์ทุกขนาด ตั้งแต่สมาร์ทโฟนไปจนถึงหน้าจอเดสก์ท็อป 4k
การตอบสนองของ CSS
เรากำลังใช้ "rem" ร่วมกับหน่วย "vw" เพื่อทำให้หน้า Landing Page หลังการคลิกตอบสนอง ซึ่งหมายความว่ามีช่องว่างสองช่องในความละเอียดของอุปกรณ์เมื่อหน้า Landing Page หลังการคลิกถูกลดขนาดลงระหว่างความกว้าง 768 ถึง 1200 พิกเซลและต่ำกว่าความกว้าง 400 พิกเซล ในการแก้ปัญหาอื่นๆ ทั้งหมด เนื้อหาหลักยังคงมีความกว้างคงที่ เช่นเดียวกับในตัวสร้าง ค่าความกว้างคงที่คือ 400px สำหรับมือถือ และ 1200px สำหรับเดสก์ท็อป
หน่วย “Rem” ช่วยให้เราสามารถคำนวณตำแหน่งและขนาดวิดเจ็ตใหม่ได้อย่างราบรื่น นอกจากนี้ยังหมายความว่าเราไม่จำเป็นต้องใช้ JavaScript เพื่อให้สิ่งนี้เกิดขึ้น
สรุป:
- เนื้อหาที่ ต่ำกว่า 400px จะปรับขนาดให้พอดีกับความกว้างของหน้าจอโดยอัตโนมัติ
- ระหว่าง 400px ถึง 767px ความกว้างของเนื้อหาจะคงที่
- จากมุมมองมือถือ 768px เปลี่ยนเป็นมุมมองเดสก์ท็อป
- เนื้อหา ตั้งแต่ 768px ถึง 1200px จะปรับขนาดให้พอดีกับความกว้างของหน้าจอโดยอัตโนมัติ
- สูงกว่า 1200px เนื้อหาได้รับการแก้ไขแล้ว
ตัวอย่างการทดสอบความเร็วของ Thor Render Engine™
เนื่องจากคุณไม่มีทางรู้ว่าผู้คนดูหน้า Landing Page หลังการคลิกของคุณอย่างไร (เดสก์ท็อป อุปกรณ์เคลื่อนที่ หรือแท็บเล็ต) ประสบการณ์ใช้งานหน้าเว็บจะต้องตอบสนองอย่างสมบูรณ์จึงเป็นสิ่งสำคัญ โซลูชัน Thor Render Engine™ ตอบสนองได้เต็มที่ในทุกความละเอียด
ตอนนี้เรามาเปรียบเทียบเอ็นจิ้นการเรนเดอร์ใหม่กับตัวสร้างเพจแบบเก่าของเรา ภาพด้านล่างแสดงผลความเร็วหน้าของหน้าเดียวกันแม้ว่าจะมี URL ต่างกันก็ตาม (หมายเหตุ: เพจไม่สามารถใช้งานได้อีกต่อไปเนื่องจาก URL เหล่านี้มีไว้เพื่อการทดสอบเท่านั้น):
ผลการเรนเดอร์หน้า Instapage แบบเก่า:
ผลลัพธ์ของ Thor Render Engine™:
คะแนน 56 ในการทดสอบครั้งแรก และเพิ่มเป็น 95 ในการทดสอบที่สอง ความเร็วในการโหลดหน้าเว็บเพิ่มขึ้น 58.9%!
การเปรียบเทียบความเร็วในการโหลดหน้าเว็บ
หลังจากสรุปการเปลี่ยนแปลงทั้งหมดด้วย Thor Render Engine™ มาดูกันว่าความเร็วในการโหลดหน้าเว็บของ Instapage เทียบกับคู่แข่งเป็นอย่างไร
เราทดสอบความเร็วของหน้านี้ (ภาพหน้าจอแสดงเฉพาะครึ่งหน้าบน) บนการเชื่อมต่อ 3G:
ระยะเวลาที่ใช้ในการโหลดหน้าเว็บมีดังนี้
- ด้วยระบบเรนเดอร์หน้า Instapage แบบเก่า (แถวบนสุด): 10.5 วินาทีในการเริ่มโหลด
- Thor Render Engine™ (แถวกลาง): ภายใน 5 วินาที หน้าเว็บถูกโหลด 98%
- ใช้คู่แข่ง (แถวล่าง): 8 วินาทีเพื่อเริ่มโหลด
ในการเชื่อมต่อ 4G นี่คือผลลัพธ์:
- ด้วยระบบเรนเดอร์หน้า Instapage แบบเก่า: 4.5 วินาทีในการเริ่มโหลด
- Thor Render Engine™: โหลดเสร็จภายใน 3.5 วินาที
- ใช้คู่แข่ง: 4.5 วินาทีเพื่อ เริ่ม โหลด
เพลิดเพลินกับการโหลดหน้าเว็บที่เร็วขึ้นด้วย Thor Render Engine™
ความเร็วของหน้ามีบทบาทสำคัญในประสบการณ์ของผู้ใช้และสุดท้ายคือการแปลงของคุณ เมื่อเวลาในการโหลดหน้าเว็บล่าช้า คุณไม่เพียงแต่เสี่ยงต่ออัตราตีกลับที่สูงเท่านั้น แต่ยังทำให้ผู้ใช้ผิดหวังในกระบวนการด้วย
ด้วย Thor Render Engine™ ตอนนี้เราสามารถรับประกันได้ว่าหน้า Landing Page หลังการคลิกของคุณจะโหลดทันทีโดยที่คุณไม่ต้องพยายาม ลงทะเบียนสำหรับการสาธิต Instapage Enterprise วันนี้และสัมผัสความแตกต่างด้วยตัวคุณเอง