โหลด JavaScript ของบุคคลที่สาม

Addy Osmani

Arthur Evans

หากคุณเพิ่มประสิทธิภาพโค้ดแล้ว แต่เว็บไซต์ยังคงโหลดช้าเกินไป อาจเป็นเพราะสคริปต์ของบุคคลที่สาม

สคริปต์ของบุคคลที่สามมีฟีเจอร์ที่เป็นประโยชน์มากมายซึ่งทำให้เว็บมีความไดนามิก โต้ตอบได้ และเชื่อมต่อถึงกันมากขึ้น บางส่วนอาจมีความสำคัญต่อฟังก์ชันหรือแหล่งรายได้ของเว็บไซต์ด้วยซ้ำ แต่การใช้รหัสผ่านก็มีความเสี่ยง ดังนี้

• เนื่องจากอาจทำให้ประสิทธิภาพของเว็บไซต์ลดลง
• ซึ่งอาจทำให้เกิดปัญหาด้านความเป็นส่วนตัวหรือความปลอดภัย
• ซึ่งอาจคาดเดาไม่ได้และพฤติกรรมของโมเดลอาจส่งผลให้เกิดผลลัพธ์ที่ไม่พึงประสงค์

ตามหลักแล้ว คุณควรตรวจสอบว่าสคริปต์ของบุคคลที่สามไม่ส่งผลกระทบต่อเส้นทางการแสดงผลที่สำคัญของเว็บไซต์ ในคู่มือนี้ เราจะอธิบายวิธีค้นหาและแก้ไขปัญหาที่เกี่ยวข้องกับการโหลด JavaScript ของบุคคลที่สาม และลดความเสี่ยงต่อผู้ใช้

สคริปต์ของบุคคลที่สามคืออะไร

JavaScript ของบุคคลที่สามมักหมายถึงสคริปต์ที่ฝังลงในเว็บไซต์ใดก็ได้โดยตรงจากผู้ให้บริการบุคคลที่สาม ตัวอย่างเช่น

• ปุ่มการแชร์ผ่านโซเชียล (Facebook, X, LinkedIn, Mastodon)

• วิดีโอเพลเยอร์แบบฝัง (YouTube, Vimeo)

• iframe ของการโฆษณา

• สคริปต์การวิเคราะห์และเมตริก

• สคริปต์การทดสอบ A/B สำหรับการทดสอบ

• ไลบรารีตัวช่วย เช่น การจัดรูปแบบวันที่ ภาพเคลื่อนไหว หรือไลบรารีฟังก์ชัน

ตัวอย่างการฝังวิดีโอ YouTube ที่สามารถเพิ่มลงในหน้าเว็บโดยใช้โค้ดต่อไปนี้

<iframe
  width="560"
  height="315"
  src="https://www.youtube.com/embed/mo8thg5XGV0"
  frameborder="0"
  allow="autoplay; encrypted-media"
  allowfullscreen
>
</iframe>

แต่การฝังสคริปต์ของบุคคลที่สามหมายความว่าเรามักจะต้องพึ่งพาสคริปต์เหล่านั้นเพื่อให้ทำงานได้อย่างรวดเร็วและไม่ทำให้หน้าเว็บของเราช้าลง สคริปต์ของบุคคลที่สามเป็นสาเหตุที่พบบ่อยซึ่งทำให้ประสิทธิภาพช้าลงเนื่องจากทรัพยากรที่อยู่นอกเหนือการควบคุมของเจ้าของเว็บไซต์ ซึ่งรวมถึงปัญหาต่อไปนี้

• การส่งคำขอเครือข่ายไปยังเซิร์ฟเวอร์หลายเครื่องมากเกินไป ยิ่งเว็บไซต์ต้องส่งคำขอมากเท่าใด ก็อาจใช้เวลาโหลดนานขึ้นเท่านั้น

• การส่ง JavaScript มากเกินไปซึ่งทำให้เทรดหลักไม่ว่าง JavaScript ที่มากเกินไปอาจบล็อกการสร้าง DOM ซึ่งทำให้การแสดงผลหน้าเว็บล่าช้า การแยกวิเคราะห์และการเรียกใช้สคริปต์ที่ใช้ CPU มากอาจทำให้การโต้ตอบของผู้ใช้ล่าช้าและทำให้แบตเตอรี่หมดเร็ว

• การส่งไฟล์ภาพที่ไม่ได้เพิ่มประสิทธิภาพหรือวิดีโอขนาดใหญ่อาจใช้เน็ตและทำให้ผู้ใช้เสียเงิน

• ปัญหาด้านความปลอดภัยที่อาจเป็นจุดเดียวของความล้มเหลว (SPOF) หากหน้าเว็บโหลดสคริปต์โดยไม่ระมัดระวัง

• การแคช HTTP ไม่เพียงพอ ทำให้เบราว์เซอร์ต้องส่งคำขอเครือข่ายเพิ่มเติมเพื่อดึงข้อมูลทรัพยากร

• การขาดการบีบอัดเซิร์ฟเวอร์ที่เพียงพอทำให้ทรัพยากรโหลดช้า

• การบล็อกการแสดงเนื้อหาจนกว่าจะประมวลผลเสร็จสมบูรณ์ ซึ่งอาจเกิดขึ้นได้เช่นกัน สำหรับสคริปต์การทดสอบ A/B แบบไม่พร้อมกัน

• การใช้ API เดิมที่ทราบว่าส่งผลเสียต่อประสบการณ์ของผู้ใช้ เช่น document.write()

