Saya Menggunakan Web Sehari Dengan Anggaran 50 MB

Artikel ini adalah bagian dari seri di mana saya mencoba menggunakan web di bawah berbagai batasan, mewakili demografi pengguna tertentu. Saya berharap dapat mengangkat profil kesulitan yang dihadapi oleh orang-orang nyata, yang dapat dihindari jika kita merancang dan mengembangkan dengan cara yang sesuai dengan kebutuhan mereka.

Terakhir kali, saya menjelajahi web selama sehari menggunakan Internet Explorer 8. Kali ini, saya menjelajahi web selama sehari dengan anggaran 50 MB.

Mengapa 50MB?

Banyak dari kita cukup beruntung untuk menggunakan paket seluler yang memungkinkan beberapa gigabyte transfer data per bulan. Jika tidak, kami biasanya dapat terhubung ke jaringan WiFi rumah atau publik yang menggunakan koneksi broadband cepat dan memiliki data tak terbatas secara efektif.

Tetapi ada bagian dunia di mana data seluler sangat mahal, dan di mana hanya ada sedikit atau tidak ada infrastruktur broadband.

Orang sering membeli paket data yang hanya berukuran puluhan megabyte dalam satu waktu, membuat gigabyte menjadi jumlah data yang relatif besar dan oleh karena itu mahal untuk dibeli.
— Dan Howdle, analis telekomunikasi konsumen di Cable.co.uk

Seberapa mahal yang kita bicarakan?

Biaya Data Seluler

Sebuah studi tahun 2018 oleh cable.co.uk menemukan bahwa Zimbabwe adalah negara termahal di dunia untuk data seluler, di mana biaya 1 GB rata-rata $75,20, mulai dari $12,50 hingga $138,46. Kisaran harga yang sangat besar disebabkan oleh jumlah data yang lebih kecil menjadi sangat mahal, semakin murah secara proporsional semakin besar paket data yang Anda komitmenkan. Anda dapat membaca metodologi studi untuk informasi lebih lanjut.

Zimbabwe sama sekali bukan satu-satunya. Guinea Khatulistiwa, Saint Helena, dan Kepulauan Falkland berada di urutan berikutnya, dengan data 1 GB masing-masing berharga $65,83, $55,47, dan $47,39. Negara-negara ini umumnya memiliki kombinasi infrastruktur teknis yang buruk dan adopsi yang rendah, yang berarti pengiriman data mahal dan tidak memiliki skala ekonomi untuk menurunkan biaya.

Data juga mahal di beberapa bagian Eropa. Sebuah gigabyte data di Yunani akan membuat Anda kembali $32,71; di Swiss, $20.22. Sebagai perbandingan, jumlah data yang sama berharga $6,66 di Inggris Raya, atau $12,37 di AS. Di ujung lain skala, India adalah tempat termurah di dunia untuk data, dengan biaya rata-rata $0,26. Kirgistan, Kazakhstan, dan Ukraina masing-masing mengikuti dengan $0,27, $0,49, dan $0,51 per GB.

Kecepatan jaringan seluler juga sangat bervariasi antar negara. Mungkin yang mengejutkan, pengguna mengalami kecepatan lebih cepat melalui jaringan seluler daripada WiFi di setidaknya 30 negara di seluruh dunia, termasuk Australia dan Prancis. Korea Selatan memiliki kecepatan pengunduhan seluler tercepat, rata-rata 52,4 Mbps, tetapi Irak memiliki unduhan paling lambat, rata-rata 1,6 Mbps dan pengunggahan 0,7 Mbps. AS menempati peringkat ke-40 di dunia untuk kecepatan unduh seluler, sekitar 34 Mbps, dan berisiko tertinggal lebih jauh saat dunia bergerak menuju 5G.

Untuk jenis koneksi jaringan seluler, 84,7% koneksi pengguna di Inggris menggunakan 4G, dibandingkan dengan 93% di AS, dan 97,5% di Korea Selatan. Ini dibandingkan dengan kurang dari 50% di Uzbekistan dan kurang dari 60% di Aljazair, Ekuador, Nepal dan Irak.

Biaya Data Broadband

Sementara itu, sebuah studi tentang biaya broadband pada tahun 2018 menunjukkan bahwa koneksi broadband di Niger berharga $263 'per megabit per bulan'. Metrik ini agak sulit untuk dipahami, jadi inilah contohnya: jika biaya rata-rata paket broadband di suatu negara adalah $22, dan kecepatan unduh rata-rata yang ditawarkan oleh paket tersebut adalah 10 Mbps, maka biaya 'per megabit per bulan' akan menjadi $2,20.

Ini adalah metrik yang menarik, dan salah satu yang mengakui bahwa kecepatan broadband adalah faktor yang sama pentingnya dengan batasan data. Biaya $263 menunjukkan kombinasi broadband yang sangat lambat dan sangat mahal. Sebagai referensi, metriknya adalah $1,19 di Inggris Raya dan $1,26 di AS.

Apa yang mungkin lebih mudah dipahami adalah biaya rata-rata paket broadband. Perhatikan bahwa penelitian ini mencari paket broadband termurah yang ditawarkan, mengabaikan apakah paket ini memiliki batas data atau tidak, sehingga memberikan gambaran kasarnya yang berguna daripada biaya data per se.

Untuk biaya paket saja, Mauritania memiliki broadband termahal di dunia, dengan rata-rata $768,16 (kisaran $307,26 hingga $1.368,72). Biaya yang sangat besar ini termasuk membangun jalur fisik ke properti, karena hanya sedikit yang sudah ada di Mauritania. Pada 0,7 Mbps, Mauritania juga memiliki salah satu jaringan broadband paling lambat di dunia.

