Desain Responsif Tidak Cukup, Kami Membutuhkan Performa Responsif

Baru-baru ini saya menemukan banyak situs web responsif dengan banyak masalah kinerja. Pada sebagian besar dari mereka, masalahnya sangat jelas sehingga hampir tidak berguna untuk apa pun selain smartphone generasi terbaru. Mengingat fakta bahwa daya tanggap sebagai sebuah konsep dimaksudkan untuk menjangkau khalayak yang lebih luas, hal ini tampaknya agak kontraproduktif.

Kontributor terbesar untuk masalah ini adalah paradigma desain desktop-first yang masih lazim. Berpikir dari perspektif mobile-first tampaknya mengatasi masalah ini, tetapi itu saja tidak menjamin kinerja yang memuaskan. Kita semua tampaknya terlalu bergantung pada degradasi yang kurang lebih anggun. Kami mengandalkan shim dan polyfill untuk mengaktifkan fungsionalitas yang hilang. Kami mengandalkan perpustakaan untuk memungkinkan pengembangan yang cepat dan mendukung kami saat kompatibilitas browser menjadi masalah.

"Kenapa khawatir?" Anda mungkin bertanya. “Sebagian besar pengunjung kami memiliki smartphone berkinerja tinggi yang menjalankan versi OS terbaru mereka. Mereka dapat menangani situs kami. Analitik memberi tahu kami demikian. ”

Saya minta maaf tentang argumen straw-man, tapi menurut saya pantas untuk menyatakan dengan lantang bahwa orang-orang yang dapat menggunakan situs Anda akan menjadi mayoritas pengguna Anda. Jika Anda tidak melihat Android 2.3 di analitik Anda, apakah itu berarti tidak ada pengguna dengan perangkat tersebut? Atau apakah itu berarti situs Anda tidak menawarkan apa pun kepada pengguna tersebut? Pertimbangkan bahwa banyak perangkat generasi itu masih ada di rak, dibeli dalam kondisi baru bahkan hingga hari ini. Anda tidak boleh mengabaikannya sebagai teknologi masa lampau.

Oleh karena itu, saya ingin berbicara tentang kasus ideal dan tujuan sebenarnya dari pengembangan web. Dan tentang praktik dan paradigma yang membawa kita lebih dekat ke tujuan tersebut.

Paradigma Desain Bata-Pertama

Sebagian besar penjualan ponsel tahunan masih diambil oleh ponsel berfitur. Porsi populasi yang lebih besar tidak membeli ponsel setiap tahun, tetapi tetap memiliki beberapa perangkat berkemampuan web yang mereka miliki. Tambahkan ke nomor telepon pintar generasi terakhir yang masih digunakan, tambahkan menyalakan dan perangkat semi-mampu web lainnya (perangkat WAP, TV, pemanggang roti, kaos dan batu bata). Tambahkan semuanya dan Anda mungkin mencapai jumlah yang mengejutkan.

Pertimbangkan kasus penggunaan untuk audiens ini. Mereka tidak akan membaca artikel panjang, menjelajah, dan meneliti di perangkat mereka. Tetapi mereka mungkin mengalami kengerian ketika mencoba mengetikkan URL pada keyboard numerik dan menavigasi halaman menggunakan tombol arah untuk mendapatkan nomor telepon atau memeriksa ulang alamat dengan cepat.

Seberapa sulit bagi kami untuk menerapkan tata letak sub-mobile-first yang hanya akan memberikan informasi itu ke perangkat di bawah ambang batas kemampuan dan kinerja tertentu?

Peningkatan yang anggun

Dengan degradasi yang anggun sebagai praktik terbaik minimum, kami telah menciptakan prinsip yang mencakup semua yang (sampai batas tertentu) menghalangi pemikiran di luarnya. Begitu degradasi yang anggun terjadi, kita pasti dapat mengatakan bahwa pekerjaan kita telah selesai, dan dilakukan dengan baik. Semakin sering kita bahkan tidak perlu memikirkannya karena sudah dicakup oleh berbagai kerangka kerja dan pustaka yang digunakan. Dan akhirnya polyfill dan shim sepenuhnya menghilangkan kebutuhan akan penurunan fungsionalitas dalam beberapa kasus.

Karena fungsi ini semakin tersedia, kebutuhan untuk memikirkannya (apalagi di luarnya) menjadi semakin jauh.

Dari sudut pandang artikel ini bisa dipecah seperti ini:

Degradasi yang tidak sopan: Jika fitur tidak tersedia, implementasinya gagal sedemikian rupa sehingga menjadi tidak dapat digunakan atau dapat digunakan dengan cara yang sangat tidak praktis.

Degradasi yang anggun: Jika suatu fitur tidak tersedia, fitur tersebut gagal dengan cara yang masih memungkinkan kegunaan yang dapat diterima.

