Zaraz ใช้ Workers เพื่อทำให้เครื่องมือของบุคคลที่สามปลอดภัยและรวดเร็ว

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

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

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

ปกติแล้ว เมื่อคุณเพิ่มบุคคลที่สามเข้าไปในเพจของคุณ คุณกำลังเพิ่มโค้ด JavaScript ไปที่ ของ HTML Google Analytics เป็นบุคคลที่สามที่โด่งดังที่สุด ดังนั้นเรามาดูการทำงานของมันกัน

ในกรณีนี้ และอีกหลายๆ กรณีโค้ดสนิปเปตที่คุณวางลงไปนั้นจะเรียกโค้ด JavaScript อื่นที่จะเรียกใช้เพิ่มเติม โค้ดสนิปเปตข้างต้นนี้จะสร้างเอเลเมนต์ ใหม่ เพิ่มแอตทริบิวต์ src เป็น https://www.google-analytics.com/analytics.js และนำมาต่อท้าย DOM แล้วเบราว์เซอร์ก็จะโหลดสคริปต์ analytics.js ซึ่งจะรวมโค้ด JavaScript มากกว่าโค้ดสนิปเปตนั้นเอง และบางครั้งยังบอกให้เบราว์เซอร์ดาวน์โหลดสคริปต์เพิ่มขึ้นอีก บางสคริปต์นั้นมีขนาดใหญ่กว่า analytics.js เสียอีก แต่มาถึงตรงนี้ ไม่มีการเก็บข้อมูลการวิเคราะห์ไว้เลย แม้ว่านี่จะเป็นเหตุผลที่คุณเพิ่ม Google Analytics เข้าไปในตอนแรกก็ตาม

<!-- Google Analytics -->
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
</script>
<!-- End Google Analytics -->

บรรทัดสุดท้ายของโค้ดสนิปเปต ga('send', 'pageview'); ใช้ฟังก์ชันที่ระบุไว้ในไฟล์ analytics.js เพื่อส่ง เพจวิวในที่สุด ฟังก์ชันนี้มีความจำเป็นเพราะเป็นสิ่งที่เก็บข้อมูลการวิเคราะห์ — ดึงข้อมูลเบราว์เซอร์ ความละเอียดหน้าจอ ภาษา และอื่นๆ... จากนั้นก็จะสร้าง URL ที่รวมข้อมูลทุกอย่างไว้ และส่งการร้องขอไปที่ URL นี้ โดยข้อมูลจะถูกเก็บไว้หลังจากขั้นตอนนี้เท่านั้น พฤติกรรมของผู้ใช้ทุกคนที่บันทึกไว้ด้วย Google Analytics จะกลายเป็นการร้องขออีกอันหนึ่ง

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

วงกลมใหญ่สีฟ้านั่นคือแหล่งข้อมูลของเว็บไซต์เรา และวงกลมอื่นๆ คือเครื่องมือของบุคคลที่สาม คุณจะเห็นว่าวงกลมใหญ่สีเขียวเป็นการร้องขอย่อยของ Facebook pixel (fbevents.js) หลัก และมีเครื่องมือใดบ้าง เช่น LinkedIn ด้านบนขวา ที่สร้างการเชื่อมต่อแบบเปลี่ยนเส้นทางเพื่อซิงค์ข้อมูล โดยเบราว์เซอร์ต้องถูกบังคับให้สร้างการร้องขอเครือข่ายที่มากขึ้น

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

การย้ายให้บุคคลที่สามไปใช้งานโค้ดภายนอกเบราว์เซอร์จะมีผลดีมากมาย

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

