Hosting sendiri sumber daya pihak ketiga: baik, buruk, jahat

Dalam beberapa tahun terakhir, semakin banyak platform untuk mengoptimalkan proyek front-end menawarkan peluang untuk hosting independen atau proksi sumber daya pihak ketiga. Akamai memungkinkan Anda untuk mengatur parameter khusus untuk URL yang dibuat sendiri. Cloudflare memiliki teknologi Edge Workers. Fasterzine dapat menulis ulang URL pada halaman sehingga mengarah ke sumber pihak ketiga yang terletak di domain utama situs.



Jika Anda tahu bahwa layanan pihak ketiga yang digunakan dalam proyek Anda tidak terlalu sering berubah, dan bahwa proses pengiriman mereka kepada pelanggan dapat ditingkatkan, maka Anda mungkin berpikir tentang membuat proxy layanan tersebut. Dengan pendekatan ini, Anda dapat "membawa" sumber daya ini lebih dekat ke pengguna dan mendapatkan kontrol lebih besar atas caching mereka di sisi klien. Ini, di samping itu, memungkinkan Anda untuk melindungi pengguna dari masalah yang disebabkan oleh "jatuhnya" layanan pihak ketiga atau penurunan kinerjanya.

Bagus: peningkatan produktivitas

Hosting sendiri sumber daya orang lain meningkatkan kinerja dengan cara yang sangat jelas. Browser tidak perlu mengakses DNS lagi, tidak perlu membuat koneksi TCP dan melakukan jabat tangan TLS pada domain pihak ketiga. Bagaimana hosting independen terhadap sumber daya orang lain memengaruhi kinerja dapat dilihat dengan membandingkan dua angka berikut.


Sumber daya pihak ketiga diunduh dari sumber eksternal (diambil dari sini )


Sumber daya pihak ketiga disimpan di tempat yang sama dengan sisa bahan situs (diambil dari sini )

Situasi ini juga ditingkatkan oleh fakta bahwa browser akan menggunakan kemampuan multiplexing dan memprioritaskan data koneksi HTTP / 2, yang sudah ditetapkan dengan domain utama.

Jika Anda tidak meng-host sumber daya pihak ketiga, maka, karena mereka akan diunduh dari domain selain yang utama, mereka tidak dapat diprioritaskan. Ini akan membuat mereka saling bersaing untuk mendapatkan bandwidth klien. Hal ini dapat mengarah pada fakta bahwa waktu pemuatan material yang penting untuk pembentukan halaman akan jauh lebih lama daripada waktu yang dapat dicapai dalam kondisi keadaan ideal. Berikut ini adalah pembicaraan tentang prioritas HTTP / 2 yang menjelaskan semua ini dengan sangat baik.

Dapat diasumsikan bahwa penggunaan atribut preconnect dalam tautan ke sumber daya eksternal akan membantu dalam menyelesaikan masalah. Namun, jika ada terlalu banyak tautan ke berbagai domain, ini dapat, pada kenyataannya, membebani jalur komunikasi pada saat yang paling penting.

Jika Anda meng-host sumber daya pihak ketiga sendiri, Anda dapat mengontrol bagaimana sumber daya ini diberikan kepada klien. Yaitu, kita berbicara tentang hal berikut:

• Anda dapat memastikan bahwa algoritma kompresi data yang paling cocok untuk setiap browser (Brotli / gzip) diterapkan.
• Anda dapat meningkatkan waktu caching sumber daya, yang biasanya tidak terlalu besar bahkan untuk penyedia paling terkenal (misalnya, nilai yang sesuai untuk tag GA diatur ke 30 menit).

Anda bahkan dapat memperpanjang TTL untuk sumber daya, misalnya, hingga satu tahun dengan memasukkan bahan yang sesuai dalam strategi manajemen caching Anda (hash URL, versi, dan sebagainya). Kami akan membicarakan ini di bawah ini.

▍ Perlindungan terhadap gangguan dalam pengoperasian layanan pihak ketiga atau dari terputusnya mereka

Aspek lain yang menarik dari hosting independen dari sumber daya pihak ketiga adalah bahwa ini memungkinkan Anda untuk mengurangi risiko yang terkait dengan gangguan dalam pengoperasian layanan pihak ketiga. Misalkan solusi pihak ketiga Anda untuk pengujian A / B diimplementasikan sebagai skrip pemblokiran yang dimuat di bagian header halaman. Script ini dimuat dengan lambat. Jika skrip yang sesuai gagal dimuat, halaman akan kosong. Jika butuh banyak waktu untuk memuatnya, halaman akan muncul dengan penundaan lama. Atau, misalkan proyek menggunakan perpustakaan yang dimuat dari sumber daya CDN pihak ketiga. Bayangkan bahwa sumber daya ini mogok atau diblokir di negara tertentu. Situasi seperti itu akan menyebabkan pelanggaran terhadap logika situs.