• องค์ประกอบ DOM มากเกินไปหรือตัวเลือก CSS ที่มีภาระในการประมวลผลสูง

• การรวมการฝังของบุคคลที่สามหลายรายการอาจทำให้มีการดึงเฟรมเวิร์กและไลบรารีหลายรายการเข้ามาหลายครั้ง ซึ่งทำให้สิ้นเปลืองทรัพยากรและทำให้ปัญหาด้านประสิทธิภาพที่มีอยู่แย่ลง

• สคริปต์ของบุคคลที่สามมักใช้เทคนิคการฝังที่สามารถบล็อก window.onload ได้หากเซิร์ฟเวอร์ตอบสนองช้า แม้ว่าการฝังจะใช้ async หรือ defer ก็ตาม

ความสามารถในการแก้ไขปัญหาเกี่ยวกับสคริปต์ของบุคคลที่สามอาจขึ้นอยู่กับเว็บไซต์และความสามารถในการกำหนดค่าวิธีโหลดโค้ดของบุคคลที่สาม โชคดีที่มีโซลูชันและเครื่องมือมากมายที่ช่วยค้นหาและแก้ไขปัญหาเกี่ยวกับทรัพยากรของบุคคลที่สามได้

คุณจะระบุสคริปต์ของบุคคลที่สามในหน้าเว็บได้อย่างไร

การระบุสคริปต์ของบุคคลที่สามในเว็บไซต์และพิจารณาผลกระทบต่อประสิทธิภาพเป็นขั้นตอนแรกในการเพิ่มประสิทธิภาพสคริปต์เหล่านั้น เราขอแนะนำให้ใช้เครื่องมือทดสอบความเร็วของเว็บฟรี ซึ่งรวมถึงเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome, PageSpeed Insights และ WebPageTest เพื่อระบุสคริปต์ที่ใช้ทรัพยากรมาก เครื่องมือเหล่านี้จะแสดงข้อมูลการวินิจฉัยที่สมบูรณ์ซึ่งบอกได้ว่าเว็บไซต์ของคุณใช้สคริปต์ของบุคคลที่สามจำนวนเท่าใด และสคริปต์ใดใช้เวลาในการดำเนินการนานที่สุด

มุมมอง Waterfall ของ WebPageTest สามารถไฮไลต์ผลกระทบของการใช้สคริปต์ของบุคคลที่สามจำนวนมากได้ รูปภาพต่อไปนี้จาก Tags Gone Wild แสดงตัวอย่างแผนภาพของคำขอเครือข่ายที่จำเป็นในการโหลดเนื้อหาหลักของเว็บไซต์ ซึ่งตรงข้ามกับสคริปต์การติดตามและการตลาด

สคริปต์ในหน้านี้ใช้เวลาโหลดนานกว่าตัวหน้าเว็บเอง

รายละเอียดโดเมนของ WebPageTest ยังมีประโยชน์ในการแสดงภาพปริมาณเนื้อหาที่มาจากต้นทางของบุคคลที่สามด้วย โดยจะแจกแจงข้อมูลนี้ตามทั้งจำนวนไบต์ทั้งหมดและจำนวนคำขอ ดังนี้

แผนภูมิรายละเอียดโดเมนแสดงปริมาณเนื้อหาของหน้าเว็บที่มาจากบุคคลที่สาม

ฉันจะวัดผลกระทบของสคริปต์ของบุคคลที่สามในหน้าเว็บได้อย่างไร

เมื่อเห็นสคริปต์ที่ทำให้เกิดปัญหา ให้ดูว่าสคริปต์นั้นทำอะไรและพิจารณาว่าเว็บไซต์ของคุณจำเป็นต้องใช้สคริปต์นั้นเพื่อให้ทำงานได้หรือไม่ หากจำเป็น ให้ทำการทดสอบ A/B เพื่อสร้างสมดุลระหว่างมูลค่าที่รับรู้กับผลกระทบต่อการมีส่วนร่วมของผู้ใช้หรือเมตริกประสิทธิภาพที่สำคัญ

การตรวจสอบเวลาในการเปิดเครื่องของ Lighthouse

การตรวจสอบเวลาในการเปิดเครื่อง JavaScript ของ Lighthouse จะไฮไลต์สคริปต์ที่มีเวลาในการแยกวิเคราะห์ คอมไพล์ หรือประเมินสคริปต์สูง ซึ่งจะช่วยให้คุณระบุสคริปต์ของบุคคลที่สามที่ใช้ CPU มากได้

การตรวจสอบเวลาในการเปิดเครื่องจะแสดงสคริปต์ที่ใช้เวลาโหลดนานที่สุด

การตรวจสอบเพย์โหลดเครือข่ายของ Lighthouse

การตรวจสอบเพย์โหลดเครือข่ายของ Lighthouse จะระบุคำขอเครือข่าย รวมถึงคำขอเครือข่ายของบุคคลที่สามที่ทำให้เวลาในการโหลดหน้าเว็บช้าลง และทำให้ผู้ใช้ใช้อินเทอร์เน็ตมือถือมากกว่าที่คาดไว้

การตรวจสอบเพย์โหลดของเครือข่ายจะแสดงให้เห็นว่าคำขอเครือข่ายใดใช้เวลามากที่สุดและดึงข้อมูลมากที่สุด

การบล็อกคำขอเครือข่ายของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome

เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ช่วยให้คุณเห็นลักษณะการทำงานของหน้าเว็บเมื่อสคริปต์ สไตล์ชีต หรือทรัพยากรอื่นๆ ที่ระบุไม่พร้อมใช้งาน ซึ่งทำได้โดยใช้การบล็อกคำขอเครือข่าย ซึ่งเป็นฟีเจอร์ที่ช่วยวัดผลกระทบของการนำทรัพยากรของบุคคลที่สามแต่ละรายการออกจากหน้าเว็บ

หากต้องการเปิดใช้การบล็อกคำขอ ให้คลิกขวาที่คำขอใดก็ได้ในแผงเครือข่าย แล้วเลือกบล็อก URL คำขอ จากนั้นแท็บการบล็อกคำขอจะแสดงในลิ้นชักเครื่องมือสำหรับนักพัฒนาเว็บ ซึ่งช่วยให้คุณจัดการคำขอที่ถูกบล็อกได้

บล็อกคำขอเครือข่ายแต่ละรายการเพื่อดูว่าหน้าเว็บทำงานอย่างไรเมื่อไม่มีคำขอเหล่านั้น

แผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome

แผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ช่วยระบุปัญหาเกี่ยวกับประสิทธิภาพของหน้าเว็บ

1. คลิกบันทึก
2. โหลดหน้าเว็บ เครื่องมือสำหรับนักพัฒนาเว็บจะแสดงแผนภาพ Waterfall ที่แสดงให้เห็นว่าเว็บไซต์ใช้เวลาในการโหลดอย่างไร
3. ไปที่จากล่างขึ้นบนที่ด้านล่างของแผงประสิทธิภาพ
4. คลิกจัดกลุ่มตามผลิตภัณฑ์ และจัดเรียงสคริปต์ของบุคคลที่สามในหน้าเว็บตามเวลาในการโหลด

สคริปต์ของบุคคลที่สามที่จัดเรียงตามผลิตภัณฑ์ โดยเริ่มจากสคริปต์ที่ใช้เวลาโหลดนานที่สุด

ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เพื่อวิเคราะห์ประสิทธิภาพการโหลดหน้าเว็บได้ที่เริ่มต้นวิเคราะห์ประสิทธิภาพรันไทม์

ต่อไปนี้เป็นเวิร์กโฟลว์ที่เราแนะนำสำหรับการวัดผลกระทบของสคริปต์ของบุคคลที่สาม

1. ใช้แผงเครือข่ายเพื่อวัดระยะเวลาที่ใช้ในการโหลดหน้าเว็บ
   • เราขอแนะนำให้เปิดการควบคุมเครือข่ายและการควบคุม CPU เพื่อจำลองสภาพการใช้งานจริง ผู้ใช้ของคุณไม่น่าจะมีการเชื่อมต่อเครือข่ายที่รวดเร็วและฮาร์ดแวร์เดสก์ท็อปที่ช่วยลดผลกระทบของสคริปต์ที่ใช้ทรัพยากรมากภายใต้สภาวะในห้องปฏิบัติการ
2. บล็อก URL หรือโดเมนที่รับผิดชอบสคริปต์ของบุคคลที่สามที่คุณเชื่อว่าเป็นปัญหา (ดูคำแนะนำในการระบุสคริปต์ที่มีค่าใช้จ่ายสูงได้ที่แผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome)
3. โหลดหน้าเว็บซ้ำและวัดเวลาในการโหลดอีกครั้ง
   • คุณอาจต้องวัดเวลาในการโหลดอย่างน้อย 3 ครั้งเพื่อให้ได้ข้อมูลที่แม่นยำยิ่งขึ้น ซึ่งเกิดจากสคริปต์ของบุคคลที่สามบางรายการที่ดึงทรัพยากรที่แตกต่างกันในการโหลดหน้าเว็บแต่ละครั้ง แผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บรองรับการบันทึกหลายรายการเพื่อช่วยในเรื่องนี้

วัดผลกระทบของสคริปต์ของบุคคลที่สามด้วย WebPageTest

WebPageTest รองรับการบล็อกคำขอแต่ละรายการไม่ให้โหลดเพื่อวัดผลกระทบในการตั้งค่าขั้นสูง > บล็อก ใช้ฟีเจอร์นี้เพื่อระบุรายการโดเมนที่จะบล็อก เช่น โดเมนโฆษณา

ระบุโดเมนที่ต้องการบล็อกในแผงนี้

เราขอแนะนำให้ใช้เวิร์กโฟลว์ต่อไปนี้เพื่อใช้ฟีเจอร์นี้

1. ทดสอบหน้าเว็บโดยไม่บล็อกบุคคลที่สาม
2. ทำการทดสอบซ้ำโดยบล็อกบุคคลที่สามบางราย
3. เลือกผลลัพธ์ 2 รายการจากประวัติการทดสอบ
4. คลิกเปรียบเทียบ

เลือกผลการทดสอบการโหลดเพื่อเปรียบเทียบ

รูปภาพต่อไปนี้แสดงฟีเจอร์แถบแสดงตัวอย่างรูปภาพของ WebPageTest ที่เปรียบเทียบลำดับการโหลดสำหรับหน้าเว็บที่มีและไม่มีทรัพยากรของบุคคลที่สามที่ใช้งานอยู่ เราขอแนะนำให้ตรวจสอบข้อมูลนี้สำหรับการทดสอบต้นทางของบุคคลที่สามแต่ละรายการ เพื่อระบุว่าโดเมนใดส่งผลต่อประสิทธิภาพของหน้าเว็บมากที่สุด

