Dampak Web Bloat terhadap Pengguna Perangkat Lambat

 (danluu.com)
1 poin oleh GN⁺ 2024-03-17 | 1 komentar | Bagikan ke WhatsApp
  • Sejak 2017, peningkatan bandwidth sampai batas tertentu melampaui pertumbuhan ukuran transfer situs umum, tetapi kebutuhan CPU aplikasi web meningkat lebih cepat daripada performa perangkat kelas bawah, sehingga aksesibilitas web memburuk bahkan dengan internet cepat
  • Bahkan pada koneksi 1Gbps, Tecno Spark 8C mengalami crash browser di forum Discourse, dan pada Itel P32, situs seperti Discourse, Reddit, Shopify, Substack, Wix, Mastodon, dan Bluesky menjadi FAIL atau praktis tidak dapat digunakan
  • Pengukuran membandingkan LCP* dan waktu CPU thread utama pada M3 Max, M1 Pro, Chrome dengan throttling CPU 10x, Tecno Spark 8C, dan Itel P32; skor PageSpeed Insights memiliki korelasi lemah dengan kecepatan yang benar-benar dirasakan
  • Situs sederhana atau lama seperti MyBB, phpBB, WordPress lama, HN, dan danluu.com berjalan relatif baik bahkan di ponsel kelas bawah, sedangkan situs dengan banyak pemuatan dinamis seperti Discourse, Medium, Reddit, dan Substack menunjukkan lag saat scroll, pencarian, dan tap yang mencolok
  • Pengguna perangkat kelas bawah di wilayah seperti Nigeria, India, dan Amerika Latin adalah pengguna web nyata; jika web dibuat hanya dengan tolok ukur iOS dan internet cepat, pengguna yang kurang mampu serta pengguna desktop berspesifikasi rendah ikut tersisih

CPU menjadi bottleneck web, bukan bandwidth

  • Pada 2017, web bloat sangat merusak usability pada koneksi lambat, dan setelah itu bandwidth koneksi kelas atas meningkat cepat, sekitar 50% per tahun menurut Nielsen
  • Masih banyak pengguna dengan internet lambat, dan sebagian besar web modern sulit digunakan pada koneksi lambat, tetapi pada situs umum peningkatan bandwidth sampai batas tertentu melampaui pertumbuhan ukuran transfer
  • Sebaliknya, kebutuhan performa CPU aplikasi web tidak membaik secepat bandwidth, sehingga web menjadi sulit digunakan di perangkat berspesifikasi rendah meski koneksi internetnya bagus
  • Forum “modern” berbasis Discourse bahkan dapat menyebabkan crash browser di Tecno Spark 8C, dan responsivitas di antara crash juga diukur lebih buruk daripada memakai BBS dengan 8 MHz 286 dan modem 1200 baud
  • Payload terkompresi untuk memuat judul pesan di Discourse berukuran 2.6 MB, sekitar 1000x lebih besar dibanding masa lalu, tetapi relatif ringan pada koneksi 1Gbps
  • Dari sisi CPU, Tecno Spark 8C dengan 8-core (2 1.6 GHz Cortex-A75 / 6 1.6 GHz Cortex-A55) pun tidak mampu menangani Discourse, padahal CPU tersebut kira-kira 100000x lebih cepat daripada 286

Target dan metrik pengukuran

  • Perangkat uji adalah M3 Max Macbook (14-core), M1 Pro Macbook (8-core), M3 Max dengan throttling 10x di Chrome DevTools, Tecno Spark 8C, dan Itel P32
  • Agar menguntungkan perangkat, jaringan memakai internet 1Gbps dan router WiFi yang dibenchmark memiliki latensi rendah saat berbeban
  • Objek perbandingan mencakup blog/microblog, forum, dan platform untuk bisnis kecil
    • Blog/microblog: danluu.com, Substack, Medium, Ghost, Hugo, Tumblr, Mastodon, Twitter, Threads, Bluesky, Patreon
    • Forum: Discourse, Reddit, Quora, vBulletin, XenForo, phpBB, MyBB
    • Platform bisnis kecil: Wix, Squarespace, Shopify, WordPress
  • Metrik utama adalah ukuran terkompresi saat transfer (wire), ukuran setelah dekompresi (raw), LCP*, dan waktu CPU thread utama
  • LCP* bukan Largest Contentful Paint yang diukur Chrome, melainkan titik ketika konten yang benar-benar berguna terlihat, jika pembaruan layar besar tidak berguna bagi pengguna
  • Waktu CPU bukan Core Web Vital, tetapi dipakai sebagai metrik sederhana yang sangat terkait dengan usability yang dirasakan pengguna di perangkat lambat

Kesenjangan usability yang terlihat dari tabel

  • danluu.com dan HN berjalan cepat di semua perangkat uji
    • danluu.com: 6kB wire / 18kB raw, 0.4s LCP* / 0.3s CPU pada Tecno Spark 8C
    • HN: 11kB wire / 50kB raw, 0.5s LCP* / 0.5s CPU pada Tecno Spark 8C
  • Forum lama berbasis PHP jauh lebih baik di perangkat lambat daripada forum modern
    • MyBB: 0.8s LCP* / 0.8s CPU pada Tecno Spark 8C
    • phpBB: 1.7s LCP* / 1.5s CPU
    • vBulletin: 4.4s LCP* / 4.8s CPU
    • Discourse: 15s LCP* / 26s CPU, dan FAIL pada Itel P32
  • Di platform blog pun, tema WordPress lama jauh lebih cepat pada perangkat berspesifikasi rendah daripada Medium dan Substack
    • WordPress(old): 0.7s LCP* / 1.7s CPU pada Tecno Spark 8C
    • Medium: 2.8s LCP* / 33s CPU
    • Substack: 14s LCP* / 14s CPU
  • Banyak situs modern gagal atau praktis tidak dapat digunakan pada Itel P32
    • XenForo, Mastodon, Bluesky, Wix, Substack, Shopify, Discourse, dan Reddit: FAIL
    • Threads: 28s LCP* / 66s CPU, Twitter: 24s LCP* / 43s CPU, Medium: 3.2s LCP* / 63s CPU
  • Halaman yang memakai 10s+ CPU menciptakan pengalaman buruk bahkan setelah selesai dimuat
    • Scroll turun hingga hanya beberapa FPS, dan delay tap menjadi panjang sehingga pengguna sulit tahu apakah tap sudah terdaftar
    • Jika pengguna tap lagi, tap pertama bisa baru terdaftar terlambat lalu tap kedua memicu tindakan yang tidak diinginkan