Taiwan memiliki broadband tercepat di dunia, dengan kecepatan rata-rata 85 Mbps. Yaman memiliki yang paling lambat, pada 0,38 Mbps. Tetapi bahkan negara-negara dengan infrastruktur broadband yang mapan memiliki apa yang disebut 'not-spots'. Inggris Raya berada di peringkat 34 dari 207 negara untuk kecepatan broadband, tetapi pada Juli 2019 masih ada sekolah di Inggris tanpa broadband.

Biaya rata-rata paket broadband di Inggris adalah $39,58, dan di Amerika Serikat adalah $67,69. Rata-rata termurah di dunia adalah Ukraina, hanya $5, meskipun kesepakatan broadband termurah dari mereka semua ditemukan di Kirgistan ($ 1,27 — terhadap rata-rata negara $108,22).

Zimbabwe adalah negara yang paling mahal untuk data seluler, dan statistiknya tidak jauh lebih baik untuk broadband-nya, dengan biaya rata-rata $128,71 dan biaya 'per megabit per bulan' $6,89.

Biaya Mutlak vs Biaya Dalam Istilah Nyata

Semua biaya yang diuraikan sejauh ini adalah biaya absolut dalam USD, berdasarkan nilai tukar pada saat penelitian. Biaya ini belum diperhitungkan untuk biaya hidup, artinya bagi banyak negara biaya sebenarnya jauh lebih tinggi secara riil.

Saya akan membatasi penjelajahan saya hari ini hingga 50 MB, yang di Zimbabwe akan dikenakan biaya sekitar $3,67 dengan tarif data seluler. Itu mungkin kedengarannya tidak banyak, tetapi para guru di Zimbabwe tahun ini mogok karena gaji mereka turun menjadi hanya $2,50 per hari.

Sebagai perbandingan, $3,67 adalah sekitar setengah dari upah minimum $7,25 di AS. Sebagai orang Zimbabwe, saya harus bekerja sekitar satu setengah hari untuk mendapatkan uang untuk membeli data 50MB ini, dibandingkan dengan hanya setengah jam di AS. Tidak mudah untuk membandingkan biaya hidup antar negara, tetapi dengan upah saja, biaya $3,67 dari 50 MB data di Zimbabwe akan terasa seperti $52 bagi orang Amerika dengan upah minimum.

Menyiapkan Eksperimen

Saya meluncurkan Chrome dan membuka alat dev, di mana saya mencekik jaringan ke koneksi 3G yang lambat. Saya ingin mensimulasikan koneksi lambat seperti yang dialami oleh pengguna di Uzbekistan, untuk melihat pengalaman seperti apa yang akan diberikan situs web kepada saya. Saya juga mencekik CPU saya untuk mensimulasikan berada di perangkat kelas bawah.

Saya menginstal ModHeader dan menyetel tajuk 'Simpan-Data' untuk memberi tahu situs web bahwa saya ingin meminimalkan penggunaan data saya. Ini juga merupakan tajuk yang disetel oleh 'Mode Ringan' Chrome untuk Android, yang akan saya bahas lebih detail nanti.

Saya mengunduh TripMode; aplikasi untuk Mac yang memberi Anda kendali atas aplikasi mana di Mac Anda yang dapat mengakses internet. Akses internet aplikasi lain diblokir secara otomatis.

Seberapa jauh saya memperkirakan anggaran 50 MB saya akan membawa saya? Dengan berat rata-rata halaman web hampir 1,7 MB, itu menunjukkan bahwa saya memiliki sekitar 29 halaman dalam anggaran saya, meskipun mungkin beberapa lebih dari itu jika saya dapat tetap berada di situs yang sama dan memanfaatkan cache browser.

Sepanjang percobaan saya akan menyarankan kiat kinerja untuk mempercepat cat yang memuaskan pertama dan waktu pemuatan halaman yang dirasakan. Beberapa tips ini mungkin tidak memengaruhi jumlah data yang ditransfer secara langsung , tetapi umumnya melibatkan penundaan pengunduhan sumber daya yang kurang penting, yang pada koneksi lambat dapat berarti sumber daya tidak pernah diunduh dan data disimpan.

Percobaan

Tanpa basa-basi lagi, saya memuat google.com, menggunakan 402 KB anggaran saya dan menghabiskan $0,03 (sekitar 1% dari anggaran Zimbabwe saya).

Secara keseluruhan, bukan ukuran halaman yang buruk, tetapi saya bertanya-tanya dari mana 24 permintaan jaringan itu berasal dan apakah halaman tersebut dapat dibuat lebih ringan atau tidak.

Beranda Google — DOM

Melihat markup halaman, tidak ada stylesheet eksternal — semua CSS inline.

Kiat Kinerja #1: CSS Penting Sebaris

Ini bagus untuk kinerja karena menghemat browser yang harus membuat permintaan jaringan tambahan untuk mengambil stylesheet eksternal, sehingga gaya dapat diuraikan dan diterapkan segera untuk cat konten pertama. Ada trade-off yang harus dilakukan di sini, karena stylesheet eksternal dapat di-cache tetapi yang inline tidak bisa (kecuali jika Anda pintar dengan JavaScript).

