Panduan ini akan menjadi dasar bagaimana sebuah web modern atau biasa disebut Progressive Web App(PWA) dikembangkan. Karena sebagian besar permasalahan web pada saat sudah berjalan adalah arsitektur yang kurang baik serta perancangan awal yang tidak disesuaikan dengan kebutuhan pengguna. Panduan ini akan memberikan gambaran bagaimana arsitektur dan perancangan sebuah aplikasi modern web tanpa menggunakan framework apapun, namun tetap bisa diterapkan di framework apapun.

Kriteria Modern Web

Untuk kebutuhan website modern yang fokus pada kebutuhan pengguna, makan kita mendefinisikan modern web sebagai berikut:

Aman

Menggunakan protokol HTTPS sehingga menjamin konten tidak diubah di jaringan (biasanya terinjeksi iklan oleh operator, atau script berbahaya oleh virus atau hacker). Serta proses transmisi data dari pengguna ke server tidak dipindai oleh pihak yang tidak diinginkan. Misalnya proses input data kartu kredit di website e-commerce.

Cepat

Dapat dimuat dan digunakan dalam waktu 5 detik di jaringan 3G dengan spesifikasi perangkat mobile menengah.

Stabil

  • Dapat diakses walaupun kondisi jaringan sedang offline atau sangat lambat.
  • Bisa beradaptasi dengan spesifikasi dan kondisi perangkat serta jaringan sehingga tetap nyaman digunakan walaupun diperangkat dengan spesifikasi rendah dan jaringan yang lambat.

Membuat betah dan nyaman

  • Tampilan yang nyaman diakses dari ukuran layar perangkat mobile, tablet, atau desktop.
  • Mampu memberikan respon terhadap interaksi (klik mouse atau tap) secara instant (kurang dari 200ms) Tidak melakukan sesuatu yang menganggu kenyamanan pengguna dalam mengakses konten atau layanan.

Terintegrasi

  • Memberikan fungsi yang dibutuhkan layaknya sebuah aplikasi seperti notifikasi, login dengan sidik jari, dan lainnya.
  • Bisa diakses dengan mudah lewat layar utama hanya dengan menekan icon, tanpa harus mengetik alamat pada browser.
  • Memudahkan pengguna dalam membagikan konten tanpa harus copy paste alamat URL konten.

Daftar lebih detail bisa dilihat di checklist PWA ini.

Menentukan Arsitektur

Berdasarkan kriteria modern web di atas, maka arsitektur akan berperan penting untuk mencapai hal di atas. Karena ada beberapa yang tidak mungkin dicapai tanpa penerapan arsitektur yang tepat. Dan arsitektur yang mendukung semua hal di atas adalah arsitektur Application Shell atau biasa disebut Single Page Application(SPA). SPA adalah arsitektur yang memungkinkan kita berpindah halaman di web tanpa harus melakukan proses loading halaman secara keseluruhan. Pada saat pengguna berpindah halaman, maka hanya konten di tengah halaman saja yang akan diperbaharui. Sedangkan bagian header yang biasa memuat logo, menu, dan search bar biasanya tidak berubah. Terkadang elemen navigasi lainnya yang tidak berubah juga adalah footer(bagian bawah halaman), dan sidebar/drawer (bagian samping yang biasa menjadi navigasi di perangkat mobile).

image

