🖖🏿 👩🏿‍🤝‍👨🏽 🚓 Harga JavaScript 2018 🍻 👮 🕝

Pengalaman pengguna dengan situs web interaktif dapat mencakup langkah mengirimkannya kode JavaScript. Seringkali - terlalu banyak kode ini. Jika situs menggunakan banyak JavaScript, ini terutama memengaruhi pengguna seluler. Misalnya, apakah Anda pernah mengunjungi halaman web seluler yang sepertinya siap digunakan tetapi tidak menanggapi klik pada tautan atau upaya menggulir halaman?

Kode JavaScript yang masuk ke peramban seluler masih merupakan sumber daya yang paling mahal, karena, dalam banyak hal, dapat menunda transisi laman ke keadaan di mana Anda dapat berinteraksi dengannya. Macam apa memuat pada sistem JavaScript hari ini? Bagaimana cara menganalisis situs? Bagaimana mempercepat pemuatan dan pemrosesan oleh browser halaman web interaktif? Eddie Osmani, yang terjemahannya kami terbitkan hari ini, memutuskan untuk menemukan jawaban untuk ini dan banyak pertanyaan lain yang muncul dengan mereka yang menggunakan JavaScript untuk mengembangkan situs web pada tahun 2018.

Ketentuan Umum

Lihatlah laporan ini, yang menunjukkan waktu yang diperlukan untuk memproses kode JavaScript CNN untuk berbagai perangkat. Ini dibangun berdasarkan pengukuran yang dilakukan melalui proyek WebPageTest.org (di sini adalah tabel dengan sumber data untuk laporan ini, ada juga data di situs web Walmart).

Waktu yang diperlukan untuk memroses kode JS cnn.com untuk berbagai perangkat

Seperti yang Anda lihat, telepon kelas atas (iPhone 8) mengatasi tugas memproses kode JS dalam waktu sekitar 4 detik. Telepon kelas menengah (Moto G4) membutuhkan sekitar 13 detik untuk menyelesaikan masalah yang sama. Anggaran, meskipun perangkat modern, seperti Alcatel 1X, membutuhkan waktu sekitar 36 detik.

Hari ini kita akan berbicara tentang strategi yang dapat diterapkan pengembang web untuk membuat situs yang nyaman dan modern, di satu sisi, dan di sisi lain, untuk memastikan pemuatan, pemrosesan, dan fungsi yang efektif dari komponen JavaScript dari situs-situs ini. Di sini, secara singkat, adalah poin utama dari percakapan kami, yang, omong-omong, didasarkan pada pidato saya baru - baru ini :

