Pengiriman front-end di era penerbitan frekuensi tinggi perlu mendesain ulang kolaborasi caching dan kompresi

Setelah sumber daya front-end memasuki ritme rilis frekuensi tinggi, masalah kinerja tidak lagi sesederhana “menghidupkan Brotli”. Layar pertama melambat, lalu lintas kembali ke asal meningkat, dan CPU node tepi bergetar. Di permukaan, tampaknya kompresinya kurang agresif. Melihat lebih dalam, sering kali caching dan kompresi dioptimalkan secara terpisah, dan akhirnya saling melemahkan pada tautan penerbitan.

Masalah seperti ini umumnya tidak terungkap pada versi pertama. Pada awalnya, tim hanya akan melihat beberapa sinyal yang tersebar: perubahan kecil menyebabkan gangguan pada tingkat hit sumber daya statis, peningkatan abnormal dalam CPU kompresi tepi pada malam promosi besar-besaran, dan volume paket kembali dalam tahap skala abu-abu tidak sesuai dengan lalu lintas resmi. Jika Anda terus memeriksa, petunjuknya biasanya mengarah pada hal yang sama: meskipun konten sumber daya hanya berubah sedikit, kunci cache, pemisahan potongan, dan input terkompresi telah menjadi serangkaian hal yang berbeda, dan lapisan transport terpaksa menelan seluruh biaya lagi.

Sampai hash sumber daya stabil, manfaat kompresi tidak dapat dipertahankan.

Setelah proyek front-end dirilis secara paralel dengan banyak halaman, banyak rute, dan banyak tim, aspek yang paling mudah diabaikan adalah stabilitas nama file. Selama segmentasi potongan sedikit menyimpang, meskipun kode bisnis hanya mengubah salinan tombol, produk akhir juga dapat menulis ulang hash dari serangkaian bundel publik. Apa yang dilihat oleh sistem caching adalah kumpulan objek baru, dan apa yang dilihat oleh sistem kompresi adalah kumpulan masukan yang muncul untuk pertama kalinya.

Pada saat ini, tidak peduli seberapa tinggi tingkat kompresinya, hal ini tidak dapat menyelamatkan tingkat hit dari kehancuran. File lama masih berada di node tepi, dan file baru telah dimasukkan kembali; cache lokal browser benar-benar tidak valid, dan CDN harus menarik ulang sumbernya, mengompresi ulang, dan mendistribusikan ulang. Perubahan bisnis kecil diperbesar menjadi pekerjaan berulang untuk seluruh jalur transmisi.

Tindakan yang sangat berguna biasanya bukan untuk terus menyesuaikan tingkat kompresi, tetapi untuk mengontrol stabilitas produk yang dirilis terlebih dahulu:

• Ketergantungan publik dipotong menjadi beberapa lapisan terpisah untuk mengurangi perubahan bisnis dan menyatukan paket-paket dasar untuk mengubah hash.
• Hindari mencampurkan perubahan frekuensi tinggi seperti stempel waktu dan nomor build langsung ke dalam konten produk
• Biarkan kode yang dekat dengan rute yang sama sebisa mungkin dimasukkan ke dalam bagian yang stabil alih-alih diacak ulang setiap kali dikompilasi.

Hanya ketika identitas sumber daya distabilkan, cache dapat terus digunakan kembali dan hasil kompresi memiliki nilai kumulatif.

Konferensi pers frekuensi tinggi menulis ulang masalah kompresi menjadi masalah versi kamus

Ketika sumber daya menjadi semakin terfragmentasi, Brotli atau gzip file tunggal masih penting, namun bukan lagi segalanya. Biaya sebenarnya mulai beralih ke bagian duplikat: kode runtime kerangka kerja, templat gaya, deklarasi tipe antarmuka, lapisan pengemasan yang dihasilkan oleh pembuat paket, seringkali sangat mirip antar kumpulan versi. Dengan tempo pelepasan yang cepat, riff-riff ini akan dibawakan berulang-ulang.

Masalahnya adalah kamus kompresi dapat dengan mudah berubah dari optimasi menjadi gangguan jika tidak dikelola bersamaan dengan irama rilis. Jika kamus dialihkan terlebih dahulu, kamus baru yang dirujuk oleh halaman lama akan tidak cocok; kamus dipotong menjadi terlalu banyak bagian, dan jumlah versi yang harus dikelola oleh node tepi meningkat tajam; pembaruan kamus tidak disinkronkan dengan sumber daya online, dan objek yang seharusnya terkena dikembalikan ke transmisi penuh.