Untuk mengetahui cara kerja situs Anda dalam kondisi tidak dapat diaksesnya beberapa layanan eksternal, Anda dapat menggunakan bagian SPOF di webpagetest.org .


Bagian SPOF di webpagetest.org

▍ Bagaimana dengan masalah caching dengan browser? (petunjuk: ini adalah mitos)

Anda mungkin berpikir bahwa menggunakan CDN yang tersedia untuk umum akan secara otomatis menghasilkan kinerja sumber daya yang lebih baik, karena layanan ini memiliki jaringan yang cukup baik dan didistribusikan di seluruh dunia. Tetapi semuanya, pada kenyataannya, sedikit lebih rumit.

Misalkan kita memiliki beberapa situs berbeda: website1.com, website2.com, website3.com. Semua situs ini menggunakan perpustakaan jQuery. Kami menghubungkannya dengan mereka menggunakan CDN, misalnya googleapis.com. Anda dapat mengharapkan browser untuk mengunduh dan cache perpustakaan sekali, dan kemudian menggunakannya saat bekerja dengan ketiga situs. Ini bisa mengurangi beban pada jaringan. Mungkin ini akan menghemat uang di suatu tempat dan membantu meningkatkan produktivitas sumber daya. Dari sudut pandang praktis, semuanya terlihat berbeda. Misalnya, Safari mengimplementasikan fitur yang disebut Intelligent Tracking Prevention : cache menggunakan kunci ganda berdasarkan sumber dokumen dan sumber daya pihak ketiga. Inilah artikel bagus tentang topik ini.

Penelitian Yahoo dan Facebook lama , serta penelitian yang lebih baru oleh Paul Calvano, menunjukkan bahwa sumber daya tidak disimpan dalam cache peramban selama yang kita duga: “Ada kesenjangan serius antara waktu caching sumber daya proyek kami sendiri dan pihak ketiga. Ini tentang CSS dan font web. Yaitu, jangka waktu caching dari 95% dari font mereka sendiri melebihi seminggu, sedangkan jangka waktu caching dari 50% dari font pihak ketiga kurang dari seminggu! Ini memberi pengembang web alasan yang bagus untuk meng-host file font sendiri! ”

Akibatnya, jika Anda meng-host materi orang lain, Anda tidak akan melihat masalah kinerja yang disebabkan oleh caching browser.

Sekarang kita telah memeriksa kekuatan sumber daya pihak ketiga yang dapat hosting sendiri, mari kita bicara tentang bagaimana membedakan implementasi yang baik dari pendekatan ini dari yang buruk.

Buruk: iblis ada di detail

Memindahkan sumber daya pihak ketiga ke domain Anda sendiri tidak dapat dilakukan secara otomatis tanpa menjaga caching sumber daya tersebut dengan benar.

Salah satu masalah utama di sini adalah waktu caching. Sebagai contoh, informasi versi termasuk dalam nama skrip pihak ketiga seperti ini: jquery-3.4.1.js . File seperti itu tidak akan berubah di masa depan, sebagai akibatnya, itu tidak akan menyebabkan masalah dengan cachingnya.

Tetapi jika skema versi tertentu tidak diterapkan ketika bekerja dengan file, skrip cache, konten yang berubah ketika nama file tidak berubah, mungkin menjadi usang. Ini bisa menjadi masalah serius, karena, misalnya, itu tidak memungkinkan secara otomatis memperkenalkan perbaikan keamanan ke dalam skrip yang harus diterima klien sesegera mungkin. Pengembang harus berupaya memperbarui skrip tersebut dalam cache. Selain itu, ini dapat menyebabkan aplikasi crash karena fakta bahwa kode yang digunakan pada klien dari cache berbeda dari versi terbaru dari kode yang merupakan bagian server dari proyek yang dirancang.

Benar, jika kita berbicara tentang materi yang sering diperbarui (manajer tag, solusi untuk pengujian A / B), maka caching mereka menggunakan CDN adalah tugas yang dapat diselesaikan, tetapi itu sudah jauh lebih rumit. Layanan seperti Commanders Act, solusi manajemen tag, menggunakan kait web untuk menerbitkan versi baru. Ini memungkinkan untuk mengatur pembilasan cache pada CDN, atau, bahkan lebih baik, kemampuan untuk memanggil pembaruan hash atau versi URL.

▍ Pengiriman bahan yang adaptif kepada pelanggan