Peningkatan yang tidak baik: Jika fitur tersebut tidak tersedia, fitur tersebut diemulasi oleh polyfill atau shim.

Di sana, masalah terpecahkan.

Yah kecuali jika Anda mempertimbangkan kinerja perangkat kelas bawah yang sama.

Kurangnya kekuatan pemrosesan dan kemampuan data adik-adik mereka, mereka diminta untuk membawa beban yang jauh lebih besar. Mengambil polyfill sebagai solusi menciptakan ilusi bahwa semua fungsi modern sekarang tersedia di semua perangkat dan dapat digunakan tanpa khawatir.

Jadi Anda menerapkan modernizr dan polyfill semuanya untuk berjaga-jaga. Perangkat yang paling tidak kompeten akhirnya memuat jumlah data terbesar, dan melakukan jumlah pemrosesan terbesar. Dengan demikian memastikan pengalaman pengguna akhir yang "terbaik".

Gagasan peningkatan yang anggun akan membalikkan konsep dengan memulai dengan persyaratan fitur terendah dan memuat peningkatan hingga keseimbangan kinerja-kegunaan optimal berdasarkan kemampuan perangkat. Dengan demikian, lalu lintas data dan persyaratan pemrosesan akan dipindahkan ke perangkat yang paling cocok untuk menanganinya.

Tentu, saat ini konsepnya sangat kompleks: tidak didukung oleh sebagian besar kerangka kerja dan pustaka, sebagian besar tidak dibahas, dan referensi untuk praktik semacam itu sedikit, berjauhan, dan terlokalisasi ke fungsi mikro. Tetapi pada titik tertentu seperti itu dengan semua konsep dan fungsionalitas.

Bisa, Tapi Harus?

Praktik terbaik lainnya dengan pengembangan web adalah memeriksa apakah fitur tersedia di perangkat sebelum mengaktifkannya.

Namun, pertimbangkan bahwa Anda dapat menginstal versi terbaru Google Chrome di ponsel Android lama Anda, dan itu akan mengklaim bahwa itu dapat menjalankan animasi CSS, WebGL, efek paralaks latar belakang, dan banyak fungsi lainnya. Tapi sungguh, sungguh , tidak bisa. Sedemikian rupa sehingga browser akan macet, dan seluruh perangkat akan menjadi tidak responsif sampai-sampai harus di-boot ulang untuk mendapatkan kembali kendali.

Masalah ini akhir-akhir ini mulai memengaruhi aplikasi Android secara besar-besaran (dari sudut pandang pengguna). Salah satu penurunan paling mencolok dalam hal ini telah memengaruhi peningkatan versi aplikasi Google Talk/Hangouts yang telah mengubah layanan mereka dari aplikasi obrolan paling ringan yang tersedia menjadi aplikasi yang hampir tidak dapat digunakan karena masalah kinerja pada perangkat lama. (Hanya untuk menekankan poin ini sekali lagi: "lebih tua" di sini berarti Anda masih dapat membelinya langsung, baru di hampir semua toko). Masalah yang sama memengaruhi aplikasi YouTube dan aplikasi Twitter (dalam pengalaman saya) dan tampaknya banyak lainnya.

Jadi, luangkan waktu sejenak selama fase perencanaan Anda untuk mengevaluasi nilai fitur inti berkinerja tinggi dibandingkan riasan mutakhir. Atau setidaknya biarkan generasi terakhir aplikasi/layanan/konten Anda tersedia dalam beberapa bentuk untuk pengguna lama. Ngomong-ngomong soal…

Biarkan Pengguna Memilih Keluar dari Bleeding Edge

Pernahkah Anda mencoba menggunakan Gmail dari perangkat lama, atau melalui sambungan yang buruk? Tautan "muat HTML dasar" itu pasti berguna.

Mengapa etalase online Anda yang mutakhir, responsif, animasi, berorientasi sentuhan tidak memiliki fungsi tersebut?

Pikirkan tentang ini: Anda meminta agar responsif sehingga Anda dapat menjangkau lebih banyak pelanggan potensial. Anda membuatnya canggih untuk meninggalkan kesan pertama yang terbaik. Akibatnya, semakin sedikit calon pelanggan yang dapat menjangkau bahkan informasi dasar tentang Anda dan layanan Anda. Jika peningkatan anggun adalah konsep yang terlalu mahal untuk Anda, mengapa Anda tidak menawarkan kepada pengunjung Anda pilihan untuk mengakses versi teks saja dari konten Anda jika versi "WOW" terlalu banyak untuk perangkat mereka.

Apakah Anda Benar-Benar Membutuhkan Seluruh Perpustakaan?

Akhirnya, praktik terbaik terakhir yang ingin saya lihat didorong sedikit melampaui standar adalah "gunakan atau hilangkan". Melacak perpustakaan dan modul mana yang benar-benar digunakan dan hanya menyertakannya terkadang membosankan, tetapi menyimpan seluruh perangkat Anda di setiap halaman hanya ceroboh.

