Zaraz menggunakan Workers untuk membuat alat pihak ketiga aman dan cepat

Kami memutuskan untuk membuat Zaraz sekitar akhir Maret 2020. Kami sedang mengerjakan produk lain ketika kami melihat semua orang bertanya kepada kami tentang dampak kinerja ketika memiliki banyak pihak ketiga di situs web mereka. Konten pihak ketiga adalah bagian penting dari sebagian besar situs web saat ini, mendukung analitik, chatbot, piksel konversi, widget — dan sebagainya. Definisi pihak ketiga adalah aset, seringkali JavaScript, yang dihosting di luar hubungan pengguna situs utama, yang tidak berada di bawah kendali langsung pemilik situs tetapi hadir atas dasar 'persetujuan'. Yair menulis secara rinci tentang proses pengukuran dampak alat pihak ketiga ini, dan bagaimana kami memutar startup kami, tetapi saya ingin menulis tentang bagaimana kami membangun Zaraz dan apa yang sebenarnya dilakukan di balik layar.

Pihak ketiga sangat bagus ketika mereka memungkinkan Anda mengintegrasikan solusi yang sudah dibuat dengan situs web Anda, dan Anda hampir tidak perlu melakukan pengkodean apa pun. Analitik? Cukup gunakan cuplikan kode ini. Widget obrolan? Tambahkan saja yang ini. Vendor pihak ketiga biasanya akan menginstruksikan Anda tentang cara menambahkan alat mereka, dan sejak saat itu semuanya seharusnya berfungsi. Benar? Namun saat Anda menambahkan kode pihak ketiga, biasanya kode tersebut mengambil lebih banyak kode dari sumber jarak jauh, yang berarti Anda semakin tidak memiliki kendali atas apa pun yang terjadi di browser pengunjung. Bagaimana Anda dapat menjamin bahwa tidak satu pun dari pihak ketiga yang ada di situs web Anda tidak diretas, dan mulai mencuri informasi, menambang mata uang kripto atau mencatat penekanan tombol di komputer pengunjung Anda?

Hal tersebut bahkan tidak harus menjadi peretasan yang disengaja. Saat kami menyelidiki semakin banyak alat pihak ketiga, kami melihat sebuah pola — terkadang lebih mudah bagi vendor pihak ketiga untuk mengumpulkan semuanya, daripada selektif atau berhati-hati tentang hal itu. Lebih sering daripada tidak, email pengguna akan menemukan jalan mereka ke alat pihak ketiga, yang dapat dengan mudah menempatkan pemilik situs web dalam masalah karena GDPR, CCPA, atau sejenisnya.

Biasanya, saat Anda menambahkan pihak ketiga ke halaman Anda, Anda akan diminta untuk menambahkan sepotong kode JavaScript ke HTML Anda. Google Analytics sejauh ini adalah pihak ketiga yang paling populer, jadi mari kita lihat bagaimana hal itu dilakukan di sana:

Dalam kasus ini, dan di sebagian besar kasus lainnya, cuplikan yang Anda tempel sebenarnya memanggil lebih banyak kode JavaScript untuk dijalankan. Cuplikan di atas membuat elemen baru, memberinya atribut https://www.google-analytics.com/analytics.js src , dan menambahkannya ke DOM. Browser kemudian memuat skrip analytics.js , yang menyertakan lebih banyak kode JavaScript daripada cuplikan itu sendiri, dan terkadang meminta browser untuk mengunduh lebih banyak skrip, beberapa di antaranya lebih besar dari analytics.js itu sendiri. Sejauh ini, bagaimanapun, tidak ada data analitik yang diambil sama sekali, meskipun inilah alasan Anda menambahkan Google Analytics sejak awal.

<!-- 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 -->

Baris terakhir dari cuplikan tersebut, ga('send', 'pageview');, menggunakan fungsi yang ditentukan dalam berkas analytics.js yang pada akhirnya mengirim sebuah pageview. Fungsi ini diperlukan karena fungsi itulah yang menangkap data analitik — fungsi mengambil jenis browser, resolusi layar, bahasa, dll... Kemudian, fungsi membuat URL yang mencakup semua data, dan mengirimkan permintaan ke URL ini. Hanya setelah langkah ini informasi analitik dapat ditangkap. Setiap peristiwa perilaku pengguna yang Anda rekam menggunakan Google Analytics akan menghasilkan permintaan lain.