Saran umum adalah agar gaya kritis Anda (apa pun di paruh atas) sejajar, dan untuk gaya lainnya menjadi eksternal dan dimuat secara asinkron. Pemuatan CSS yang tidak sinkron dapat dicapai dalam satu baris HTML yang sangat cerdas:

 <link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

Devtools menunjukkan versi DOM yang sudah diedit. Jika Anda ingin melihat apa yang sebenarnya diunduh ke browser, alihkan ke tab Sumber dan temukan dokumennya.

Anda dapat melihat ada BANYAK JavaScript sebaris di sini. Perlu dicatat bahwa itu telah diperburuk daripada hanya diperkecil.

Kiat Kinerja #2: Perkecil dan Perkecil Aset Anda

Minifikasi menghilangkan spasi dan karakter yang tidak perlu, tetapi uglifikasi sebenarnya 'menghancurkan' kode menjadi lebih pendek. Tandanya adalah bahwa kode tersebut berisi nama variabel yang dibuat oleh mesin dan pendek daripada kode sumber yang tidak tersentuh. Ini bagus karena ini berarti skrip lebih kecil dan lebih cepat untuk diunduh.

Meski begitu, skrip sebaris terlihat kira-kira 120 KB dari sumber daya halaman 210 KB (sekitar setengah dari ukuran gzip 60 KB). Selain itu, ada lima file JavaScript eksternal sebesar 291 KB dari 402 KB yang diunduh:

Ini berarti bahwa JavaScript menyumbang sekitar 80 persen dari keseluruhan berat halaman.

Ini bukan JavaScript yang tidak berguna; Google harus memiliki beberapa untuk menampilkan saran saat Anda mengetik. Tapi saya curiga banyak dari itu adalah kode pelacakan dan pengaturan iklan.

Sebagai perbandingan, saya menonaktifkan JavaScript dan memuat ulang halaman:

Versi pencarian Google yang dinonaktifkan JS hanya 102 KB, dibandingkan dengan 402 KB. Meskipun Google tidak dapat memberikan saran otomatis dalam kondisi ini, situs ini masih berfungsi, dan saya baru saja mengurangi penggunaan data hingga seperempat dari sebelumnya. Jika saya benar-benar harus membatasi penggunaan data saya dalam jangka panjang, salah satu hal pertama yang akan saya lakukan adalah menonaktifkan JavaScript. Ini tidak seburuk kedengarannya.

Kiat Kinerja #3: Lebih Sedikit Lebih Banyak

Inlining, uglifying dan minifying aset semuanya baik dan bagus, tetapi kinerja terbaik datang dari tidak menurunkan aset di tempat pertama.

• Sebelum menambahkan fitur baru, apakah Anda memiliki anggaran kinerja?
• Sebelum menambahkan JavaScript ke situs Anda, dapatkah fitur Anda diselesaikan menggunakan HTML biasa? (Misalnya, validasi formulir HTML5).
• Sebelum menarik pustaka JavaScript atau CSS yang besar ke dalam aplikasi Anda, gunakan sesuatu seperti bundlephobia.com untuk mengukur seberapa besar itu. Apakah kenyamanan sebanding dengan bobotnya? Bisakah Anda mencapai hal yang sama menggunakan kode vanilla dengan ukuran data yang jauh lebih kecil?

Menganalisis Info Sumber Daya

Ada banyak hal yang harus dibongkar di sini, jadi mari kita mulai. Saya hanya punya 50 MB untuk dimainkan, jadi saya akan memeras setiap bagian dari pemuatan halaman ini. Selesaikan tutorial singkat Chrome Devtools.

402 KB ditransfer, tetapi sumber daya 1,1 MB: apa artinya sebenarnya?

Itu berarti 402 KB konten sebenarnya diunduh, tetapi dalam bentuk terkompresi (menggunakan algoritma kompresi seperti gzip atau brotli). Peramban kemudian harus melakukan beberapa pekerjaan untuk membongkarnya menjadi sesuatu yang berarti. Ukuran total data yang dibongkar adalah 1,1 MB.

Pembongkaran ini tidak gratis — ada beberapa milidetik overhead dalam mendekompresi sumber daya. Tapi itu overhead yang dapat diabaikan dibandingkan dengan mengirim 1,1MB secara langsung.

Kiat Kinerja #4: Kompres Aset Berbasis Teks

Sebagai aturan umum, selalu kompres aset Anda, menggunakan sesuatu seperti gzip. Tapi jangan gunakan kompresi pada gambar Anda dan file biner lainnya — Anda harus mengoptimalkannya terlebih dahulu di sumbernya. Kompresi sebenarnya bisa membuat mereka lebih besar.

Dan, jika Anda bisa, hindari mengompresi file yang berukuran 1500 byte atau lebih kecil. Ukuran paket TCP terkecil adalah 1500 byte, jadi dengan mengompresi, katakanlah, 800 byte, Anda tidak menyimpan apa pun, karena masih ditransmisikan dalam paket byte yang sama. Sekali lagi, biayanya dapat diabaikan, tetapi membuang waktu CPU kompresi di server dan waktu CPU dekompresi pada klien.

Sekarang kembali ke tab Jaringan di Chrome: mari gali prioritas tersebut. Perhatikan bahwa sumber daya memiliki prioritas "Tertinggi" hingga "Terendah" — ini adalah tebakan terbaik browser tentang sumber daya yang lebih penting untuk diunduh. Semakin tinggi prioritasnya, semakin cepat browser akan mencoba mengunduh aset.

Kiat Kinerja #5: Berikan Petunjuk Sumber Daya ke Peramban

