ข้อมูลเบื้องต้นเกี่ยวกับเทคโนโลยีที่พร้อมใช้งาน
เหตุใดความเร็วในการโหลดหน้าเว็บจึงเป็นสิ่งสำคัญ
ผู้ใช้ส่วนใหญ่มักพบว่าการโหลดหน้าเว็บที่ช้าเป็นสาเหตุหลักที่ทำให้รู้สึกหงุดหงิด (54% ในการศึกษาของผู้ใช้ที่ดำเนินการโดย Google) จึงไม่น่าแปลกใจที่การโหลดหน้าเว็บที่เร็วขึ้นจะให้ผลลัพธ์ที่ดีกว่าสำหรับธุรกิจ ที่จริงแล้ว หากผู้เข้าชมรู้สึกไม่พอใจก่อนที่จะโต้ตอบกับเว็บไซต์ ก็เป็นไปได้อย่างยิ่งที่พวกเขาจะอยู่ต่อนานพอที่จะเห็นคุณค่าของเว็บไซต์ อันที่จริง การศึกษาอีกอย่างหนึ่งของ Google จากเว็บไซต์อีคอมเมิร์ซ การเงิน และท่องเที่ยว 254 เว็บไซต์ แสดงให้เห็นว่าเว็บไซต์ที่โหลดได้ภายในเวลาไม่เกิน 2 วินาทีมีอัตรา Conversion สูงขึ้น 15%
การเร่งความเร็ว Largest Contentful Paint (LCP)
ดังที่กล่าวไปแล้ว คุณไม่สามารถปรับปรุงสิ่งที่คุณไม่สามารถวัดผลได้ สำหรับประสบการณ์ของผู้ใช้บนเว็บ เราเชื่อว่า Core Web Vitals ประกอบด้วยชุดเมตริกที่เน้นผู้ใช้เป็นหลักและออกแบบมาเพื่อบันทึกแง่มุมพื้นฐานของประสบการณ์ของผู้ใช้ โดยเฉพาะอย่างยิ่ง Largest Contentful Paint (LCP) จะวัดประสิทธิภาพการโหลดหน้าเว็บด้วยการรายงานเวลาที่ใช้ในการแสดงข้อความหรือบล็อกรูปภาพที่ใหญ่ที่สุดที่ผู้ใช้เห็น เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดี LCP ควรเกิดขึ้นภายใน 2.5 วินาทีนับจากที่หน้าเว็บเริ่มโหลดเป็นครั้งแรก (นั่นคือเกณฑ์ LCP ที่ดี)
มาดูปัจจัยที่มีผลต่อ LCP ของหน้าเว็บทั่วไปกัน
![Waterfall การโหลดหน้าเว็บ](https://developer.chrome.com/static/blog/cross-origin-prefetch/image/page-loading-waterfall-4af0ea7b706fb.png?authuser=6&hl=th)
เมื่อผู้ใช้เข้าชมหน้าเว็บ เบราว์เซอร์จะขอ HTML จากเซิร์ฟเวอร์ เซิร์ฟเวอร์จะตอบสนองด้วย HTML ซึ่งทำให้เบราว์เซอร์แนะนำสิ่งที่จะต้องดึงข้อมูลต่อไป ซึ่งรวมถึง CSS, JavaScript, แบบอักษร และรูปภาพ เมื่อคำตอบเหล่านี้กลับมา เบราว์เซอร์จะต้องทำการประเมินด้วย แล้วก็จะจัดวางและระบายสีคอมโพเนนต์ในหน้าเว็บในที่สุด แต่เวลาส่วนใหญ่ในการรอให้แพ็กเก็ตเหล่านั้นเดินทางจากอุปกรณ์ไปยังเซิร์ฟเวอร์แล้วย้อนกลับมาที่อุปกรณ์ อันที่จริง ข้อมูลของเรา (Chrome สำหรับ Android ค่ามัธยฐาน) แสดงให้เห็นว่าโดยปกติแล้วเวลาในการตอบสนองที่ผู้ใช้มองเห็นได้ประมาณ 40% ใช้เวลาไปกับเบราว์เซอร์เพื่อรอให้ไบต์แรกกลับมาจากเซิร์ฟเวอร์
พลังของการดึงข้อมูลล่วงหน้า
หากมีคนดึงข้อมูลไฟล์เหล่านี้ล่วงหน้าได้ทั้งหมด ซึ่งก็คือการดึงข้อมูลก่อนที่ผู้ใช้จะไปที่หน้านั้น จะช่วยเร่งความเร็วได้อย่างมาก โดยเหลืองานเพียงไม่กี่อย่างก่อนจะแสดงหน้าเว็บ นั่นคือการประเมิน คำนวณเลย์เอาต์ และการทาสี
![การแสดงวิดีโอตามลำดับขั้น](https://developer.chrome.com/static/blog/cross-origin-prefetch/image/streamlined-waterfall-c2fd5aa96470c.png?authuser=6&hl=th)
ข้อมูลที่มีการแชร์ก่อนหน้านี้ทำให้เราสามารถดึงข้อมูลทรัพยากรหลักล่วงหน้าได้และยังโหลดหน้าเว็บได้เร็วขึ้นมากด้วย ในกรณีของเว็บไซต์เดียวกัน เทคนิคประเภทนี้พร้อมใช้งานกับแบบพื้นฐาน เช่น rel=prefetch
แต่ในสถานการณ์แบบข้ามเว็บไซต์ วิธีนี้ไม่ได้ง่ายนัก
การนำทางข้ามเว็บไซต์
แม้ว่าการดึงข้อมูลล่วงหน้าจะมีมาระยะหนึ่งแล้ว แต่ก็ต้องมีการพิจารณาเพิ่มเติมเมื่อดึงข้อมูลหน้าจากเว็บไซต์หนึ่งล่วงหน้าขณะที่ผู้ใช้อยู่อีกเว็บไซต์หนึ่ง
สมมติว่าเว็บไซต์อ้างอิงสั่งให้เบราว์เซอร์ดึงข้อมูลหน้าเว็บจากเว็บไซต์อื่นล่วงหน้า เห็นได้ชัดว่าเมื่อผู้ใช้คลิกลิงก์ไปยังหน้าที่ดึงข้อมูลล่วงหน้านี้ ผู้ใช้จะได้รับประสบการณ์ที่ดีขึ้นและโหลดหน้าเว็บได้เร็วขึ้นมาก แต่จะเกิดอะไรขึ้นหากผู้ใช้ไม่เคยคลิกลิงก์นี้ เขาไม่คาดหวังว่าเว็บไซต์ที่เชื่อมโยงจะเรียนรู้ว่าอาจสนใจหัวข้อใดหัวข้อหนึ่งขณะที่กำลังเรียกดูเว็บไซต์ดังกล่าว แต่นี่ก็ถือเป็นความเสี่ยงสูงเช่นกัน เนื่องจากคำขอการดึงข้อมูลล่วงหน้าจะมีที่อยู่ IP ของผู้ใช้ และคุกกี้ (หากมี) เหมือนกับคำขอทั่วไปอื่นๆ
โซลูชัน
ในช่วง 3 ปีที่ผ่านมา เราได้พัฒนาโซลูชัน 2 รายการ ได้แก่ Private Prefetch Proxy และ Signed Exchanges (SXG) เพื่อใช้การดึงข้อมูลล่วงหน้าข้ามเว็บไซต์โดยไม่ละเมิดความเป็นส่วนตัว นอกจากนี้ เรายังทําการทดสอบขนาดใหญ่เพื่อยืนยันว่าการดึงข้อมูลล่วงหน้าแบบข้ามต้นทางให้ประโยชน์ด้านความเร็วอย่างมาก เมื่อดูตัวอย่างที่ Google สามารถดึงข้อมูล HTML หลักล่วงหน้าได้อย่างปลอดภัยสำหรับการนำทางครั้งถัดไปของผู้ใช้ เราพบว่าส่วนของการโหลดหน้าเว็บที่มี LCP ระดับ "ดี" เพิ่มขึ้นถึง 14 เปอร์เซ็นต์
สิ่งสำคัญที่ควรพิจารณา
แม้ว่าพร็อกซีการดึงข้อมูลล่วงหน้าส่วนตัวและ Signed Exchange จะช่วยแก้ปัญหาการใช้งานเดียวกันได้ แต่เทคโนโลยีแต่ละอย่างก็มีข้อดีข้อเสียต่างกัน ดังนั้น ตัวเลือกที่ดีที่สุดจึงขึ้นอยู่กับความต้องการเฉพาะของเว็บไซต์ เพื่อช่วยให้คุณเข้าใจถึงข้อดีและข้อเสียต่างๆ ต่อไปนี้ ส่วนต่อไปนี้จึงครอบคลุมข้อควรพิจารณาที่สำคัญ 2 ประการสำหรับการเปิดใช้การดึงข้อมูลล่วงหน้าข้ามเว็บไซต์และการเลือกระหว่างเทคโนโลยี 2 อย่างที่ใช้ได้ นอกจากนี้ คุณยังจะเห็นรายละเอียดเพิ่มเติมในบทความเจาะลึกของแต่ละเทคโนโลยีอีกด้วย
ผู้เข้าชมซ้ำ
เปิดใช้การดึงข้อมูลล่วงหน้าข้ามเว็บไซต์ได้ง่ายๆ สำหรับผู้ใช้ที่เข้าชมเว็บไซต์เป็นครั้งแรก สำหรับผู้เข้าชมซ้ำ ขึ้นอยู่กับว่าเว็บไซต์มีการปรับเปลี่ยนในแบบของคุณมากน้อยเพียงใด กรณีนี้เกิดจากข้อเท็จจริงที่ว่าคำขอดึงข้อมูลล่วงหน้าข้ามเว็บไซต์ไม่สามารถรวมคุกกี้ได้เนื่องด้วยเหตุผลด้านความเป็นส่วนตัว
- สำหรับผู้เข้าชมครั้งแรก ข้อจำกัดนี้จะไม่ก่อให้เกิดปัญหาใดๆ เนื่องจากผู้เข้าชมเหล่านี้ไม่มีคุกกี้ตั้งแต่แรก ด้วยเหตุนี้ คุณจึงเปิดใช้การดึงข้อมูลล่วงหน้าข้ามเว็บไซต์สำหรับผู้ใช้เหล่านี้ได้โดยไม่ต้องมีการเปลี่ยนแปลงในเว็บไซต์
- หากต้องการเปิดใช้การดึงข้อมูลล่วงหน้าข้ามเว็บไซต์สำหรับผู้เข้าชมที่กลับมาและเว็บไซต์มีการปรับเปลี่ยนในแบบของคุณโดยอิงตามคุกกี้ คุณจะต้องโหลดองค์ประกอบที่กำหนดเองเหล่านี้แบบ Lazy Loading หลังจากที่ผู้ใช้ไปยังส่วนต่างๆ แล้ว วิธีนี้ได้ผลเนื่องจากเมื่อไปยังส่วนต่างๆ แล้ว จะไม่มีการจำกัดคุกกี้อีกต่อไปเนื่องจากผู้ใช้เลือกเข้าชมเว็บไซต์ของคุณอย่างชัดเจน ดังนั้น ณ เวลานำทาง เว็บไซต์ของคุณจะมีสิทธิ์เข้าถึงคุกกี้ตามปกติ โปรดดูแนวทางปฏิบัติแนะนำสำหรับการโหลดแบบ Lazy Loading เพื่อดูคำแนะนำที่เป็นรูปธรรม
- หากปัจจุบันคุณเข้ารหัสการปรับเปลี่ยนในแบบของคุณลงใน HTML โดยตรง คุณจะยังคงทำได้เมื่อมีคุกกี้ และใช้การโหลดแบบ Lazy Loading เป็นกลยุทธ์สำรองสำหรับหน้าเว็บที่ดึงข้อมูลล่วงหน้า
- หากเว็บไซต์ไม่ได้รับการปรับเปลี่ยนในแบบของคุณตามคุกกี้ หรือหากการปรับเปลี่ยนในแบบของคุณไม่สำคัญนัก ก็สามารถเลือกแสดงเนื้อหาเดียวกันต่อผู้เข้าชมซ้ำได้เหมือนกับที่คุณแสดงแก่ผู้เข้าชมครั้งแรก
ขณะนี้พร็อกซีการดึงข้อมูลล่วงหน้าส่วนตัวจะเปิดใช้สำหรับผู้เข้าชมครั้งแรก (ลิงก์ที่ไม่มีคุกกี้) ที่มีการทำงานอย่างต่อเนื่องเพื่อขยายการครอบคลุมไปยังผู้เข้าชมซ้ำ (ลิงก์ที่มีคุกกี้) ในทางกลับกัน Signed Exchange รองรับการดึงข้อมูลล่วงหน้าข้ามเว็บไซต์อยู่แล้วทั้งสำหรับผู้เข้าชมครั้งแรกและผู้เข้าชมที่กลับมา (ตามแนวทางที่ระบุไว้ข้างต้น)
การแสดงข้อมูลเพิ่มเติมจากการดึงข้อมูลล่วงหน้า
การเปิดใช้การดึงข้อมูลล่วงหน้าข้ามเว็บไซต์อาจทำให้เกิดการแสดงข้อมูลเพิ่มเติม อันที่จริง หากผู้บอกต่อดึงข้อมูลหน้าเว็บของคุณล่วงหน้า แต่ผู้ใช้ไม่คลิกลิงก์ นี่จะเป็นการเข้าชมเพิ่มเติมสำหรับคุณ
- เพื่อลดปัญหานี้ คุณสามารถขอให้ URL ที่มาแสดงคำขอการดึงข้อมูลล่วงหน้าน้อยลง ในทำนองเดียวกัน URL ที่มาหรือเบราว์เซอร์ก็สามารถลดปัญหานี้ได้ด้วยการมุ่งเน้นที่ทรัพยากรที่ค่อนข้างขนาดเล็กแต่มีความสำคัญ (เช่น ทรัพยากรหลัก, CSS ที่สำคัญ หรือทรัพยากรย่อยของ JavaScript) และนี่คือข้อดีข้อเสียระหว่างความเร็วกับการเข้าชมที่เพิ่มขึ้น
- อีกทางเลือกหนึ่งจะช่วยชดเชยการเข้าชมนี้โดยเลือกใช้การแคชเพิ่มเติม (ดูรายละเอียดเพิ่มเติมได้ในส่วนนี้ใน Signed Exchange) ข้อเสียก็คือ การแคชเนื้อหาไว้นานเกินไปอาจทำให้แสดงข้อมูลเก่าให้กับผู้ใช้ได้ ซึ่งถือเป็นการทดแทนกันระหว่างการแสดงข้อมูลเพิ่มเติมและความใหม่ของเนื้อหา
เพื่อให้สามารถตัดสินใจได้ดีที่สุด ให้ถามตัวเองว่าเว็บไซต์อยู่ตรงไหนในสเกลที่เลื่อนระหว่างความใหม่สูงสุดกับคำขอเพิ่มเติมน้อยที่สุด คำตอบสำหรับคำถามนี้ขึ้นอยู่กับความต้องการเฉพาะของธุรกิจและผู้ใช้ของคุณ
เริ่มต้นใช้งาน
เทคโนโลยีเหล่านี้ได้รับการผสานรวมไว้ใน Google Search เพื่อให้เว็บไซต์เริ่มปรับปรุง LCP ได้ทันที เราหวังว่าสิ่งนี้จะช่วยสนับสนุนผู้บอกต่อที่ได้รับความนิยมอื่นๆ ให้ติดตาม และทำให้เว็บเป็นไปอย่างรวดเร็วยิ่งขึ้นในวงกว้าง!
แม้ว่าเทคโนโลยีทั้ง 2 อย่างจะช่วยแก้ปัญหาการใช้งานเดียวกันได้ แต่ก็ให้ข้อได้เปรียบที่ต่างกันกับข้อควรพิจารณาหลักๆ ที่อธิบายก่อนหน้านี้ คุณอาจตัดสินใจเริ่มต้นด้วยเทคโนโลยีหนึ่ง แล้วเปลี่ยนไปเป็นอีกเทคโนโลยีหนึ่งก็ได้ตามความต้องการ หรือความชื่นชมในประโยชน์ที่คุณมีต่อพัฒนาการต่างๆ ดูรายละเอียดแบบเจาะลึกเหล่านี้เพื่อดูว่าเทคโนโลยีใดเหมาะกับสถานการณ์ของคุณที่สุด