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

Addy Osmani
Addy Osmani
X GitHub
Arthur Evans
X GitHub

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

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

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

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

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

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

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

  • โปรแกรมเล่นวิดีโอที่ฝัง (YouTube, Vimeo)

  • iframe การโฆษณา

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WebPageTest การตั้งค่าขั้นสูง < Block. แสดงพื้นที่ข้อความสำหรับระบุโดเมนที่จะบล็อก
ระบุโดเมนที่คุณต้องการบล็อกในแผงนี้

เราขอแนะนำให้ใช้ขั้นตอนการทำงานต่อไปนี้เพื่อใช้ฟีเจอร์นี้

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

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

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

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

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

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

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 ได้
คุณสามารถโหลดชิ้นงานแบบ 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() มีปัญหา:

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

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

แนวทางปฏิบัติแนะนำสำหรับ Lighthouse ในการตรวจสอบการแจ้งว่าไม่เหมาะสม การใช้ document.write()
รายงาน 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 ของบุคคลที่สาม เราขอแนะนำให้คุณอ่านข้อมูลต่อไปนี้

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