ผลกระทบของการบล็อกทรัพยากรของบุคคลที่สาม จาก การใช้ WebPageTest เพื่อวัดผลกระทบของแท็กจากบุคคลที่สาม โดย Andy Davies

WebPageTest ยังรองรับคำสั่ง 2 รายการที่ทำงานในระดับ DNS เพื่อบล็อกโดเมนด้วย ดังนี้

• blockDomains จะใช้รายการโดเมนที่จะบล็อก
• blockDomainsExcept จะใช้รายการโดเมนและบล็อกทุกอย่างที่ไม่ได้อยู่ในรายการ

WebPageTest ยังมีแท็บจุดเดียวของความล้มเหลว (SPOF) ที่ช่วยให้คุณจำลองการหมดเวลาหรือการโหลดทรัพยากรไม่สำเร็จโดยสมบูรณ์ได้ SPOF จะหมดเวลาอย่างช้าๆ ซึ่งต่างจากการบล็อกโดเมน จึงมีประโยชน์ในการทดสอบลักษณะการทำงานของหน้าเว็บเมื่อบริการของบุคคลที่สามมีภาระงานหนักหรือไม่พร้อมใช้งานชั่วคราว

ใช้ฟีเจอร์การทดสอบ SPOF เพื่อจำลองความล้มเหลวของโดเมนที่ระบุ

ตรวจหา iframe ที่ใช้ทรัพยากรมากโดยใช้งานที่ใช้เวลานาน

เมื่อสคริปต์ใน iframe ของบุคคลที่สามใช้เวลานานในการทำงาน สคริปต์ดังกล่าวอาจบล็อกเทรดหลักและทำให้งานอื่นๆ ล่าช้า งานที่ใช้เวลานานเหล่านี้อาจทำให้ตัวแฮนเดิลเหตุการณ์ทำงานช้าหรือเฟรมหลุด ซึ่งทำให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่แย่ลง

หากต้องการตรวจหางานที่ใช้เวลานานสำหรับการตรวจสอบผู้ใช้จริง (RUM) ให้ใช้ JavaScript PerformanceObserver API เพื่อสังเกตรายการ longtask รายการเหล่านี้มีพร็อพเพอร์ตี้การระบุแหล่งที่มาซึ่งคุณใช้เพื่อระบุบริบทของเฟรมที่ทำให้เกิดงานที่ใช้เวลานานได้

โค้ดต่อไปนี้จะบันทึกรายการ longtask รายการลงในคอนโซล รวมถึงรายการสำหรับ iframe ที่ "ใช้ทรัพยากรมาก"

<script>
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // Attribution entry including "containerSrc":"https://example.com"
      console.log(JSON.stringify(entry.attribution));
    }
  });

  observer.observe({entryTypes: ['longtask']});
</script>

<!-- Imagine this is an iframe with expensive long tasks -->
<iframe src="https://example.com"></iframe>

ดูข้อมูลเพิ่มเติมเกี่ยวกับการตรวจสอบงานที่ใช้เวลานานได้ที่เมตริกประสิทธิภาพที่ให้ความสำคัญกับผู้ใช้เป็นหลัก

คุณจะโหลดสคริปต์ของบุคคลที่สามอย่างมีประสิทธิภาพได้อย่างไร

หากสคริปต์ของบุคคลที่สามทำให้การโหลดหน้าเว็บช้าลง คุณมีตัวเลือกหลายอย่างในการปรับปรุงประสิทธิภาพ ดังนี้

• โหลดสคริปต์โดยใช้แอตทริบิวต์ async หรือ defer เพื่อหลีกเลี่ยงการบล็อกการแยกวิเคราะห์เอกสาร
• หากเซิร์ฟเวอร์จากบุคคลที่สามทำงานช้า ให้พิจารณาโฮสติ้งสคริปต์ด้วยตนเอง
• หากสคริปต์ไม่ได้เพิ่มมูลค่าที่ชัดเจนให้กับเว็บไซต์ ให้นำสคริปต์ออก
• ใช้คำแนะนำเกี่ยวกับทรัพยากร เช่น <link rel=preconnect> หรือ <link rel=dns-prefetch> เพื่อทำการค้นหา DNS สำหรับโดเมนที่โฮสต์สคริปต์ของบุคคลที่สาม

ใช้ async หรือ defer

การดำเนินการ JavaScript เป็นการบล็อกโปรแกรมแยกวิเคราะห์ เมื่อเบราว์เซอร์พบสคริปต์ เบราว์เซอร์จะต้องหยุดการสร้าง DOM ชั่วคราว ส่งสคริปต์ไปยังเครื่องมือ JavaScript และอนุญาตให้สคริปต์ทำงานก่อนที่จะดำเนินการสร้าง DOM ต่อ

แอตทริบิวต์ async และ defer จะเปลี่ยนลักษณะการทำงานนี้ดังนี้

• async ทำให้เบราว์เซอร์ดาวน์โหลดสคริปต์แบบอะซิงโครนัสขณะที่ยังคงแยกวิเคราะห์เอกสาร HTML ต่อไป เมื่อสคริปต์ดาวน์โหลดเสร็จแล้ว ระบบจะบล็อกการแยกวิเคราะห์ขณะที่สคริปต์ทำงาน