• ควบคุมข้อมูลที่ส่งให้บุคคลที่สาม เครื่องมือของบุคคลที่สามมักจะเก็บข้อมูลจากเพจและเบราว์เซอร์โดยอัตโนมัติ ตัวอย่างเช่น วัดพฤติกรรม/การใช้งานของไซต์ ในหลายๆ กรณี ข้อมูลเหล่านี้ควรจะเป็นส่วนตัว ตัวอย่างเช่น เครื่องมือหลายอันเก็บข้อมูล document.location แต่เรามักจะเห็นว่าหน้า "รีเซ็ตรหัสผ่าน" ใส่อีเมลของผู้ใช้ไว้ใน URL ซึ่งหมายความว่าอีเมลถูกส่งและบันทึกไว้โดยไม่รู้ตัวจากผู้ให้บริการบุคคลที่สามและโดยไม่ได้รับอนุญาติ การย้ายการใช้งานของบุคคลที่สามไปอยู่บริเวณขอบนอกหมายความว่าเราจะเห็นข้อมูลทุกอย่างที่ถูกส่งไป ซึ่งหมายความว่าเราสามารถแจ้งเตือนหรือคัดกรองได้ในกรณีที่เครื่องมือพยายามจะเก็บข้อมูลที่สามารถระบุถึงตัวบุคคลได้หรือปกปิดข้อมูลส่วนตัวก่อนที่จะส่งไปถึงเซิร์ฟเวอร์ของบุคคลที่สาม คุณลักษณะนี้ยังไม่มีให้บริการในเวอร์ชั่นเบต้าสาธารณะ แต่หากคุณต้องการใช้งานวันนี้ กรุณาติดต่อเรา

• การลดจำนวนโค้ดที่ใช้ในเบราว์เซอร์และการสแกนโค้ดทั้งหมดที่ใช้งานในเบราว์เซอร์จะทำให้เราสามารถยืนยันได้ว่าโค้ดนั้นไม่อันตรายและทำงานตามที่สมควรเท่านั้น เรากำลังพยายามเชื่อมต่อ Zaraz กับ Cloudflare Page Shield เพื่อให้ทำงานโดยอัตโนมัติ

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

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

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

• ใช้งาน JavaScript เครื่องมือบุคคลที่สามทั้งหมดต้องใช้ JavaScript ถ้าเราจะย้ายการใช้งานไปที่คลาวด์ วิธีที่ดีที่สุดคือต้องสามารถใช้งาน JavaScript ได้ด้วย

• ความปอลดภัย เรากำลังจัดการกับข้อมูลที่ละเอียดอ่อน เราจะไม่เสี่ยงให้ใครแฮกเข้ามาใน EC2 ของเรา เราต้องการทำให้แน่ใจว่าข้อมูลจะไม่คงอยู่บนเซิร์ฟเวอร์ หลังจากที่เราส่งการตอบสนอง HTTP ของเราไปแล้ว

• ควบคุมได้เต็มที่ CDNs บางอันอนุญาตให้ตั้งค่ากฎที่ซับซ้อนในการจัดการการร้องขอได้ แต่การเปลี่ยนหัวของ HTTP มีการตั้งค่าโค้ดเปลี่ยนเส้นทางหรือการตอบสนอง HTTP ที่ไม่เพียงพอ เราต้องการสร้างโค้ด JavaScript อย่างรวดเร็ว หมายความว่าเราต้องการควบคุมการตอบสนองได้อย่างเต็มที่ เรายังต้องการใช้ไลบรารี JavaScript จากภายนอกอีกด้วย

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

ในขั้นต้น เราคิดว่าเราต้องสร้างที่เก็บ Docker ที่สามารถใช้งานได้ทั่วโลกและใช้เซิร์ฟเวอร์ HTTP ของตัวเอง แต่เพื่อนของเราจากกลุ่ม Y Combinator บอกให้เราตรวจสอบ Cloudflare Workers

ในตอนแรก เราคิดว่ามันจะใช้ไม่ได้ — Workers ไม่ได้ทำงานแบบแอปพลิเคชัน Node.js และเรารู้สึกว่าข้อจำกัดจะทำให้เราไม่สามารถสร้างสิ่งที่ต้องการได้ เราวางแผนจะให้ Workers จัดการกับการร้องขอจากเบราว์เซอร์ของผู้ใช้ แล้วใช้ AWS Lambda ทำงานหนักในการประมวลผลข้อมูลและส่งไปให้ผู้ให้บริการบุคคลที่สาม