Kenyataannya adalah bahwa sebagian besar alat terdiri dari lebih dari satu berkas sumber daya, dan sebenarnya tidak mungkin untuk mengetahui sebelumnya alat apa yang akan dimuat tanpa mengujinya di situs web Anda. Anda dapat menggunakan Request Map Generator untuk mendapatkan representasi visual dari semua sumber daya yang dimuat di situs web Anda, termasuk cara mereka memanggil satu sama lain. Berikut adalah Peta Permintaan dari situs web e-niaga demo yang kami buat:

Lingkaran biru besar itu adalah sumber daya situs web kami, dan semua lingkaran lainnya adalah alat pihak ketiga. Anda dapat melihat bagaimana lingkaran hijau besar sebenarnya adalah sub-permintaan dari piksel Facebook utama (fbevents.js), dan berapa banyak alat, seperti LinkedIn di kanan atas, yang membuat rantai pengalihan untuk menyinkronkan beberapa data, dengan mengorbankan browser untuk membuat lebih banyak permintaan jaringan.

Karena kami ingin membuat pihak ketiga lebih cepat, lebih aman, dan privat, kami harus mengembangkan cara berpikir baru yang mendasar tentang mereka dan sistem baru untuk menjalankannya. Kami hadir dengan sebuah rencana: membangun platform di mana pihak ketiga dapat menjalankan kode di luar browser, sambil tetap mendapatkan akses ke informasi yang mereka butuhkan dan dapat berbicara dengan DOM bila diperlukan. Kami tidak percaya bahwa pihak ketiga itu jahat: mereka tidak pernah bermaksud memperlambat Internet semua orang, mereka tidak punya pilihan lain. Mampu menjalankan kode di edge dan menjalankannya dengan cepat akan membuka kemungkinan baru dan mengubah semua itu, tetapi transisinya sulit.

Dengan memindahkan kode pihak ketiga untuk dijalankan di luar browser, kami mendapatkan banyak keberhasilan.

• Situs web akan memuat lebih cepat dan lebih interaktif. Browser yang merender situs web Anda sekarang dapat fokus pada hal terpenting — situs web Anda. Pengunduhan, penguraian, dan eksekusi semua skrip pihak ketiga tidak akan lagi bersaing atau bahkan memblokir rendering dan interaktivitas situs web Anda.

• Kontrol atas data yang dikirim ke pihak ketiga. Alat pihak ketiga sering kali secara otomatis mengumpulkan informasi dari halaman dan dari browser untuk, misalnya, mengukur perilaku/penggunaan situs. Dalam banyak kasus informasi ini harus tetap bersifat privat. Misalnya, sebagian besar alat mengumpulkan document.location, tetapi kami sering melihat halaman "setel ulang kata sandi" termasuk email pengguna di URL, yang berarti email tanpa diketahui dikirim dan disimpan oleh penyedia pihak ketiga, biasanya tanpa persetujuan. Memindahkan eksekusi pihak ketiga ke edge berarti kami memiliki visibilitas penuh terhadap apa yang sedang dikirim. Artinya kami dapat memberikan peringatan dan filter jika alat mencoba mengumpulkan Informasi Identitas Pribadi atau menutupi bagian pribadi data sebelum mencapai server pihak ketiga. Sekarang, fitur ini tidak tersedia dalam versi beta publik, tetapi hubungi kami jika Anda ingin mulai menggunakannya hari ini.

• Dengan mengurangi jumlah kode yang dieksekusi di browser dan dengan memindai semua kode yang dieksekusi di dalamnya, kami dapat terus memverifikasi bahwa kode tersebut tidak dirusak dan hanya melakukan apa yang dimaksudkan untuk dilakukan. Kami sedang bekerja untuk menghubungkan Zaraz dengan Cloudflare Page Shield untuk melakukan ini secara otomatis.