Ini juga merupakan perubahan yang sangat praktis dalam pengiriman front-end baru-baru ini: strategi caching dan protokol kompresi tidak lagi dapat dikelola oleh tim yang berbeda. Versi sumber daya, versi kamus, dan ruang kunci cache pada dasarnya merupakan masalah penerbitan yang sama.

Pendekatan hierarki seperti berikut ini biasanya lebih stabil daripada “kompresi kuat terpadu untuk seluruh situs”:

const policy = {
  immutableAssets: 'public, max-age=31536000, immutable',
  releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
  sharedDictionary: 'versioned-by-release-train'
}

Kuncinya bukanlah konfigurasi ketiga baris ini, namun batasan yang diungkapkannya: sumber daya dengan siklus hidup yang panjang, daftar siklus hidup yang pendek, dan versi kamus terkompresi harus berkembang bersama sesuai dengan ritme rilis yang sama.

Tekanan untuk kembali ke sumber seringkali bukan karena file tersebut terlalu besar, tetapi karena metode kegagalannya terlalu kasar.

Kesalahan penilaian lain yang sangat umum adalah mengaitkan peningkatan bandwidth secara langsung dengan bobot halaman. Halamannya tentu menjadi lebih berat, tetapi ampli online yang lebih berbahaya biasanya merupakan pilihan yang tepat.

Jika Anda membersihkan berdasarkan direktori, awalan, atau bahkan seluruh situs setiap kali Anda mempublikasikannya, lapisan cache akan langsung kehilangan memorinya. Saat ini, meskipun ukuran file tidak terus bertambah, nilai puncak kembali ke asal akan meningkat dengan sendirinya. Segera setelah sumber dikembalikan, tepinya dikompres ulang, objek dihangatkan kembali, dan browser diunduh ulang. Jendela penerbitan akan berubah dari perubahan langkah kecil menjadi relokasi situs penuh.

Dalam skenario seperti ini, hal yang paling berharga adalah radius kegagalan yang dapat dikontrol:

• Hanya batalkan manifes, HTML, dan sumber daya yang dapat diubah yang benar-benar berubah
• Cobalah untuk tidak membersihkan file statis dengan hash, dan serahkan ke referensi baru untuk peralihan alami.
• Bagi rilis ke dalam urutan “pertama unggah sumber daya baru, lalu potong referensi, lalu daur ulang sumber daya lama” alih-alih menghapus semuanya sekaligus

Yang benar-benar sensitif mengenai biaya transfer bukan hanya ukuran file, tetapi juga bagaimana sistem memutuskan konten mana yang harus diambil ulang.

Batasan yang berlaku ditentukan bersama dengan skala sumber daya dan frekuensi rilis.

Kumpulan desain bersama ini tidak diperlukan untuk semua situs. Untuk proyek dengan jumlah halaman statis yang sedikit, paket sumber daya yang kecil, dan frekuensi rilis mingguan atau bahkan bulanan, menggunakan nama file hash tradisional ditambah pra-kompresi Brotli biasanya cukup stabil.

Caching dan kompresi bersama-sama dengan cepat menjadi infrastruktur pengiriman setelah karakteristik berikut diterapkan:

• Dirilis beberapa kali sehari, dengan skala abu-abu, rollback, atau peluncuran regional
• Produk front-end berukuran besar, memiliki banyak ketergantungan publik, dan memiliki hubungan potongan yang kompleks.
• CDN, penyimpanan objek, kompresi tepi, dan cache browser secara bersamaan berpartisipasi dalam tautan transmisi
• Lalu lintasnya sangat tinggi sehingga tingkat cache hit dan nilai puncak kembali ke asal akan secara langsung mencerminkan biaya dan stabilitas.

Setelah pengiriman front-end memasuki tahap ini, kompresi tidak lagi hanya “membuat file lebih kecil”, dan caching tidak lagi hanya “menyimpan lebih banyak salinan konten”. Apa yang keduanya putuskan bersama adalah: untuk perubahan bisnis kecil, apakah hanya mengirim satu bagian lagi, atau apakah seluruh tautan transmisi perlu dijalankan kembali. Semakin sering Anda mempublikasikan, semakin mahal perbedaannya.