ความพยายามครั้งแรกกับ Workers เป็นไปอย่างเรียบง่าย เพียงแค่ยืนยันว่าเราสามารถใช้งานเพื่อให้ได้ผล JavaScript ฝั่งเบราว์เซอร์แบบไดนามิกที่สร้างขึ้นอย่างรวดเร็ว

นี่เป็นตัวอย่างเล็กๆ แต่ผมจำได้ว่าโทรหา Yair หลังจากนั้นและบอกว่า "มันใช้งานได้จริงๆ!" ซึ่งเป็นข้อพิสูจน์ความยืดหยุ่นของ Workers เราเพียงแค่สร้างปลายทางที่ใช้งานไฟล์ JavaScript ที่สร้างขึ้นแบบไดนามิก และใช้เวลาในการตอบสนองน้อยกว่า 10 มิลลิวินาที เราสามารถวาง < script src="path/to/worker.js" > ไว้ใน HTML ของเราได้และทำเหมือนกับว่า Worker เป็นไฟล์ JavaScript ทั่วไป

addEventListener('fetch', (event) => {
 event.respondWith(handleRequest(event.request))
})
 
async function handleRequest(request) {
   let code = '(function() {'
  
   if (request.headers.get('user-agent').includes('Firefox')) {
     code += `console.log('Hello Firefox!');`
   } else {
     code += `console.log('Hey other browsers...');`
   }
  
   code += '})();'
  
   return new Response(code, {
     headers: { 'content-type': 'text/javascript' }
   });
}

เมื่อเรามองให้ลึกลงไป เราพบว่า Workers ตอบสนองต่อคำสั่งของเรามากมาย และเรียนรู้ว่าเราสามารถทำสิ่งที่ซับซ้อนที่สุดได้ใน Workers ฟังก์ชัน Lambda เริ่มทำงานน้อยลงๆ และถูกลบออกไปในที่สุด การทดสอบความเป็นไปได้ของ Node.js สามารภเปลี่ยนไปเป็น Workers ได้อย่างง่ายดาย

ในระยะเริ่มต้นเราได้ยินคำถามอย่างเช่น "ถ้ามันใช้งานได้จริง ทำไมมันไม่มีมาตั้งนานแล้ว" เรามักจะพูดว่าเมื่อปัญหาเป็นสิ่งที่อยู่มายาวนาน การเข้าถึงการประมวลผลแบบ edge computing จึงเป็นความเป็นไปได้ใหม่ หลังจากนั้น การอัปเดตต่อผู้ลงทุนครั้งแรกของเราหลังจากสร้างโปรแกรมต้นแบบ เราบอกพวกเขาเกี่ยวกับระยะเวลาการตอบสนองที่รวดเร็วอย่างไม่น่าเชื่อ เราได้รับการยกย่องมากมาย — พูดถึง "การยืนอยู่บนไหล่ของยักษ์" Workers ทำงานได้ตามที่เราตั้งไว้ทุกอย่าง การใช้งาน JavaScript และใช้ V8 engine ที่เหมือนกันในเบราว์เซอร์ หมายความว่าเราจะสามารถใช้สภาพแวดล้อมแบบเดียวกันในการย้ายเครื่องมือไปทำงานบนคลาวด์ (และยังช่วยเรื่องการจ้างงานด้วย) และยังเปิดโอกาสความเป็นไปได้ในการใช้งาน WebAssembly สำหรับงานที่เฉพาะเจาะจงได้ในภายหลัง ความจริงที่ว่า Workers เป็นแบบไร้เซิร์ฟเวอร์และไร้สถานะด้วยค่าเริ่มต้น เป็นจุดขายความไว้วางใจของเรา เราบอกลูกค้าว่าเราไม่สามารถรักษาข้อมูลส่วนบุคคลของพวกเขาได้แม้จะว่าเป็นความผิดพลาดก็ตาม และมันก็เป็นความจริง การผสมผสานระหว่าง webpack และ Wrangler หมายความว่าเราสามารถเขียนแอปพลิเคชันได้อย่างเต็มที่ — ด้วยโมดูลและส่วนเสริมภายนอก — เพื่อเปลี่ยนตรรกะของเราทั้ง 100% ไปสู่ Worker และประสิทธิภาพช่วยทำให้เราเอาชนะการสาธิตทั้งหมดได้