Perbedaan antara perangkat nyata dan throttling CPU

  • Throttling CPU Chrome DevTools praktis, tetapi tidak secara konsisten mendekati hasil pada perangkat lambat nyata
  • Dalam perbandingan M3/10 dan Tecno Spark 8C, perbedaannya sangat bervariasi antar-situs
    • danluu.com dan Ghost cukup mendekati
    • Medium, Substack, dan Twitter memiliki waktu CPU sekitar 3x lebih lambat pada Tecno Spark 8C
    • Reddit dan Discourse sekitar 4x lebih lambat
    • Shopify menunjukkan hasil Tecno Spark 8C lebih cepat lebih dari satu digit dibanding M3/10
  • Halaman lambat kadang menjadi lebih lambat secara superlinear ketika perangkat makin lambat, dan kelambatan satu halaman tidak selalu memprediksi kelambatan halaman lain
  • Discourse, Medium, dan Reddit tampak tidak banyak memakai CPU pada M3 dan M1, tetapi pada Tecno Spark 8C termasuk yang paling lambat
  • Reddit memakai ~90% CPU meski hanya ditunggu tanpa interaksi, sehingga CPU ditandai sebagai ∞

Kekuatan situs lama dan halaman sederhana

  • Situs lama umumnya lebih cepat daripada situs terbaru, dan situs yang secara visual tidak banyak berubah selama 10–20 tahun termasuk yang paling cepat
  • MyBB lebih cepat daripada Discourse sebesar 3.6x / 5x pada M3, dan 19x / 33x pada Tecno Spark 8C
  • WordPress(old) diukur lebih cepat daripada Medium sebesar 17.5x / 10x pada M3 Max, dan 4x / 19x pada Tecno Spark 8C
  • Ghost adalah platform modern yang diluncurkan setahun setelah Medium, tetapi menjadi pengecualian karena performanya mampu bersaing dengan platform lama
  • NodeBB juga hampir menjadi pengecualian di antara forum modern dalam pengujian lampiran
    • 0.3s / 0.4s pada M1
    • 3.4s / 7.2s pada Tecno Spark 8C
    • Jauh lebih cepat daripada Discourse, dan scroll serta tap setelah load pada dasarnya berfungsi

Jebakan pemuatan dinamis dan optimasi metrik

  • Situs yang memuat sebagian halaman terlebih dahulu lalu mengambil sisanya secara dinamis, seperti Discourse, Reddit, dan Substack, memiliki usability nyata yang lebih buruk daripada skor di tabel
  • Pada perangkat lambat, sulit memprediksi jarak scroll, dan jika scroll terlalu jauh, pemuatan tambahan dapat terpicu dan membuat halaman berhenti
  • Halaman yang menghapus konten lama yang sudah discroll pada praktiknya tidak dapat digunakan di perangkat lambat
  • Halaman dengan pemuatan dinamis sulit memakai pencarian cepat Ctrl/Command+F bawaan browser sebagaimana adanya, sehingga harus mengimplementasikan pencarian sendiri
    • Pencarian Google Docs selama beberapa bulan terakhir atau sekitar setahun terakhir dimuat sangat lambat sehingga sulit digunakan segera setelah dokumen dibuka
    • Pencarian Discourse tidak pernah bekerja baik di perangkat lambat atau perangkat yang tidak sangat cepat
  • Secara teori, pekerjaan CPU awal bisa membuat interaksi berikutnya lebih cepat, tetapi halaman yang diuji lambat pada load awal, load berikutnya, maupun interaksi setelah load

Gamifikasi LCP

  • LCP pada awalnya adalah metrik untuk memperkirakan kapan konten utama halaman terlihat oleh pengguna, tetapi pengukuran Chrome lebih mendekati kapan paint besar di layar terjadi
  • Sebagian situs menurunkan LCP dengan cepat menampilkan layar loading besar yang tidak membantu pengguna, lalu memecah konten sebenarnya menjadi pembaruan kecil agar tidak terhitung sebagai LCP
  • Discourse secara terbuka memperkenalkan Discourse Splash, dan menjelaskan bahwa pada load lambat, layar splash besar sangat mengurangi LCP
  • Jawaban resmi Discourse pada intinya menyebut bahwa jika banner konten sebenarnya lebih besar daripada splash, itu merugikan LCP
  • Contoh dengan selisih besar antara LCP* berbasis konten berguna dan LCP yang diukur Chrome adalah Wix dan Discourse
    • Wix: 6x pada M3, 12x pada M1, 3x pada Tecno Spark 8C
    • Discourse: 10x pada M3, 12x pada M1, 4x pada Tecno Spark 8C

Dampak optimasi performa pada bisnis

  • Di perusahaan besar, peningkatan performa situs dan aplikasi memiliki nilai finansial besar hingga bisa diukur lewat A/B test
  • Bahkan dalam holdback jangka panjang, peningkatan performa muncul sebagai intervensi yang berdampak relatif besar pada pertumbuhan dan retensi
  • Di Twitter, latensi p99 yang diamati pengguna sekitar 60s bukan hanya di India dan beberapa negara Afrika, tetapi juga di United States
  • Di tiap negara ada cukup banyak pengguna dengan perangkat atau koneksi lambat, sehingga faktor pembatas lebih dekat ke kesabaran pengguna daripada distribusi rata-rata perangkat dan koneksi di seluruh populasi
  • Perbaikan yang memangkas 60s menjadi 50s pada perangkat lambat juga dapat berdampak pada pengguna perangkat kelas atas, misalnya memangkas 5s menjadi 4.5s, serta memengaruhi pendapatan, pertumbuhan, dan retensi

