Dalam beberapa tahun terakhir, semakin banyak platform untuk mengoptimalkan proyek front-end yang menawarkan peluang untuk hosting mandiri atau proksi sumber daya pihak ketiga. Akamai memungkinkan Anda mengatur untuk URL yang dibuat sendiri. Cloudflare memiliki teknologi Edge Workers. Fasterzine bisa URL pada halaman sehingga mengarah ke sumber pihak ketiga yang terletak di domain utama situs.
Jika Anda mengetahui bahwa layanan pihak ketiga yang digunakan dalam proyek Anda tidak terlalu sering berubah, dan bahwa proses penyampaiannya ke klien dapat ditingkatkan, maka Anda mungkin mempertimbangkan untuk menggunakan proxy pada layanan tersebut. Dengan pendekatan ini, Anda dapat mendekatkan sumber daya ini dengan pengguna Anda dan mendapatkan kontrol lebih penuh atas cache mereka di sisi klien. Selain itu, ini memungkinkan Anda melindungi pengguna dari masalah yang disebabkan oleh βcrashβ layanan pihak ketiga atau penurunan kinerjanya.
Bagus: Peningkatan kinerja
Menghosting 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. Anda dapat melihat bagaimana menghosting sendiri sumber daya orang lain memengaruhi kinerja dengan membandingkan dua gambar berikut.
Sumber daya pihak ketiga diunduh dari sumber eksternal (diambil dari )
Sumber daya pihak ketiga disimpan di tempat yang sama dengan materi situs lainnya (diambil dari )
Situasi ini juga ditingkatkan dengan fakta bahwa browser akan menggunakan kemampuan untuk menggandakan dan memprioritaskan data dari koneksi HTTP/2 yang telah dibuat dengan domain utama.
Jika Anda tidak menghosting sumber daya pihak ketiga, karena sumber daya tersebut akan dimuat dari domain yang berbeda dari domain utama, sumber daya tersebut tidak dapat diprioritaskan. Hal ini akan menyebabkan mereka bersaing satu sama lain untuk mendapatkan bandwidth klien. Hal ini dapat mengakibatkan waktu pemuatan konten yang penting untuk membangun halaman menjadi lebih lama daripada yang dapat dicapai dalam kondisi ideal. berbicara tentang prioritas HTTP/2 yang menjelaskan semua ini dengan sangat baik.
Dapat diasumsikan bahwa penggunaan atribut terkait dengan sumber daya eksternal preconnect akan membantu dalam memecahkan masalah tersebut. Namun, jika terlalu banyak tautan ini ke domain berbeda, hal ini justru dapat membebani jalur komunikasi pada saat yang paling genting.
Jika Anda menghosting sendiri sumber daya pihak ketiga, Anda dapat mengontrol bagaimana tepatnya sumber daya tersebut diberikan kepada klien. Yaitu, kita berbicara tentang hal berikut:
- Anda dapat memastikan bahwa algoritma kompresi data yang paling sesuai dengan setiap browser digunakan (Brotli/gzip).
- Anda dapat menambah waktu cache untuk sumber daya yang biasanya tidak terlalu lama, bahkan dengan penyedia paling terkenal (misalnya, nilai yang sesuai untuk tag GA disetel ke 30 menit).
Anda bahkan dapat memperluas TTL untuk suatu sumber daya hingga, katakanlah, satu tahun dengan memasukkan konten yang relevan ke dalam strategi manajemen cache Anda (hash URL, pembuatan versi, dll.). Kami akan membicarakannya di bawah.
βPerlindungan terhadap gangguan dalam pengoperasian layanan pihak ketiga atau penutupannya
Aspek menarik lainnya dari sumber daya pihak ketiga yang menghosting mandiri adalah memungkinkan Anda memitigasi risiko yang terkait dengan penghentian layanan pihak ketiga. Anggaplah solusi pengujian A/B pihak ketiga yang Anda gunakan diimplementasikan sebagai skrip pemblokiran yang dimuat di bagian kepala halaman. Skrip ini dimuat dengan lambat. Jika skrip terkait gagal dimuat, halaman akan kosong. Jika memuat sangat lama, halaman akan muncul dengan penundaan yang lama. Atau, misalkan proyek menggunakan perpustakaan yang diunduh dari sumber daya CDN pihak ketiga. Bayangkan sumber daya ini mengalami kegagalan atau diblokir di negara tertentu. Situasi seperti ini akan mengakibatkan pelanggaran logika situs.
Untuk mengetahui cara kerja situs Anda ketika beberapa layanan eksternal tidak tersedia, Anda dapat menggunakan bagian SPOF di .
Bagian SPOF di webpagetest.org
βBagaimana dengan masalah cache materi di browser? (petunjuk: itu hanya mitos)
Anda mungkin berpikir bahwa menggunakan CDN publik secara otomatis akan menghasilkan kinerja sumber daya yang lebih baik, karena layanan ini memiliki jaringan berkualitas tinggi dan didistribusikan ke seluruh dunia. Namun sebenarnya semuanya sedikit lebih rumit.
Katakanlah kita memiliki beberapa situs berbeda: website1.com, website2.com, website3.com. Semua situs ini menggunakan perpustakaan jQuery. Kami menghubungkannya menggunakan CDN, misalnya - googleapis.com. Anda dapat mengharapkan browser mengunduh dan menyimpan cache perpustakaan satu kali, lalu menggunakannya di ketiga situs. Hal ini dapat mengurangi beban pada jaringan. Mungkin ini akan memungkinkan Anda menghemat uang dan membantu meningkatkan kinerja sumber daya. Dari sudut pandang praktis, semuanya terlihat berbeda. Misalnya, Safari memiliki fitur bernama : Cache menggunakan kunci ganda berdasarkan sumber dokumen dan sumber sumber pihak ketiga. artikel bagus tentang topik ini.
studi lama ΠΈ , serta yang lebih baru Paul Calvano, menunjukkan bahwa sumber daya tidak disimpan dalam cache browser selama yang kita harapkan: βAda kesenjangan yang serius antara waktu cache dari sumber daya milik proyek dan sumber daya pihak ketiga. Kita berbicara tentang CSS dan font web. Yaitu, 95% font asli memiliki masa pakai cache lebih dari seminggu, sementara 50% font pihak ketiga memiliki masa pakai cache kurang dari seminggu! Hal ini memberi pengembang web alasan kuat untuk menghosting file font sendiri!β
Akibatnya, jika Anda menghosting konten orang lain, Anda tidak akan melihat masalah kinerja apa pun yang disebabkan oleh cache browser.
Sekarang kita telah membahas kelebihan hosting mandiri pihak ketiga, mari kita bahas tentang cara membedakan implementasi yang baik dari pendekatan ini dan yang buruk.
Keburukan: Iblis ada dalam detailnya
Memindahkan sumber daya pihak ketiga ke domain Anda sendiri tidak dapat dilakukan secara otomatis tanpa memastikan bahwa sumber daya tersebut disimpan dalam cache dengan benar.
Salah satu masalah utama di sini adalah waktu cache. Misalnya, informasi versi disertakan dalam nama skrip pihak ketiga seperti ini: jquery-3.4.1.js. File seperti itu tidak akan berubah di masa mendatang, dan akibatnya, hal ini tidak akan menimbulkan masalah apa pun dengan cache-nya.
Namun jika skema versi tertentu tidak digunakan saat bekerja dengan file, skrip cache, yang isinya berubah sementara nama file tetap tidak berubah, mungkin menjadi usang. Ini bisa menjadi masalah serius, karena, misalnya, tidak memungkinkan patch keamanan otomatis ditambahkan ke skrip yang harus diterima klien secepat mungkin. Pengembang harus berupaya memperbarui skrip tersebut di cache. Selain itu, hal ini dapat menyebabkan kegagalan aplikasi karena kode yang digunakan pada klien dari cache berbeda dari versi terbaru kode yang dirancang untuk bagian server proyek.
Benar, jika kita berbicara tentang materi yang sering diperbarui (manajer tag, solusi untuk pengujian A/B), maka menyimpannya dalam cache menggunakan alat CDN adalah tugas yang dapat diselesaikan, tetapi jauh lebih rumit. Layanan seperti Commanders Act, solusi manajemen tag, menggunakan webhook saat menerbitkan versi baru. Ini memberi Anda kemampuan untuk memaksa pembersihan cache di CDN, atau, lebih baik lagi, kemampuan untuk memaksa pembaruan hash atau URL.
β Pengiriman materi yang adaptif kepada klien
Selain itu, ketika kita berbicara tentang caching, kita perlu mempertimbangkan fakta bahwa pengaturan caching yang digunakan pada CDN mungkin tidak cocok untuk beberapa sumber pihak ketiga. Misalnya, sumber daya tersebut dapat menggunakan teknologi sniffing agen pengguna (pelayanan adaptif) untuk melayani browser tertentu dengan versi konten yang dioptimalkan secara khusus untuk browser tersebut. Teknologi ini mengandalkan ekspresi reguler, atau database informasi header HTTP, untuk mengetahui kemampuan browser. User-Agent. Begitu mereka mengetahui browser mana yang mereka gunakan, mereka memberikan materi yang dirancang untuk browser tersebut.
Di sini Anda dapat mengingat dua layanan. Yang pertama adalah googlefonts.com. Yang kedua adalah polyfill.io. Layanan Google Fonts menyediakan, untuk sumber daya tertentu, berbagai kode CSS, bergantung pada kemampuan browser (memberikan tautan ke sumber daya woff2 menggunakan unicode-range).
Berikut adalah hasil dari beberapa kueri Google Font yang dibuat dari browser berbeda.
Hasil kueri Google Font dari Chrome
Hasil kueri Google Font dijalankan dari IE10
Polyfill.io hanya memberi browser polyfill yang dibutuhkannya. Hal ini dilakukan karena alasan kinerja.
Misalnya, mari kita lihat apa yang terjadi jika Anda menjalankan permintaan berikut dari browser berbeda:
Menanggapi permintaan yang dijalankan dari IE10, 34 KB data akan diterima. Dan jawabannya, yang dijalankan dari Chrome, akan kosong.
Marah: Beberapa pertimbangan privasi
Poin ini merupakan poin terakhir, namun tidak kalah pentingnya. Intinya adalah hosting mandiri sumber daya pihak ketiga di domain utama proyek atau di subdomainnya dapat membahayakan privasi pengguna dan berdampak negatif pada proyek web utama.
Jika sistem CDN Anda tidak dikonfigurasi dengan benar, Anda mungkin mengirimkan cookie domain Anda ke layanan pihak ketiga. Jika pemfilteran yang tepat tidak diatur di tingkat CDN, maka cookie sesi Anda, yang biasanya tidak dapat digunakan dalam JavaScript (dengan httponly), dapat dikirim ke host asing.
Hal inilah yang dapat terjadi pada pelacak seperti Eulerian atau Criteo. Pelacak pihak ketiga mungkin telah menetapkan pengidentifikasi unik di cookie. Jika mereka adalah bagian dari materi situs, mereka dapat membaca pengidentifikasi sesuai kebijaksanaan mereka saat pengguna bekerja dengan sumber daya web yang berbeda.
Saat ini, sebagian besar browser menyertakan perlindungan terhadap jenis perilaku pelacak ini. Hasilnya, pelacak kini menggunakan teknologi , menyamar sebagai naskah mereka sendiri untuk berbagai proyek. Yaitu, pelacak menawarkan pemilik situs untuk menambahkan CNAME ke pengaturan mereka untuk domain tertentu, yang alamatnya biasanya terlihat seperti kumpulan karakter acak.
Meskipun tidak disarankan untuk membuat cookie situs web tersedia untuk semua subdomain (misalnya - *.website.com), banyak situs yang melakukan hal ini. Dalam hal ini, cookie tersebut secara otomatis dikirim ke pelacak pihak ketiga yang menyamar. Akibatnya, kita tidak bisa lagi membicarakan privasi apa pun.
Hal yang sama juga terjadi pada header HTTP , yang dikirim hanya ke domain utama, karena dapat digunakan untuk membuat pengguna. Pastikan layanan CDN yang Anda gunakan memfilter header ini dengan benar.
Hasil
Jika Anda berencana untuk segera menerapkan hosting mandiri sumber daya pihak ketiga, izinkan saya memberi Anda beberapa saran:
- Host perpustakaan JS, font, dan file CSS terpenting Anda. Hal ini akan mengurangi risiko kegagalan situs atau penurunan kinerja karena tidak tersedianya sumber daya penting bagi situs karena kesalahan layanan pihak ketiga.
- Sebelum Anda melakukan cache sumber daya pihak ketiga di CDN, pastikan bahwa beberapa jenis sistem versi digunakan saat memberi nama file mereka, atau bahwa Anda dapat mengelola siklus hidup sumber daya ini dengan mengatur ulang cache CDN secara manual atau otomatis saat menerbitkan versi baru. naskah.
- Berhati-hatilah dengan CDN, server proxy, dan pengaturan cache Anda. Ini akan memungkinkan Anda untuk mencegah proyek atau header Anda dikirimi cookie
Client-Hintslayanan pihak ketiga.
Pembaca yang terhormat Apakah Anda menghosting materi orang lain di server Anda yang sangat penting untuk pengoperasian proyek Anda?
Sumber: www.habr.com