ขณะที่เราสร้าง Zaraz แพลตฟอร์ม Workers ก็ก้าวหน้าขึ้น เราจบลงด้วยการใช้ Workers KV ในการเก็บการกำหนดค่าผู้ใช้ และใช้ Durable Objects ในการติดต่อระหว่าง Workers Worker หลักของเรามีการปรับใช้ฝั่งเซิร์ฟเวอร์มากกว่าเครื่องมือของบุคคลที่สามที่โด่งดัง 50 อย่าง แทนที่ JavaScript กว่าเป็นร้อยเป็นพันโค้ดที่ใช้งานแบบดั้งเดิมในเบราว์เซอร์ รายการเติบโตขึ้นเรื่อยๆ เรายังเผยแพร่ SDK ที่อนุญาตให้ผู้ให้บริการบุคคลที่สามสร้างการสนับสนุนเครื่องมือของพวกเขาได้ เป็นครั้งแรกที่พวกเขาจะทำงานในสภาพแวดล้อมที่ปลอดภัย เป็นส่วนตัว และรวดเร็ว

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

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

run({system, utils}) { 
  // The `system` object includes information about the current page, browser, and more 
  const { device, page, cookies } = system
  // The `utils` are a set of functions we found useful across multiple tools
  const { getCookieString, waitUntil } = utils

  // Get the existing cookie content, or create a new UUID instead
  const cookieName = 'visitor-identifier'
  const sessionCookie = cookies[cookieName] || crypto.randomUUID()

  // Build the payload
  const payload = {
    session: sessionCookie,
    ip: device.ip,
    resolution: device.resolution,
    ua: device.userAgent,
    url: page.url.href,
    title: page.title,
  }

  // Construct the URL
  const baseURL = 'https://example.com/collect?'
  const params = new URLSearchParams(payload)
  const finalURL = baseURL + params

  // Send a request to the third-party server from the edge
  waitUntil(fetch(finalURL))
  
  // Save or update the cookie in the browser
  return getCookieString(cookieName, sessionCookie)
}

ในตัวอย่างนี้ เราเริ่มจากการตรวจสอบการมีอยู่ของคุกกี้ที่ระบุเซสชันชื่อ “visitor-identifier” หากมีอยู่เราก็จะอ่านค่าของมัน แต่หากไม่มีเราจะสร้าง UUID ใหม่ให้ โปรดทราบว่าความสามารถของ Workers สามารถเข้าถึงได้ที่นี่ เราใช้ crypto.randomUUID() เหมือนกับที่เราใช้ฟังก์ชันอื่นๆ จากนั้นเราจึงเก็บข้อมูลที่เครื่องมือต้องการ — ตัวแทนผู้ใช้ URL ปัจจุบัน ชื่อเพจ ความละเอียดหน้าจอ IP address ของผู้ใช้ — และเนื้อหาของคุกกี้ “visitor-identifier” เราสร้าง URL สุดท้ายที่ Worker ต้องใช้ในการส่งการร้องขอไป และเราใช้ waitUntil เพื่อทำให้มั่นใจว่าการร้องขอนั้นไปถึงที่หมาย การดึงข้อมูลเวอร์ชันของ Zaraz จะให้ข้อมูลบันทึก การป้องกันข้อมูลสูญหาย และความสามารถในการลองอีกครั้งให้กับเครื่องโดยอัตโนมัติ

ท้ายที่สุด เราคืนค่าฟังก์ชัน getCookieStringสตริงใดก็ตามที่คืนค่าโดยฟังก์ชัน run จะส่งไปยังผู้เยี่ยมชมในฐานะ JavaScript ฝั่งเบราว์เซอร์ ในกรณีนี้ getCookieString จะคืนค่าบางอย่าง เช่น document.cookie = 'visitor-identifier=5006e6fa-7ce6-45ef-8724-c846f1953369; Path=/; Max-age=31536000'; ทำให้เบราว์เซอร์สร้างคุกกี้บุคคลที่หนึ่งขึ้น ครั้งต่อไปที่ผู้ใช้งานโหลดเพจ คุกกี้ visitor-identifierจะปรากฏขึ้น ทำให้ Zaraz ใช้งาน UUID อีกครั้งแทนที่จะสร้างอันใหม่ขึ้น

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