Agar proyek web dapat bekerja dengan cepat, Anda hanya perlu mengunduh kode JavaScript yang diperlukan untuk halaman saat ini. Menggunakan teknologi pemecahan kode memungkinkan Anda untuk mengatur pemuatan secepat mungkin dari apa yang pasti dibutuhkan pengguna, dan menerapkan teknik pemuatan malas untuk fragmen kode lainnya. Berkat pendekatan ini, halaman mendapat kesempatan untuk memuat lebih cepat daripada dalam kasus lain, dan dengan cepat mencapai keadaan di mana ia dapat berinteraksi dengan. Jika Anda menggunakan sistem yang, secara default, menggunakan pemisahan kode berbasis rute, ini membuat perbedaan.
Patuhi batasan yang ditetapkan untuk parameter proyek, yang disebut "anggaran kinerja", dan belajar untuk mematuhinya. Jadi, misalnya, perkirakan ukuran kode JS yang diperkecil dan dikompresi yang diperlukan untuk halaman yang dirancang untuk perangkat seluler tidak boleh melebihi 170 Kb . Ketika mengkonversi bahan-bahan tersebut ke bentuk normal, sekitar 700 Kb kode diperoleh. Pembatasan seperti itu sangat penting untuk keberhasilan proyek, namun hanya mereka sendiri yang secara ajaib tidak dapat membuat situs lambat. Budaya tim , struktur dan sarana untuk memonitor implementasi aturan memainkan peran di sini. Pengembangan proyek tanpa anggaran berkontribusi pada penurunan produktivitas secara bertahap dan dapat menyebabkan konsekuensi yang tidak menyenangkan.
Pelajari cara mengaudit bundel JavaScript (rakitan) dan memperkecil ukurannya. Sangat mungkin bahwa pelanggan harus mengunduh versi lengkap perpustakaan , sementara hanya sebagian dari mereka yang diperlukan agar proyek dapat berfungsi. Mungkin proyek menyertakan polyfill untuk browser yang tidak mereka butuhkan, dan duplikasi kode tidak dikecualikan.
Setiap interaksi pengguna dengan situs adalah awal dari masa tunggu baru, setelah itu dimungkinkan untuk bekerja dengan situs (inilah yang disebut "waktu untuk interaktivitas", TTI, Waktu untuk Interaktif). Optimalisasi patut dipertimbangkan dalam konteks ini. Ukuran kode yang ditransmisikan sangat penting untuk jaringan seluler yang lambat, dan waktu yang diperlukan untuk menguraikan kode JavaScript adalah untuk perangkat dengan kemampuan komputasi sederhana.
Jika menggunakan JavaScript sisi klien tidak meningkatkan pengalaman pengguna Anda, pertimbangkan apakah akan menggunakan JS dalam situasi ini. Mungkin dalam kasus seperti itu akan lebih cepat untuk membuat kode HTML di server. Pikirkan tentang membatasi penggunaan kerangka kerja klien, tentang menggunakannya hanya untuk membentuk halaman yang benar-benar tidak dapat melakukannya tanpanya. Baik rendering di server dan rendering pada klien, jika teknologi ini digunakan secara tidak benar, menjadi sumber masalah serius.

Proyek web modern dan masalah penggunaan berlebihan JavaScript

Ketika seorang pengguna mengakses situs Anda, Anda mungkin mengirimnya sejumlah besar file, banyak di antaranya adalah skrip. Dari perspektif browser web, tampilannya seperti ini.

Seperti inilah rasanya browser, yang dibanjiri file

Tidak peduli betapa saya mencintai JavaScript, saya tidak bisa tidak mengakui kenyataan bahwa itu selalu menjadi bagian situs yang paling mahal dan paling sulit bagi browser untuk diproses. Sebenarnya, saya ingin berbicara tentang mengapa JavaScript bisa menjadi masalah utama situs.

JavaScript adalah bagian tersulit dari situs ini

Menurut laporan Arsip JavaScript Juli tentang menggunakan JavaScript, rata-rata halaman web hari ini menggunakan sekitar 350 KB kode JavaScript yang diperkecil dan dikompres. Kode ini diurai menjadi sesuatu seperti skrip 1 MB yang perlu diproses oleh browser. Agar pengguna seluler dapat berinteraksi dengan halaman seperti itu, ia harus menunggu lebih dari 14 detik .

Halaman rata-rata yang berisi 350 KB kode JS terkompresi menjadi interaktif di perangkat seluler dalam waktu sekitar 15 detik

Jika Anda tidak tahu persis bagaimana ikatan JavaScript Anda memengaruhi berapa lama pengguna harus menunggu sampai mereka dapat berinteraksi dengan situs Anda, lihat alat Mercusuar .

Waktu pengunduhan data pada jaringan seluler dan pemrosesannya pada prosesor yang tidak cepat memberikan kontribusi serius sambil menunggu halaman disiapkan untuk bekerja pada perangkat seluler.

Mari kita menganalisis keadaan di bidang jaringan seluler dengan melihat data OpenSignal . Gambar berikut, di sebelah kiri, menunjukkan ketersediaan jaringan 4G di dunia (semakin gelap warna yang digunakan untuk melukis wilayah negara tersebut - semakin tinggi ketersediaannya), kecepatan transfer data ditunjukkan di sebelah kanan (lagi - semakin gelap semakin tinggi kecepatan). Negara-negara yang wilayahnya berwarna abu-abu tidak termasuk dalam penelitian ini. Perlu dicatat bahwa di daerah pedesaan, bahkan di AS, kecepatan transfer data seluler bisa 20% lebih lambat daripada di kota.