Saat Anda mengonfigurasikan alat pihak ketiga melalui pengelola tag biasa, banyak hal yang terjadi di browser pengunjung yang berada di luar kendali Anda. Pengelola tag akan memuat lalu mengevaluasi semua aturan pemicu untuk memutuskan alat mana yang akan dimuat. Kemudian pengelola tag biasanya akan menambahkan tag skrip dari alat tersebut ke DOM halaman, membuat browser mengambil skrip dan menjalankannya. Skrip ini berasal dari sumber yang tidak tepercaya atau tidak diketahui, sehingga meningkatkan risiko eksekusi kode berbahaya di browser. Mereka juga dapat memblokir browser agar tidak interaktif hingga dijalankan sepenuhnya. Mereka umumnya bebas melakukan apa pun yang mereka inginkan di browser, tetapi biasanya mereka kemudian akan mengumpulkan beberapa informasi dan mengirimkannya ke beberapa titik akhir di server pihak ketiga. Dengan Zaraz, browser pada dasarnya tidak melakukan semua itu.

Saat kami mulai mengodekan Zaraz, kami secepatnya memahami bahwa keputusan infrastruktur kami akan berdampak besar pada layanan kami. Bahkan, jika salah pilih, kami bisa tidak memiliki layanan sama sekali. Alternatif paling umum untuk Zaraz adalah perangkat lunak Manajemen Tag tradisional. Mereka umumnya tidak memiliki komponen dari sisi server: setiap kali pengguna "memublikasikan" konfigurasi, berkas JavaScript dirender dan dihosting sebagai aset statis pada CDN. Dengan Zaraz, ide tersebut memindahkan sebagian besar evaluasi kode dari browser, dan merespons dengan kode JavaScript yang dibuat secara dinamis setiap waktu. Kami perlu menemukan solusi yang memungkinkan kami memiliki komponen dari sisi server, tetapi bisa secepat CDN. Jika tidak, kemungkinan muncul risiko yang akan memperlambat situs web dan bukan membuatnya lebih cepat.

Kami membutuhkan Zaraz untuk dapat digunakan dari tempat yang dekat dengan pengguna yang berkunjung. Karena menyiapkan server di seluruh dunia tampak seperti tugas yang terlalu besar untuk startup yang masih sangat muda, kami melihat beberapa platform tanpa server terdistribusi. Kami melakukan pencarian ini dengan daftar kecil persyaratan:

• Jalankan JavaScript: Semua alat pihak ketiga menggunakan JavaScript. Jika kita memasangnya untuk dijalankan di lingkungan cloud, cara termudah untuk melakukannya adalah dengan menggunakan JavaScript juga.

• Aman: Kami sedang memproses data sensitif. Kami tidak dapat menanggung risiko karena seseorang meretas instans EC2 kami. Kami ingin memastikan bahwa data tidak selalu berada di beberapa server setelah kami mengirim respons HTTP kami.

• Dapat diprogram sepenuhnya: Beberapa CDN mengizinkan pengaturan yang rumit untuk menangani permintaan, tetapi mengubah HTTP header, mengatur pengalihan, atau kode respons HTTP tidak cukup. Kita perlu membuat kode JavaScript dengan cepat, artinya kita membutuhkan kontrol penuh atas tanggapan. Kita juga perlu menggunakan beberapa pustaka JavaScript eksternal.

• Sangat cepat dan terdistribusi secara global: Pada tahap awal perusahaan, kami telah memiliki pelanggan di AS, Eropa, India, dan Israel. Saat kami bersiap untuk menunjukkan Bukti Konsep kepada mereka, kami harus memastikan bahwa Bukti Konsep akan cepat di mana pun mereka berada. Kami bersaing dengan pengelola tag dan Platform Data Pelanggan yang memiliki waktu respons yang cukup cepat, jadi kami harus dapat merespons secepat jika konten kami dihosting secara statis di CDN, atau lebih cepat.

Awalnya kami pikir perlu membuat wadah Docker yang akan berjalan di seluruh dunia dan akan menggunakan server HTTP mereka sendiri, tetapi kemudian seorang teman dari kumpulan Y Combinator kami mengatakan bahwa kami harus memeriksa Cloudflare Worker.