Baru-baru ini, saya telah melacak seberapa banyak fungsionalitas yang sebenarnya saya gunakan setelah saya menyertakan perpustakaan. Dan tool yang paling sering saya gunakan adalah jQuery. Seringkali saya menemukan bahwa saya hanya menggunakan satu atau dua fungsi (seperti $.extend atau $.ready), atau lebih buruk lagi, saya menggunakannya hanya untuk mendapatkan elemen berdasarkan kelas atau ID. Terkadang saya membiarkannya seperti itu, di lain waktu saya kembali melalui kode untuk menghapus atau memisahkan ketergantungan.

Bukankah lebih rapi jika Anda dapat secara otomatis menganalisis apa dan berapa banyak perpustakaan yang akhirnya digunakan dan menurunkan berat badan berdasarkan hasil?

Banyak perpustakaan dan aplikasi menawarkan opsi untuk menyesuaikan pemuatan sebelum Anda mulai menggunakannya. Tapi saya tetap memiliki perasaan bahwa seharusnya tidak terlalu jauh dari jangkauan kami untuk menstandarisasi arsitektur build otomatis "gunakan atau hilangkan" di perpustakaan kami.

Saya memiliki alergi terhadap pendekatan "sertakan semuanya". Tetapi menggunakannya bersama dengan fungsionalitas seperti itu mungkin mengubah pendekatan menjadi sesuatu yang mirip dengan papan prototipe: alat pengembangan yang terlalu fleksibel yang diperkecil tidak hanya dalam sintaks, tetapi juga dalam fungsionalitas sebenarnya itu sendiri.

Apa yang diperlukan adalah versi pengembangan saja dari perpustakaan yang akan, melalui uji unit fungsionalitas dependen, memungkinkan pelacakan fitur yang digunakan dan menghasilkan ketergantungan minimal atau setidaknya skala pemanfaatan (seperti menanyakan apakah saya telah menyertakan jQuery untuk 8% fungsinya atau 80%). Output ketergantungan kemudian dapat digunakan untuk memilih, mengagregasi, dan meminimalkan output untuk produksi.

Tapi Apa Yang Dapat Saya Lakukan Tentang Ini?

Pertama-tama, libatkan masalahnya . Pikirkan, diskusikan dengan rekan Anda, dan coba temukan masalahnya dalam skenario dunia nyata.

Cobalah. Gali ponsel generasi terakhir yang telah Anda simpan di laci di suatu tempat. Coba gunakan di situs web Anda sendiri dan periksa apakah kontennya bahkan dapat digunakan dari jarak jauh. Kunjungi beberapa kerabat yang ketinggalan zaman di pedesaan dan cobalah menjadi penginjil teknologi bagi mereka. Lihat apakah kelambatan mereka dalam adopsi teknologi sebenarnya difasilitasi oleh masalah aksesibilitas.

Jika Anda seorang pembeli yang memesan situs web, pastikan untuk meminta (setidaknya) dukungan tingkat rendah untuk masalah ini. Ingat: tujuannya bukan untuk membuat port penuh semua fitur Anda ke perangkat tingkat rendah. Yang ditanyakan hanyalah pengguna tersebut mendapatkan informasi kontak Anda alih-alih perangkat mereka mogok.

Sisihkan sumber daya aktual untuk ini: solusi paling sederhana untuk masalah ini tidak boleh lebih dari satu atau dua hari dan beberapa pemikiran ke depan. Ingatlah alasan paling mendasar untuk membuat situs web di tempat pertama (apalagi membuat situs responsif).

Jika Anda adalah pengembang paket yang mengerjakan pustaka, kerangka kerja, bundel, atau perangkat lunak lain yang dapat disematkan: Andalah yang dapat membuat perbedaan terbesar di sini. Jika Anda dapat memfasilitasi atau menggabungkan konsep-konsep ini ke dalam platform Anda, Anda akan memengaruhi keseluruhan lanskap pengembangan web. Jika Anda memasukkannya ke dalam desain paket Anda, beri tahu saya dan saya akan menginjili untuk Anda.

Dan terakhir, **jika Anda seorang pengembang atau desainer**, jangan hanya berhenti pada praktik terbaik. Selalu mencoba untuk melihat sedikit di atas cakrawala itu. Kerja keras Anda untuk mendorong konsep-konsep ini yang belum pernah diminta siapa pun, yang tidak didukung dan tidak didokumentasikan untuk kepentingan klien dan pengguna Anda.

Pada akhirnya, jika Anda ingin mendengar seseorang membicarakan hal ini selama berjam-jam dan menemukan diri Anda berada di dekat Zagreb, beri tahu saya. Kita bisa pergi minum kopi.