Browser akan menebak apa aset prioritas tertinggi, tetapi Anda dapat memberikan petunjuk sumber daya menggunakan <link rel="preload"> , yang menginstruksikan browser untuk mendownload aset sesegera mungkin. Merupakan ide bagus untuk memuat font, logo, dan hal lain apa pun yang muncul di paruh atas.

Mari kita bicara tentang caching. Saya akan menahan ALT dan klik kanan untuk mengubah tajuk kolom saya untuk membuka beberapa informasi yang lebih menarik. Kita akan memeriksa Cache-Control.

Cache-Control menunjukkan apakah sumber daya dapat di-cache atau tidak, berapa lama dapat di-cache, dan aturan apa yang harus diikuti saat memvalidasi ulang. Menetapkan nilai cache yang tepat sangat penting untuk menjaga biaya data dari kunjungan berulang tetap rendah.

Kiat Kinerja #6: Setel Header kontrol-cache Pada Semua Aset yang Dapat Di-Cacheable

Perhatikan bahwa nilai cache-control dimulai dengan arahan public atau private , diikuti dengan nilai kedaluwarsa (mis max-age=31536000 ). Apa arti direktif itu, dan mengapa nilai max-age yang anehnya spesifik?

Nilai 31536000 adalah jumlah detik dalam satu tahun, dan merupakan nilai maksimum teoretis yang diizinkan oleh spesifikasi kontrol-cache. Adalah umum untuk melihat nilai ini diterapkan ke semua aset statis dan secara efektif berarti "sumber daya ini tidak akan berubah". Dalam praktiknya, tidak ada browser yang akan men-cache selama satu tahun penuh, tetapi akan men-cache aset selama masuk akal.

Untuk menjelaskan direktif publik/pribadi, kita harus menjelaskan dua cache utama yang ada di luar server. Pertama, ada cache browser tradisional, di mana sumber daya disimpan di mesin pengguna ('klien'). Dan kemudian ada cache CDN, yang berada di antara klien dan server; sumber daya di-cache di tingkat CDN untuk mencegah CDN meminta sumber daya dari server asal berulang kali.

Arahan Cache-Control dari public memungkinkan sumber daya di-cache di klien dan CDN. Nilai private berarti hanya klien yang dapat menyimpannya; CDN tidak seharusnya. Nilai terakhir ini biasanya digunakan untuk halaman atau aset yang ada di belakang otentikasi, di mana tidak masalah untuk di-cache di klien tetapi kami tidak ingin membocorkan informasi pribadi dengan menyimpannya di CDN dan mengirimkannya ke pengguna lain.

Satu hal yang menarik perhatian saya adalah bahwa logo Google memiliki kontrol cache "pribadi". Gambar lain pada halaman tersebut memiliki cache publik, dan saya tidak tahu mengapa logo tersebut diperlakukan secara berbeda. Jika Anda punya ide, beri tahu saya di komentar!

Saya menyegarkan halaman dan sebagian besar sumber daya disajikan dari cache, selain dari halaman itu sendiri, yang seperti yang Anda lihat sudah bersifat private, max-age=0 , artinya tidak dapat di-cache. Ini normal untuk halaman web dinamis di mana penting bagi pengguna untuk selalu mendapatkan halaman terbaru saat mereka menyegarkan.

Pada titik inilah saya secara tidak sengaja mengklik URL 'Penjelasan' di devtools, yang membawa saya ke referensi analisis jaringan, dengan biaya sekitar 5 MB dari anggaran saya. Ups.

Dokumen Google Dev

4,2 MB dari halaman 5 MB baru ini diturunkan ke gambar; khususnya SVG. Yang paling berat adalah 186 KB, yang tidak terlalu besar — ​​jumlahnya sangat banyak, dan semuanya diunduh sekaligus.

Pemuatan halaman 5 MB itu adalah 10% dari anggaran saya untuk hari ini. Sejauh ini saya telah menggunakan 5,5 MB, termasuk pemuatan ulang tanpa JavaScript dari beranda Google, dan menghabiskan $0,40. Saya bahkan tidak bermaksud membuka halaman ini.

Apa yang akan menjadi pengalaman pengguna yang lebih baik di sini?

Kiat Performa #7: Lazy-load Gambar Anda

Biasanya, jika saya tidak sengaja mengklik tautan, saya akan menekan tombol kembali di browser saya. Saya tidak akan menerima manfaat apa pun dari mengunduh gambar-gambar itu — betapa sia-sianya 4,2 MB!

Terlepas dari video, di mana Anda biasanya tahu apa yang Anda hadapi, gambar sejauh ini merupakan penyebab terbesar penggunaan data di web. Sebuah studi dari 500 situs web teratas dunia menemukan bahwa gambar mengambil hingga 53% dari berat halaman rata-rata. “Ini berarti mereka memiliki dampak besar pada waktu pemuatan halaman dan selanjutnya kinerja secara keseluruhan”.

Alih-alih mengunduh semua gambar pada pemuatan halaman, praktik yang baik adalah memuat lambat gambar sehingga hanya pengguna yang terlibat dengan halaman yang membayar biaya untuk mengunduhnya. Pengguna yang memilih untuk tidak menggulir paro bawah karena itu tidak menyia-nyiakan bandwidth yang tidak perlu dengan mengunduh gambar yang tidak akan pernah mereka lihat.

Ada panduan css-tricks.com yang bagus untuk meluncurkan pemuatan lambat untuk gambar yang menawarkan keseimbangan yang baik antara yang memiliki koneksi bagus, yang koneksi buruk, dan yang JavaScript dinonaktifkan.