Ketersediaan jaringan 4G dan kecepatan data

Kami mengatakan di atas bahwa dibutuhkan sejumlah waktu untuk mengunduh dan mem-parsing 350 KB kode JS yang diperkecil dan dikompresi. Namun, jika Anda melihat situs populer, ternyata mereka mengirimkan lebih banyak kode kepada pengguna. Data yang ditunjukkan pada gambar di bawah ini diambil dari sini . Mereka adalah ukuran bundel JavaScript yang dibongkar dari berbagai sumber daya web terkenal, seperti Google Sheets, kode JS yang dibongkar yang pada platform desktop membutuhkan 5,8 MB.

Membongkar ukuran perakitan JavaScript untuk berbagai sumber

Seperti yang Anda lihat, pada platform desktop dan mobile, browser terkadang harus memproses beberapa megabyte kode JS untuk bekerja dengan berbagai situs. Pertanyaan utama di sini adalah - bisakah Anda menggunakan JavaScript dalam jumlah besar?

JavaScript tidak gratis

Menurut Alex Russell, situs yang membutuhkan JavaScript dalam jumlah besar untuk bekerja tidak dapat diakses oleh lapisan pengguna yang luas. Menurut statistik, pengguna tidak menunggu (dan tidak akan menunggu) untuk memuat sumber daya tersebut.

Bisakah Anda membelinya?

Jika Anda harus mengirim terlalu banyak kode JS ke pengguna, pertimbangkan untuk menggunakan teknologi pemecahan kode untuk memecah bundel menjadi beberapa bagian kecil, atau kurangi jumlah kode menggunakan algoritma pengocok pohon .

Bundel JS dari situs modern sering kali mencakup yang berikut:

Kerangka web klien atau pustaka antarmuka pengguna.
Alat untuk mengelola keadaan aplikasi (misalnya, Redux).
Polyfill (sering untuk browser modern yang tidak membutuhkannya).
Versi lengkap perpustakaan, dan bukan hanya bagian-bagian yang benar-benar digunakan (misalnya, seluruh perpustakaan Lodash, perpustakaan Moment.js dalam versi dengan dukungan untuk semua standar regional).
Seperangkat komponen antarmuka pengguna (tombol, header, sidebars, dan sebagainya).

Semua hal di atas berkontribusi pada ukuran keseluruhan kode yang harus diterima dan diproses oleh browser pengguna. Secara alami, semakin banyak kode - semakin banyak waktu yang dibutuhkan browser untuk dapat membawa halaman ke kondisi kerja.

Proses memuat halaman web mirip dengan memindahkan film di proyektor, yang menangkap tiga langkah kunci yang menjawab pertanyaan-pertanyaan berikut:

Apakah ini terjadi? (Apakah itu terjadi?).
Apa gunanya ini? (Apakah ini berguna?).
Bisakah ini digunakan? (Apakah bisa digunakan?).

Inilah cara membayangkan langkah-langkah ini, yang, pada gilirannya, dapat dibagi menjadi "bingkai" yang lebih kecil, jika kita melanjutkan analogi dengan film.

Pemuatan halaman adalah suatu proses. Baru-baru ini, fokus industri web telah bergeser ke indikator yang mencerminkan pengalaman pengguna bekerja dengan halaman web. Alih-alih memberikan semua perhatian kami pada peristiwa onload atau domContentLoaded , kami sekarang bertanya-tanya apakah pengguna dapat benar-benar bekerja dengan halaman tersebut. Jika dia mengklik sesuatu pada halaman, apakah akan ada reaksi langsung?

Proses pemuatan halaman web

Pada langkah "Apakah ini terjadi?" situs mungkin mulai mentransfer beberapa data ke browser. Di sini Anda dapat mengajukan pertanyaan tentang apakah akses browser pengguna ke server telah diperbaiki (misalnya, dengan mengklik tautan tertentu), dan apakah server sudah mulai menghasilkan respons.
Pada langkah "Apa gunanya ini?" situs ini menampilkan beberapa teks atau konten lain yang memungkinkan pengguna, pertama, mempelajari sesuatu yang bermanfaat, dan kedua, dapat menarik minatnya.
Pada langkah "Bisakah ini digunakan?" pengguna dapat memulai interaksi penuh dengan situs, yang dapat mengarah pada peristiwa tertentu.

