Apa itu Profiling?
Ketika kita membuat perangkat lunak apapun, atau dalam kasus saya aplikasi web, kita harus menganalisa performa dari perangkat lunak agar dapat mengetahui seberapa baik aplikasi kita berjalan dan mencari tahu apakah ada masalah dalam performa yang dapat diperbaiki sehingga aplikasi dapat berjalan sebaik mungkin.
The perfect app
Setiap developer secara jelas menginginkan aplikasinya untuk berjalan sebaik mungkin dan dalam kasus aplikasi web, salah satu metric performa untuk performa adalah load time. Saya ingin mengarahkan mata Anda ke kutipan di bawah ini untuk mengetahui seberapa pentingnya performa yang baik dalam suatu aplikasi.
A Bing study found that a 10ms increase in page load time costs the site $250K in revenue annually. – Rob Trace and David Walp, Senior Program Managers at Microsoft
Mungkin anda bingung mengapa selisih 10 ms akan sangat berpengaruh terhadap pendapatan suatu perusahaan per tahun karena 10 ms merupakan waktu yang sangat singkat, tetapi katakan kita membuat situs yang melibatkan banyak transaksi, dan setiap transaksi membutuhkan waktu 100 ms, aplikasi tersebut kira kira dapat melakukan 864000 transaksi per hari . Ketika kita menambahkan 10 ms ke waktu eksekusi untuk transaksi tersebut menjadi 110 ms, kita hanya dapat melakukan 785454 transaksi per hari. Katakan setiap transaksi kita mendapatkan 0.01 US Dollar, ini berarti kita akan kehilangan 595.46 US Dollar per hari. Jika kita kalikan dengan 365 berarti kita akan kehilangan 217342.9 US Dollar per tahun. Jika untuk setiap transaksi kita mendapatkan sedikit lebih banyak uang (sekitar 15 persen) maka dapat dengan jelas kita ketahui mengapa peningkatan page load time dapat mengurangi $250K dari pendapatan suatu perusahaan per tahun. Oleh karena itu kita harus bekerja keras supaya aplikasi kita dapat berjalan secara instan sehingga pendapatannya akan maksimal bukan?
Salah satu masalah besar yang dapat dilakukan oleh seorang pengembang perangkat lunak adalah untuk mengkhawatirkan optimisasi segala aspek dari program mereka sehingga menghabiskan banyak waktu yang seharusnya dapat digunakan pada pengembangan fitur agar dapat dipublikasikan dengan lebih cepat. Ini merupakan kesalahan yang disebut premature optimization dan berikut adalah pendapat Donald Knuth, salah satu orang yang berkontribusi dalam mengembangkan Knuth – Morris – Pratt Algorithm:
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. – Donald Knuth
Berarti ketika ada suatu hal yang sebenarnya dapat diperbaiki, kita harus menganalisa dulu apakah hal tersebut critical. Kalau tidak, seharusnya ditinggalkan saja, atau jika dapat dilakukan secara instan atau setidaknya tanpa menghabiskan waktu yang lama, lakukan secukupnya.
Aplikasi yang digunakan untuk profiling
Saya menggunakan Chrome Devtools untuk melakukan profiling dasar. Menurut dokumentasi yang bisa diakses di link ini, Chrome DevTools adalah serangkaian perangkat yang dibangun secara langsung ke dalam aplikasi Google Chrome yang dapat digunakan untuk men-diagnosa atau mengubah suatu halaman web dengan mudah. Salah satu fitur yang paling sering digunakan mungkin adalah fitur inspect element, karena saya melihat begitu banyak meme yang dibuat dengan mengganti kata-kata pada suatu situs tertentu. Untuk mengakses Chrome DevTools, anda dapat membukanya dengan meng-klik kanan dan mengklik inspect, atau menekan Control+Shift+C pada Windows (untuk OS lain dapat dilihat pada dokumentasi yang dapat diakses pada tautan ini).
Dalam ini, ada banyak sekali tab yang dapat kita pakai. Ada Device Mode, yang biasa digunakan Front End Developer untuk mengubah tampilan sehingga seakan-akan ditampilkan pada perangkat mobile, Elements Panel dimana fitur untuk mengganti DOM dan CSS dapat ditemukan, Console Panel dimana kita dapat melihat log console (saya, dan saya yakin, banyak developer menggunakan fitur ini untuk menguji fitur aplikasi web yang dibuat dengan command console.log), ataupun mengevaluasi nilai suatu variabel dengan menginput nama variabel tersebut dalam consolenya (akan direturn nilainya jika variabel tersebut tidak bersifat private), Sources Panel yang seharusnya digunakan untuk melakukan debugging javascript, Network Panel yang digunakan untuk mendebug aktivitas network, Performance Panel yang digunakan untuk mengukur dan mencari masalah dalam performa, Memory Panel, yang digunakan untuk mencari memory leak jika ada, Application Panel, yang digunakan untuk mencari resource yang di-load, dan Security Panel untuk menganalisa isu yang berhubungan dengan Security.
Hasil Profiling
Untuk kasus ini, saya menggunakan Chrome DevTools untuk mengetahui seberapa lama home page aplikasi saya dapat ter-load. Karena aplikasi kami hanya ada satu tipe user saja (tautan akan mengarah ke blog post tentang persona), dan karena saya meminta agar situs tidak diakses oleh orang lain terlebih dahulu sebelum profiling, kami pasti hanya akan menguji performa aplikasi untuk satu pengguna saja, untuk satu tipe user. Panel yang akan saya pakai adalah Performance dan Network. Berikut adalah tampilan hasilnya
Performance
Network
Dapat dilihat pada performance, tepatnya pada screengrab di bawah grafik bahwa aplikasi memiliki waktu loading yang sangat lama dari mulai penekanan enter pada omnibox. Saya memprediksi hal ini akan terjadi karena aplikasi kami untuk sekarang dilayani menggunakan Heroku dengan plan gratis. Dengan Plan Gratis, Dyno akan tidur setelah inaktif selama 30 menit (untuk mengetahui lebih lengkap arsitektur perangkat lunak yang kami buat, anda dapat mengakses tautan ini).
Solusi yang saya dapat berikan untuk ini adalah untuk membeli paket Hobby dimana untuk setiap Dyno, akan dihargai sebesar 7 Dollar. Ini seharusnya cukup untuk aplikasi skala kecil yang kami buat (tautan akan menuju ke detil arsitektur perangkat lunak kami). Anda dapat melihat dibawah bahwa ketika situs dicoba untuk dijalankan kembali, maka loading akan terjadi dengan sangat cepat.
Pada Tab Network, dapat dilihat bahwa terdapat sedikit sekali javascript yang di-load. Padahal, ketika kita lihat folder src dari aplikasinya saja dapat dilihat bahwa terdapat banyak sekali file javascript.
Hal ini disebabkan oleh fitur Build yang tersedia pada React Scripts yang tersedia jika anda menggunakan Create React App, sebuah perangkat lunak yang direkomendasikan untuk digunakan untuk membangun aplikasi satu laman berbasis React, untuk membangun aplikasi satu laman anda (anda dapat mengakses situsnya dengan mengklik tautan ini). Fitur ini akan meminimalkan file Javascript yang dibutuhkan dan membaginya dalam beberapa chunk yang akan di-load sesuai kebutuhan. Untuk selengkapnya dapat anda dapat mengklik tautan ini untuk mengunjungi laman dokumentasi React Scripts yang tersedia.
Menggunakan React Profiler
Permasalahannya di atas adalah pengaksesan yang lambat ke aplikasi, dan argumentasi yang saya berikan adalah bahwa aplikasi tersebut berjalan dengan lambat bukan karena konfigurasi aplikasi kami yang tidak teroptimisasi dengan baik, tetapi karena Heroku harus “membangunkan” dyno-nya terlebih dahulu sebelum kami dapat mengakses halaman splash page. Mari kita coba menggunakan React Profiler untuk memastikan bahwa kesalahan terletak pada Heroku dan bukan kami.
Untuk menggunakan React Profiler pada browser Chrome, anda dapat pergi ke Chrome Webstore dan mencari React Developer Tools.
Dengan penambahan React Developer Tools, akan ada dua tab tambahan, yaitu Components dimana kita bisa melihat components yang digunakan untuk melakukan konstruksi halaman tersebut, dan Profiler dimana performa aplikasi berbasis react dapat diukur.
React Developer Tools sebagai ekstensi memiliki fitur dimana pengguna akan menentukan apakah sebuah halaman dibuat menggunakan React. Jika tidak, maka anda dapat melihat tanda di sebelah omnibox yang akan terlihat seperti ini 
. Kalau ya, maka anda dapat melihat tanda di sebelah omnibox yang akan terlihat seperti ini 
.
Jika anda mengklik simbolnya, maka anda dapat melihat notifikasi bahwa halaman tersebut menggunakan react versi development, react versi production ataupun tidak menggunakan react sama sekali.
Mari kita jalankan aplikasi secara lokal agar kita dapat fokus untuk menguji aplikasi tanpa ada overhead dari proses heroku.
Components Tab
Profiler Tab
Jika melihat Components dan membandingkannya dengan Profiler tab, maka dapat disimpulkan bahwa semuanya berhasil di render. Jika melihat lebih jauh lagi, dapat dilihat bahwa Profiler melihat bahwa aplikasi dijalankan selama 19.5 ms sebelum komponen diberhentikan, ada beberapa jeda untuk me-render Pagecontainer dan ada beberapa jeda juga dari mounting komponen PageContainer (yang merupakan komponen utama yang di-render) dengan mounting komponen anaknya. Total Render Time dari PageContainer adalah 18.4ms, dengan loading selama 11 ms sebelum komponen anaknya di-render yang dihabiskan untuk menjalankan konstruktor dan metode-metode yang dijalankan setelah komponen tersebut baru di-mount dan setiap kali komponen tersebut di-render, dan juga 1.1ms setelah aplikasi dijalankan untuk me-load komponen pertamanya. Tetapi apakah itu cukup baik?
Menurut Jakob Nielsen, response time dibagi tiga:
- Sekitar 0.1 detik untuk komponen yang interaktif agar pengguna merasa bahwa mereka benar-benar berinteraksi dengan komponen tersebut secara langsung
- Sekitar 1.0 detik agar tidak meng-interrupt user flow
- Sekitar 10 detik agar tidak meng-interrupt user attention
Karena loading ter-lama adalah 11ms / 1.1 detik, maka meski sedikit lebih tinggi dibandingkan 1 detik, itu sesuai poin kedua dimana ia seharusnya tidak meng-interrupt user flow ketika loading terjadi maksimum sekitar 1.0 detik.
Kesimpulan yang bisa ditarik disini adalah, benar fakta bahwa heroku meng-interrupt performa secara besar, dan agar performa aplikasi dapat membaik, maka saya sarankan untuk meng-upgrade plan heroku agar dyno tidak akan tidur.
Penutup
Sebenarnya masih banyak lagi hal yang dapat dilakukan untuk mem-profile aplikasi secara keseluruhan, tetapi karena yang terpikirkan oleh saya adalah user experience ketika pertama kali membuka aplikasi itu, hal inilah yang saya lakukan. Jika ada kesalahan, atau ada saran mengenai profiling yang dapat saya lakukan, anda dapat mengomentarinya di bawah atau bahkan menghubungi saya secara langsung. Terima kasih telah membaca blog post ini, dan nantikan blog post selanjutnya yang mungkin akan menjelaskan tentang user evaluation atau user acceptance test.
Sumber:
https://auth0.com/blog/12-steps-to-a-faster-web-app/
Catatan sehari hari 