Jika halaman ini telah menerapkan pemuatan lambat sesuai panduan di atas, masing-masing dari 38 SVG akan diwakili oleh gambar placeholder 1 KB secara default, dan hanya dimuat ke tampilan saat digulir.

Kiat Kinerja #8: Gunakan Format yang Tepat Untuk Gambar Anda

Saya pikir Google telah melewatkan trik dengan tidak menggunakan WebP, yang merupakan format gambar berukuran 26% lebih kecil dibandingkan dengan PNG (tanpa kehilangan kualitas) dan berukuran 25-34% lebih kecil dibandingkan dengan JPEG (dan kualitas sebanding). Saya pikir saya akan mencoba mengonversi SVG ke WebP.

Mengonversi ke WebP memang menurunkan salah satu SVG dari 186 KB menjadi hanya 65 KB, tetapi sebenarnya, melihat gambar secara berdampingan, WebP menjadi buram:

Saya kemudian mencoba mengonversi salah satu PNG ke WebP, yang seharusnya lossless dan seharusnya lebih kecil. Namun, keluaran WebP *lebih berat* (127 KB, dari 109 KB)!

Ini mengejutkan saya. WebP belum tentu merupakan peluru perak yang kita pikirkan, dan bahkan Google telah lalai menggunakannya di halaman ini.

Jadi saran saya adalah: jika memungkinkan, bereksperimenlah dengan format gambar yang berbeda berdasarkan per gambar. Format yang menjaga kualitas terbaik untuk ukuran terkecil mungkin bukan yang Anda harapkan.

Sekarang kembali ke DOM. Saya menemukan ini:

Perhatikan kata kunci async pada skrip analitik Google?

Meskipun menjadi salah satu hal pertama di kepala dokumen, ini diberi prioritas rendah, karena kami secara eksplisit memilih untuk tidak menjadi permintaan pemblokiran dengan menggunakan kata kunci async .

Permintaan pemblokiran adalah permintaan yang menghentikan rendering halaman. Panggilan <script> diblokir secara default, menghentikan penguraian HTML hingga skrip diunduh, dikompilasi, dan dieksekusi. Inilah sebabnya mengapa kami secara tradisional menempatkan panggilan <script> di akhir dokumen.

Kiat Kinerja #9: Hindari Menulis Panggilan Skrip Pemblokiran

Dengan menambahkan atribut async ke tag <script> kami, kami memberi tahu browser untuk tidak berhenti merender halaman tetapi mengunduh skrip di latar belakang. Jika HTML masih diurai pada saat skrip diunduh, penguraian dijeda saat skrip dijalankan, lalu dilanjutkan. Ini jauh lebih baik daripada memblokir rendering segera setelah <script> ditemukan.

Ada juga atribut defer , yang agak berbeda. <script defer> memberitahu browser untuk merender halaman saat skrip dimuat di latar belakang, dan bahkan jika HTML masih diurai pada saat skrip diunduh, skrip harus menunggu hingga halaman dirender sebelum dapat dieksekusi . Ini membuat skrip sepenuhnya non-blocking. Baca “Memuat JavaScript secara efisien dengan penangguhan dan asinkron” untuk informasi selengkapnya.

Pokoknya, cukup membedah Google. Saatnya mencoba situs lain. Anggaran saya masih tersisa hampir 45 MB!

Amazon

Beranda Amazon dimuat dengan berat total sekitar 6 MB. Salah satunya adalah gambar 587 KB yang bahkan tidak dapat saya temukan di halaman. Ini adalah PNG, mungkin memiliki teks yang tajam, tetapi pada latar belakang fotografi — kombinasi klasik yang buruk untuk kinerja.

Sebenarnya, ada beberapa ratus kilobyte gambar di tab jaringan saya yang sebenarnya tidak bisa saya lihat di halaman. Saya menduga ada kesalahan konfigurasi di suatu tempat di Amazon, tetapi gambar-gambar tak terlihat ini digabungkan dengan mengunyah setidaknya 1 MB data saya.

Bagaimana dengan gambar pahlawan? Ini adalah gambar utama di halaman, dan hanya 94 KB yang ditransfer — tetapi ukurannya bisa dikurangi sekitar 15% jika dipotong langsung di sekitar teks dan pemain sepak bola. Kami kemudian dapat menerapkan warna latar belakang yang sama di CSS seperti pada gambar. Ini memiliki keuntungan tambahan karena ukurannya dapat diubah ke layar yang lebih kecil sambil mempertahankan keterbacaan teks.

Saya telah mengatakannya sekali, dan saya akan mengatakannya lagi: mengoptimalkan dan memuat lambat gambar Anda adalah satu-satunya manfaat terbesar yang dapat Anda buat untuk bobot halaman situs Anda .

Mengoptimalkan gambar yang disediakan, sejauh ini, pengurangan data yang paling signifikan. Anda dapat membuat kasus JavaScript adalah kesepakatan yang lebih besar untuk kinerja secara keseluruhan, tetapi tidak pengurangan data. Mengoptimalkan atau menghapus gambar adalah cara teraman untuk memastikan pengalaman yang jauh lebih ringan dan itulah pengoptimalan utama yang diandalkan Penghemat Data.
— Tim Kadlec, Memahami Halaman Chrome Lite

Agar adil bagi Amazon, jika saya mengubah ukuran browser ke ukuran seluler dan menyegarkan halaman, situs dioptimalkan untuk seluler dan total berat halaman hanya 2,1 MB.