• defer ทำให้เบราว์เซอร์ดาวน์โหลดสคริปต์แบบอะซิงโครนัสขณะที่ยังคงแยกวิเคราะห์เอกสาร HTML ต่อไป จากนั้นจะรอเรียกใช้สคริปต์จนกว่าการแยกวิเคราะห์เอกสารจะเสร็จสมบูรณ์

ใช้ async หรือ defer สำหรับสคริปต์ของบุคคลที่สามเสมอ เว้นแต่ว่าสคริปต์นั้นจำเป็นสำหรับเส้นทางการแสดงผลที่สำคัญ ใช้ async หากสคริปต์ต้องทำงานก่อนในกระบวนการโหลด เช่น สคริปต์การวิเคราะห์บางรายการ ใช้ defer สำหรับทรัพยากรที่มีความสำคัญน้อยกว่า เช่น วิดีโอที่แสดงผลในตำแหน่งที่ต่ำกว่าในหน้าเว็บซึ่งผู้ใช้จะไม่เห็นในตอนแรก

หากประสิทธิภาพเป็นสิ่งที่คุณให้ความสำคัญเป็นอันดับแรก เราขอแนะนำให้รอเพิ่มสคริปต์แบบอะซิงโครนัสหลังจากที่เนื้อหาสำคัญของหน้าเว็บโหลดเสร็จแล้ว เราไม่แนะนำให้ใช้ async สำหรับไลบรารีที่จำเป็น เช่น jQuery

หมายเหตุ: ใน Chrome และเบราว์เซอร์อื่นๆ ที่ใช้ Blink แอตทริบิวต์ async และ defer จะลดลำดับความสำคัญของคำขอเครือข่ายสำหรับทรัพยากร จึงอาจทำให้โหลดช้ากว่าการใช้สคริปต์ที่บล็อกอย่างมาก ซึ่งเป็นประโยชน์อย่างยิ่งสำหรับสคริปต์ Analytics

สคริปต์บางรายการต้องโหลดโดยไม่มี async หรือ defer โดยเฉพาะสคริปต์ที่เป็นส่วนสำคัญของเว็บไซต์ ซึ่งรวมถึงไลบรารี UI หรือเฟรมเวิร์กเครือข่ายนำส่งข้อมูล (CDN) ที่เว็บไซต์ของคุณจะทำงานไม่ได้หากไม่มี

สคริปต์อื่นๆ จะไม่ทำงานหากโหลดแบบอะซิงโครนัส ตรวจสอบเอกสารประกอบของสคริปต์ที่คุณใช้อยู่ และแทนที่สคริปต์ที่โหลดแบบอะซิงโครนัสไม่ได้ด้วยสคริปต์อื่นที่โหลดได้ โปรดทราบว่าบุคคลที่สามบางรายแนะนำให้เรียกใช้สคริปต์แบบซิงโครนัส แม้ว่าสคริปต์จะทำงานแบบอะซิงโครนัสได้ดีพอๆ กันก็ตาม

โปรดทราบว่า async ไม่ได้ช่วยแก้ปัญหาได้ทุกอย่าง หากหน้าเว็บมีสคริปต์จำนวนมาก เช่น สคริปต์การติดตามเพื่อวัตถุประสงค์ในการโฆษณา การโหลดสคริปต์แบบอะซิงโครนัสจะไม่ช่วยป้องกันไม่ให้หน้าเว็บโหลดช้าลง

ใช้คำแนะนำเกี่ยวกับทรัพยากรเพื่อลดเวลาในการตั้งค่าการเชื่อมต่อ

การสร้างการเชื่อมต่อกับต้นทางของบุคคลที่สามอาจใช้เวลานาน โดยเฉพาะในเครือข่ายที่ช้า เนื่องจากคำขอเครือข่ายมีองค์ประกอบที่ซับซ้อนหลายอย่าง รวมถึงการค้นหา DNS และการเปลี่ยนเส้นทาง คุณสามารถใช้คำแนะนำเกี่ยวกับทรัพยากร เช่น เพื่อทำการค้นหา DNS สำหรับโดเมนที่โฮสต์สคริปต์ของบุคคลที่สามตั้งแต่เนิ่นๆ ในกระบวนการโหลดหน้าเว็บ เพื่อให้คำขอเครือข่ายที่เหลือดำเนินการได้เร็วขึ้นในภายหลัง

<link rel="dns-prefetch" href="http://example.com" />

หากโดเมนของบุคคลที่สามที่คุณเชื่อมต่อใช้ HTTPS คุณยังใช้ ได้ด้วย ซึ่งจะทำการค้นหา DNS และแก้ไขการส่งข้อมูลไปกลับของ TCP และจัดการการเจรจาต่อรอง TLS ขั้นตอนอื่นๆ เหล่านี้อาจช้ามากเนื่องจากเกี่ยวข้องกับการยืนยันใบรับรอง SSL ดังนั้นการเชื่อมต่อล่วงหน้าจึงช่วยลดเวลาในการโหลดได้อย่างมาก

<link rel="preconnect" href="https://cdn.example.com" />

สคริปต์ "แซนด์บ็อกซ์" ที่มี iframe

หากคุณโหลดสคริปต์ของบุคคลที่สามลงใน iframe โดยตรง สคริปต์ดังกล่าวจะไม่บล็อกการดำเนินการของหน้าหลัก AMP ใช้วิธีนี้เพื่อไม่ให้ JavaScript อยู่ในเส้นทางที่สำคัญ โปรดทราบว่าวิธีนี้ยังคงบล็อกเหตุการณ์ onload ดังนั้นอย่าพยายามแนบฟีเจอร์สําคัญกับ onload