Halaman interaktif dan masalahnya

Di atas, kami menyebutkan indikator seperti waktu untuk interaktivitas (Waktu untuk interaktif, TTI). Mari kita bicarakan lebih detail. Di bawah ini, dalam gambar animasi yang disiapkan oleh Kevin Schaaf, Anda dapat melihat bagaimana halaman tersebut, tidak semua materi yang telah diunduh dan diproses, membuat pengguna berpikir bahwa ia dapat melakukan beberapa tindakan, tetapi, pada kenyataannya, karena fakta bahwa JS yang sesuai kode belum sepenuhnya diproses, tindakan ini tidak dapat dilakukan.

Pengguna kecewa oleh halaman yang membutuhkan waktu terlalu lama untuk bersiap-siap

Agar halaman menjadi interaktif, ia harus dapat dengan cepat menanggapi interaksi pengguna. Sejumlah kecil kode JS yang memberi daya pada halaman membantu mengurangi waktu yang dibutuhkan untuk menyiapkan halaman untuk bekerja.

Jika pengguna mengklik tautan atau menggulir halaman, ia perlu melihat bahwa, sebagai tanggapan atas tindakannya, sesuatu terjadi. Jika halaman tidak merespons dampak pengguna, mereka tidak menyukainya.

Berikut ini adalah laporan yang dihasilkan dalam lingkungan pengujian menggunakan alat Mercusuar, yang berisi serangkaian indikator (ada juga Waktu untuk interaktif), yang berfokus pada bagaimana pengguna memandang halaman.

Laporan Lighthouse, yang mencakup indikator yang mencerminkan persepsi pengguna tentang halaman

Sesuatu yang mirip dengan yang ditunjukkan pada gambar sebelumnya terjadi ketika rendering server digunakan dalam proyek tertentu, dan hasil dari apa yang dihasilkan pada server dan kode JS yang digunakan untuk "merevitalisasi" antarmuka pengguna ditransmisikan ke klien (misalnya, itu , dapat menghubungkan event handler dan beberapa mekanisme tambahan yang bertanggung jawab atas perilaku halaman).

Ketika browser sedang memproses kode yang menghubungkan peristiwa yang mungkin dibutuhkan oleh pengguna, kemungkinan besar semua ini akan dieksekusi di utas yang sama yang memproses input pengguna. Inilah yang disebut arus utama.

Memuat terlalu banyak kode JavaScript menggunakan utas utama (misalnya, ini terjadi ketika menggunakan <script> ) memiliki efek buruk pada waktu untuk interaktivitas. Mengunduh kode JS yang Anda rencanakan untuk dijalankan di pekerja web atau caching dengan pekerja layanan tidak memiliki dampak negatif yang kuat pada TTI.

Berikut adalah video yang menunjukkan contoh pengguna yang bekerja dengan situs yang gagal. Biasanya, pengguna dapat dengan aman memilih kotak centang atau mengklik tautan. Namun, jika Anda meniru pemblokiran utas utama, pengguna tidak akan dapat melakukan apa pun - tidak mencentang kotak, atau mengklik tautan.

Cobalah untuk meminimalkan situasi di mana utas utama mungkin diblokir. Berikut adalah bahan di mana Anda dapat menemukan detail tentang ini.

Kami melihat bagaimana tim yang bekerja dengan kami menderita JavaScript bertindak di TTI di banyak jenis situs.

JavaScript dapat menunda output elemen yang terlihat dalam mode interaktif

Situasi ini dapat menjadi masalah serius bagi banyak perusahaan. Di atas adalah beberapa contoh dari mesin pencari Google. Elemen muncul di layar, mereka tampak seolah-olah sudah mungkin untuk bekerja dengannya, tetapi jika terlalu banyak kode JS yang bertanggung jawab atas fungsinya, mereka memasuki mode operasi dengan beberapa penundaan. Ini mungkin tidak menarik bagi pengguna. Idealnya, segala sesuatu yang dapat berinteraksi dengan pengguna harus beroperasi secepat mungkin.

