Sebagian besar website tidak gagal karena idenya jelek. Website gagal karena kode di baliknya menjadi mahal untuk diubah: redesign butuh berbulan-bulan, mengganti satu kalimat perlu developer, dan setiap fitur baru membuat fitur berikutnya makin lambat. Topik ini mengumpulkan cara kami menghindari hal itu di tbskit — standar kerja, perkakas, dan kebiasaan yang menjaga situs tetap cepat dan mudah disunting bertahun setelah peluncuran.
Mengapa kode kami perlakukan sebagai aset bisnis
Website bukan hasil sekali serah, melainkan aset yang terus beroperasi. Pertanyaan yang kami ajukan di awal setiap proyek bukan “framework mana yang sedang tren”, tapi “siapa yang akan mengubah halaman ini enam bulan lagi, dan berapa lama pengerjaannya?” Satu pertanyaan itu menentukan cara kami menyusun konten, seberapa banyak abstraksi yang kami pakai, dan seberapa banyak yang kami dokumentasikan.
Dalam praktiknya, ada tiga komitmen yang kami pegang di setiap pembangunan:
- Blok bangunan yang kecil, membosankan, dan dikenal luas. Developer baru — tim Anda atau tim kami — harus produktif pada jam pertama, bukan minggu pertama.
- Konten hidup di berkas, bukan di dalam kode. Teks, gambar, dan struktur halaman harus bisa diubah tanpa menyentuh komponen.
- Anggaran, bukan niat. Kecepatan dan aksesibilitas diberi angka yang bisa diukur, dan build gagal dengan lantang saat angka itu terlewat.
Stack yang sengaja kami jaga tetap kecil
Kami membangun situs statis-dulu dengan Astro dan TypeScript, karena situs yang mengirim HTML alih-alih runtime framework lebih mudah di-hosting, lebih murah dijalankan, dan lebih cepat dibuka. Jika interaktivitas memang dibutuhkan, kami menambahkannya sebagai island, satu komponen demi satu komponen, bukan mengirim aplikasi klien penuh ke setiap pengunjung.
Aturan kami untuk dependensi sederhana: setiap paket harus membuktikan dirinya layak. Dependensi adalah kontrak pemeliharaan yang tidak pernah kedaluwarsa — ia butuh pembaruan, perhatian keamanan, dan orang yang memahaminya. Kami lebih memilih menulis empat puluh baris kode yang jujur daripada mengimpor pustaka yang tidak kami kendalikan.
Anggaran performa, bukan janji
“Cepat” bukan perasaan, melainkan hasil pengukuran. Setiap proyek mendapat anggaran yang mencakup:
- Largest Contentful Paint dan Interaction to Next Paint dari perangkat nyata, bukan dari laptop developer di wifi kantor.
- Total JavaScript yang dikirim per halaman, dengan batas keras yang harus dibicarakan lebih dulu sebelum dinaikkan.
- Berat dan format gambar, karena gambar biasanya adalah tuas terbesar pada kecepatan yang dirasakan pengunjung.
Anggaran hanya bekerja jika otomatis, jadi kami menyambungkannya ke proses build dan memeriksanya kembali sebelum peluncuran, di perangkat paling lambat yang wajar digunakan oleh audiens klien. Kalau sebuah fitur melewati batas, kami mengubah fiturnya — bukan batasnya.
Aksesibilitas dan semantik sejak commit pertama
Aksesibilitas bukan audit di akhir proyek; pada titik itu yang dibutuhkan sudah penulisan ulang. Kami mulai dari HTML semantik, urutan heading yang masuk akal, fokus keyboard yang terlihat, jalur keyboard untuk setiap elemen interaktif, dan kontras warna yang diukur terhadap palet — bukan hanya dilihat. Uji pembaca layar dan alat otomatis punya tempatnya, tetapi fondasinya adalah markup yang sudah bermakna.
Perhatian yang sama berbuah di SEO. Crawler membaca struktur yang sama dengan teknologi
bantu: satu <h1> yang jelas, tautan yang deskriptif, alternatif gambar yang bermakna,
dan metadata yang sesuai dengan isi halaman.
Bagaimana pekerjaan direview dan dirilis
Setiap perubahan melewati review, bahkan saat perubahannya kecil — di sanalah penamaan,
aksesibilitas, dan kasus tepi tertangkap saat masih murah diperbaiki. Kami menjaga
branch tetap pendek, menulis pesan commit yang menjelaskan alasan perubahan, dan
menganggap continuous deployment sebagai hal normal: push ke main, pantau build, dan
verifikasi di produksi.
Sebelum rilis kami menjalankan daftar periksa singkat: apakah halaman tetap tampil tanpa JavaScript, apakah redirect dari URL lama masih bekerja, apakah sitemap dan canonical benar, dan apakah kami bisa melakukan rollback dalam satu langkah bila ada masalah.
Serah terima: kode yang bisa tim Anda rawat
Akhir sebuah proyek adalah awal dari kepemilikan. Kami menyerahkan repositori dengan README yang menjelaskan cara menjalankan, membangun, dan men-deploy situs, di mana konten disimpan, bagaimana media disimpan, dan keputusan mana yang mungkin perlu dikunjungi ulang nanti. Kalau tim Anda ingin mengambil alih pengembangan, kami memudahkannya; kalau Anda lebih suka kami tetap terlibat, itulah fungsi dukungan berkelanjutan kami.
Apa yang kami terbitkan di topik Kode
Artikel di topik ini membahas satu keputusan pada satu waktu: pemodelan konten, strategi rendering, skrip pihak ketiga, migrasi dan redirect, serta cara menjaga situs yang makin besar tetap bisa diprediksi. Semuanya ditulis untuk orang yang harus hidup dengan hasilnya — tim pemasaran, pemilik produk, dan developer yang mewarisi kode.
Kalau Anda sedang merencanakan pembangunan atau penyelamatan proyek, ceritakan proyek Anda dan kami akan menunjukkan pendekatan kami.