นอกจากนี้ Chrome ยังรองรับนโยบายสิทธิ์ (เดิมคือนโยบายฟีเจอร์) ซึ่งเป็นชุดนโยบายที่ช่วยให้นักพัฒนาซอฟต์แวร์เลือกปิดใช้การเข้าถึงฟีเจอร์บางอย่างของเบราว์เซอร์ได้ คุณสามารถใช้ฟีเจอร์นี้เพื่อป้องกันไม่ให้เนื้อหาของบุคคลที่สามทำให้เกิดพฤติกรรมที่ไม่พึงประสงค์ในเว็บไซต์

โฮสต์สคริปต์ของบุคคลที่สามด้วยตนเอง

หากต้องการควบคุมวิธีโหลดสคริปต์ที่สำคัญมากขึ้น เช่น เพื่อลดเวลา DNS หรือปรับปรุงส่วนหัวการแคช HTTP คุณอาจโฮสต์สคริปต์ด้วยตนเองได้

อย่างไรก็ตาม การโฮสต์ด้วยตนเองก็มีปัญหาในตัว โดยเฉพาะอย่างยิ่งเมื่อต้องอัปเดตสคริปต์ สคริปต์ที่โฮสต์เองจะไม่ได้รับการอัปเดตอัตโนมัติสำหรับการเปลี่ยนแปลง API หรือการแก้ไขด้านความปลอดภัย ซึ่งอาจทำให้สูญเสียรายได้หรือเกิดปัญหาด้านความปลอดภัยจนกว่าคุณจะอัปเดตสคริปต์ด้วยตนเอง

หรือจะแคชสคริปต์ของบุคคลที่สามโดยใช้ Service Worker เพื่อควบคุมความถี่ในการดึงข้อมูลสคริปต์จากเครือข่ายได้มากขึ้นก็ได้ นอกจากนี้ คุณยังใช้ Service Worker เพื่อสร้างกลยุทธ์การโหลดที่จำกัดคำขอของบุคคลที่สามที่ไม่จำเป็นจนกว่าหน้าเว็บจะถึงช่วงเวลาสำคัญของผู้ใช้ได้ด้วย

การทดสอบ A/B กับกลุ่มตัวอย่างผู้ใช้ขนาดเล็ก

การทดสอบ A/B (หรือการแยกทดสอบ) เป็นเทคนิคในการทดสอบหน้าเว็บ 2 เวอร์ชันเพื่อวิเคราะห์ประสบการณ์และพฤติกรรมของผู้ใช้ โดยจะแสดงหน้าเวอร์ชันต่างๆ ให้กับกลุ่มตัวอย่างการเข้าชมเว็บไซต์ที่แตกต่างกัน และพิจารณาจากข้อมูลวิเคราะห์ว่าเวอร์ชันใดให้อัตรา Conversion ที่ดีกว่า

อย่างไรก็ตาม การทดสอบ A/B ได้รับการออกแบบมาให้เลื่อนการแสดงผลออกไปเพื่อตัดสินใจว่าการทดสอบใดที่ต้องทำงานอยู่ JavaScript มักใช้เพื่อตรวจสอบว่าผู้ใช้ของคุณเป็นส่วนหนึ่งของการทดสอบ A/B หรือไม่ แล้วจึงเปิดใช้ตัวแปรที่ถูกต้อง กระบวนการนี้อาจทำให้ประสบการณ์การใช้งานแย่ลงแม้แต่สำหรับผู้ใช้ที่ไม่ได้อยู่ในการทดสอบ

เพื่อเร่งการแสดงผลหน้าเว็บ เราขอแนะนำให้ส่งสคริปต์การทดสอบ A/B ไปยังกลุ่มตัวอย่างฐานผู้ใช้ที่เล็กลง และเรียกใช้โค้ดที่ตัดสินว่าจะแสดงหน้าเว็บเวอร์ชันใดในฝั่งเซิร์ฟเวอร์

โหลดทรัพยากรของบุคคลที่สามแบบ Lazy Loading

ทรัพยากรของบุคคลที่สามที่ฝังไว้ เช่น โฆษณาและวิดีโอ อาจเป็นปัจจัยหลักที่ทำให้ Page Speed ช้าหากสร้างขึ้นอย่างไม่เหมาะสม คุณสามารถใช้การโหลดแบบ Lazy Loading เพื่อโหลดทรัพยากรที่ฝังไว้เฉพาะเมื่อจำเป็นเท่านั้น เช่น รอแสดงโฆษณาในส่วนท้ายของหน้าจนกว่าผู้ใช้จะเลื่อนลงมามากพอที่จะเห็นโฆษณา นอกจากนี้ คุณยังโหลดเนื้อหาของบุคคลที่สามแบบ Lazy Loading หลังจากที่เนื้อหาหน้าหลักโหลดแล้ว แต่ก่อนที่ผู้ใช้อาจโต้ตอบกับหน้าเว็บได้ด้วย

คุณสามารถใช้การโหลดแบบ Lazy Loading กับชิ้นงานที่ผู้ใช้จะไม่เห็นทันทีเมื่อโหลดหน้าเว็บ

โปรดระมัดระวังเมื่อโหลดทรัพยากรแบบ Lazy Loading เนื่องจากมักเกี่ยวข้องกับโค้ด JavaScript ที่อาจได้รับผลกระทบจากการเชื่อมต่อเครือข่ายที่ไม่เสถียร

