Sebuah tim pengembang perangkat lunak video editing berbasis browser baru-baru ini membagikan studi kasus teknis mendalam tentang cara mereka mengatasi hambatan performa yang membuat rendering video promosi 30 detik berlangsung selama puluhan menit. Masalahnya klasik namun sering terlewat: mesin rendering yang seharusnya hanya menghabiskan beberapa milidetik per frame justru membutuhkan hampir satu detik penuh, meskipun dijalankan pada mesin yang mampu memainkan game modern dengan lancar.
Video promosi produk tersebut terdiri dari 1.050 frame dengan resolusi 1.920 x 1.080 piksel. Pada kondisi awal, rendering di browser memakan waktu sekitar satu frame per detik, sedangkan server headless Chromium di Railway membutuhkan sepuluh menit untuk menyelesaikan tugas yang sama. Setelah investigasi mendalam dan empat perbaikan terpisah yang digabung dalam satu komit, median waktu per frame turun drastis ke rentang 90 hingga 165 milidetik — peningkatan performa sekitar 80 persen — dengan bukti perbandingan piksel yang memastikan kualitas visual tidak berubah.
Arsitektur mesin rendering ini cukup standar untuk aplikasi video modern di browser. Setiap frame digambar ke elemen canvas, lalu bitmap hasilnya disuplai ke VideoEncoder WebCodecs untuk menghasilkan H.264 dalam wadah MP4. Lapisan-lapisan video — teks, gambar, bentuk dengan CSS asli — merupakan elemen DOM. Proses rasterisasi lapisan dilakukan melalui library modern-screenshot yang menserialisasi sub-pohon elemen ke SVG foreignObject sebelum merasternya. Lapisan efek tambahan dilewatkan ke kompositor WebGL untuk blur, distorsi, dan filter CSS. Paket kode yang sama berjalan di tab browser untuk pratinjau dan ekspor lokal, serta di Chromium headless pada pekerja API.
Kunci diagnostik bukanlah memprofil seluruh proses rendering sekaligus — angka total hanya menyembunyikan detail. Tim memasang pengukur waktu di setiap tahap pipa per frame: pengambilan DOM, komposisi efek, pemrosesan overlay, dan encoding. Median diambil per adegan karena keempat adegan menggunakan komposisi lapisan yang sangat berbeda. Median keseluruhan awalnya mencapai 0,9 detik kerja serial per frame. Pembagian waktu menunjuk ke empat masalah terpisah di empat subsistem berbeda.
Masalah pertama bersifat logis murni: antarmuka pratinjau menampilkan kanvas overlay pasca-efek agar pengguna melihat dampak efek pada lapisan terisolasi. Pekerjaan itu ditangani EffectOverlayManager, dan fungsi process()-nya dijalankan pada setiap frame ekspor — padahal jalur ekspor tidak memiliki UI sama sekali. Biayanya 60 hingga 260 milidetik per frame murni sia-sia, tergantung adegan. Solusinya sederhana: bendera captureFrame pada jalur ekspor kini mematikan pemrosesan overlay. Kemenangan gratis dengan risiko nol.
Masalah kedua terletak pada manajemen konteks WebGL. Lapisan efek dikomposisi pada ukuran bounding-box yang diberi padding. Kode lama menghancurkan dan menciptakan ulang WebGLEffectCompositor setiap kali ukuran berubah. Menghancurkan kompositor berarti kehilangan konteks GL melalui ekstensi WEBGL_lose_context dan merekompilasi setiap shader pada frame berikutnya. Karena lapisan beranimasi mengubah bounding box-nya terus-menerus, tim membayar biaya teardown konteks penuh di tengah rendering, berulang kali. Perbaikan berupa kolam LRU kecil berkunci ukuran render persis, dibatasi empat instance — cukup menampung beberapa ukuran yang bergantian di sebuah adegan, cukup kecil agar lapisan beranimasi tidak bisa memperluasnya tak terbatas.
Masalah ketiga adalah yang paling berat. Pemanggilan domToCanvas memakan 16 hingga 300 milidetik per panggilan — serialisasi DOM penuh dan rasterisasi. Tim sudah mencache permukaan lapisan, tetapi kunci cache menyertakan setiap properti. Akibatnya, animasi opacity paling sederhana — animasi paling umum di template manapun — membatalkan cache pada setiap frame, memaksa re-rasterisasi konten identik 1.050 kali per rendering. Wawasan perbaikannya: konten dan transformasi adalah hal yang berbeda. Fade atau slide mengubah di mana dan betapa transparan lapisan digambar; tidak mengubah seperti apa lapisan itu. Canvas sudah tahu menerjemahkan, menskalakan, memutar, dan mengatur alpha — itu yang dilakukan drawImage dengan transformasi afine dan globalAlpha, dalam mikrodetik.
Cache kini berlapis dua. Tingkat A (kunci properti penuh) — setiap properti berpartisipasi. Kenaikan mengembalikan permukaan jadi utuh. Sama seperti sebelumnya. Tingkat B (kunci konten) — mengecualikan properti yang hanya diterapkan saat menggambar: transformasi, opacity, filter CSS (dikonsumsi downstream oleh lolos WebGL), dan volume audio (transisi fade menganimasikannya setiap frame bersama opacity). Kenaikan melewati domToCanvas sepenuhnya dan menggambar ulang bitmap konten tercache dengan transformasi saat ini: 1 hingga 3 milidetik dibanding 16 hingga 300 milidetik. Tingkat B hanya benar karena cara capture dibangun: klon dirasterisasi dengan transform: none dan opacity: 1 dipaksa, sehingga bitmap bebas transformasi dan opacity sejak konstruksi. Detail tambahan: lapisan placeholder kosong (ukuran nol) dulunya juga melewati putaran foreignObject setiap frame. Caching hasil ukuran nol menghabiskan satu entri peta dan melewati proses itu sepenuhnya.
Masalah keempat ditemukan berkat verifikasi piksel. Tim memverifikasi perubahan performa dengan perbedaan piksel — merender frame yang sama sebelum dan sesudah, lalu membandingkan bitmap. Perbedaan hanya muncul pada fade, dan keluaran baru kurang transparan dari lama. Itu bukan regresi: itu mengekspos bug yang sudah ada. Ekspor telah memasukkan opacity ke bitmap hasil capture dan menerapkannya lagi via globalAlpha — efektifnya opacity kuadrat. Pratinjau menerapkannya sekali. Ekspor dan pratinjau tidak sepakat tentang setiap fade di setiap video, dan tidak ada yang sadar karena fade sedikit lebih opak tetap terlihat seperti fade. Perbaikan: buang opacity dari klon capture (sudah dilakukan untuk Tingkat B), terapkan persis sekali saat menggambar. Ekspor kini cocok dengan pratinjau — yang merupakan spesifikasi sebenarnya.
Hasilnya mengesankan. Median adegan per frame pada template peluncuran produk yang memulai investigasi ini turun drastis. Adegan yang sebelumnya memakan waktu 0,5 hingga 1 detik per frame kini menyelesaikan dalam 90 hingga 165 milidetik. Verifikasi piksel mengonfirmasi kesetaraan visual, sekaligus memperbaiki ketidaksesuaian lama antara pratinjau dan ekspor pada setiap animasi opacity. Semua perubahan dikemas dalam satu komit atomik, membuktikan bahwa profiling granular dan pemahaman mendalam tentang batasan platform browser bisa menghasilkan lompatan performa besar tanpa menulis ulang arsitektur.