Single Page Application dengan aristektur application shell (sumber: https://developers.google.com/web/fundamentals/architecture/app-shell)

Pilihan arsitektur SPA ini biasanya kurang familiar dengan pengembang PHP, Python, Ruby atau server side scripting lainnya karena biasanya pengembang biasanya secara default akan menggunakan arsitektur Multi Page Application(MPA). MPA adalah arsitektur di mana aplikasi web berpindah halaman dengan melakukan loading halaman keseluruhan termasuk header, footer, dan sidebar halaman web walaupun bagian tersebut masih sama. Kekurangan arsitektur ini adalah pengguna akan melihat jeda perpindahan halaman, karena browser akan menimpa keseluruhan halaman yang tampil dengan halaman baru. Berbeda dengan arsitektur SPA yang hanya mengganti bagian konten tengah saja.

Karena itu, bagi pengembang yang menggunakan bahasa pemrograman server side scripting, pertimbangkan untuk memisahkan arsitektur aplikasi di mana aplikasi server side script berfungsi untuk mengirimkan data atau hanya untuk untuk proses rendering pertama. Namun selanjutnya untuk navigasi atau perpindahan antar halaman akan ditangani oleh client side, atau JavaScript di halaman web.

Untuk memudahkan, beberapa library/framework populer sebenarnya sudah menggabungkan konsep SPA dengan server side rendering beberapa contohnya adalah:

Terkait bagaimana penggunaan setiap framework, silakan mengecek dokumentasi masing-masing.

Persiapan

Sebelum memulai pengembangan ada baiknya menyiapkan beberapa hal penting yang akan memudahkan pengembang.

Tools Pengembangan

Tool pengembangan tentu menjadi pilihan yang akan memudahkan dalam proses pengembangan. Di panduan ini tidak akan membahas terlalu jauh, karena biasanya setiap pilihan framework sudah memiliki tool pengembangan sendiri. Dan setiap pengembang juga sudah memiliki code editor favorit. Tapi beberapa hal yang mungkin bisa membantu dalam pengembangan web modern adalah:

  • Web server yang mendukung SPA, dapat membuka aplikasi SPA tanpa harus mengakses root. Biasanya ini sama dengan penyetelan friendly URL di MPA, dimana semua URL di website tersebut disetel untuk mengarah ke file index bila file tidak ditemukan.
  • Browser debugging tool yang mendukung responsive layout, debugging service worker, cache storage, performance, network, dan lainnya. Chrome Dev Tools bisa menjadi pilihan awal bila belum memiliki preferensi.

image

Tampilan proses debugging yang secara default selalu menampilkan mobile layout di Chrome Dev Tools.

  • Build tools yang digunakan untuk mem-bundle semua aset aplikasi web untuk siap di-deploy ke server. Build tools yang popular saat ini adalah Webpack dan Parcel. Lebih jauh terkait build tools akan dibahas terpisah.

Target Dasar Pengguna

Tentukan kira-kira target dasar pengguna website yang akan dibuat seperti apa. Dalam menentukan kita bisa melakukan pengecekan pada beberapa referensi dan yang perlu diperhatikan dari sisi pengguna adalah:

  • Jenis perangkat yang digunakan (mobile, tablet, atau desktop).
  • Spesifikasi perangkat (spesifikasi rendah, menengah, atau tinggi).
  • Kondisi jaringan (Wifi, 4G, 3G, atau 2G) termasuk apakah kemungkinan offline cukup tinggi, misalnya akan digunakan di gunung atau di hutan.
  • Jenis atau versi browser yang digunakan oleh pengguna, apakah pengguna menggunakan modern browsers(Chrome, Firefox, Safari, Edge,Opera, dan lain-lain) yang selalu diperbaharui, atau tidak.

Terkadang kita bisa mengasumsikan faktor-faktor di atas berdasarkan jenis websitenya. Sebagai contoh, bila sifatnya adalah profil perusahaan maka kita berasumsi perangkat mobile, tablet, dan desktop spesifikasi menengah dengan jaringan 3G. Yang sering jadi kesalahan adalah beberapa pengembang fokus pada desktop pada saat mengembangkan website profil perusahaan karena pada saat presentasi ke klien, memang menggunakan laptop dan wifi. Tapi pada saat klien ingin menunjukkan ke partner pada saat ketemu di event, mereka menggunakan perangkat mobile di jaringan 3G yang padat pengguna, dan klien tidak bisa menunjukkan profil perusahaannya karena layout berantakan di mobile, atau terlalu berat karena di mobile, atau bahkan tidak tampil karena di jaringan 3G padat dan lambat. Jadi pastikan kita memahami kapan aplikasi web akan digunakan, perangkat apa, dan di jaringan apa.

Tentukan Sumber Daya Kritis

Sumber daya kritis di aplikasi web adalah file yang dibutuhkan oleh sebuah web untuk dapat menampilkan sesuatu di layar dengan baik. Bila file ini tidak terunduh semua, maka browser tidak akan dapat menampilkan sesuatu di layar. File ini biasanya terdiri dari:

  • HTML dokumen halaman yang akan ditampilkan
  • CSS file yang digunakan untuk layout halaman
  • JavaScript file yang digunakan untuk menampilkan halaman. Ini biasanya merupakan library UI yang menggunakan JavaScript. Misalnya jQuery UI,
  • Fonts, bila tidak diatur dengan benar bisa jadi font membuat konten teks tidak ditampilkan sampai font selesai diunduh.

Biasanya bila kita menggunakan arsitektur Single Page App(SPA), hal ini biasanya diatur oleh build tool yang kita gunakan misalkan Webpack, atau Parcel. Bila kita tidak menggunakan arsitektur SPA dan memasukkan manual file JavaScript, CSS, dan fonts ke halaman HTML kita maka akan diperlukan proses optimasi yang sebaiknya:

  • Ukuran file sekecil mungkin. Ini bisa dicapai dengan membuang spasi, komentar, kode tidak terpakai, dan kompresi file.
  • Jumlah file sesedikit mungkin karena ini berhubungan dengan jumlah request. Ini biasanya dibantu build tool untuk mengabungkan aset statis kita ke dalam satu file yang sama.
  • Round trip atau proses bolak balik meminta ke server seminimal mungkin, ini biasanya terjadi bila ada CSS atau JavaScript yang memanggil atau memasukkan file lain. Contohnya hindari penggunaan import di file CSS. Usahakan hanya terjadi satu round trip dimana file HTML yang menjadi referensi file mana saja yang dibutuhkan untuk menampilkan sesuatu di layar.

Jadi di awal pengembangan, silakan tentukan berapa file kritis maksimal dan berapa total ukuran dari file kritis ini. Dan ini bisa dimasukkan dalam anggaran kecepatan yang menjadi topik berikutnya.

Tentukan Anggaran Kecepatan

Kecepatan tampil sebuah website sangat bergantung terhadap seberapa besar ukuran file yang dimuat oleh browser, spesifikasi perangkat, dan kecepatan jaringan. Karena itu sebelum kita bisa menentukan anggaran kecepatan website, kita harus menentukan target dasar pengguna seperti yang dijelaskan di atas.

Kalau kita menetapkan target kecepatan tampil dan bisa digunakan aplikasi web kita pada 5 detik, maka untuk perangkat Android harga 2 jutaan, dan jaringan 3G yang berkisar 400 Kbps perhitungannya akan sebagai berikut:

1,6 detik akan digunakan untuk DNS lookup dan TLS handshaking.

Sisa 3,4 detik untuk melakukan download dan pemrosesan keseluruhan file. Dan kalau kita kalkulasi maka di jaringan 400Kbps

400 Kbps = 50KB/s

50KB/s * 3,4 = 170KB

Dengan perhitungan di atas, kita hanya punya anggaran kecepatan sebesar 170KB ukuran file yang bisa dikirim. Ini belum termasuk waktu pemrosesan, karena setiap file seperti HTML, CSS, JS tentunya setelah di-download perlu di-parsing dan di-compile. Untungnya file seperti HTML, CSS, dan JS bisa dikompres. Sehingga ukuran 170KB kalau tidak dikompres akan berkisar 0,7 MB atau sekitar 700KB.

image

Gambaran anggaran kecepatan untuk 170KB menggunakan framework (sumber: https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e)

Jadi usahakan dalam membuat aplikasi web yang cepat bila ingin ditampilkan dalam 5 detik, maka hasil build untuk di-deploy ke server maksimal total ukurannya adalah 700KB. Coba kita lihat beberapa perbandingan ukuran file default bila kita menggunakan library atau framework. Di Indonesia, library Bootstrap adalah salah satu library populer terutama di pengembang PHP. Bila kita menggunakan Bootstrap dalam website kita maka kurang lebih anggaran kecepatan kita menjadi:

Bootstrap CSS dan JavaScript

CSS 21KB tanpa dikompres menjadi 138KB

JS 20KB tanpa dikompres menjadi 69KB

Total 41KB tanpa dikompres menjadi 207KB

Kalau cuma menggunakan CSS dan JS files dari Bootstrap kita sudah menghabiskan 200KB dari total 700KB. Sehingga sisa yang bisa kita gunakan adalah sekitar 500KB.

Lalu kita butuh jQuery karena beberapa plugin atau themes Bootstrap bergantung pada jQuery.

jQuery v3 30KB tanpa dikompres menjadi 84KB

Sisa anggaran kecepatan 500–84 = 416KB.

Nah dengan demikian bila kita menggunakan library Bootstrap dan jQuery maka sisa ukuran file yang bisa kita gunakan pada load awal aplikasi kita pada saat pertama kali dibuka adalah 416KB saja. Dan ini mungkin akan kombinasi antara HTML, fonts, gambar, serta library lainnya yang mungkin kita gunakan seperti corousel, dialog window, dan lainnya.

Dengan atau Tanpa Build Tools

Untuk bisa membuat kode yang kita bikin bisa teroptimasi seperti kode yang lebih kecil, dan hanya memuat kode yang dipakai saja di dalam aplikasi bila kita menggunakan library maka kita memerlukan tool untuk membantu kita. Pertanyaannya apakah kita ingin menggunakan build tools atau hanya ingin membuat ukuran file lebih kecil?

Bila kita tidak ingin terlalu kompleks, pilihannya bisa hanya sekedar melakukan minify pada file kita. Atau bahkan kalau kita tidak ingin melakukan minify, pastikan kita memasang gzip compression di web server kita agar response web server akan selalu terkompresi.

Namun bila ingin lebih optimal, maka kita memerlukan build tools seperti Webpack atau Parcel. Build tools bisa membantu kita untuk melakukan optimasi kode kita seperti:

  • minify kode dengan membuang kode yang tidak perlu seperti space dan komentar.
  • tree shaking, atau membuang kode yang tidak terpakai dalam aplikasi kita. Ini berguna bila kita menggunakan library dalam aplikasi kita.
  • code spliting, atau memisahkan kode kita berdasarkan halaman web sehingga kode yang dimuat di halaman tersebut hanyalah kode yang terpakai di halaman tersebut.
  • code transform, melakukan transformasi kode kita agar bisa berjalan di versi browser yang kita targetkan.

Webpack adalah build tool paling populer karena muncul sebelum Parcel. Parcel sendiri mulai populer karena kemudahan penggunaannya yang mengusung _zero configuratio_n, dalam artian bisa langsung digunakan tanpa konfigurasi. Beberapa hal yang perlu disiapkan pada saat kita memasang build tools sebelum memulai pengembangan adalah:

  • Atur build tools agar sesuai dengan anggaran kecepatan yang sudah kita set sebelumnya. Sebagai contoh adalah total ukuran aplikasi kita setelah di-build adalah 170KB sesuai yang kita jabarkan di anggaran kecepatan kita sebelumnya. Kalau kalian menggunakan Webpack, kalian bisa melakukan konfigurasi anggaran kecepatan kalian seperti dijelaskan di dokumentasi Webpack ini. Untuk tool lain, bila tidak memiliki pengaturan untuk anggaran kecepatan, bisa mengecek dengan manual setiap build pastikan agar hasil build tidak melebihi ukuran maksimal yang sudah diset di anggaran kecepatan.

image

Warning bila hasil build melebihi maksimal anggaran kecepatan pada Webpack (sumber: https://medium.com/webpack/webpack-performance-budgets-13d4880fbf6d)

  • Tentukan target build kita untuk JavaScript versi berapa, apakah ES5 atau ES6. Atau mungkin sesuai versi browser, misalnya 2 versi terakhir dari browser modern. Saya biasanya membuat 2 target build. Satu untuk versi yang bisa jalan di search engine crawler(Googlebot menggunakan Chrome versi 41), dan satu untuk 2 versi terakhir browser.

Kesimpulan

Dalam mempersiapkan pengembangan web, tentunya kita harus sesuai dengan target pengguna kita. Sehingga kita bisa merancang aplikasi web kita sesuai dengan kondisi pengguna. Sehingga pengguna bisa mengakses dan menggunakan aplikasi web kita dalam kondisi apapun. Dan untuk memudahkan kita dalam proses pengembangan kedepannya maka sangat penting untuk memperhatikan pemilihan arsitektur, dan anggaran kecepatan dalam aplikasi web kita. Karena mengubah 2 hal ini di dalam aplikasi web kita bisa dibilang akan sangat rumit dan terkadang memaksa pengembang untuk memulai pengembangan web dari awal lagi karena tidak dapat memenuhi kebutuhan penggunaannya.