Desain yang mempertimbangkan perangkat berspesifikasi rendah

  • Pada perangkat lambat atau koneksi dengan bandwidth rendah/tidak stabil, pengalaman terbaik umumnya adalah memuat banyak konten sekaligus sebagai halaman statis
  • Atribut width, height, dan alt yang tepat pada gambar membantu, tetapi progressive JPEG tidak terlalu membantu secara khusus
  • Pada perangkat lambat dengan koneksi cepat, halaman statis yang ringan berjalan baik, dan halaman dinamis ringan yang mempertimbangkan performa juga dapat berjalan
  • Pada halaman berat, pemuatan tambahan saat scroll dan pengambilalihan pencarian merusak model interaksi yang bisa digunakan
  • Substack bisa memiliki LCP artikel yang cepat di iPhone 8, tetapi ada kasus di mana untuk scroll melewati header harus menunggu load halaman berikutnya selama 6s, lalu setelah itu masih menunggu 1s~2s
  • Sebagai contoh sebaliknya, halaman plain HTML besar relatif berjalan baik bahkan di perangkat berspesifikasi rendah
  • Dokumentasi standard library Zig mengambil semua kode sumber di awal dan merender secara lokal, tetapi setelah memakai CPU 4.7s pada Tecno Spark 8C, responsivitasnya relatif tetap terjaga

Pengguna berpenghasilan rendah dan aksesibilitas

  • Tecno Spark 8C bisa didapat sekitar USD 50-60 di Nigeria dan USD 100-110 di India, tetapi proporsinya terhadap pendapatan rumah tangga median di wilayah tersebut jauh lebih besar daripada iPhone generasi saat ini di AS
  • Dalam skala global, Tecno Spark 8C tidak mendekati perangkat termurah, dan Itel P32 juga masih berada di atas banyak perangkat berspesifikasi paling rendah yang benar-benar dipakai
  • Menurut Alex Russell, pangsa iOS adalah 7% di India dan 6% di Amerika Latin
  • Berdasarkan telemetri Windows, sebagian besar pengguna laptop/desktop tampaknya memakai perangkat berspesifikasi rendah yang kemungkinan lebih lambat daripada iPhone terbaru
  • “Lifeline” phone yang diberikan kepada orang dalam pengawasan pemasyarakatan ada yang berupa iPhone 6 atau iPhone 8, tetapi banyak juga yang lebih rendah daripada Itel P32, dan batas data yang kecil dapat membuat mereka sulit mencari kerja, mengisi formulir bantuan sosial, atau memakai Maps setelah kuota habis
  • Aplikasi mobile bisa diunduh terlebih dahulu saat koneksi bagus, tetapi aplikasi web tidak dapat digunakan pada koneksi terbatas jika setiap kali diakses harus mengunduh JavaScript terkompresi berukuran beberapa MB

Kondisi dan keterbatasan eksperimen

  • Tiap situs diukur dengan mencari pengalaman yang sebisa mungkin “paling dasar”
    • WordPress memakai demo tema default saat ini, twentytwentyfour
    • Shopify memakai tema pertama yang terlihat dalam daftar tema
    • Discourse, vBulletin, XenForo, phpBB, dan MyBB memakai halaman yang ditemukan sebagai forum resmi
  • Pekerjaan ini dilakukan sebagai proyek singkat dengan pengumpulan dan analisis data dalam satu hari, sehingga tidak mencerminkan tema paling umum atau distribusi kustomisasi pengguna nyata
  • Laptop diuji pada baterai sekitar 60%, tidak tersambung daya, dan dibiarkan mendekati kesetimbangan termal di ruangan 20°C
  • Ponsel diuji pada daya sekitar 100%, tersambung listrik, tanpa aplikasi dan tab lain
  • Pengguna nyata kemungkinan besar akan melihat performa lebih buruk pada perangkat yang sama karena lebih banyak aplikasi dan pekerjaan background
  • Ukuran diukur pada mobile, sehingga jika mobile dan desktop menerima aset berbeda, ukuran aset mobile yang tercermin
  • CPU diukur sebagai waktu CPU thread utama; waktu thread lain dicatat tetapi tidak digunakan dalam metrik

