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

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

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

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

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

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

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

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

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

• iframe โฆษณา

• สคริปต์ Analytics และเมตริก

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

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

<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 หากเซิร์ฟเวอร์ตอบสนองช้า แม้ว่าการฝังจะใช้แบบแอ็กซิงโครนัสหรือเลื่อนเวลาไว้ก่อนก็ตาม

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

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

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

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

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

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

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

การตรวจสอบเวลาในการเริ่มต้นระบบของ Lighthouse

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

นอกจากนี้ WebPageTest ยังรองรับคําสั่ง 2 รายการที่ทํางานในระดับ DNS สําหรับการบล็อกโดเมน ดังนี้

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

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

ตรวจหา iframe ที่มีราคาสูงโดยใช้ Long Tasks

เมื่อสคริปต์ใน 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

สคริปต์บางรายการต้องโหลดโดยไม่มี 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 Testing ไว้ให้เลื่อนการแสดงผลเพื่อตัดสินใจว่าต้องเปิดใช้งานการทดสอบใด JavaScript มักใช้เพื่อตรวจสอบว่าผู้ใช้รายใดของคุณอยู่ในกลุ่มทดสอบ A/B หรือไม่ จากนั้นจึงเปิดใช้ตัวแปรที่ถูกต้อง กระบวนการนี้อาจทําให้ประสบการณ์การใช้งานแย่ลงสําหรับผู้ใช้ที่ไม่ได้เข้าร่วมการทดสอบด้วย

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

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

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

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

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

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

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

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

ข้อมูลวิเคราะห์การโหลดแบบ Lazy Loading

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

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

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

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

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

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

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

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

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

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

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

ความเสี่ยงในการใช้เครื่องมือจัดการแท็ก

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

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

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

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

• สคริปต์ที่โหลดไลบรารี 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
• อันตรายที่อาจเกิดขึ้นจากสคริปต์ของบุคคลที่สาม
• วิธีที่สคริปต์ของบุคคลที่สามสามารถทํางานได้อย่างมีประสิทธิภาพบนเว็บ
• เหตุใดความรวดเร็วจึงสำคัญ - เวทมนตร์ CSS
• ความขัดแย้งในห่วงโซ่อุปทานของ JavaScript: SRI, CSP และการวางใจไลบรารีของบุคคลที่สาม
• CSS ของบุคคลที่สามไม่ปลอดภัย

ขอขอบคุณ Kenji Baheux, Jeremy Wagner, Pat Meenan, Philip Walton, Jeff Posnick และ Cheney Tsai ที่ให้ความร่วมมือในการตรวจสอบ