เครื่องมือของบุคคลที่สามหลายอย่างต้องการเก็บข้อมูลพฤติกรรมในช่วงที่ผู้ใช้เข้าเยี่ยมชม ตัวอย่างเช่น คุณอาจต้องวาง conversation pixel ทันทีหลังจากผู้ใช้คลิก "ส่ง" บนฟอร์มบัตรเครดิต เนื่องจากเราย้ายเครื่องมือไปไว้บนคลาวด์ คุณจะไม่สามารถเข้าถึงไลบรารีนั้นได้จากเบราว์เซอร์ เราจึงสร้าง zaraz.track() — แนวทางที่อนุญาตให้คุณเรียกเครื่องมือทางโปรแกรมและเลือกให้ข้อมูลเพิ่มเติมกับเครื่องมือนั้นได้

จากตัวอย่างนี้ เราทำให้ Zaraz ทราบเกี่ยวกับทริกเกอร์ที่ชื่อว่า “card-submission” และเราก็ได้ให้ข้อมูลที่เกี่ยวข้องไปด้วย คุณค่า ของการดำเนินการที่เราได้มาจากส่วนประกอบของ ID ทั้งหมด และรหัสธุรกรรมที่เป็นการเขียนโค้ดไว้แบบตายตัว และพิมพ์ลงบน backend ของเราโดยตรง

document.getElementById("credit-card-form").addEventListener("submit", () => {
  zaraz.track("card-submission", {
    value: document.getElementById("total").innerHTML,
    transaction: "X-98765",
  });
});

ในอินเทอร์เฟซของ Zaraz เครื่องมือกำหนดค่าสามารถติดตามทริกเกอร์ที่แตกต่างและหลากหลายได้ เมื่อโค้ดด้านบนถูกกระตุ้น Zaraz จะทำการตรวจสอบบริเวณขอบนอก ว่าเครื่องมือใดติดตามทริกเกอร์ card-submission และจะให้ข้อมูลเพิ่มเติม และจัดการคำร้องขอด้วยรหัสธุรกรรมและค่านั้น

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

คุณไม่ต้องเป็นนักเขียนโค้ดเพื่อจะใช้งานทริกเกอร์ แดชบอร์ด Zaraz อนุญาตให้คุณเลือกชุดเทมเพลตที่กำหนดไว้แล้ว เช่น การฟังคลิก การเลื่อนหรืออื่นๆ ที่คุณสามารถแนบไว้กับส่วนประกอบของเว็บไซต์โดยไม่ต้องแตะต้องโค้ดของคุณ เมื่อคุณรวม zaraz.track() กับความสามารถในการควบคุมเครื่องมือของคุณเอง สิ่งที่คุณจะได้รับเป็นการผสมผสานสำคัญของ Workers เข้ากับเว็บไซต์ของคุณ คุณสามารถเขียนโค้ด backend ที่ต้องการ และ Zaraz จะมีหน้าที่เรียกมาใช้งานในเวลาและปัจจัยที่เหมาะสม

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

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

หากคุณต้องการทดลองใช้เวอร์ชันเบต้าแบบฟรี กรุณาคลิกที่นี่ หากคุณเป็นองค์กรและมีข้อกำหนดเพิ่มเติม/กำหนดเอง กรุณา คลิกที่นี่ เพื่อเข้าชื่อรอ เข้าร่วมช่อง Discord ของเรา คลิกที่นี่

หารือกันบน Twitter หารือกันบน Hacker News หารือกันบน Reddit

CIO Week Cloudflare Workers

ติดตามบน Twitter

Yo'av Moshe |@yoavmoshe

Cloudflare |Cloudflare