หากเพิ่มประสิทธิภาพโค้ดแล้ว แต่เว็บไซต์ยังคงโหลดช้าเกินไป แสดงว่าอาจเป็นเพราะสคริปต์ของบุคคลที่สาม
สคริปต์ของบุคคลที่สามมีฟีเจอร์ที่มีประโยชน์มากมายซึ่งทำให้เว็บมีความไดนามิก อินเทอร์แอกทีฟ และเชื่อมโยงกันมากขึ้น บางรายการอาจมีความสำคัญต่อฟังก์ชันการทำงานหรือแหล่งรายได้ของเว็บไซต์ แต่การใช้แอปเหล่านี้มีความเสี่ยงดังนี้
- เนื่องจากอาจทำให้ประสิทธิภาพของเว็บไซต์ช้าลง
- ซึ่งอาจก่อให้เกิดปัญหาด้านความเป็นส่วนตัวหรือความปลอดภัย
- ข้อมูลเหล่านี้อาจคาดเดาไม่ได้ และลักษณะการทํางานอาจก่อให้เกิดผลลัพธ์ที่ไม่ตั้งใจ
คุณควรตรวจสอบว่าสคริปต์ของบุคคลที่สามไม่ส่งผลต่อเส้นทางการแสดงผลที่สําคัญของเว็บไซต์ ในคู่มือนี้ เราจะอธิบายวิธีค้นหาและแก้ไขปัญหาที่เกี่ยวข้องกับการโหลด 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 ช่วยระบุปัญหาเกี่ยวกับประสิทธิภาพของหน้าเว็บ
- คลิกบันทึก
- โหลดหน้าเว็บ เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์จะแสดงแผนภาพ Waterfall ที่แสดงวิธีที่เว็บไซต์ใช้เวลาในการโหลด
- ไปที่จากล่างขึ้นบนที่ด้านล่างของแผงประสิทธิภาพ
- คลิกจัดกลุ่มตามผลิตภัณฑ์ แล้วจัดเรียงสคริปต์ของบุคคลที่สามในหน้าเว็บตามเวลาในการโหลด
ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เพื่อวิเคราะห์ประสิทธิภาพการโหลดหน้าเว็บได้ที่หัวข้อเริ่มต้นใช้งานการวิเคราะห์ประสิทธิภาพรันไทม์
เวิร์กโฟลว์ที่แนะนําในการวัดผลสคริปต์ของบุคคลที่สามมีดังนี้
- ใช้แผงเครือข่ายเพื่อวัดระยะเวลาในการโหลดหน้าเว็บ
- เราขอแนะนำให้เปิดการจำกัดแบนด์วิดท์ของเครือข่ายและการจำกัด CPU เพื่อจำลองสถานการณ์จริง ผู้ใช้ของคุณมีแนวโน้มที่จะใช้การเชื่อมต่อเครือข่ายที่รวดเร็วและฮาร์ดแวร์เดสก์ท็อปที่ช่วยลดผลกระทบของสคริปต์ราคาแพงภายใต้เงื่อนไขในห้องทดลอง
- บล็อก URL หรือโดเมนที่รับผิดชอบสคริปต์ของบุคคลที่สามที่คุณเชื่อว่าเป็นปัญหา (ดูคำแนะนำในการระบุสคริปต์ที่มีค่าใช้จ่ายสูงได้ในแผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome)
- โหลดหน้าเว็บซ้ำและวัดเวลาในการโหลดอีกครั้ง
- คุณอาจต้องวัดเวลาในการโหลดอย่างน้อย 3 ครั้งเพื่อให้ได้ข้อมูลที่แม่นยำมากขึ้น กรณีนี้เกิดขึ้นเมื่อสคริปต์ของบุคคลที่สามบางรายการดึงข้อมูลแหล่งข้อมูลที่แตกต่างกันเมื่อมีการโหลดหน้าเว็บแต่ละครั้ง แผงประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์รองรับการบันทึกหลายรายการเพื่อช่วยแก้ปัญหานี้
วัดผลของสคริปต์ของบุคคลที่สามด้วย WebPageTest
WebPageTest รองรับการบล็อกคำขอแต่ละรายการไม่ให้โหลดเพื่อวัดผลลัพธ์ในการตั้งค่าขั้นสูง > บล็อก ใช้ฟีเจอร์นี้เพื่อระบุรายการโดเมนที่จะบล็อก เช่น โดเมนโฆษณา
เราขอแนะนําเวิร์กโฟลว์ต่อไปนี้ในการใช้ฟีเจอร์นี้
- ทดสอบหน้าเว็บโดยไม่บล็อกบุคคลที่สาม
- ทําการทดสอบซ้ำโดยบล็อกบุคคลที่สามบางราย
- เลือก 2 รายการจากประวัติการทดสอบ
- คลิกเปรียบเทียบ
รูปภาพต่อไปนี้แสดงฟีเจอร์แถบสไลด์ของ 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 ที่ช่วยตรวจสอบ