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

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

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

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

ตามหลักการแล้ว คุณควรตรวจสอบว่าสคริปต์ของบุคคลที่สามไม่ส่งผลกระทบต่อเส้นทางการแสดงผลที่สำคัญของเว็บไซต์ ในคู่มือนี้ เราจะแนะนำวิธีค้นหาและแก้ไขปัญหาเกี่ยวกับการโหลด 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 หากเซิร์ฟเวอร์ตอบสนองช้า แม้ว่าการฝังจะใช้การซิงค์หรือการเลื่อนเวลาออกไปก็ตาม

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

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

ขั้นตอนแรกในการเพิ่มประสิทธิภาพสคริปต์นั้นคือการระบุสคริปต์ของบุคคลที่สามในเว็บไซต์และการกำหนดผลที่มีต่อประสิทธิภาพ เราขอแนะนำให้ใช้เครื่องมือทดสอบความเร็วเว็บฟรี ซึ่งรวมถึง Chrome DevTools, 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 ยังรองรับคำสั่ง 2 คำสั่งในระดับ DNS สำหรับการบล็อกโดเมนด้วย ดังนี้

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

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

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

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

หากต้องการตรวจจับงานที่ใช้เวลานานสำหรับ Real User Monitoring (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 หรือการแก้ไขด้านความปลอดภัย ซึ่งอาจนำไปสู่การสูญเสียรายได้หรือปัญหาด้านความปลอดภัยจนกว่าคุณจะอัปเดตสคริปต์ด้วยตนเองได้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ขอขอบคุณ Kenji Baheux, Jeremy Wagner, Pat Meenan, Philip Walton, Jeff Posnick และ Cheney Tsai ที่เข้ามารีวิว