Situasinya
Sebuah perusahaan sudah memiliki website yang dibangun menggunakan Next.js. Website sudah berjalan di production dan digunakan oleh pengguna setiap hari.
Setelah beberapa waktu, kebutuhan website berkembang. Beberapa halaman perlu diperbarui, komponen baru mulai ditambahkan, dependency semakin banyak, dan proses build mulai terasa lebih berat.
Di sisi pengguna, beberapa halaman mulai terasa lambat. Di sisi developer, perubahan yang seharusnya sederhana mulai membutuhkan perhatian lebih karena struktur codebase sudah cukup kompleks.
Masalah lain muncul ketika Docker image diperiksa menggunakan security scanner seperti Trivy. Beberapa vulnerability ditemukan pada dependency maupun package yang berada di dalam image.
Masalah sebenarnya: website bukan sekadar membutuhkan tampilan baru. Ada masalah performance, dependency, security, architecture, dan maintenance yang perlu dilihat sebagai satu kesatuan.
Analisis
Untuk kasus seperti ini, langkah pertama bukan langsung mengganti seluruh aplikasi dengan codebase baru.
Website yang sudah berjalan biasanya memiliki banyak behaviour yang tidak selalu terlihat dari UI: business rule, API integration, authentication, analytics, SEO, environment configuration, dan deployment process.
Karena itu, keputusan antara enhancement, refactor, upgrade, atau rewrite sebaiknya dibuat setelah kondisi existing dipahami.
1. Masalah performance
Website yang terasa lambat tidak selalu berarti Next.js merupakan masalahnya. Performa dapat dipengaruhi oleh cara component dirancang, rendering strategy, data fetching, image, font, third-party script, JavaScript bundle, hingga API yang digunakan.
Misalnya, component yang sebenarnya tidak membutuhkan interaksi browser dapat menjadi client component dan menyebabkan lebih banyak JavaScript dikirim ke browser.
Karena itu, optimasi sebaiknya dimulai dengan mencari bottleneck, bukan sekadar mengejar angka Lighthouse.
2. Dependency mulai tertinggal
Aplikasi yang sudah berjalan beberapa tahun dapat memiliki dependency yang cukup tertinggal. Upgrade juga tidak selalu sederhana karena satu package dapat memiliki dependency lain yang saling berkaitan.
Meng-upgrade satu package dapat memunculkan perubahan behaviour, compatibility issue, atau kebutuhan regression testing.
Karena itu, dependency upgrade perlu dilakukan secara terencana, terutama untuk framework utama seperti Next.js dan React.
3. Muncul Trivy vulnerabilities
Production application menggunakan Docker image. Ketika image tersebut di-scan menggunakan Trivy, ditemukan beberapa vulnerability.
Temuan seperti ini perlu dianalisis berdasarkan package, versi, dependency path, severity, availability of patched version, dan bagaimana package tersebut digunakan oleh aplikasi.
Tidak semua vulnerability dapat diselesaikan hanya dengan menjalankan update seluruh dependency.
4. Codebase semakin sulit dirawat
Seiring bertambahnya fitur, business logic dapat mulai bercampur dengan UI component, data fetching, configuration, dan utility code.
Akibatnya, perubahan kecil dapat memiliki impact yang lebih besar dari perkiraan.
Ini merupakan salah satu bentuk technical debt yang sering tidak terlihat oleh pengguna, tetapi sangat terasa oleh developer.
Apa yang perlu diperiksa?
Sebelum menentukan strategi revamp, website sebaiknya mendapatkan technical assessment sederhana.
| Area | Yang diperiksa | Tujuan |
|---|---|---|
| UI / UX | Layout, responsive behaviour, accessibility, consistency, dan usability. | Menentukan bagian yang perlu diperbaiki. |
| Performance | Bundle, rendering, image, font, API request, dan third-party script. | Menemukan bottleneck utama. |
| Dependencies | Next.js, React, npm packages, lockfile, dan transitive dependencies. | Menentukan upgrade yang aman. |
| Docker | Base image, installed packages, image size, dan build process. | Mengurangi attack surface dan technical debt. |
| Security | Trivy findings, severity, dependency path, dan patched version. | Menentukan vulnerability yang perlu ditangani. |
| Architecture | Component structure, business logic, API, configuration, dan data fetching. | Menentukan area yang perlu direfactor. |
Performance: jangan hanya mengejar skor
Salah satu kesalahan umum dalam melakukan revamp adalah menjadikan angka Lighthouse sebagai satu-satunya target.
Lighthouse sangat berguna sebagai indikator, tetapi angka tersebut seharusnya digunakan untuk membantu menemukan masalah, bukan menjadi tujuan tanpa memahami penyebabnya.
Contoh hal yang perlu diperiksa
- Apakah component benar-benar membutuhkan client-side JavaScript?
- Apakah data fetching dilakukan terlalu banyak atau terlalu sering?
- Apakah image sudah menggunakan strategi yang tepat?
- Apakah third-party script memperlambat initial page load?
- Apakah bundle memasukkan dependency yang sebenarnya tidak diperlukan?
- Apakah rendering strategy sesuai dengan karakter halaman?
Setelah penyebabnya diketahui, barulah ditentukan apakah perlu mengubah component boundary, rendering strategy, data fetching, asset handling, atau dependency.
Bagaimana menangani Trivy vulnerabilities?
Trivy dapat menemukan vulnerability pada OS package maupun dependency yang terdapat di dalam Docker image.
Karena itu, hasil scanning tidak sebaiknya langsung diterjemahkan menjadi "semua package harus di-update".
Setiap finding perlu dilihat konteksnya.
Contoh proses analisis
1. Identifikasi package: cari tahu package dan versi yang terkena vulnerability.
2. Cari dependency path: tentukan apakah package merupakan direct dependency atau transitive dependency.
3. Periksa patched version: pastikan apakah sudah tersedia versi yang memperbaiki vulnerability.
4. Periksa impact: tentukan apakah package digunakan pada runtime, build process, atau hanya tooling.
5. Tentukan remediation: upgrade, override, mengganti dependency, mengubah base image, atau mendokumentasikan alasan mengapa finding tertentu belum dapat diperbaiki.
Dependency tidak selalu bisa di-update sembarangan
Misalnya sebuah vulnerability berasal dari dependency yang berada cukup dalam di dependency tree.
Mengubah package di root project belum tentu mengubah package yang digunakan oleh dependency lain.
Di sinilah dependency tree perlu diperiksa terlebih dahulu. Dalam beberapa kasus solusi dapat berupa upgrade package utama. Dalam kasus lain diperlukan override atau upgrade framework yang membawa dependency tersebut.
"npm update" bukan strategi security. Security remediation membutuhkan pemahaman dependency tree, compatibility, dan regression impact.
Refactor architecture secara bertahap
Jika masalah architecture memang ditemukan, refactor tidak harus dilakukan sekaligus.
Salah satu pendekatan adalah memperbaiki struktur berdasarkan tanggung jawab.
- UI component fokus pada presentation dan interaction.
- Business rule dipisahkan dari presentation.
- Data fetching memiliki boundary yang jelas.
- Configuration tidak tersebar di berbagai component.
- Utility dan shared logic ditempatkan pada lokasi yang konsisten.
Dengan pendekatan tersebut, halaman baru dapat menggunakan struktur yang lebih baik tanpa harus langsung memindahkan seluruh aplikasi.
Pilihan pendekatan revamp
| Pendekatan | Kapan dipilih | Catatan |
|---|---|---|
| Minor Enhancement | Struktur aplikasi masih sehat dan masalah hanya berada di beberapa bagian. | Technical debt lama masih tersisa. |
| Refactor Bertahap | Masalah terdapat di beberapa area tetapi aplikasi masih layak dipertahankan. | Membutuhkan disiplin dan regression testing. |
| Major Upgrade + Refactor | Framework dan dependency sudah cukup tertinggal, sementara architecture juga membutuhkan perubahan. | Compatibility issue lebih tinggi. |
| Rewrite | Technical debt sudah membuat perubahan existing hampir tidak ekonomis. | Risiko kehilangan behaviour existing paling tinggi. |
Rekomendasi
Untuk kasus seperti ini, kami tidak akan langsung menawarkan "buat ulang website menggunakan Next.js versi terbaru".
Langkah yang lebih masuk akal adalah mendapatkan baseline terlebih dahulu, kemudian menentukan prioritas perbaikan.
Rekomendasi Deduksi
Audit terlebih dahulu. Petakan UI, performance, dependency, Docker, security, dan architecture sebelum menentukan scope pekerjaan.
Stabilkan sistem. Tangani masalah security dan build yang paling penting sebelum melakukan perubahan besar.
Upgrade secara terencana. Upgrade framework dan dependency dengan regression testing, bukan sekadar menjalankan update seluruh package.
Improve performance berdasarkan data. Fokus pada bottleneck yang benar-benar memberikan dampak terhadap pengguna.
Refactor secara bertahap. Rapikan architecture ketika area tersebut disentuh, sehingga perubahan dapat dilakukan tanpa rewrite besar.
Revamp UI setelah fondasi lebih sehat. Dengan begitu desain baru tidak terus membawa masalah technical debt lama ke halaman baru.
Bagaimana dengan biaya?
Biaya technical revamp sangat bergantung pada kondisi existing. Dua website yang sama-sama menggunakan Next.js belum tentu memiliki tingkat pekerjaan yang sama.
Website dengan sedikit halaman tetapi dependency dan architecture yang kompleks bisa membutuhkan pekerjaan lebih banyak dibandingkan website dengan banyak halaman tetapi struktur yang sehat.
Karena itu, estimasi yang lebih sehat biasanya diberikan setelah audit atau technical assessment singkat.
Yang dihitung bukan sekadar jumlah halaman. Dalam technical revamp, biaya dipengaruhi oleh kompleksitas, risiko perubahan, dependency, integrasi, dan kondisi codebase existing.
Output yang ideal
Technical revamp sebaiknya menghasilkan lebih dari sekadar website yang terlihat lebih bagus.
Setelah pekerjaan selesai, tim sebaiknya memiliki gambaran yang lebih jelas mengenai architecture, dependency, security findings, performance baseline, dan cara melakukan maintenance berikutnya.
- Technical assessment atau audit.
- Daftar prioritas perbaikan.
- Dependency dan framework upgrade plan.
- Performance improvement.
- Security remediation.
- Architecture refactoring yang diperlukan.
- Dokumentasi perubahan penting.
Kesimpulan
Website yang sudah berjalan tidak selalu membutuhkan rewrite. Begitu juga website yang terlihat lambat tidak selalu membutuhkan optimasi besar-besaran.
Yang dibutuhkan terlebih dahulu adalah memahami masalahnya.
Dengan audit yang tepat, revamp dapat dilakukan secara bertahap: fix yang penting, stabilize sistem, improve performance, refactor bagian yang perlu, kemudian revamp pengalaman pengguna.
Dengan cara ini, website tidak hanya terlihat lebih baru, tetapi juga menjadi lebih sehat untuk dikembangkan setelah revamp selesai.