TTI dan perangkat seluler

Berikut adalah TTI untuk news.google.com saat menggunakan koneksi internet 3G yang lambat. Di sini Anda dapat melihat data berdasarkan diagram yang dibangun ini. Pengukuran dilakukan melalui WebPageTest dan Mercusuar.

TTI untuk news.google.com

Setelah menganalisis data ini, Anda dapat melihat bahwa di antara perangkat dari kategori terendah dan tertinggi ada kesenjangan yang serius. Jadi, perangkat paling kuat dalam tes TTI adalah sekitar 7 detik. Paling sederhana - sudah 55 detik.

Di sini kita memiliki pertanyaan tentang apa yang seharusnya menjadi TTI. Kami percaya bahwa Anda harus berusaha untuk membuat halaman lebih interaktif pada perangkat kelas menengah yang terhubung ke jaringan 3G yang lambat dalam waktu kurang dari 5 detik.

Perlu berjuang untuk TTI dalam 5 detik

Mungkin di sini Anda akan mengatakan bahwa semua pengguna Anda memiliki ponsel kelas atas dan terhubung ke jaringan cepat. Namun, benarkah demikian? Mungkin seseorang terhubung ke jaringan Wi-Fi "cepat" di beberapa kafe, tetapi, pada kenyataannya, hanya karakteristik kecepatan koneksi 2G atau 3G yang tersedia baginya. Menilai kemampuan pengguna, seseorang tidak dapat mengabaikan berbagai perangkat dan metode mengakses jaringan yang mereka gunakan.

Dampak perampingan kode JS pada TTI

Berikut adalah beberapa contoh bagaimana mengurangi ukuran kode halaman JS mempengaruhi TTI.

Proyek Pinterest mengurangi bundel JS dari 2,5 MB menjadi kurang dari 200 KB. Waktu untuk interaktivitas berkurang dari 23 detik menjadi 5,6 detik. Pendapatan perusahaan tumbuh sebesar 44%, jumlah langganan meningkat sebesar 753%, jumlah pengguna mingguan aktif versi mobile dari situs tumbuh sebesar 103%.
AutoTrader mengurangi bundel JS sebesar 56%, menghasilkan pengurangan TTI sekitar 50%.
Sumber daya Nikkei.com memangkas ukuran bundel JS sebesar 43%, yang memungkinkan TTI meningkat 14 detik.

Hasil ini menunjukkan bahwa situs harus dirancang untuk lingkungan seluler yang fleksibel, dan pada saat yang sama mencoba untuk memastikan bahwa mereka tidak terikat dengan volume besar kode JavaScript.

Merancang situs didasarkan pada lingkungan seluler yang fleksibel

TTI memiliki banyak hal yang harus dilakukan. Misalnya, penggunaan perangkat seluler untuk melihat situs web yang kemampuan jaringannya dibatasi oleh rencana tarif tertentu dapat memengaruhi indikator ini, TTI dapat dipengaruhi oleh kenyataan bahwa pengguna bekerja melalui publik, bukan titik akses Wi-Fi yang cepat, atau fakta bahwa pengguna seluler bergerak konstan, kehilangan jaringan secara berkala.

Ketika seseorang bekerja dengan situs Anda dalam situasi yang serupa dengan yang baru saja kami jelaskan, dan pada saat yang sama, untuk memastikan sumber daya berfungsi, perlu untuk mengunduh dan memproses sejumlah besar kode JS, bagi pengguna, sesi interaksi dengan situs tersebut mungkin berakhir kosong layar. Atau, jika situs masih menampilkan setidaknya sesuatu di layar, mungkin perlu waktu sangat lama untuk menunggu sebelum Anda dapat bekerja dengannya. Masalah seperti itu, idealnya, dapat dikurangi dengan hanya mengurangi ukuran kode JS yang diperlukan agar situs dapat berfungsi.

Mengapa JavaScript sangat mahal?

Untuk memahami mengapa menyiapkan kode JavaScript untuk halaman dapat membuat beban besar pada sistem, mari kita bicara tentang apa yang terjadi ketika server mengirim data ke browser.

Jadi, semuanya dimulai dengan fakta bahwa pengguna memasukkan URL situs yang ia inginkan untuk masuk ke bilah alamat browser.

Semuanya dimulai dengan memasukkan URL di bilah alamat browser

Permintaan tersebut kemudian dikirim ke server, yang mengembalikan markup HTML ke browser. Browser mem-parsing markup ini dan menemukan sumber daya yang diperlukan untuk membentuk halaman: CSS, JavaScript, gambar. Maka browser perlu meminta semua ini dari server dan memprosesnya.
Dalam skenario ini, semuanya terjadi, misalnya, ketika bekerja dengan Google Chrome.

Kesulitan dalam seluruh proses ini adalah bahwa JavaScript, pada akhirnya, ternyata menjadi penghambat seluruh sistem. Idealnya, kami ingin browser untuk dengan cepat menampilkan representasi grafis dari halaman, setelah itu dimungkinkan untuk berinteraksi dengannya. Tetapi, jika JavaScript adalah hambatan, maka, setelah menampilkan sesuatu di layar, pengguna dipaksa untuk memeriksa tanpa daya apa yang tidak bisa ia kerjakan.

Tujuan kami adalah untuk memastikan bahwa JavaScript tidak lagi menjadi hambatan dalam skenario modern interaksi pengguna dengan sumber daya web.

Bagaimana cara mempercepat kerja dengan JavaScript?

Tugas akselerasi JavaScript dapat dipecah menjadi beberapa subtugas. Waktu yang dihabiskan untuk segala sesuatu yang berhubungan dengan JS adalah jumlah dari beban, parsing, kompilasi dan mengeksekusi kode.

Kecepatan JavaScript terdiri dari kecepatan memuat, mem-parsing, menyusun, dan mengeksekusi kode

Semua ini berarti bahwa kita memerlukan kecepatan baik dalam transfer kode dan dalam pemrosesan.
Jika terlalu banyak waktu dihabiskan untuk mem-parsing dan menyusun skrip di mesin JS, ini mempengaruhi seberapa cepat pengguna dapat berinteraksi dengan halaman.

Pertimbangkan beberapa data pada proses di atas. Berikut ini lebih lanjut tentang bagaimana V8 , mesin JavaScript yang digunakan di Chrome, menghabiskan waktu memproses halaman yang berisi skrip.

Mengurai dan mengkompilasi langkah mengambil 10-30% dari waktu di V8 saat memuat halaman

Fragmen yang mewakili waktu yang diperlukan untuk menguraikan kode situs populer disorot dalam warna oranye. Kuning menunjukkan waktu kompilasi. Bersama-sama, kedua tahap ini memakan waktu sekitar 30% dari total waktu yang diperlukan untuk memproses kode JS halaman. 30% adalah angka serius.

Di Chrome 66, V8 mengkompilasi kode di utas latar belakang, yang dapat menghemat hingga 20% waktu kompilasi. Namun, parsing dan kompilasi masih merupakan operasi yang sangat mahal, jadi Anda jarang melihat skrip besar yang mulai dijalankan dalam waktu kurang dari 50 ms. setelah memuat, meskipun dikompilasi di utas latar belakang.

Apa bedanya JavaScript dengan sumber daya lainnya?

Harus diingat bahwa waktu yang diperlukan, misalnya, untuk memproses skrip dengan ukuran 200 Kb, dan untuk memproses gambar dengan ukuran yang sama, bervariasi secara signifikan. Dalam contoh ini, jumlah data yang dikirim melalui jaringan mungkin sama, waktu untuk transfer mereka juga. Ini tidak bisa dikatakan tentang biaya sumber daya yang dibutuhkan untuk mengubah data menjadi sesuatu yang dapat Anda kerjakan.

Kode JavaScript 200 KB dan file JPEG dengan ukuran yang sama adalah dua hal yang berbeda.