Tapi ini membawa saya ke poin saya berikutnya ...

Kiat Kinerja #10: Jangan Membuat Asumsi Tentang Koneksi Data

Sulit untuk mendeteksi apakah seseorang di desktop menggunakan koneksi broadband atau sedang melakukan tethering melalui dongle atau seluler terbatas data. Banyak orang bekerja di kereta seperti itu, atau tinggal di daerah di mana infrastruktur broadband buruk tetapi sinyal seluler kuat. Dalam kasus Amazon, ada ruang untuk menghemat banyak data di situs desktop dan kita tidak boleh berpuas diri hanya karena ukuran layar menunjukkan bahwa saya tidak menggunakan perangkat seluler.

Ya, kita harus mengharapkan pemuatan halaman yang lebih besar jika area pandang kita 'berukuran desktop' karena gambar akan lebih besar dan dioptimalkan lebih baik untuk layar daripada gambar seluler yang lebih kasar. Tapi halamannya tidak boleh lebih besar.

Selain itu, saya mengirim tajuk Save-Data dengan permintaan saya. Header ini secara eksplisit menunjukkan preferensi untuk pengurangan penggunaan data, dan saya berharap lebih banyak situs web mulai memperhatikannya di masa mendatang.

Beban 'desktop' awal mungkin 6 MB, tetapi setelah duduk dan menontonnya selama satu menit, beban itu telah naik menjadi 8,6 MB karena sumber daya dengan prioritas lebih rendah dan pelacakan peristiwa mulai beraksi. Berat halaman ini mencakup hampir 1,7 MB JavaScript yang diperkecil. Aku bahkan tidak ingin mulai melihat itu.

Kiat Kinerja #11: Gunakan Pekerja Web Untuk JavaScript Anda

Mana yang lebih buruk — 1,7 MB JavaScript atau 1,7 MB gambar? Jawabannya adalah JavaScript: kedua aset tersebut tidak setara dalam hal kinerja.

Gambar JPEG perlu di-decode, raster, dan dicat di layar. Bundel JavaScript perlu diunduh dan kemudian diurai, dikompilasi, dieksekusi —dan ada sejumlah langkah lain yang perlu diselesaikan oleh mesin. Sadarilah bahwa biaya ini tidak cukup setara.
— Addy Osmani, Biaya JavaScript di 2018

Jika Anda harus mengirimkan JavaScript sebanyak ini, coba masukkan ke web worker. Ini menjauhkan sebagian besar JavaScript dari utas utama, yang sekarang dibebaskan untuk mengecat ulang UI, membantu halaman web Anda tetap responsif pada perangkat berdaya rendah.

Saya sekarang sekitar 15,5 MB ke dalam anggaran saya, dan telah menghabiskan $1,14 dari anggaran data Zimbabwe saya. Saya harus bekerja selama setengah hari sebagai guru untuk mendapatkan uang untuk sampai sejauh ini.

Pinterest

Saya telah mendengar hal-hal baik tentang kinerja Pinterest, jadi saya memutuskan untuk mengujinya.

Mungkin ini bukan tes yang paling adil; Saya dibawa ke halaman masuk, di mana proses asinkron menemukan saya masuk ke Facebook dan memasukkan saya secara otomatis. Halaman dimuat relatif cepat, tetapi permintaan merayap karena semakin banyak konten yang dimuat sebelumnya.

Namun, saya melihat bahwa pada pemuatan halaman berikutnya, pekerja layanan memunculkan banyak konten — menghemat sekitar setengah dari berat halaman:

Situs Pinterest adalah aplikasi web progresif; itu menginstal pekerja layanan untuk secara manual menangani caching CSS dan JS. Saya sekarang dapat mematikan WiFi saya dan terus menggunakan situs (walaupun tidak terlalu berguna):

Kiat Kinerja #12: Gunakan Pekerja Layanan Untuk Memberikan Dukungan Offline

Bukankah lebih bagus jika saya hanya perlu memuat situs web sekali melalui jaringan, dan sekarang mendapatkan semua informasi yang saya butuhkan bahkan jika saya sedang offline?

Contoh yang bagus adalah situs web yang menunjukkan ramalan cuaca selama seminggu. Saya hanya perlu mengunduh halaman itu sekali. Jika saya mematikan data seluler saya dan kemudian kembali ke halaman di beberapa titik, itu seharusnya dapat menyajikan konten terakhir yang diketahui kepada saya. Jika saya terhubung ke internet lagi dan memuat halaman, saya akan mendapatkan perkiraan yang lebih terkini, tetapi aset statis seperti CSS dan gambar harus tetap disajikan secara lokal dari pekerja layanan.

Ini dimungkinkan dengan menyiapkan pekerja layanan dengan strategi caching yang baik sehingga halaman yang di-cache dapat diakses kembali secara offline. Situs web dokumentasi lodash adalah contoh bagus dari pekerja layanan di alam liar:

Konten yang jarang diperbarui dan cenderung digunakan secara teratur adalah kandidat yang sempurna untuk perawatan pekerja layanan. Situs dinamis dengan umpan berita yang selalu berubah tidak begitu cocok untuk pengalaman offline, tetapi tetap dapat mengambil manfaat.

