Zaraz use Workers to make third-party tools secure and fast

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

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

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

ทุกวันนี้ เครื่องมือของบุคคลที่สามทำงานยังไง

ปกติแล้ว เมื่อคุณเพิ่มบุคคลที่สามเข้าไปในเพจของคุณ คุณกำลังเพิ่มโค้ด JavaScript ไปที่ <head> ของ HTML 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 -->

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

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

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

a chart showing all the resources fetched when downloading an example website. The map shows how one resource can end up in a chain of other external resources, that are often coming from untrusted servers and responding with very large payloads.

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

สถานที่ใหม่ที่จะใช้ระบบจัดการแท็ก — บริเวณขอบนอก

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

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

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

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

เลือก Cloudflare Workers

ตอนที่เราจัดการกับการเข้ารหัส 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 ฝั่งเบราว์เซอร์แบบไดนามิกที่สร้างขึ้นอย่างรวดเร็ว

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' }
   });
}

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

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

การใช้งานแพลตฟอร์ม Cloudflare 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

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)
}

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

ในตัวอย่างนี้ เราเริ่มจากการตรวจสอบการมีอยู่ของคุกกี้ที่ระบุเซสชันชื่อ “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() — แนวทางที่อนุญาตให้คุณเรียกเครื่องมือทางโปรแกรมและเลือกให้ข้อมูลเพิ่มเติมกับเครื่องมือนั้นได้

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

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

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

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

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

เข้าร่วม Cloudflare

เมื่อมีผู้ใช้ใหม่เริ่มใช้งาน 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