หากคุณเพิ่มประสิทธิภาพโค้ดแล้ว แต่เว็บไซต์ยังโหลดช้าเกินไป อาจเป็นไปได้ว่าเป็นความผิดพลาดของสคริปต์ของบุคคลที่สาม
สคริปต์ของบุคคลที่สามมีฟีเจอร์ที่มีประโยชน์มากมายที่ทำให้เว็บมีความไดนามิก อินเทอร์แอกทีฟ และเชื่อมต่อถึงกันมากขึ้น ซึ่งบางอย่างอาจสำคัญต่อฟังก์ชันการทำงานของเว็บไซต์หรือแหล่งรายได้ แต่การใช้งานมีความเสี่ยง
- เนื่องจากอาจทำให้ประสิทธิภาพของเว็บไซต์ช้าลง
- ซึ่งอาจทำให้เกิดปัญหาด้านความเป็นส่วนตัวหรือความปลอดภัย
- ซึ่งอาจทำให้คาดเดาไม่ได้ และพฤติกรรมของทั้ง 2 อย่างอาจรับผลกระทบที่ไม่คาดคิดได้
ตามหลักการแล้ว คุณควรตรวจสอบว่าสคริปต์ของบุคคลที่สามไม่ส่งผลกระทบต่อเส้นทางการแสดงผลที่สำคัญของเว็บไซต์ ในคู่มือนี้ เราจะแนะนำวิธีค้นหาและแก้ไขปัญหาเกี่ยวกับการโหลด JavaScript ของบุคคลที่สามและลดความเสี่ยงต่อผู้ใช้
สคริปต์ของบุคคลที่สามคืออะไร
JavaScript ของบุคคลที่สามมักจะหมายถึงสคริปต์ที่สามารถฝังลงในเว็บไซต์ใดก็ได้จากผู้ให้บริการบุคคลที่สามโดยตรง ตัวอย่างเช่น
ปุ่มการแชร์ผ่านโซเชียล (Facebook, X, LinkedIn, Mastodon)
โปรแกรมเล่นวิดีโอที่ฝัง (YouTube, Vimeo)
iframe การโฆษณา
สคริปต์ Analytics และเมตริก
สคริปต์การทดสอบ A/B สำหรับการทดสอบ
ไลบรารีตัวช่วย เช่น การจัดรูปแบบวันที่ ภาพเคลื่อนไหว หรือไลบรารีการทำงาน
![ตัวอย่างการฝังวิดีโอ YouTube](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/example-a-youtube-video-c78967c85a13b.jpeg?authuser=9&hl=th)
<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 จากการทดสอบหน้าเว็บที่แสดง
เว็บไซต์จริงเทียบกับเวลาที่ใช้ในการโหลดสคริปต์ติดตาม](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/waterfall-view-webpagete-35c332733c4dc.jpeg?authuser=9&hl=th)
รายละเอียดโดเมนของ WebPageTest ก็อาจเป็นประโยชน์สำหรับการแสดงภาพปริมาณเนื้อหาที่มาจากต้นทางของบุคคลที่สามได้เช่นกัน โดยจะแจกแจงตามไบต์ทั้งหมดและจำนวนคำขอ
![แยกตามโดเมน (การดูครั้งแรก)
แสดงเปอร์เซ็นต์ของคำขอและไบต์ของบุคคลที่สามแต่ละราย](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/content-breakdown-domain-f79c0ab40182d.png?authuser=9&hl=th)
ฉันจะวัดผลกระทบที่สคริปต์ของบุคคลที่สามมีต่อหน้าเว็บของฉันได้อย่างไร
เมื่อเห็นสคริปต์ที่ทำให้เกิดปัญหา ให้ค้นหาว่าสคริปต์ทำหน้าที่อะไรและพิจารณาว่าเว็บไซต์จำเป็นต้องทำงานหรือไม่ หากจำเป็น ให้ทำการทดสอบ A/B เพื่อสร้างความสมดุลระหว่างมูลค่าที่รับรู้กับผลที่มีต่อเมตริกการมีส่วนร่วมหรือประสิทธิภาพที่สำคัญของผู้ใช้
การตรวจสอบเวลาเปิดเครื่อง Lighthouse
การตรวจสอบเวลาเปิดเครื่อง JavaScript ของ Lighthouse จะไฮไลต์สคริปต์ที่มีเวลาการแยกวิเคราะห์ รวบรวม หรือประเมินสคริปต์ซึ่งมีราคาแพง ซึ่งจะช่วยให้คุณระบุสคริปต์ของบุคคลที่สามที่ใช้ CPU ได้
![Lighthouse แสดงการรองรับ
การประเมินและแยกวิเคราะห์สคริปต์](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/lighthouse-showing-suppor-8af1a01ba2c3e.png?authuser=9&hl=th)
การตรวจสอบเพย์โหลดของเครือข่าย Lighthouse
การตรวจสอบเพย์โหลดเครือข่ายของ Lighthouse จะระบุคำขอของเครือข่าย รวมถึงคำขอเครือข่ายของบุคคลที่สามที่ทำให้โหลดหน้าเว็บช้าลงและทำให้ผู้ใช้ใช้เวลากับอินเทอร์เน็ตมือถือมากกว่าที่คาดไว้
![ประภาคารแสดงการรองรับเพย์โหลด
ของเครือข่ายขนาดใหญ่](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/lighthouse-showing-suppor-63ad35702fbc3.png?authuser=9&hl=th)
การบล็อกคำขอของเครือข่ายเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ช่วยให้คุณเห็นวิธีการทำงานของหน้าเว็บเมื่อสคริปต์ สไตล์ชีต หรือทรัพยากรอื่นๆ ที่ระบุไม่พร้อมใช้งาน ซึ่งทำได้ด้วยการบล็อกคำขอเครือข่าย ซึ่งเป็นฟีเจอร์ที่ช่วยวัดผลกระทบของการนำทรัพยากรของบุคคลที่สามแต่ละรายการออกจากหน้าเว็บ
หากต้องการเปิดใช้การบล็อกคำขอ ให้คลิกขวาที่คำขอใดก็ได้ในแผงเครือข่าย แล้วเลือกบล็อก URL คำขอ จากนั้นแท็บการบล็อกคำขอจะแสดงในลิ้นชักเครื่องมือสำหรับนักพัฒนาเว็บเพื่อให้คุณจัดการคำขอที่ถูกบล็อกได้
![บล็อก URL คำขอจากแผง
เครือข่ายเครื่องมือสำหรับนักพัฒนาเว็บ](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/block-request-urls-the-d-66fa36ce9b253.png?authuser=9&hl=th)
แผงประสิทธิภาพเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
แผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ช่วยระบุปัญหาเกี่ยวกับประสิทธิภาพเว็บของหน้าเว็บ
- คลิกบันทึก
- โหลดหน้าเว็บ เครื่องมือสำหรับนักพัฒนาเว็บจะแสดงแผนภาพ Waterfall ซึ่งแสดงวิธีที่เว็บไซต์ใช้เวลาในการโหลด
- ไปที่ล่างขึ้นบนที่ด้านล่างของแผงประสิทธิภาพ
- คลิกจัดกลุ่มตามผลิตภัณฑ์ และจัดเรียงสคริปต์บุคคลที่สามของหน้าเว็บตามเวลาที่ใช้ในการโหลด
![แผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บแสดงมุมมองล่างขึ้นบนที่จัดกลุ่มตามผลิตภัณฑ์ (บุคคลที่สาม)](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/devtools-performance-pane-76e2e3248ed5f.png?authuser=9&hl=th)
หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เพื่อวิเคราะห์ประสิทธิภาพการโหลดหน้าเว็บ โปรดดูเริ่มต้นใช้งานการวิเคราะห์ประสิทธิภาพรันไทม์
ต่อไปนี้เป็นเวิร์กโฟลว์ที่แนะนำสำหรับการวัดผลกระทบของสคริปต์ของบุคคลที่สาม
- ใช้แผงเครือข่ายเพื่อวัดว่าใช้เวลานานเท่าใดในการโหลดหน้าเว็บ
- หากต้องการจำลองสภาพการใช้งานจริง เราขอแนะนำให้เปิดการควบคุมเครือข่ายและการควบคุม CPU ผู้ใช้ของคุณมีแนวโน้มที่จะไม่มีการเชื่อมต่อเครือข่ายที่เร็วและฮาร์ดแวร์เดสก์ท็อปที่ลดผลกระทบของสคริปต์ราคาแพงภายใต้เงื่อนไขของห้องทดลอง
- บล็อก URL หรือโดเมนที่รับผิดชอบสคริปต์ของบุคคลที่สามที่คุณเชื่อว่าเป็นปัญหา (ดูแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับคำแนะนำในการระบุสคริปต์ที่มีค่าใช้จ่าย)
- โหลดหน้าเว็บซ้ำและวัดเวลาที่ใช้ในการโหลดอีกครั้ง
- เพื่อข้อมูลที่แม่นยำมากขึ้น คุณอาจต้องวัดความเร็วในการโหลดอย่างน้อย 3 ครั้ง ซึ่งกรณีนี้จะคำนึงถึงสคริปต์ของบุคคลที่สามบางส่วนที่ดึงทรัพยากรที่แตกต่างกันในการโหลดหน้าเว็บแต่ละครั้ง แผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บจึงรองรับการบันทึกหลายรายการเพื่อช่วยในเรื่องนี้
วัดผลกระทบของสคริปต์ของบุคคลที่สามด้วย WebPageTest
WebPageTest รองรับการบล็อกคำขอแต่ละรายการไม่ให้โหลดเพื่อวัดผลกระทบของแต่ละคำขอได้ในการตั้งค่าขั้นสูง > บล็อก ใช้ฟีเจอร์นี้เพื่อระบุรายการโดเมนที่จะบล็อก เช่น โดเมนโฆษณา
![WebPageTest การตั้งค่าขั้นสูง < Block.
แสดงพื้นที่ข้อความสำหรับระบุโดเมนที่จะบล็อก](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/webpagetest-advanced-sett-e8803075edd46.png?authuser=9&hl=th)
เราขอแนะนำให้ใช้ขั้นตอนการทำงานต่อไปนี้เพื่อใช้ฟีเจอร์นี้
- ทดสอบหน้าเว็บโดยไม่บล็อกบุคคลที่สาม
- ทำการทดสอบกับบุคคลที่สามที่ถูกบล็อกซ้ำอีกครั้ง
- เลือกผลลัพธ์ 2 รายการจากประวัติการทดสอบ
- คลิกเปรียบเทียบ
![WebPageTest จะแสดงตัวเลือกการเปรียบเทียบ
ซึ่งช่วยให้คุณเปรียบเทียบรายงาน 2 ฉบับได้](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/webpagetest-displaying-c-f6c3f4461ff9b.png?authuser=9&hl=th)
รูปภาพต่อไปนี้แสดงฟีเจอร์แถบแสดงตัวอย่างของ WebPageTest ที่เปรียบเทียบลำดับการโหลดของหน้าที่มีและไม่มีทรัพยากรของบุคคลที่สามที่ใช้งานอยู่ เราขอแนะนำให้ตรวจสอบเรื่องนี้เพื่อทดสอบต้นทางของบุคคลที่สามแต่ละรายการ เพื่อดูว่าโดเมนใดส่งผลต่อประสิทธิภาพของหน้าเว็บมากที่สุด
![แถบฟิล์ม WebPageTest ที่แสดงผลกระทบ
จากการโหลดเว็บไซต์ทั้งโดยที่ปิดหรือไม่ได้ปิดใช้บุคคลที่สาม](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/webpagetest-filmstrip-dis-c4ad9edb942af.png?authuser=9&hl=th)
นอกจากนี้ WebPageTest ยังรองรับคำสั่ง 2 คำสั่งในระดับ DNS สำหรับการบล็อกโดเมนด้วย ดังนี้
blockDomains
ใช้รายการโดเมนที่จะบล็อก- blockDomainsExcept จะแสดงรายการโดเมนและบล็อกสิ่งที่ไม่อยู่ในรายการ
นอกจากนี้ WebPageTest ยังมีแท็บจุดล้มเหลว (SPOF) จุดเดียวที่ช่วยให้คุณจำลองการหมดเวลาหรือล้มเหลวในการโหลดทรัพยากรได้สำเร็จ SPOF จะหมดเวลาซึ่งต่างจากการบล็อกโดเมน ซึ่งมีประโยชน์สำหรับการทดสอบลักษณะการทำงานของหน้าเว็บเมื่อบริการของบุคคลที่สามมีภาระงานมากหรือไม่พร้อมใช้งานชั่วคราว
![WebPageTest การตั้งค่าขั้นสูง > SPOF > โฮสต์
ที่ล้มเหลว](/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/webpagetest-advanced-sett-698d1c0664b84.png)
ตรวจหา 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 ได้](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/an-illustration-showing-a-f0d6b6d27f361.png?authuser=9&hl=th)
โปรดระวังเมื่อโหลดทรัพยากรแบบ 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()](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/devtools-console-warnings-8a4bc282f4492.png?authuser=9&hl=th)
document.write()
หากได้รับข้อผิดพลาดนี้ คุณสามารถตรวจสอบการใช้งาน document.write()
ของเว็บไซต์ได้โดยมองหาส่วนหัว HTTP ที่ส่งไปยังเบราว์เซอร์
นอกจากนี้ Lighthouse ยังสามารถไฮไลต์สคริปต์ของบุคคลที่สามที่ยังใช้ document.write()
อยู่ได้อีกด้วย
![แนวทางปฏิบัติแนะนำสำหรับ Lighthouse ในการตรวจสอบการแจ้งว่าไม่เหมาะสม
การใช้ document.write()](https://web.developers.google.cn/static/articles/optimizing-content-efficiency-loading-third-party-javascript/image/lighthouse-best-practices-bc22b2c90d6af.png?authuser=9&hl=th)
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 ที่เข้ามารีวิว