Pekerja layanan benar-benar dapat menghemat hari ketika Anda memiliki anggaran data yang ketat. Saya tidak yakin pengalaman Pinterest adalah yang paling optimal dalam hal penggunaan data – halaman berikutnya berukuran sekitar 0,5 MB bahkan pada halaman dengan sedikit gambar — tetapi membiarkan JavaScript Anda menangani permintaan halaman untuk Anda dan mempertahankan elemen navigasi yang sama di tempatnya bisa sangat berprestasi. BBC mengelola ukuran transfer hanya 3,1 KB untuk kunjungan kembali ke artikel yang dapat dirender melalui aplikasi satu halaman.

Sejauh ini, Pinterest sendiri telah menghabiskan 14 MB, yang berarti saya telah menghabiskan sekitar 30 MB dari anggaran saya, atau $2,20 (hampir upah sehari) dari anggaran Zimbabwe saya.

Saya sebaiknya berhati-hati dengan 20 MB terakhir saya… tapi di mana kesenangannya?

Tempat permainan

Saya memilih yang ini karena terasa sangat lamban di ponsel saya di masa lalu dan saya ingin menggali alasannya. Benar saja, memuat beranda menghabiskan 8,5 MB data.

6,5 MB ini turun ke video yang diputar otomatis di tengah halaman, yang — agar adil — tampaknya tidak diunduh sampai saya mulai menggulir. Namun demikian…

Saya hanya bisa melihat setengah video di viewport saya — sisi kanan terpotong. Itu juga berdurasi 30 detik, dan saya berani bertaruh bahwa kebanyakan orang tidak akan duduk dan menonton semuanya. Aset tunggal ini lebih dari tiga kali lipat ukuran halaman.

Kiat Performa #13: Jangan Muat Ulang Video

Sebagai aturan, kecuali mode komunikasi utama situs Anda adalah video, jangan lakukan pramuat.

Jika Anda adalah YouTube atau Netflix, masuk akal untuk berasumsi bahwa seseorang yang datang ke halaman Anda ingin video tersebut dimuat secara otomatis dan diputar secara otomatis. Ada harapan bahwa video akan mengunyah beberapa data, tetapi itu adalah pertukaran yang adil untuk konten. Tetapi jika Anda adalah situs yang media utamanya adalah teks dan gambar — dan Anda kebetulan menawarkan konten video tambahan — maka jangan lakukan pramuat video.

Pikirkan artikel berita dengan video tersemat. Banyak pengguna hanya ingin membaca sekilas judul artikel sebelum beralih ke hal berikutnya. Orang lain akan membaca artikel tersebut tetapi mengabaikan penyematan apa pun. Dan orang lain akan rajin mengklik dan menonton setiap video yang disematkan. Kita tidak boleh memonopoli bandwidth setiap pengguna dengan asumsi bahwa mereka ingin menonton video ini.

Untuk mengulangi: pengguna tidak suka memutar video secara otomatis. Sebagai pengembang, kami hanya melakukannya karena manajer kami menyuruh kami, dan mereka hanya memberi tahu kami untuk melakukannya karena semua aplikasi paling keren melakukannya, dan aplikasi paling keren hanya melakukannya karena iklan video menghasilkan pendapatan 20 hingga 50 kali lebih banyak daripada tradisional. iklan. Google Chrome telah mulai memblokir video putar otomatis untuk beberapa situs, berdasarkan preferensi pribadi, jadi meskipun Anda mengembangkan situs untuk memutar video secara otomatis, tidak ada jaminan bahwa itulah pengalaman yang diperoleh pengguna Anda.

Jika kami setuju bahwa merupakan ide yang baik untuk menjadikan video sebagai pengalaman keikutsertaan (klik untuk memutar), kami dapat mengambil langkah lebih jauh dan membuatnya klik untuk memuat juga. Itu berarti mengejek gambar placeholder video dengan tombol putar di atasnya, dan hanya mengunduh video saat Anda mengklik tombol putar. People on fast connections should notice no difference in buffer speed, and people on slow connections will appreciate how fast the rest of your site loaded because it didn't have to preload a large video file.

Anyway, back to Gamespot, where I was indeed forced to preload a large video file I ended up not watching. I then clicked through to a game review page that weighed another 8.5 MB, this time with 5.4 MB of video, before I even started scrolling down the page.

What was really galling was when I looked at what the video actually was. It was an advert for a Samsung TV! This advert cost me $0.40 of my Zimbabwe wages. Not only was it pre-loaded, but it also didn't end up playing anywhere as far as I'm aware, so I never actually saw it.

The 'real' video — the gameplay footage (in other words, the content) — wasn't actually loaded until I clicked on it. And that ploughed through my remaining data in seconds.

Itu dia. That's my 50 MB gone. I'll need to work another 1.5 days as a Zimbabwean schoolteacher to repeat the experience.

Performance Tip #14: Optimize For First Page Load

What's striking is that I used 50 MB of data and in most cases, I only visited one or two pages on any given site. If you think about it, this is true of most user journeys today.

Think about the last time you Googled something. You no doubt clicked on the first search result. If you got your answer, you closed the tab, or else you hit the back button and moved onto the next search result.

With the exception of a few so-called 'destination sites' such as Facebook or YouTube, where users habitually go as a starting point for other activities, the majority of user journeys are ephemeral. We stumble across random sites to get the answers to our questions, never to return to those sites again.

Web development practices are heavily skewed towards optimising for repeat visitors. “Cache these assets — they'll come in handy later”. “Pre-load this onward journey, in case the user clicks to read more”. “Subscribe to our mailing list”.

Instead, I believe we should optimize heavily for one-off visitors. Call it a controversial opinion, but maybe caching isn't really all that important. How important can a cached resource that never gets surfaced again be ? And perhaps users aren't actually going to subscribe to your mailing list after reading just the one article, so downloading the JavaScript and CSS for the mail subscription modal is both a waste of data and an annoying user experience.