Pada awalnya, kami pikir hal itu tidak akan berhasil — Workers tidak berfungsi seperti aplikasi Node.js, dan kami merasa bahwa batasan akan mencegah kami membangun apa yang kami inginkan. Kami berencana untuk membiarkan Workers menangani permintaan yang datang dari browser pengguna, dan kemudian menggunakan AWS Lambda untuk pekerjaan berat yang sebenarnya memproses data dan mengirimkannya ke vendor pihak ketiga.

Upaya pertama kami dengan Workers sangat sederhana: hanya mengonfirmasi bahwa kami dapat menggunakannya untuk benar-benar mengembalikan JavaScript dari sisi browser dinamis yang dihasilkan dengan cepat:

Itu adalah contoh kecil, tetapi saya ingat menelepon Yair setelah itu dan mengatakan "ini benar-benar bisa berhasil!". Hal itu membuktikan fleksibilitas Workers. Kami baru saja membuat titik akhir yang menyajikan berkas JavaScript, berkas JavaScript ini dibuat secara dinamis, dan waktu responsnya kurang dari 10 md. Sekarang kita dapat menempatkan <script src="path/to/worker.js"> dalam HTML kami dan memperlakukan Worker ini seperti berkas JavaScript biasa.

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

Saat melihat lebih dalam, kami menemukan Workers dapat menjawab permintaan demi permintaan dari daftar kami, dan menemukan bahwa kami dapat melakukan hal paling rumit dalam Workers. Fungsi Lambda tidak terlalu banyak bekerja, dan pada akhirnya dihilangkan. Bukti konsep Node.js kecil kami dengan mudah dikonversi menjadi Workers.

Saat kami mengadakan investasi awal, banyak pertanyaan muncul, seperti "jika ini berhasil, mengapa tidak ada yang membuat sebelumnya?" Kami sering berkata bahwa masalah tersebut sudah sejak lama ada, komputasi tepi yang mudah diakses adalah kemungkinan yang masih baru. Kemudian, pada salah satu pembaruan investor pertama kami, setelah prototipe dibuat, kami memberi tahu mereka tentang waktu respons yang luar biasa cepat yang berhasil dicapai dan kami pun menuai pujian — ini sungguh definisi "berdiri di atas pundak raksasa." Workers dengan mudah memenuhi kebutuhan kami. Menjalankan JavaScript dan menggunakan mesin V8 yang sama dengan browser dan berarti kami dapat menjaga lingkungan yang sama saat menyambungkan alat untuk menjalankannya di cloud (ini juga membantu perekrutan). Ini juga membuka kemungkinan untuk kemudian menggunakan WebAssembly dalam tugas tertentu. Karena Workers dirancang tanpa server dan tanpa format fisik dari awal, kami yakin hal tersebut dapat menjadi faktor yang menjual: kami memberi tahu pelanggan bahwa kami tidak dapat menyimpan personal data mereka secara tidak sengaja, dan ini benar adanya. Integrasi dengan webpack dan Wrangler menunjukkan bahwa kami dapat menulis aplikasi penuh — dengan modul dan dependensi eksternal — untuk mengalihkan logika kami sepenuhnya ke Worker kami. Dan kinerjanya membantu kami menciptakan demo yang mengesankan.

Dan seiring kami membangun Zaraz, platform Workers menjadi lebih berkembang. Kami akhirnya menggunakan Workers KV untuk menyimpan konfigurasi pengguna dan Durable Objects untuk berkomunikasi antar Workers. Workers utama kami menyimpan implementasi dari sisi server lebih dari 50 alat pihak ketiga populer, menggantikan ratusan ribu baris kode JavaScript yang umumnya berjalan dalam browser. Daftar ini terus berkembang dan kami juga baru saja menerbitkan SDK yang membuat vendor pihak ketiga dapat membangun sendiri dukungan untuk alat mereka. Untuk pertama kalinya, mereka dapat melakukan ini dalam lingkungan yang aman, privat, dan cepat.