Gambar JPEG perlu diterjemahkan, diraster, dan ditampilkan. Dan bundel JS diperlukan, jika kita anggap simpel, muat, parse, kompilasi, eksekusi. Bahkan, mesin harus menyelesaikan masalah lain dalam proses pemrosesan JS-code. Secara umum, harus diingat bahwa lebih banyak sumber daya sistem dihabiskan untuk memproses kode JavaScript, yang ukurannya, dalam byte, sebanding dengan ukuran bahan lainnya.

Salah satu alasan yang baru-baru ini menarik begitu banyak perhatian pada masalah kecepatan pemrosesan kode JavaScript oleh browser adalah penyebaran teknologi seluler yang luar biasa.

Keragaman web dan perangkat seluler

Ada berbagai macam perangkat di dunia web seluler. Jika Anda mencoba, secara sederhana, untuk mengklasifikasikannya berdasarkan biaya, maka ini adalah ponsel entry-level, yang terletak di wilayah $ 30, perangkat kelas menengah, yang harganya tidak melebihi $ 200, dan perangkat kelas atas, yang harganya sekitar $ 1000.

Berbagai perangkat seluler

Jika keadaan berubah dengan baik, maka situs harus bekerja pada perangkat tingkat menengah dan lebih tinggi. Namun, pada kenyataannya, tidak semua pengguna memiliki perangkat tersebut.

Jadi, sebagian besar pengguna dapat bekerja di Internet dari perangkat tingkat awal dan menengah. Selain itu, bahkan jika kita membatasi diri pada dua level ini, jangkauan kemampuan perangkat yang termasuk di dalamnya bisa sangat besar. Sebagai contoh, prosesor di beberapa dari mereka akan berjalan dengan kecepatan penuh, dan di beberapa dari mereka frekuensi mereka dapat diturunkan untuk menghemat energi atau untuk mencegah perangkat terlalu panas.

Prosesor yang sebanding mungkin memiliki ukuran cache yang berbeda. Pada akhirnya, perangkat dapat menggunakan prosesor yang sama sekali berbeda, belum lagi komponen sistem lainnya. Akibatnya, waktu yang diperlukan untuk memproses sumber daya, seperti JavaScript, akan sangat tergantung pada karakteristik perangkat yang digunakan untuk melihat situs. Selain itu, ponsel entry-level digunakan di seluruh dunia, bahkan di Amerika Serikat .

Berikut adalah hasil studi tentang smartphone Android yang saat ini digunakan oleh newzoo . Seperti yang Anda lihat, OS Android diinstal pada 75,9% ponsel yang digunakan, sementara pada 2018 diperkirakan 300 juta perangkat lain akan ditambahkan ke dalamnya. Banyak dari perangkat baru ini akan ramah anggaran.

Smartphone Android pada tahun 2018

Mari kita lihat berapa lama untuk mengurai dan mengkompilasi JavaScript pada berbagai perangkat modern. Berikut ini data mentahnya.

Waktu yang diperlukan untuk pemrosesan (parsing dan kompilasi) 1 Mb kode JS yang tidak terkompresi (misalnya, bisa sekitar 200 Kb kode yang diperkecil yang dikompres dengan gzip). Pengukuran dilakukan secara manual pada perangkat nyata.

Di bagian atas diagram adalah perangkat kelas atas, seperti iPhone 8, yang memproses skrip relatif cepat. Jika Anda turun lebih rendah, maka sudah ada perangkat mid-range, seperti Moto G4, dan Alcatel 1X yang sangat sederhana. Perbedaan antara perangkat ini terlihat dengan mata telanjang.

Seiring waktu, ponsel yang menjalankan Android menjadi lebih murah, tetapi tidak lebih cepat . Biasanya, ponsel murah menggunakan prosesor yang lemah dengan cache L2 / L3 kecil. Akibatnya, jika Anda fokus pada perangkat tingkat atas, Anda dapat sepenuhnya mengabaikan kebutuhan pengguna rata-rata yang tidak memiliki perangkat seperti itu.

Mari kita kembali misalnya dengan situs nyata, yang sudah kami sentuh. Pengukuran dilakukan dengan menggunakan WebPageTest, di sini adalah sumber data.