Selain itu, ketika kita berbicara tentang caching, kita juga harus memperhitungkan fakta bahwa pengaturan caching yang digunakan pada CDN mungkin tidak cocok untuk beberapa sumber daya pihak ketiga. Sebagai contoh, sumber daya tersebut dapat menggunakan teknologi menghirup agen pengguna, penyajian adaptif, untuk menyediakan versi materi yang dioptimalkan untuk browser tertentu untuk browser ini. Teknologi ini, untuk mengetahui kemampuan browser, bergantung pada ekspresi reguler, atau pada database yang mengumpulkan informasi tentang header HTTP User-Agent . Setelah mengetahui peramban mana yang mereka hadapi, mereka memberikan materi yang dirancang untuk itu.

Di sini Anda dapat memanggil kembali dua layanan. Yang pertama adalah googlefonts.com. Yang kedua adalah polyfill.io. Layanan Google Font menyediakan, untuk beberapa sumber daya, berbagai kode-CSS tergantung pada kemampuan peramban (memberikan tautan ke sumber daya woff2 menggunakan unicode-range ).

Berikut adalah hasil dari beberapa permintaan Google Font yang dibuat dari berbagai browser.


Hasil Kueri Huruf Chrome


Hasil permintaan Google Fonts dibuat dari IE10

Polyfill.io memberikan browser hanya polyfill yang dibutuhkannya. Ini dilakukan karena alasan kinerja.

Misalnya, lihat apa yang terjadi jika Anda menjalankan permintaan berikut dari browser yang berbeda: https://polyfill.io/v3/polyfill.js?features=default

Menanggapi permintaan yang dibuat dari IE10, 34 Kb data akan datang. Dan jawabannya, dibuat dari Chrome, akan kosong.

Marah: beberapa pertimbangan privasi

Item ini terakhir dalam urutan, tetapi tidak penting. Intinya adalah hosting independen dari sumber daya pihak ketiga pada domain utama proyek atau pada subdomainnya dapat membahayakan privasi pengguna dan mempengaruhi proyek web utama.

Jika sistem CDN Anda tidak dikonfigurasikan dengan benar, mungkin berakhir mengirimkan cookie dari domain Anda ke layanan pihak ketiga. Jika pemfilteran yang tepat tidak diatur pada tingkat CDN, maka cookie sesi Anda, yang dalam kondisi normal tidak dapat digunakan dalam JavaScript (dengan atribut httponly ), dapat dikirim ke host asing.

Inilah yang bisa terjadi dengan pelacak seperti Eulerian atau Criteo. Pelacak pihak ketiga dapat menetapkan pengidentifikasi unik dalam cookie. Jika mereka adalah bagian dari materi situs, mereka dapat membaca pengidentifikasi atas kebijakan mereka selama pekerjaan pengguna dengan sumber daya web yang berbeda.

Saat ini, sebagian besar browser menyertakan perlindungan terhadap perilaku pelacak tersebut. Akibatnya, pelacak sekarang menggunakan teknologi CNAME Cloaking , menyamar sebagai skrip mereka sendiri untuk berbagai proyek. Yaitu, pelacak menawarkan pemilik situs untuk menambahkan CNAME ke pengaturan domain mereka untuk domain tertentu, yang alamatnya biasanya terlihat seperti kumpulan karakter acak.

Meskipun tidak disarankan bahwa cookie situs web dapat diakses oleh semua subdomain (misalnya, * .website.com), banyak situs melakukan ini. Dalam hal ini, cookie semacam itu secara otomatis dikirim ke pelacak pihak ketiga yang disamarkan. Akibatnya, Anda tidak dapat lagi berbicara tentang privasi apa pun.

Selain itu, hal yang sama terjadi dengan header HTTP Client-Hints , yang dikirim hanya ke domain utama, karena mereka dapat digunakan untuk membuat sidik jari digital pengguna. Harap pastikan bahwa layanan CDN yang Anda gunakan dengan benar menyaring tajuk tersebut.

Ringkasan

Jika Anda akan segera memperkenalkan hosting independen dari sumber pihak ketiga - izinkan saya memberi Anda beberapa tips:

• Tuan rumah perpustakaan JS, font, dan file CSS Anda yang paling penting. Ini akan mengurangi risiko kegagalan situs atau penurunan kinerjanya sebagai akibat dari kenyataan bahwa sumber daya vital untuk situs untuk bekerja tidak tersedia karena layanan pihak ketiga.
• Sebelum melakukan caching sumber daya pihak ketiga pada CDN, pastikan Anda menggunakan sistem versi saat menamai file mereka, atau bahwa Anda dapat mengontrol siklus hidup sumber daya ini dengan secara manual atau secara otomatis membilas cache CDN saat menerbitkan versi baru dari skrip.
• Berhati-hatilah dengan pengaturan untuk CDN, server proxy, cache. Ini akan memungkinkan Anda untuk mencegah pengiriman cookie dari proyek Anda atau header Client-Hints ke layanan pihak ketiga.

Pembaca yang budiman! Apakah Anda memposting materi orang lain di server Anda yang sangat penting untuk proyek Anda?