Contoh penting per situs

  • Wix tidak dapat melakukan scroll dengan stabil pada Tecno Spark 8C, dan gagal secara nondeterministik pada Itel P32
  • Patreon memiliki performa scroll yang lebih buruk daripada angka load awalnya, sehingga cukup merepotkan untuk mencari posting lama sampai perlu mempertahankan indeks posting Patreon terpisah
  • Discourse sangat menggamifikasi LCP; bahkan pada koneksi 1Gbps di M3 Max, LCP yang diukur Chrome adalah 115ms, tetapi konten sebenarnya dimuat pada 1.1s
  • Bluesky menampilkan layar kosong pada Itel P32
  • Dua kasus penggunaan nyata pertama Shopify sama-sama jauh lebih lambat daripada halaman demo yang diuji
  • Tumblr mengalami error JavaScript pada Itel P32, tetapi karena itu halaman justru dimuat lebih cepat dan scroll serta klik tautan tetap bekerja
  • MyBB tidak menyediakan versi mobile sehingga bisa kurang menguntungkan di Google, tetapi pada mobile lambat, scroll dan tap benar-benar berjalan baik
  • Woo Commerce dikecualikan dari tabel karena sulit dibandingkan dengan Shopify hanya berdasarkan performa load awal, dan perlu perbandingan terpisah yang mencakup alur nyata seperti keranjang dan checkout

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-17
Opini Hacker News

  • Baru-baru ini saat mencoba ponsel Android yang relatif lambat, bahkan halaman web yang tampaknya hanya berisi teks dan gambar pun bisa terasa sangat menyiksa saat dimuat.
    Hambatan sebenarnya bukan jaringan, melainkan lebih ke pelacak dan iklan, serta JavaScript yang membengkak.
    Ponsel lama yang lambat membuat browser penuh seperti Firefox mobile sendiri terlalu berat, sehingga orang memakai browser ringan seperti Firefox Focus; tetapi karena tidak bisa memakai ekstensi, uBlock Origin pun tidak bisa digunakan dan pengalaman web jadi makin buruk.
    Beberapa situs mengeluh jika bukan browser “standar” dan menjadi tidak dapat digunakan, sementara perusahaan memaksa pengguna memasang aplikasi sebagai gantinya.
    Dulu ada versi sederhana untuk perangkat dan koneksi lambat, tetapi kini makin menghilang; mungkin karena tanpa pembengkakan JavaScript, sulit menjalankan jaringan iklan dan pelacakan.

    • Ini benar-benar situasi serba salah, karena web modern praktis tidak berguna tanpa pemblokiran iklan.
      Terutama lebih parah ketika iklan acak tertanam di halaman yang bisa di-scroll tanpa akhir.
    • Bahkan saat memakai browser standar pun, ada perusahaan yang sengaja merusak situs web agar orang memakai aplikasi.
      Contoh terbaru, web shop Nike menampilkan error yang tidak berguna saat checkout, dan tim dukungan hanya berkata “coba pakai aplikasi”.
      Situs pemesanan maskapai Eropa juga merupakan contoh umum situs web perusahaan besar yang sering rusak.
      Aneh rasanya menganggap bahwa pada 2024, dengan sumber daya yang nyaris tak terbatas, ketidakmampuan membuat situs web yang berfungsi tidak berdampak buruk pada merek.
    • Aplikasi semacam itu pun sembilan dari sepuluh kemungkinan besar hanyalah cangkang browser berisi salinan offline dari sebagian situs web.
    • Saat menulis kode untuk situs utama nokia.com 10 tahun lalu, kami mendeteksi dengan berbagai cara apakah pemuatan resource lambat, lalu menyetel flag untuk mematikan fitur tambahan.
      Situs itu harus berjalan di semua negara, dan banyak ponsel paling lambat adalah produk perusahaan tersebut.
    • Saya masih punya MacBook Pro keluaran 2013, saya simpan karena itu keyboard terbaik yang pernah dibuat Apple.
      Memang tidak cepat, tetapi tidak ada kesulitan memakai situs web; hanya tidak seketika hardware baru, namun tetap sangat layak dipakai.
      Namun saya memang memakai uBlock Origin.
      Saya penasaran apakah perangkat Android seperti ini benar-benar lebih lemah dalam praktik dibanding MacBook spesifikasi dasar berusia 11 tahun.

  • Saya sangat setuju dengan poin Dan bahwa kita harus menyadari tingkat ketimpangan di seluruh dunia, tetapi negara berpendapatan menengah seperti Amerika Latin dan Asia Tenggara juga harus dimasukkan.
    Misalnya, ada pengguna dengan kuota data bulanan satu digit GB, serta RAM/CPU setara flagship AS 10 tahun lalu.
    Bukan berarti Discourse sama sekali tidak bisa dipakai, tetapi pengalamannya kemungkinan terasa sangat lambat dan tidak menyenangkan.
    Saya rasa alasan Dan melihat peningkatan bertahap pada CPU/RAM/disk dapat menaikkan partisipasi secara terukur juga terutama karena kelompok pengguna ini.
    Dari grafik Dan terlihat bahwa pengguna perangkat termurah seperti Itel P32 tidak banyak diuntungkan oleh optimisasi bertahap.
    Yang bisa membantu adalah arsitektur klien yang sama sekali berbeda, yang mengorbankan fitur dan polesan demi menyediakan kode setipis mungkin; dengan kata lain, semacam mode lite/dasar alternatif.
    Namun pendekatan seperti ini jarang berhasil, karena masalah empati muncul lagi: developer AS sering salah menilai apa yang harus dipertahankan dan dibuang demi performa.

    • Saya tidak paham mengapa itu harus menjadi pilihan “alternatif”.
      Saya mempertanyakan apa yang saat ini diberikan Discourse dibanding PhpBB atau forum DLang.
      Selain desain yang ramah mobile, dalam dunia yang normal beberapa baris perbaikan CSS responsif seharusnya sudah cukup.
    • Saya tinggal di negara Asia Tenggara yang miskin, dan orang-orang yang memakai paket data kecil tidak menghemat data karena situs web yang efisien; mereka memakai Wi-Fi yang ada di mana-mana.
      Data 30GB per bulan harganya $3.64, sekitar 4–6 jam kerja berdasarkan upah minimum.
      Yang lebih penting, orang-orang di sini tidak memakai data secara sembarangan seperti di Barat.
      Di setiap kafe, restoran, supermarket, dan mal ada Wi-Fi gratis, dan kebanyakan orang menanyakan kata sandi Wi-Fi sebelum melihat menu.
      Saya belum pernah melihat atau mendengar orang berkata situs web menghabiskan data terlalu cepat.
      Ini terdengar seperti kekhawatiran yang dibuat-buat oleh orang yang belum pernah benar-benar tinggal di negara berkembang.
      Alasan data habis di sini adalah menonton video di TikTok, Instagram, dan Facebook, bukan karena bloat situs web.
    • Jika semua situs lebih efisien, pengguna non-teknis mungkin akan lebih lambat merasa “komputer saya jadi lambat, harus beli baru”, sehingga umur pakai laptop dan PC juga bisa bertambah.
      Hal yang sama berlaku untuk bloatware yang ikut terpasang di komputer.
      Baru-baru ini saya membeli laptop baru dan ditawari “tuning” seharga $50.
      Bayangkan dealer mobil baru menawarkan hal seperti itu; rasanya aneh.
    • Bahkan di iPhone generasi sebelumnya, sebagian situs seperti ini benar-benar sangat sulit ditoleransi.
      Jika sinyal buruk, masalahnya menjadi 10 kali lebih parah.
      Ini bukan soal UI rumit dengan header tetap dan iklan yang membuat hanya sepertiga layar terlihat, melainkan soal ukuran situs web itu sendiri, yang dirakit asal-asalan sampai terlihat seperti dokumen desain.
      Situs yang bahkan jika dibuat dengan benar pun sudah bloat menjadi tidak bisa digunakan pada koneksi internet lambat, apalagi pada hardware lambat.
      Sulit membayangkan seperti apa rasanya memakai internet dalam kondisi yang dijelaskan, dan saya hanya berharap orang-orang itu memakai situs lokal yang disesuaikan dengan bandwidth dan perangkat mereka, bukan harus berurusan dengan sampah bloat yang kita hadapi.
    • Saya tinggal di Kanada, paket data saya juga satu digit GB, dan saya baru saja upgrade dari flagship yang hampir berusia 10 tahun.
      Sebagian besar situs web terasa hampir seperti penyiksaan.

  • Menarik bahwa kebanyakan orang hanya menyalahkan atasan atau perusahaan raksasa yang menakutkan
    Para developer tidak mengakui bahwa ada juga kelompok besar programmer web yang kurang kompeten yang tidak terlalu memahami efisiensi, dan tampaknya juga tidak berminat memahaminya
    Mereka juga ikut bertanggung jawab atas dunia perangkat lunak web yang menyedihkan ini, sama seperti atasan atau elite korporat yang memaksa orang membuat perangkat lunak buruk

    • Saya pernah bekerja dengan orang-orang seperti itu
      Saat ditanya bagian konkret dari “hasil akhir”, yaitu HTML, CSS, JS, mereka menatap seolah saya berbicara dalam bahasa lain
      Mereka berasal dari dunia framework JavaScript dan tidak terlalu memikirkan hasil di bawahnya
      Filosofi saya hampir kebalikannya: bertanya kode minimal yang masih mudah dirawat seperti apa yang bisa menghasilkan hasil setara dengan situs web HTML+CSS+JS yang ditulis tangan dengan baik
      Biasanya hasilnya menjadi beberapa orde magnitudo lebih kecil
      Ketika mereka bertanya bagaimana saya membuat 1.000 baris tabel bisa difilter secara real-time namun tetap cepat dimuat dan berjalan baik di mobile, saya bilang saya hanya mengirim seluruh data pada request pertama lalu secara dinamis menyembunyikan data yang tidak cocok dengan filter
      Web server hanya perlu mengirim data cache yang sama ke semua orang, dan JavaScript yang berjalan di situs juga hanya itu, sehingga bagi mereka terlihat anehnya cepat
      Dalam solusi berbasis framework mereka, kalau melihat HTML baris tabel serupa, 80% isinya boilerplate yang bahkan tidak dipakai
      Pengembangan web sudah terlalu kaku, dan banyak orang sudah terlalu jauh melenceng dari esensi teknologi web
    • Sekitar 5 tahun lalu, saya melamar ke sebuah perusahaan yang membantu orang-orang di pedesaan Afrika menjual barang yang mereka produksi dengan lebih mudah
      Jika target utamanya pengguna AS atau Uni Eropa, mungkin masuk akal untuk tidak terlalu mengoptimalkan hardware kelas bawah serta koneksi yang tidak stabil, ber-bandwidth rendah, dan berlatensi tinggi
      Namun jika targetnya pedesaan Afrika, optimisasi agresif terasa sudah semestinya
      Tetapi halaman berandanya memuat gambar raksasa 2 MB yang diperkecil dengan CSS menjadi 500×1000 piksel, dan setelah itu kondisinya lebih buruk lagi
      Saya tidak ingat ukuran persis payload JS-nya, tetapi beberapa MB, dan meski sebagian besar tampak seperti aplikasi backend tradisional berbasis template, frontend-nya sangat berat
      Karena konsepnya bagus, saya tetap melamar, tetapi teknologinya mengerikan
      Saya bahkan tidak lolos tahap wawancara pertama, jadi saya tidak tahu alasannya, tetapi sulit membayangkan selain para developer Eropa Barat tidak benar-benar menyadari apa yang mereka lakukan dalam aspek ini
    • Sebagai orang yang pernah bekerja di “perusahaan raksasa yang menakutkan”, tanggung jawabnya 100% ada pada mereka
      Titik awalnya bukan developer, melainkan anggaran
      Jika jajaran atas tidak paham teknologi atau tidak punya latar belakang engineering, biasanya mereka menganggarkan fitur baru, tetapi menganggarkan terlalu sedikit atau sama sekali tidak menganggarkan pemeliharaan dan penghapusan technical debt
      Kalaupun ada anggaran pemeliharaan, hampir semuanya ditangani tim pemeliharaan luar negeri yang lebih murah
      Tim fitur membangun fitur selama 6 bulan, mengadakan “sesi KT” 1 jam dengan tim pemeliharaan luar negeri, lalu menyerahkan kodenya
      Tim luar negeri punya sebagian informasi tentang fitur itu, tetapi tidak cukup untuk mengelola technical debt yang sudah ada; mereka hanya menjaga agar api tidak berkobar
      Jika siklus ini berulang 100–1000 kali di dalam organisasi, frontend yang semula paling banyak cukup 250 ribu baris dengan cepat menjadi 2 juta baris
      Bahkan jika engineer terbaik masuk ke tim fitur baru, mereka harus bekerja di dalam kotak yang sudah terbentuk
      Jika mockup dan elemen tidak cocok, bisa jadi mockup-nya salah, UI kit sudah di-upgrade, atau UI kit lama perlu direfaktor, tetapi tidak ada anggaran untuk itu
      Jadi tim diperintahkan menyalin komponen dan memodifikasinya agar sesuai dengan fitur mereka
      Saat menyerahkannya ke tim pemeliharaan pun, tim baru tidak ingin menyentuh pekerjaan fitur yang sudah ada, jadi dibiarkan begitu saja
      Manajemen nonteknis tidak tahu bedanya, dan setelah bertahun-tahun tim menyalin/menempel demi menyesuaikan fitur baru, codebase akhirnya memiliki lebih dari 50 komponen bernama “Button”
    • Itu tidak adil
      Jika ada developer berpengalaman di tim yang mementingkan efisiensi, dan mereka mendorong situs yang lebih efisien atau membangunnya lebih efisien sejak awal, halaman memang bisa menjadi lebih baik
      Namun sebagian besar adalah masalah insentif
      Jika manajemen tidak peduli, programmer kemungkinan lebih memilih membuatnya sekadar berjalan dalam separuh waktu dan menghabiskan backlog, daripada menghabiskan waktu untuk meningkatkan efisiensi
    • Biasanya perangkat lunak web yang buruk berjalan seiring dengan konten yang buruk
      Jadi perangkat yang lambat adalah filter yang bagus untuk menghindari sampah

  • Baru-baru ini saya pindah dari LG flagship berusia 6 tahun ke Galaxy baru, dan perbedaan performanya sangat besar
    Seharusnya tidak begitu
    Saat dirilis, itu perangkat yang sangat kelas atas, belum terlalu tua, dan masih berfungsi seperti baru
    Melihat Galaxy S9 untuk pengujian juga mengalami kesulitan yang sama, tampaknya masalahnya bukan hanya ponsel saya
    Saya berharap Amazon ikut masuk dalam pengujian
    Dari pengalaman, situs web Amazon termasuk yang paling buruk di antara yang terburuk pada perangkat mobile berusia lebih dari 4 tahun
    Bahkan pada hardware mobile kelas atas yang relatif baru, itu satu-satunya situs yang saya akses rutin yang hampir tidak bisa digunakan

    • Setelah memakai dua perangkat Snapdragon 835 berusia 7 tahun, saya merasa RAM dan versi Android terbaru membuat perbedaan besar
      Saya memakai OnePlus 5 dengan Android 14 lewat LineageOS sebagai perangkat harian, dan pengalaman pengguna untuk pekerjaan non-game masih cukup baik
      Ponsel ini punya RAM 6 GB, jadi masih mirip dengan ponsel kelas menengah masa kini
      Satu-satunya keluhan saya adalah baterainya harus diganti dan membongkar ponsel itu merepotkan
      Sebaliknya, Galaxy S8 dengan SoC yang sama, memori 4 GB, dan Android 9 bawaan dengan modifikasi Samsung tersendat tanpa henti
      Selisih memori 2 GB mungkin berpengaruh, tetapi perbedaan kedua ponsel itu seperti siang dan malam
      Saya tidak tahu apakah manajemen memori Android 14 jauh lebih baik daripada Android 9, atau software Samsung yang lambat dan bengkak yang menahan perangkat itu
      Bagaimanapun, menyebalkan bahwa banyak perusahaan tidak menguji di perangkat lama dan murah
      Jika menargetkan pengguna global, mereka harus melihat bahwa sebagian besar orang di dunia tidak memakai flagship terbaru
    • Saya penasaran apakah Anda pernah mencoba menonaktifkan JavaScript di Amazon
      Sebenarnya tidak berjalan seburuk itu
      Tentu saja saya setuju bahwa kita seharusnya tidak perlu melakukan itu
    • Baru-baru ini saya pergi ke Brasil dan ponsel baru saya dirampas dari tangan, jadi sekarang saya memakai ponsel cadangan berusia 4 tahun, dan jujur saja saya tidak merasakan perbedaannya
      Namun saya memakai Firefox dengan semua pemblokir iklan, jadi sepertinya itu membantu
    • Saya punya Palm Phone, dan pada titik ini saya rasa hampir mustahil dipakai untuk browsing web
    • Di iPhone 8 dengan iOS 16 terbaru, Amazon tidak bermasalah

  • Teknologi saat ini terlalu tidak peduli bahkan terhadap orang yang tidak terbiasa dengan teknologi
    Menurut saya smartphone adalah contoh utamanya
    Saya melihat sangat banyak orang yang nyaris tidak bisa memakai perangkat mereka sendiri, atau bahkan sama sekali tidak memahaminya, dan bagi mereka semuanya tampak seperti ilmu hitam
    Masalah terbesarnya adalah ketergantungan berlebihan pada navigasi gestur, yang karena tidak terlihat jadi seolah tidak ada
    Bilah gestur di iPhone mungkin masih bisa ditebak entah bagaimana, tetapi mereka tidak punya konsep tentang Notification Center atau Control Center
    Orang-orang ini bukan bodoh, dan di bidang lain mereka bisa jauh lebih unggul daripada saya
    Dalam teknologi, masalahnya bukan kurangnya usaha, melainkan kurangnya antarmuka yang intuitif

    • Membeli iPhone baru pun tidak disertai dokumentasi, dan itu tidak membantu
      Untuk melihat dokumentasi sungguhan, harus mencari sampai halaman dokumentasi di situs Apple, lalu menggali sedikit lagi sebelum menemukan halaman yang hanya secara garis besar menunjukkan beberapa gestur yang mungkin digunakan
      Kapan dan gestur apa yang harus digunakan pun tidak ada lebih dari contoh satu kalimat
      Itu pun baru soal sistem operasinya saja
      Saya ragu berapa banyak aplikasi yang menyertakan dokumentasi yang menjelaskan bagaimana fitur gestur digunakan di aplikasi mereka sendiri
      https://support.apple.com/guide/iphone/learn-basic-gestures-...
    • Saya pernah melihat orang paruh baya atau lebih tua yang mungkin bahkan tidak bisa mengoperasikan tape deck kaset dan kesulitan memakai mesin tik
      Mereka jelas tumbuh di sekitar perangkat-perangkat seperti itu
      Jadi menurut saya ini bukan semata-mata kesalahan teknologi modern
    • Dilihat dari luar, setidaknya antarmuka untuk produk-produk yang mencolok tampaknya dirancang dengan pendekatan satu ukuran untuk semua
      Alih-alih membiarkan pengguna memilih desain dan interaksi yang cocok untuk mereka, desainer atau penanggung jawab produk bertindak seolah mereka tahu apa yang terbaik bagi semua pengguna
    • Masalah ketergantungan berlebihan pada navigasi gestur bukan masalah smartphone, melainkan masalah khas iPhone
      Itu salah satu keluhan terbesar saya setelah pindah dari Android
      Di mana tombol back, di mana tombol home, dan di mana tombol-tombol itu sendiri, saya tidak tahu
      Saya benar-benar benci obsesi Apple pada minimalisme, dan saat ponsel ini mati saya akan kembali ke Android

  • Artikel ini pada dasarnya sulit dibaca bagi saya yang berusia 48 tahun di desktop
    Setelah menambahkan baris berikut ke body di developer tools, barulah bisa dibaca
    font-size: 18px;
    line-height: 1.5em;
    max-width: 38rem;
    Dengan begitu terlihat betapa mudah dibaca dan indahnya hasilnya
    Saya banyak membaca tulisan Dan Luu, tetapi setiap kali harus mengubahnya seperti ini
    Serius, para teknisi, membuat halaman lebih mudah dibaca hanya membutuhkan tambahan 64 byte

    • Saya berusia 53 tahun dan sudah setidaknya 5 tahun melewati saat seharusnya mengganti kacamata, jadi sekarang pun kacamata saya menggantung di ujung hidung dan kadang harus saya sesuaikan sudutnya
      Halaman itu hampir baik-baik saja, cukup diperbesar dengan CTRL +
      Halaman itu hampir murni teks dan nyaris tidak ada manipulasi
      Anda punya solusi yang cocok untuk kasus penggunaan Anda, dan saya juga punya solusi saya
      Pembaca tunanetra juga bisa mengaksesnya dengan solusi mereka sendiri
      Karena sumbernya sederhana, solusi aksesibilitasnya juga menjadi cukup sederhana
      Menurut saya Dan tahu cara berkomunikasi secara efektif
      Ia menjaganya tetap sederhana, dan tidak berasumsi bahwa orang pasti membacanya dengan mata
      Kita bisa dengan mudah mengubah tampilannya sesuai tujuan masing-masing
      Jika tidak suka cara tampilnya, Anda bisa memformat ulang sendiri sebelum membaca
      Dengan kata lain, Dan menyampaikan pesannya sebagai aliran teks sederhana yang mudah dimanipulasi
    • Menurut saya usulan perbaikannya masuk akal, tetapi jika Dan Luu sendiri memasukkan aturan CSS itu, di sini akan ada tanggapan yang meratapi rendahnya kepadatan dan “ruang kosong berlebihan”
      Kemungkinan besar pembaca Luu secara umum lebih menyukai pendekatan minim gaya
    • Saya tidak setuju
      Pengguna bisa mengubah ukuran jendela, ukuran font, warna, dan sebagainya sesuai preferensi mereka
      Tidak semestinya harus diubah untuk setiap file, dan semestinya diperbolehkan menambahkan file CSS pengguna yang dapat diterapkan ke banyak file
    • Jika font terlalu kecil, Anda bisa mengubah ukuran font bawaan browser
      Itu ada di halaman pengaturan dasar Firefox
      Jika situs web memaksa font-size: 18px;, bagi pengguna yang memilih font lebih besar di browser, teksnya justru bisa menjadi lebih kecil
    • Saya setuju bahwa CSS minimal perlu ditambahkan
      Namun bisa juga menggunakan mode baca di browser, dan itu cukup sekali klik alih-alih beberapa langkah lewat developer tools

  • Sebagai catatan, Raspberry Pi 3 tidak bisa dipakai untuk YouTube
    Ini terjadi dalam setahun terakhir; sebelumnya video masih bisa “ditonton” sekitar 10–15 FPS, dan itu cukup untuk menonton video perbaikan di bengkel
    Saat Raspberry Pi Model B, yaitu model pertama, dirilis, perangkat itu bisa memutar video 1080p dari penyimpanan, menonton YouTube, dan juga bermain game
    Entah apa yang dilakukan YouTube, dan entah apa juga yang dilakukan layanan lain
    Jika serius memikirkan krisis dan perubahan iklim, akal-akalan Google dan Meta seperti ini harus diawasi dengan sangat ketat
    Membakar siklus CPU demi keuntungan—kalau menebak secara spontan, karena teknologi iklan—hingga YouTube rusak di perangkat berdaya rendah seharusnya dikritik keras oleh media, dan meski pengalaman pengguna secara keseluruhan buruk, orang harus memakai layanan yang lebih efisien

    • Mungkin juga karena tidak adanya decoding video hardware
      Pi3 punya akselerasi hardware x264, sementara YouTube sejak beberapa waktu lalu mulai memakai codec lain
    • YouTube jelas makin berat
      Di MacBook Air Intel keluaran awal 2021 pun video berhenti secara acak pada beban sedang, padahal dulu tidak begitu
    • Dari semua data yang ada, konsumsi energi perangkat klien tampaknya nyaris seperti galat pembulatan dalam hal kontribusi terhadap perubahan iklim
      Menyerang sisi itu untuk mengatasi perubahan iklim sama tidak masuk akalnya dengan melarang sedotan plastik atau kantong plastik
    • Untuk menjelajah situs saya memakai Invidious, dan untuk video sebenarnya saya menontonnya lewat skrip yang membongkar obfuscation untuk mendapatkan URL stream asli lalu meneruskannya ke VLC
      Sebagai titik acuan lain, YouTube 10 tahun lalu pasti sepenuhnya baik-baik saja di hardware itu
      Biang keroknya adalah pembengkakan web secara umum, dan lebih spesifik lagi monster-monster abstraksi yang menjadi lazim di JS
      Bahkan kepada orang yang sama sekali tidak percaya pada “krisis iklim”, kita tetap bisa mengatakan bahwa seiring waktu keahlian pertukangan dan kualitas menghilang sehingga kekacauan seperti ini terjadi
      Karena itu saya melihat ini sebagai topik yang bisa disepakati oleh semua pihak di seluruh spektrum politik
    • Perlu ada organisasi pemantau yang mengawasi bobot halaman per situs dan per pengguna, lalu memublikasikan nama untuk mempermalukan mereka
      Bisa dengan gaya Consumer Reports, atau berupa add-on yang bekerja seperti rating Nielsen

  • Orang dari Discourse itu adalah contoh klasik seseorang yang merancang produk berdasarkan dunia yang ia harapkan ada, bukan dunia nyata tempat kita hidup
    Perangkat dengan Qualcomm SoC ada dalam jumlah miliaran, akan terus ada, dan akan terus diproduksi serta dijual
    Sebanyak apa pun mengeluh, itu tidak akan berubah
    Terimalah kenyataan itu dan optimalkan untuk perangkat tersebut
    Para pengguna perangkat itu tidak peduli pada keluhan developer; kalau software crash, mereka hanya akan menganggap developernya tidak kompeten

    • Atau bisa juga mengambil jalur dengan berkata “ini bukan untuk Anda”

  • Biasanya saya suka tulisan Dan Luu, tetapi kali ini rasanya meleset
    Tabel LCP/CPU-nya bagus, tetapi setelah itu tulisannya mengalir seperti psikologi kursi santai
    Dengan beberapa komentar acak dari pendiri Discourse sebagai dasar, ia meminta pembaca membayangkan sikap para software engineer
    Bahkan Knuth pun ia seret turun berdasarkan pernyataan soal performa single-core versus multi-core dan pernyataan terkait Itanium, padahal itu adalah titik perdebatan akademis yang sudah lama
    Tulisannya terasa terlalu lembek dan terlalu bertumpu pada ribut-ribut internet, sehingga sulit untuk benar-benar bertahan

    • Tapi memang ada sikap seperti itu, bukan?
      Ucapan pendiri Discourse hanya sangat menjelaskan saja
      Jika belakangan ini Anda pernah memakai web, pembengkakannya sudah di luar bayangan sampai-sampai Google kini menyebut Largest Contentful Paint 2,4 detik sebagai cepat: https://blog.chromium.org/2020/05/the-science-behind-web-vit...
      Itu data 4 tahun lalu, jadi sekarang kemungkinan sudah lebih buruk
      Tidak perlu mencari jauh-jauh, mulai dari YouTube di desktop yang memuat CSS 2,5 MB, sampai pendiri Vercel yang membanggakan situs yang katanya sangat cepat tetapi begitu diberi sedikit pembatasan perlu 20 detik untuk loading: https://x.com/dmitriid/status/1735338533303259571
    • Saya hampir tidak pernah melihat perusahaan menangani performa dengan serius
      Waktu respons layanan API sederhana untuk frontend 500 ms pun tidak ada yang menertawakannya
      Saya juga bertanya-tanya berapa banyak engineer yang tahu dan peduli berapa biaya cloud mereka sendiri
    • Saya rasa Knuth sampai batas tertentu benar
      Paralelisme saat ini tidak dipakai di 90% software, kecuali untuk kasus penggunaan khusus atau saat menjalankan program single-thread yang sama pada banyak item data
      Baik bahasa pemrograman maupun hardware belum mendukung paralelisme granular dengan baik, dan membuat software klasik menjadi cepat lewat pendekatan paralel sangatlah sulit
    • Saya tidak tahu apa yang diperdebatkan
      Luu justru menulisnya dengan cukup murah hati
      Knuth lebih seperti mengeluh bahwa makan siang gratis yang berlangsung selama beberapa dekade akan berakhir
    • Menurut saya ringkasannya cukup bagus
      Jeff Atwood hanya dipilih sebagai contoh
      Para pemikir web development terkenal dengan banyak pengikut terus-menerus melontarkan pandangan serupa, dan banyak pengikut menerima begitu saja ucapan mereka

  • Semua perusahaan berhenti peduli, terutama perusahaan seperti Google dan Apple yang dulu berada di garis depan standar dan praktik desain web yang baik
    Google baru-baru ini menutup HTML Gmail, yang berjalan cepat dan baik bahkan di ponsel Android 2008 dengan RAM 256MB dan Firefox lama
    Tentu saja versi baru yang membengkak dengan JavaScript itu membuat browser langsung tumbang
    Ini memang contoh ekstrem, tetapi ponsel kelas bawah memiliki RAM 2GB, dan sekarang sulit mengharapkan performa yang masuk akal saat menjelajah web dengan perangkat seperti ini
    Web mobile sangat buruk, dan ini disengaja untuk mendorong pengguna masuk ke aplikasi “native”
    Karena bagi perusahaan seperti Apple dan Google, pengumpulan data dan penayangan iklan menjadi lebih mudah

    • Sebagian memang jelas begitu, tetapi bagaimana dengan Amazon atau Decathlon, jaringan besar olahraga dan outdoor di Eropa, saya tidak tahu
      Situs mereka mengerikan di mobile, dan Decathlon juga mengerikan bahkan di desktop yang bukan berperforma tinggi
      Namun mereka juga tidak secara mencolok merekomendasikan aplikasi, jadi sepertinya harus dianggap sekadar tidak kompeten
      Sepertinya para developer hanya menguji semuanya di perangkat kelas atas yang terhubung ke backbone
    • Pada hari Kamis, Google mengakhiri satu-satunya “produk” yang masih layak dipakai
      RIP Google
      Reddit baru tidak bisa digunakan, dan old Reddit sudah terlalu tua
      Twitch nyaris hanya bisa dipakai karena masalah chat dan stream video
      Daftarnya panjang
      Jika sudah punya formula final, setiap perubahan menjadi perubahan buruk demi jaminan pekerjaan
      Suatu hari nanti para kera di gumpalan tanah ini akan menyadari bahwa pekerjaan dan uang itu tidak benar-benar ada, tetapi saat itu semuanya sudah terlambat
      Tidak, saatnya adalah sekarang
      RIP Humans