Waktu yang diperlukan untuk memroses kode JS cnn.com untuk berbagai perangkat

Pada iPhone 8 (menggunakan chip A11 ), pemrosesan membutuhkan waktu 9 detik lebih cepat dari pada ponsel kelas menengah. Kita berbicara tentang fakta bahwa pada iPhone 8 situs tersebut akan interaktif 9 detik sebelumnya.

Sekarang ketika WebPageTest mendukung Alcatel 1X (ponsel ini dijual di AS dengan harga sekitar $ 100, itu dijual pada awal penjualan), kita dapat melihat " storyboard " dari situs web cnn.com yang memuat ponsel entry-level dan mid-range. Alcatel 1X memuat situs sepenuhnya menggunakan jaringan 3G dalam 65 detik. Bahkan tidak "lambat." Ini tidak bisa diterima.

Unduh cnn.com dengan Alcatel 1X, Moto G gen 1, Moto G4

Studi ini menunjukkan bahwa kita mungkin harus berhenti berpikir bahwa semua pengguna kami bekerja di jaringan cepat pada perangkat yang kuat. Oleh karena itu, aplikasi harus diuji di jaringan nyata dan di perangkat nyata. Variasi perangkat seluler yang harus dijalankan situs adalah masalah nyata.

Jangan berasumsi bahwa semua pengguna menggunakan jaringan cepat dan perangkat canggih.

Ilya Grigorik mengatakan volatilitas adalah apa yang membunuh pengalaman pengguna. Bahkan perangkat yang cepat terkadang dapat berjalan lambat. Dan jaringan yang cepat bisa lambat. Variabilitas dapat memperlambat apa saja.

Sementara variabilitas dapat membunuh pengalaman pengguna, pengembangan proyek web yang didasarkan pada bukan perangkat yang paling produktif memungkinkan Anda untuk membuat pengguna "cepat" dan "lambat" merasa nyaman. Jika tim Anda dapat menganalisis statistik dan memahami perangkat mana yang digunakan untuk bekerja dengan situs Anda, ini akan memberi Anda petunjuk tentang perangkat mana yang mungkin layak disimpan di kantor dan menggunakannya untuk menguji situs tersebut.

Situs pengujian ada di perangkat nyata yang terhubung ke jaringan nyata

Jika opsi dengan ponsel kelas menengah Anda sendiri tidak cocok untuk Anda, proyek WebPageTest menawarkan akses ke ponsel Moto G4 yang disesuaikan saat memilih konfigurasi pengujian seluler. Ada konfigurasi lain di sana.

Selain itu, pengujian harus dilakukan pada jaringan tempat pengguna biasa bekerja. Sebelumnya, saya berbicara tentang pentingnya menguji situs pada ponsel entry-level dan mid-range, dan Brian Holt membuat komentar luar biasa berikut tentang hal ini: sangat penting untuk mengetahui audiens Anda. Dia mengatakan bahwa mengetahui audiens dan mengoptimalkan kinerja aplikasi untuk kebutuhan audiens sangat penting.

Kenali audiens Anda

Perlu dicatat bahwa tidak setiap situs harus bekerja dengan baik pada perangkat entry-level yang terhubung ke jaringan 2G. , — .

, , Google Analytics → Audience → Mobile → Devices. .

Google Analytics

, . — , , , , .

JavaScript — . : , , ( gzip , Brotli , Zopfli ).

,

.

JavaScript — .

—

-, , , , .

, , JavaScript, , , , .

JavaScript-,

, JS-, , , . , — ( code splitting ).

, JS- , , , . , .

—

, , , JS-, . , .

webpack Parcel . React , Vue.js Angular .

React

React- React loadable — , API, React, .

.

 import OtherComponent from './OtherComponent'; const MyComponent = () => ( <OtherComponent/> );

 import Loadable from 'react-loadable'; const LoadableOtherComponent = Loadable({ loader: () => import('./OtherComponent'), loading: () => <div>Loading...</div>, }); const MyComponent = () => ( <LoadableOtherComponent/> );