The Decline Of Proxy Browsers

I had hoped to try out Opera Mini as part of this experiment. Opera Mini is a mobile web browser which proxies web pages through Opera's compression servers. It accounts for 1.42% of global traffic as of June 2019, according to caniuse.com.

Opera Mini claims to save up to 90% of data by doing some pretty intensive transcoding. HTML is parsed, images are compressed, styling is applied, and a certain amount of JavaScript is executed on Opera's servers. The server doesn't respond with HTML as you might expect — it actually transcodes the data into Opera Binary Markup Language (OBML), which is progressively loaded by Opera Mini on the device. It renders what is essentially an interactive 'snapshot' of the web page — think of it as a PDF with hyperlinks inside it. Read Tiffany Brown's excellent article, “Opera Mini and JavaScript” for a technical deep-dive.

It would have been a perfect way to eek my 50 MB budget as far as possible. Unfortunately, Opera Mini is no longer available on iOS in the UK. Attempting to visit it in the app store throws an error:

It's still available “in some markets” but reading between the lines, Opera will be phasing out Opera Mini for its new app — Opera Touch — which doesn't have any data-saving functionality apart from the ability to natively block ads.

Opera desktop used to have a 'Turbo mode', acting as a traditional proxy server (returning a HTML document instead of OBML), applying data-saving techniques but less intensively than Opera Mini. According to Opera, JavaScript continues to work and “you get all the videos, photos and text that you normally would, but you eat up less data and load pages faster”. However, Opera quietly removed Turbo mode in v60 earlier this year, and Opera Touch doesn't have a Turbo mode either. Turbo mode is currently only available on Opera for Android.

Android is where all the action is in terms of data-saving technology. Chrome offers a 'Lite mode' on its mobile browser for Android, which is not available for iPhones or iPads because of “platform constraints“. Outside of mobile, Google used to provide a 'Data Saver' extension for Chrome desktop, but this was canned in April.

Lite mode for Chrome Android can be forcibly enabled, or automatically kicks in when the network's effective connection type is 2G or worse, or when Chrome estimates the page will take more than 5 seconds to reach first contentful paint. Under these conditions, Chrome will request the lite version of the HTTPS URL as cached by Google's servers, and display this stripped-down version inside the user's browser, alongside a “Lite” marker in the address bar.

I'd love to try it out — apparently it disables scripts, replaces images with placeholders, prevents loading of non-critical resources and shows offline copies of pages if one is available on the device. This saves up to 60% of data. However, it isn't available in private (Incognito) mode, which hints at some of the privacy concerns surrounding proxy browsers.

Mode Ringan membagikan URL HTTPS dengan Google, oleh karena itu masuk akal jika mode ini tidak tersedia di Penyamaran. Namun informasi lain seperti cookie, informasi login, dan konten halaman yang dipersonalisasi tidak dibagikan dengan Google — menurut ghacks.net — dan “tidak pernah memutuskan koneksi aman antara Chrome dan situs web”. Orang bertanya-tanya mengapa tampaknya tidak ada layanan penghemat data ini yang diizinkan di iOS (dan tidak ada berita apakah mode Lite akan tersedia di iOS).

Proksi penghemat data membutuhkan banyak kepercayaan; aktivitas penjelajahan Anda, cookie, dan informasi sensitif lainnya dipercayakan ke beberapa server, seringkali di negara lain. Banyak proxy tidak akan berfungsi lagi karena banyak situs telah pindah ke HTTPS, yang berarti inisiatif seperti mode Turbo telah menjadi "fitur yang tidak berguna". HTTPS mencegah perilaku man-in-the-middle semacam ini, yang merupakan hal yang baik, meskipun itu berarti kematian beberapa layanan proxy ini dan telah membuat situs kurang dapat diakses oleh mereka yang memiliki koneksi buruk.

Saya tidak dapat menemukan alat penghemat data yang kompatibel dengan OSX atau iOS kecuali untuk Bandwidth Hero untuk Firefox (yang memerlukan pengaturan layanan kompresi data Anda sendiri — jauh melampaui kemampuan teknis sebagian besar pengguna!) dan skyZIP Proxy (yang, terakhir diperbarui di 2017 dan penuh dengan kesalahan ketik, saya tidak bisa mempercayai diri sendiri).

Kesimpulan

Mengurangi jejak data situs web Anda seiring dengan peningkatan kinerja frontend. Ini adalah satu-satunya hal yang paling dapat diandalkan yang dapat Anda lakukan untuk mempercepat situs Anda.

Selain biaya data, ada banyak alasan bagus untuk fokus pada kinerja, seperti yang dijelaskan dalam posting blog GOV.UK tentang masalah ini:

• 53% pengguna akan meninggalkan situs seluler jika memuat lebih dari 3 detik.
• Orang harus berkonsentrasi 50% lebih ketika mencoba menyelesaikan tugas sederhana di situs web menggunakan koneksi yang lambat.
• Halaman web yang lebih berperforma lebih baik untuk masa pakai baterai perangkat pengguna, dan biasanya membutuhkan lebih sedikit daya pada server untuk mengirimkannya. Situs berkinerja baik untuk lingkungan.

Kami tidak memiliki kekuatan untuk mengubah biaya global ketidaksetaraan data. Namun kami memiliki kekuatan untuk mengurangi dampaknya, meningkatkan pengalaman bagi semua orang dalam prosesnya.