หมายเหตุ: LazySizes เป็นไลบรารี JavaScript ยอดนิยมสำหรับการโหลดรูปภาพและ iframe แบบ Lazy Loading โดยรองรับการฝัง YouTube และวิดเจ็ต

DoubleClick มีคำแนะนำเกี่ยวกับวิธีโหลดโฆษณาแบบ Lazy Loading ในเอกสารประกอบอย่างเป็นทางการ

การโหลดแบบ Lazy Loading ที่มีประสิทธิภาพด้วย Intersection Observer

ที่ผ่านมา วิธีการตรวจหาว่าองค์ประกอบหนึ่งๆ ปรากฏในวิวพอร์ตเพื่อวัตถุประสงค์ในการโหลดแบบ Lazy Loading หรือไม่นั้นมักเกิดข้อผิดพลาดได้ง่ายและมักทำให้เบราว์เซอร์ทำงานช้าลง วิธีการที่ไม่มีประสิทธิภาพเหล่านี้มักจะคอยฟังเหตุการณ์ scroll หรือ resize จากนั้นใช้ DOM API เช่น getBoundingClientRect() เพื่อคำนวณตำแหน่งขององค์ประกอบที่สัมพันธ์กับวิวพอร์ต

IntersectionObserver คือ API ของเบราว์เซอร์ที่ช่วยให้เจ้าของเว็บตรวจจับได้อย่างมีประสิทธิภาพเมื่อองค์ประกอบที่สังเกตเข้าหรือออกจากวิวพอร์ตของเบราว์เซอร์ นอกจากนี้ LazySizes ยังมีการรองรับที่ไม่บังคับสำหรับ IntersectionObserver ด้วย

การวิเคราะห์การโหลดแบบ Lazy Loading

หากเลื่อนการโหลดสคริปต์ Analytics ออกไปนานเกินไป คุณอาจพลาดข้อมูล Analytics ที่มีค่า โชคดีที่มีกลยุทธ์ในการเริ่มต้นการวิเคราะห์แบบ Lazy Loading ขณะที่ยังคงเก็บข้อมูลการโหลดหน้าเว็บในช่วงแรกไว้

บล็อกโพสต์ของ Phil Walton เรื่องการตั้งค่า Google Analytics ที่ฉันใช้กับทุกเว็บไซต์ที่สร้างครอบคลุมกลยุทธ์หนึ่งสำหรับ Google Analytics

โหลดสคริปต์ของบุคคลที่สามอย่างปลอดภัย

ส่วนนี้จะให้คำแนะนำในการโหลดสคริปต์ของบุคคลที่สามอย่างปลอดภัยที่สุด

หลีกเลี่ยง document.write()

สคริปต์ของบุคคลที่สาม โดยเฉพาะสำหรับบริการที่เก่ากว่า บางครั้งจะใช้ document.write() เพื่อแทรกและโหลดสคริปต์ ซึ่งเป็นปัญหาเนื่องจาก document.write() ทำงานไม่สอดคล้องกัน และแก้ไขข้อบกพร่องของความล้มเหลวได้ยาก

วิธีแก้ไขปัญหา document.write() คือการไม่ใช้ ใน Chrome 53 ขึ้นไป เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome จะบันทึกคำเตือนไปยังคอนโซลสำหรับการใช้ document.write() ที่เป็นปัญหา ดังนี้

การใช้แฟล็กเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome document.write()

หากได้รับข้อผิดพลาดนี้ คุณสามารถตรวจสอบการใช้งาน document.write() ของเว็บไซต์ได้โดยดูที่ส่วนหัว HTTP ที่ส่งไปยังเบราว์เซอร์ Lighthouse ยังสามารถไฮไลต์สคริปต์ของบุคคลที่สามที่ยังคงใช้ document.write() อยู่ได้ด้วย

รายงาน Lighthouse แสดงสคริปต์ที่ใช้ document.write()

ใช้ Tag Manager อย่างระมัดระวัง

แท็กคือข้อมูลโค้ดที่ช่วยให้ทีมการตลาดดิจิทัลรวบรวมข้อมูล ตั้งค่าคุกกี้ หรือผสานรวมเนื้อหาของบุคคลที่สาม เช่น วิดเจ็ตโซเชียลมีเดียลงในเว็บไซต์ได้ แท็กเหล่านี้จะเพิ่มคำขอเครือข่าย ทรัพยากร Dependency ของ JavaScript และทรัพยากรอื่นๆ ลงในหน้าเว็บ ซึ่งอาจส่งผลต่อประสิทธิภาพของหน้าเว็บ และการลดผลกระทบดังกล่าวต่อผู้ใช้จะทำได้ยากขึ้นเมื่อมีการเพิ่มแท็กมากขึ้น

เราขอแนะนําให้ใช้เครื่องมือจัดการแท็ก เช่น Google Tag Manager (GTM) เพื่อให้การโหลดหน้าเว็บเร็ว GTM ช่วยให้คุณติดตั้งใช้งานแท็กแบบอะซิงโครนัสได้ เพื่อไม่ให้แท็กบล็อกการโหลดของกันและกัน ลดจำนวนการเรียกใช้เครือข่ายที่เบราว์เซอร์ต้องใช้เพื่อเรียกใช้แท็ก และรวบรวมข้อมูลแท็กใน UI ชั้นข้อมูล

ความเสี่ยงจากการใช้ Tag Manager