Kebanyakan alat pihak ketiga memiliki dua hal mendasar: Pertama, mereka mengumpulkan informasi dari browser seperti resolusi layar, URL saat ini, judul halaman, atau konten cookie. Kedua, mereka mengirimnya ke server. Ini biasanya sederhana, tetapi saat situs web memiliki puluhan alat semacam ini, dan masing-masing membuat kueri untuk informasi yang diperlukan dan mengirimkan permintaannya, perlambatan sering kali terjadi. Di Zaraz, hal ini terjadi dengan cara yang berbeda: Setiap alat memiliki fungsi run dan saat Zaraz mengevaluasi permintaan pengguna dan memutuskan untuk memuat alat, Zaraz akan memulai fungsi run. Dengan cara ini, kami membuat integrasi untuk lebih dari 50 alat yang berbeda, semuanya dari kategori yang berbeda, dan inilah cara kami mengundang vendor pihak ketiga untuk menulis integrasi mereka sendiri ke Zaraz.

Kode di atas berjalan di Cloudflare Workers kami, bukan di browser. Sebelumnya, memiliki 10x lebih banyak alat berarti ada 10x lebih banyak permintaan rendering browser yang harus dibuat untuk situs web Anda dan 10x lebih banyak kode JavaScript yang perlu dievaluasi. Kode ini sering kali repetitif, misalnya, hampir semua alat menerapkan fungsi "ambil cookie" mereka sendiri. Ini juga berarti 10x lebih banyak sumber yang harus Anda pastikan bebas dari manipulasi. Saat menjalankan alat di edge, hal ini tidak memengaruhi browser sama sekali: Anda dapat menambahkan sebanyak mungkin alat yang diinginkan, tetapi alat tidak akan dimuat dan berpengaruh pada browser.

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

Dalam contoh ini, kami terlebih dahulu memeriksa adanya cookie yang mengidentifikasi sesi, yang disebut "visitor-identifier". Jika ada, kami akan mengidentifikasi nilainya; jika tidak, kami akan membuat UUID baru untuk cookie ini. Perhatikan bahwa semua fungsi Workers dapat diakses di sini: kami menggunakan crypto.randomUUID() seperti halnya kami dapat menggunakan fungsi Workers lainnya. Kami lalu mengumpulkan semua informasi yang dibutuhkan alat contoh kami — agen pengguna, URL saat ini, halaman judul, resolusi layar, alamat IP klien — dan konten cookie “visitor-identifier”. Kami membuat URL akhir yang dibutuhkan Worker untuk mengirim permintaan, lalu menggunakan waitUntil untuk memastikan permintaan terkirim ke sana. Versi pengambilan Zaraz memberikan pencatatan otomatis, pencegahan kehilangan data, dan kapabilitas pengulangan untuk alat kami.

Terakhir, kami mengembalikan nilai fungsi getCookieString. String apa pun yang dikembalikan oleh fungsi run akan diteruskan kepada pengunjung sebagai JavaScript dari sisi browser. Dalam hal ini, getCookieString mengembalikan data semacam ini, document.cookie = 'visitor-identifier=5006e6fa-7ce6-45ef-8724-c846f1953369; Path=/; Max-age=31536000';, agar browser membuat cookie pihak pertama. Berikutnya pengguna memuat halaman, cookie visitor-identifier sudah ada dan Zaraz akan menggunakan kembali UUID tanpa membuat yang baru.

Sistem fungsi run ini memungkinkan kami untuk dapat memisahkan dan mengisolasi setiap alat agar menjalankannya secara terpisah dari sistem, sembari tetap menyediakannya dengan semua konteks dan data yang diperlukan dari browser, dan kapabilitas Workers. Kami mengundang vendor pihak ketiga untuk bekerja dan membangun masa depan dengan alat pihak ketiga yang aman, privat, dan cepat.

Banyak alat pihak ketiga yang harus mengumpulkan informasi perilaku selama kunjungan pengguna. Misalnya, Anda ingin menempatkan piksel percakapan langsung setelah pengguna mengeklik "kirim" pada formulir kartu kredit. Karena kami memindahkan alat ke cloud, Anda tidak lagi dapat mengakses perpustakaan dari konteks browser. Karena itu, kami membuat zaraz.track() — metode yang membuat Anda dapat memanggil alat secara terprogram, dan secara opsional menyediakan lebih banyak informasi:

Dalam contoh ini, kami memberi tahu Zaraz tentang pemicu bernama “card-submission”, dan kami mengaitkan beberapa data dengannya — nilai transaksi yang kami ambil dari elemen dengan ID total, dan kode transaksi yang hardcoded dan dicetak secara langsung dari backend kami.

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

Pada antarmuka Zaraz, alat yang dikonfigurasi dapat didaftarkan dengan beberapa pemicu yang berbeda. Saat kode di atas dipicu, Zaraz memeriksa alat yang didaftarkan dengan pemicu card-submission dari edge dan memanggilnya dengan data tambahan yang dipasok dengan benar, guna mengisi kode transaksi dan nilai yang benar ke permintaan.

Ini berbeda dengan cara kerja pengelola tag tradisional: dataLayer.push GTM yang memiliki fungsi serupa, tetapi dievaluasi dari sisi klien. Hasilnya adalah, GTM, saat digunakan secara intensif, akan mengembangkan skripnya dan menjadi alat terberat yang harus dimuat situs web. Setiap peristiwa yang menggunakan dataLayer.push akan menyebabkan evaluasi berulang pada kode di browser dan setiap alat yang cocok dengan evaluasi akan menjalankan kode di browser, dan mungkin dapat memanggil lebih banyak aset eksternal. Karena peristiwa ini biasanya berlangsung dengan interaksi pengguna, hal tersebut sering kali membuat interaksi pengguna dengan situs web terasa lambat, karena menjalankan alat akan memakan sumber daya thread utama. Dengan Zaraz, alat ini ada dan hanya dievaluasi di edge, meningkatkan kecepatan dan keamanan situs web.

Anda tidak harus menjadi pengode untuk menggunakan pemicu. Dasbor Zaraz membuat Anda dapat memilih dari rangkaian templat, seperti pengamat klik, peristiwa gulir, dan lainnya, yang dapat Anda pasangkan ke elemen apa pun pada situs web Anda tanpa menyentuh kode Anda. Saat Anda memadukan zaraz.track() dengan kemampuan untuk memprogram alat Anda sendiri, Anda pada intinya akan mendapatkan satu baris integrasi Workers ke situs web Anda. Anda dapat menulis kode backend yang Anda inginkan dan Zaraz akan menangani pemanggilannya pada saat yang tepat dengan parameter yang tepat.

Saat pelanggan baru mulai menggunakan Zaraz, kami melihat sebuah pola: tim terbaik yang bekerja dengan kami memilih Cloudflare, dan beberapa tim juga memindahkan bagian infrastruktur backend mereka ke Workers. Kami merasa dapat lebih jauh meningkatkan kinerja dan integrasinya untuk perusahaan yang juga menggunakan Cloudflare. Kami dapat menyisipkan bagian kode ke dalam halaman dan lebih jauh mengurangi jumlah permintaan jaringan. Integrasi juga memungkinkan kami untuk menghapus waktu yang dibutuhkan bagi DNS untuk mengartikan skrip kami, karena kami dapat menggunakan Workers sebagai proxy untuk Zaraz ke dalam domain pelanggan kami. Berintegrasi dengan Cloudflare membuat penawaran kami jauh lebih menarik.

Saat kami masih menggunakan Y Combinator pada musim dingin 2020 dan menyadari berapa banyak pihak ketiga dapat memengaruhi kinerja situs web, kami melihat misi besar di hadapan kami: menciptakan web yang lebih cepat, privat, dan aman dengan mengurangi jumlah beban pihak ketiga. Misi ini tidak berubah hingga sekarang. Seiring diskusi kami dengan Cloudflare berlanjut, kami sangat senang karena kami berbicara dengan orang-orang yang mengemban visi yang sama. Kami tidak sabar mewujudkan peluang untuk memperluas solusi kami bagi jutaan situs web di internet, dan membuat mereka lebih cepat dan aman, serta mengurangi emisi karbon.

Jika Anda ingin menjelajahi versi beta gratis, klik di sini. Jika Anda adalah perusahaan dan memiliki persyaratan tambahan/khusus, klik di sini untuk bergabung ke daftar tunggu. Untuk bergabung ke saluran Discord kami, klik di sini.