Cara kerja pemrosesan file secara lokal di browser
Kalau tidak ada yang diunggah, sebenarnya apa yang mengerjakan prosesnya — dan di mana?
Apa arti "lokal" di sini
Konverter daring yang konvensional adalah situs web dengan endpoint unggah. File Anda dikirim ke komputer yang tidak Anda kendalikan, diproses di sana, disimpan selama jangka waktu tertentu, lalu ditawarkan kembali sebagai unduhan. Pemrosesan lokal menghapus bagian tengah kalimat itu: kode yang membaca file Anda berjalan di dalam tab browser yang sudah Anda buka, di prosesor Anda sendiri, dan hasilnya ditulis kembali ke disk Anda sendiri.
Situsnya tetap diambil lewat jaringan — HTML, lembar gaya, skrip, dan modul WebAssembly semuanya datang dari sebuah server, sama seperti halaman web mana pun. Yang membedakan adalah arahnya. Kode program turun; file Anda tidak naik.
Browser sudah punya semua komponennya
| Fitur | Apa yang disediakannya |
|---|---|
| API File dan Blob | Membaca byte dari file yang dipilih atau dijatuhkan pengguna, tanpa pengiriman formulir |
| Web Workers | Menjalankan pekerjaan berat di thread latar agar antarmukanya tetap responsif |
| WebAssembly | Menjalankan pustaka codec C, C++, atau Rust yang sudah dikompilasi pada kecepatan mendekati native |
| Canvas dan OffscreenCanvas | Mendekode, menggambar, mengubah ukuran, dan meng-encode ulang gambar |
| WebCodecs | Menjangkau encoder dan decoder video berakselerasi perangkat keras milik browser sendiri |
| WebGPU | Menjalankan inferensi model dan pekerjaan piksel paralel di prosesor grafis |
| File System Access | Menulis hasilnya langsung ke lokasi yang dipilih pengguna, di platform yang mendukungnya |
Tidak ada satu pun dari ini yang eksotis. Ini platform yang sama dengan yang menjalankan spreadsheet, perkakas desain, dan gim di dalam sebuah tab. Satu-satunya keputusan yang tidak lazim adalah menolak menambahkan server ke dalamnya.
Jalur yang dilalui sebuah file
- Anda memilih sebuah file. Browser menyerahkan sebuah handle ke halaman itu — bukan salinan, melainkan sebuah rujukan.
- Halaman membaca byte-byte pertamanya untuk mengenali jenis file yang sebenarnya dari signature-nya, alih-alih memercayai ekstensinya.
- Halaman memperkirakan berapa banyak memori yang dibutuhkan tugas itu, lalu menolak atau mengantrekan pekerjaannya kalau angka itu melebihi apa yang bisa disediakan perangkat dengan aman.
- Byte-nya dipindahkan ke sebuah Web Worker. Memindahkan sebuah ArrayBuffer memindahkan kepemilikannya, bukan menyalinnya, sehingga file besar tidak sampai ada dua kali di memori.
- Di dalam worker, sebuah codec WebAssembly atau sebuah API platform mengerjakan proses dekode dan encode yang sesungguhnya.
- Hasilnya kembali dalam bentuk byte, dibungkus dalam sebuah Blob, lalu ditawarkan kepada Anda sebagai unduhan atau ditulis ke lokasi yang Anda pilih.
- URL sementara untuk Blob itu dicabut dan buffer-nya dilepaskan.
Kenapa WebAssembly adalah bagian yang mengubah keadaan
Codec gambar dan video adalah hasil puluhan tahun kode C yang dioptimalkan dengan cermat. Menulisnya ulang dalam JavaScript tidak pernah realistis. WebAssembly adalah format instruksi biner portabel yang dieksekusi browser di dalam sandbox pada kecepatan mendekati kode native, yang berarti pustaka-pustaka yang sudah ada itu bisa dikompilasi lalu dikirim ke browser apa adanya.
Sandbox-nya sama pentingnya dengan kecepatannya. Sebuah modul WebAssembly tidak punya akses bawaan ke sistem file Anda, jaringan Anda, atau tab Anda yang lain. Ia hanya melihat memori yang diserahkan halaman kepadanya dan tidak lebih dari itu. Codec yang jahat, atau yang sekadar bermasalah, tidak bisa berkeliaran lalu membaca sesuatu yang tidak diserahkan kepadanya.
Apa yang masih menyentuh jaringan, dan kenapa itu bukan file Anda
Tiga hal datang lewat jaringan: halamannya sendiri, mesin untuk alat yang Anda buka, dan — untuk penghapusan latar — bobot modelnya. Ketiganya adalah aset statis milik FileSlimmer sendiri, diambil dari origin FileSlimmer sendiri sebelum satu byte pun milik Anda dibaca. Ketiganya adalah unduhan, bisa di-cache, dan setelah pemakaian pertama bisa disajikan dari cache browser sendiri tanpa jaringan sama sekali.
Semua yang terjadi setelah titik itu bersifat lokal. Mesin-mesinnya menerima byte file hanya lewat postMessage dari halaman; mereka tidak pernah diberi URL tujuan pengiriman apa pun, dan sebuah content security policy membatasi ke mana halaman itu bisa terhubung sekalipun ada kode yang mencobanya.
Pertukarannya, dikatakan apa adanya
| Pertimbangan | Di browser Anda | Di sebuah server |
|---|---|---|
| Ke mana file Anda pergi | Tidak ke mana-mana | Ke komputer yang tidak Anda kendalikan |
| Kecepatan | Sebatas kemampuan perangkat Anda | Sebatas yang dibayar operatornya |
| File yang sangat besar | Dibatasi memori browser | Dibatasi ketentuan operatornya |
| Bisa jalan offline | Ya, begitu mesinnya ter-cache | Tidak |
| Format yang tidak lazim | Hanya yang bisa dikompilasi ke WebAssembly | Apa pun yang dipasang operatornya |
| Batch seribu file | Terkendala perangkatnya | Biasanya lebih cocok |
Pemrosesan lokal tidak selalu lebih baik. Ia lebih baik ketika filenya bersifat pribadi, ketika perangkatnya mumpuni, dan ketika pekerjaannya muat di memori. Server lebih baik ketika Anda perlu memproses jauh lebih banyak daripada yang bisa ditampung satu komputer. Jernih soal situasi mana yang sedang Anda hadapi lebih berguna daripada bersikeras bahwa satu pendekatan menang di mana-mana.
Apa yang tidak diklaim di sini
Ini adalah pernyataan tentang apa yang dilakukan aplikasi ini. Ini bukan klaim tentang ekstensi browser Anda, yang bisa membaca isi halaman mana pun yang Anda buka, bukan pula tentang sistem operasi Anda, yang bisa memeriksa file mana pun yang Anda sentuh, bukan pula tentang operator jaringan Anda, yang bisa melihat bahwa Anda mengunjungi sebuah situs. Semua itu di luar jangkauan situs web mana pun, dan alat yang mengatakan sebaliknya sedang melebih-lebihkan dirinya.
Klaimnya sempit dan bisa diperiksa: file yang Anda pilih diproses secara lokal di browser ini dan tidak diunggah oleh FileSlimmer. Panduan berikutnya menjelaskan cara memverifikasinya sendiri alih-alih sekadar memercayainya.
Alat untuk ini
Sumber
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs