Teknologi
5G sudah menjadi kenyataan. Ikon yang sesuai mulai muncul di bagian atas layar ponsel di seluruh dunia. Jika Anda terhubung ke jaringan 5G, maka Anda mungkin telah memperhatikan bahwa jaringan seperti itu tampaknya tidak jauh lebih cepat daripada jaringan 4G. Saya cukup mengerti itu. Mereka mengatakan bahwa sekarang, pada masa pembentukan jaringan baru, proses migrasi infrastruktur menghambat kecepatan 5G yang sebenarnya. Tetapi setelah teknologi 5G, dalam segala hal, telah matang, diharapkan kecepatan jaringan akan meningkat sangat banyak. Jadi, menurut beberapa informasi, kecepatan pengunduhan data rata-rata di jaringan 5G pada 2019 dapat berkisar
dari 100 Mbit hingga 1 Gbit per detik . Ini berarti bahwa akan mungkin untuk mengunduh seluruh diskografi Teman, dan kemudian dengan sungguh-sungguh menyeretnya ke keranjang, setelah melakukan ini dalam waktu yang hampir bersamaan dengan memuat halaman web biasa. Saya tidak mencoba untuk keluar pada nomor tertentu sekarang. Saya hanya mengatakan bahwa, mungkin, bekerja di jaringan 5G mungkin terlihat seperti itu. Masa depan seperti itu hanya bisa disebut "indah".
Ya, jangan lupa bahwa dalam jaringan 5G tidak hanya bandwidth akan meningkat. Penurunan latensi jaringan juga diperkirakan. Dan penundaan adalah salah satu hambatan kinerja web yang panjang dan terkenal. Mengurangi keterlambatan berarti waktu yang diperlukan untuk terhubung ke situs web, seperti yang dirasakan pengguna, turun hingga hampir nol. Sekali lagi - itu hanya terlihat indah.
Ternyata kualitas jaringan akan tumbuh secara signifikan segera. Dan itu, tampaknya, harus menyelesaikan masalah kecepatan web modern. Jadi?
Seharusnya, tetapi penulis materi, terjemahan yang kami terbitkan hari ini, tidak mengharapkan 5G untuk benar-benar mempercepat web. Setidaknya - itu akan mempercepat, tetapi tidak segera. Dia percaya bahwa jika tren modern dalam pengembangan web tidak berubah, maka adopsi luas jaringan 5G akan mengarah pada fakta bahwa rata-rata pengguna akan bekerja di web tidak lebih baik, tetapi lebih buruk.
Lebih buruk? Tapi bagaimana?
Jaringan yang lebih cepat harus menyelesaikan masalah kecepatan pemuatan situs, tetapi sejauh ini peningkatan kecepatan jaringan secara tidak sengaja memengaruhi web. Saya bertanya-tanya mengapa? Intinya adalah ini: secara historis, akselerasi jaringan memungkinkan pengembang mengirim lebih banyak kode ke pengunjung situs web. Secara khusus, kita berbicara tentang kode JavaScript.
Dari 2011 hingga 2019, tingkat
cakupan 4G di dunia tumbuh dari 5% menjadi 79%. Pada saat yang sama, nilai median jumlah rata-rata kode JavaScript yang dikirimkan ke perangkat seluler meningkat sebesar
611% - dari 52 Kb menjadi 372,9 Kb. Tentu saja, volume JS-code telah tumbuh tidak hanya karena pertumbuhan kecepatan jaringan. Banyak faktor lain yang berkontribusi terhadap hal ini. Situs, tentu saja, selama ini menjadi jauh lebih interaktif. Ini bisa mengarah pada peningkatan volume komponen JS mereka. Selain itu, desain yang responsif telah menyebar. Akibatnya, banyak situs mulai mengirim bundel JavaScript yang sama ke semua perangkat tempat situs ini menjelajah. Namun, perlu diperjelas bahwa situs desktop yang dikirim ke pelanggan rata-rata hanya 50 KB lebih banyak pada kode JS pada tahun 2011 daripada rekan seluler mereka. Secara umum, dapat dicatat bahwa pola pengembangan antarmuka tidak banyak berubah sejak 2011. Misalnya, situs web Boston Globe, yang dalam perkembangannya kami berpartisipasi, dibuat dengan perhatian besar pada kenyamanan bekerja dengannya di berbagai perangkat. Diluncurkan pada 2010. Antarmuka situs berita masih diatur dengan cara yang persis sama. Dan akhirnya, tren di atas, menurut data terbaru, terus berlanjut. Yaitu, selama beberapa tahun terakhir, jumlah rata-rata kode JS yang dikirim ke pelanggan telah meningkat lebih dari
50% .
Dan sekarang, sebelum kita mulai menyalahkan kerangka kerja JavaScript untuk semuanya, perlu dicatat bahwa ada perasaan bahwa pertumbuhan volume kode JS tidak sepenuhnya terkait dengan kemampuan antarmuka situs. Di sini harus dicatat bahwa sebagian besar pertumbuhan volume kode dikaitkan dengan peningkatan penggunaan skrip pihak ketiga sebesar
706% . Tidak diragukan lagi, permintaan untuk mengunduh skrip pihak ketiga dapat merujuk ke kerangka kerja JS, tetapi lebih sering ini adalah hal lain. Ini mungkin kode pelacak, perpustakaan A / B, skrip untuk personalisasi. Ini bisa berupa iklan, chat bot ... Dan semua ini, pada gilirannya, membuat permintaan untuk skrip tambahan, dan skrip tambahan ini masih memuat sesuatu. Di depan kita, bisa dikatakan, kesenangan yang tak terkendali. Tetapi kesenangan seperti itu biasanya memiliki konsekuensi buruk.
Jadi, ketika bandwidth jaringan tumbuh, begitu pula jumlah kode JS yang digunakan pada halaman web. Tetapi bahkan di sini Anda mungkin berpikir bahwa jika semua kode ini dimuat cukup cepat, maka pertumbuhan volumenya adalah fenomena yang relatif tidak berbahaya. Benar, ini, sayangnya, tidak demikian. Jika Anda membandingkan kode JavaScript dengan jenis sumber daya lain yang digunakan untuk membuat halaman web, ternyata JavaScript adalah kesenangan yang sangat mahal. Harga JavaScript jauh lebih tinggi daripada harga bahan lainnya.
"Semuanya terlihat bagus di ponsel saya."
Kenyamanan pengembang dapat dengan mudah memimpin industri web di jalur yang bengkok.
Pada perangkat seluler rata-rata, dari yang masih digunakan, parsing kode JavaScript 200 Kb (dikompres untuk mempercepat transfer) mungkin memerlukan waktu
6 detik atau bahkan lebih . Dan ini setelah kode diunduh melalui jaringan. Sebelum Anda memutuskan bahwa 200 Kb tidak realistis banyak untuk situs tertentu, saya sarankan Anda mengingat bahwa melihat situs modern berarti bahwa pengguna, rata-rata, akan mengunduh hampir
dua kali lipat kode JS. Pada saat yang sama, dalam proses penguraian kode ini, halaman mungkin terlihat, tetapi tidak responsif terhadap dampak. Atau mungkin halaman tersebut akan benar-benar kosong (ini adalah jika skrip terhubung ke halaman menggunakan pendekatan tradisional, yaitu, sehingga pengolahannya memblokir rendering halaman). Halaman tidak aktif dan halaman kosong sama buruknya, tetapi kekhawatiran khusus adalah bahwa banyak dari mereka yang terlibat dalam pengembangan web bahkan tidak melihat masalah seperti itu sendiri.
Perangkat seluler rata-rata bukanlah iPhone mahal terbaru dengan tiga kamera. Perangkat rata-rata, bahkan di AS, adalah ponsel terlaris yang harganya sekitar $ 130. Ini mungkin iPhone, tetapi tidak berarti yang terbaru. Kemungkinan besar, itu akan menjadi ponsel Android kelas menengah yang berisi isian perangkat keras yang relatif lemah. Apa yang bisa saya katakan - ini adalah ponsel terlaris dengan Amazon. Pada saat penulisan ini, di tempat ketiga adalah perangkat $ 59.
Jika orang-orang dengan ponsel semacam itu bahkan menggunakan jaringan cepat baru, perangkat mereka akan secara harfiah “dicekik” oleh jumlah kode yang harus diproses untuk menampilkan halaman web. Dan ini akan meniadakan potensi peningkatan kecepatan pengunduhan materi yang dapat memberikan jaringan 5G.
Bagaimana dengan mereka yang tidak memiliki koneksi 5G?
Pengorganisasian distribusi jaringan 5G membutuhkan perubahan infrastruktur besar. Calon pertama untuk munculnya jaringan tersebut adalah negara-negara maju dan kota-kota teknologi tinggi. Di negara-negara berkembang dan daerah pedesaan, jaringan ini tidak mungkin muncul dengan cepat. Ini berarti bahwa orang yang tinggal di tempat yang tidak memiliki jaringan 5G, dalam kondisi modern, tidak hanya dapat bekerja dengan halaman web pada perangkat yang tidak tercepat, tetapi juga mengunduh kode halaman-halaman ini, yang volumenya semakin bertambah, menggunakan 3G dan 2G lama -jaring. Orang-orang seperti itu akan sakit dua kali lipat dari pengenalan jaringan 5G.
Apa yang harus dilakukan
Tanggung jawab untuk menyelesaikan masalah ini terletak pada industri pengembangan web, masing-masing dari kita. Tentu saja, kami perlu meningkatkan prioritas pengiriman konten halaman web ke klien, tetapi kami juga harus berhenti memasukkan kode JavaScript dalam jumlah besar ke proyek kami. Penting untuk menganalisis skrip yang digunakan, secara teratur memeriksa dependensi proyek. Banyak dari dependensi ini dapat ditinggalkan oleh pengembang mereka, atau mereka mungkin proyek yang berumur pendek. Mungkin kita bahkan bisa memanfaatkan pengalaman
The Telegraph di sini
dengan menghapus skrip pihak ketiga lama dan melihat apakah ada yang mengeluh tentang masalah apa pun. Kami dapat memeriksa ketergantungan kami pada pelacakan tindakan pengguna dan pada personalisasi iklan. Mungkin kita, sama seperti
The New York Times , akan mengetahui bahwa penayangan iklan non-personal reguler kepada pengguna dapat
meningkatkan pendapatan iklan kami. Dan jika memang begitu - perlu menyingkirkan skrip iklan yang telah menjadi tidak perlu. Anda dapat menggunakan alat seperti
Kaliber atau
SpeedCurve untuk melihat bahwa metrik kinerja proyek web Anda tidak melampaui batas. Pada saat yang sama, perlu diperjuangkan untuk memastikan bahwa setiap orang yang terkait dengan proyek menangani proyek, sehingga semua orang tahu bagaimana tindakan atau kelambanannya mempengaruhi proyek.
Yang paling penting, kita perlu memastikan bahwa manajer, pemilik situs web, pengembang, perancang, dan tentunya semua orang, memiliki akses ke telepon kelas menengah dan memiliki kesempatan untuk menguji situs kami secara teratur di telepon tersebut. Dan bahkan lebih baik - jika ponsel tersebut terhubung ke paket prabayar atau tarif terbatas. Ini akan memberi tahu Anda berapa lama untuk memilih batas lalu lintas di dunia jaringan 5G. Jika semua orang yang terkait dengan situs tertentu tahu tentang bagaimana kinerjanya di dunia nyata, ini akan memiliki efek menguntungkan pada semua pengunjung situs. Termasuk, omong-omong, bagi mereka yang menggunakan ponsel modern cepat.
Meningkatkan kualitas jaringan berarti bahwa komunitas pengembangan memiliki peluang besar untuk meningkatkan ruang web yang mereka buat. Apakah mereka memanfaatkan peluang ini atau tidak hanya bergantung pada mereka.
Pembaca yang budiman! Apakah Anda berpikir bahwa adopsi jaringan 5G yang meluas dapat memperlambat web?