แม้ว่า Tag Manager จะออกแบบมาเพื่อปรับปรุงการโหลดหน้าเว็บให้มีประสิทธิภาพ แต่การใช้งานอย่างไม่ระมัดระวังอาจทำให้หน้าเว็บโหลดช้าลงได้ด้วยวิธีต่อไปนี้

• แท็กและListener เหตุการณ์อัตโนมัติจำนวนมากเกินไปใน Tag Manager จะทำให้เบราว์เซอร์ส่งคำขอเครือข่ายมากกว่าที่จำเป็น และลดความสามารถของโค้ดในการตอบสนองต่อเหตุการณ์อย่างรวดเร็ว
• ทุกคนที่มีข้อมูลเข้าสู่ระบบและสิทธิ์เข้าถึงจะเพิ่ม JavaScript ลงใน Tag Manager ได้ ซึ่งไม่เพียงแต่จะเพิ่มจำนวนคำขอเครือข่ายที่มีค่าใช้จ่ายสูงซึ่งจำเป็นต่อการโหลดหน้าเว็บเท่านั้น แต่ยังอาจก่อให้เกิดความเสี่ยงด้านความปลอดภัยและปัญหาด้านประสิทธิภาพอื่นๆ จากสคริปต์ที่ไม่จำเป็นด้วย เราขอแนะนำให้จำกัดสิทธิ์เข้าถึง Tag Manager เพื่อลดความเสี่ยงเหล่านี้

หลีกเลี่ยงสคริปต์ที่ทำให้ขอบเขตส่วนกลางเสียหาย

สคริปต์ของบุคคลที่สามอาจทำงานในลักษณะต่างๆ ที่ทำให้หน้าเว็บของคุณเสียหายโดยไม่คาดคิด ดังนี้

• สคริปต์ที่โหลดทรัพยากร Dependency ของ JavaScript อาจทำให้ขอบเขตส่วนกลางเต็มไปด้วยโค้ดที่โต้ตอบกับโค้ดของคุณได้ไม่ดี
• การอัปเดตที่ไม่คาดคิดอาจทำให้เกิดการเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบ
• โค้ดของบุคคลที่สามสามารถแก้ไขได้ระหว่างการส่งเพื่อให้ทำงานแตกต่างกันระหว่างการทดสอบและการทำให้หน้าเว็บใช้งานได้จริง

เราขอแนะนำให้ตรวจสอบสคริปต์ของบุคคลที่สามที่คุณโหลดเป็นประจำเพื่อตรวจหาผู้ไม่ประสงค์ดี นอกจากนี้ คุณยังสามารถใช้การทดสอบด้วยตนเอง, ความสมบูรณ์ของทรัพยากรย่อย และการส่งโค้ดของบุคคลที่สามอย่างปลอดภัยเพื่อรักษาความปลอดภัยของหน้าเว็บได้ด้วย

กลยุทธ์การลดความเสี่ยง

ต่อไปนี้คือกลยุทธ์ขนาดใหญ่เพื่อลดผลกระทบของสคริปต์ของบุคคลที่สามต่อประสิทธิภาพและความปลอดภัยของเว็บไซต์

• HTTPS: เว็บไซต์ที่ใช้ HTTPS ต้องไม่ขึ้นอยู่กับบุคคลที่สามที่ใช้ HTTP ดูข้อมูลเพิ่มเติมได้ที่เนื้อหาผสม

• แซนด์บ็อกซ์: พิจารณาเรียกใช้สคริปต์ของบุคคลที่สามใน iframe ที่มีแอตทริบิวต์ sandbox เพื่อจำกัดการดำเนินการที่สคริปต์ทำได้

• นโยบายรักษาความปลอดภัยเนื้อหา (CSP): คุณสามารถใช้ส่วนหัว HTTP ในการตอบกลับของเซิร์ฟเวอร์เพื่อกำหนดลักษณะการทำงานของสคริปต์ที่เชื่อถือได้สำหรับเว็บไซต์ของคุณ รวมถึงตรวจจับและลดผลกระทบจากการโจมตีบางอย่าง เช่น Cross Site Scripting (XSS)

ต่อไปนี้เป็นตัวอย่างวิธีใช้คำสั่ง script-src ของ CSP เพื่อระบุแหล่งที่มาของ JavaScript ที่อนุญาตของหน้าเว็บ

// Given this CSP header Content-Security-Policy: script-src
https://example.com/ // The following third-party script will not be loaded or
executed

<script src="https://not-example.com/js/library.js"></script>

อ่านเพิ่มเติม

หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับการเพิ่มประสิทธิภาพ JavaScript ของบุคคลที่สาม เราขอแนะนำให้อ่านบทความต่อไปนี้

• ประสิทธิภาพและความยืดหยุ่น: การทดสอบความสามารถในการรับภาระงานของบุคคลที่สาม
• การเพิ่มการโต้ตอบด้วย JavaScript
• อันตรายที่อาจเกิดขึ้นจากสคริปต์ของบุคคลที่สาม
• How 3rd Party Scripts can be performant citizens on the web
• Why Fast Matters - CSS Wizardry
• The JavaScript Supply Chain Paradox: SRI, CSP and Trust in Third Party Libraries
• CSS ของบุคคลที่สามไม่ปลอดภัย

ขอขอบคุณ Kenji Baheux, Jeremy Wagner, Pat Meenan, Philip Walton, Jeff Posnick และ Cheney Tsai สำหรับการตรวจสอบ