Hari baik untuk semua Hari ini saya ingin berbicara dengan Anda tentang pengoptimalan. Apa itu, mengapa itu diperlukan, dan yang paling penting, bagaimana memastikan bahwa itu tidak menyakitkan saat itu.
Pertama-tama, kita akan mengerti apa itu optimasi secara umum, dan apa itu optimasi di JS. Jadi, optimasi adalah peningkatan sesuatu sesuai dengan karakteristik kuantitatif. JS mengidentifikasi empat karakteristik kuantitatif untuk dirinya sendiri:
Jumlah kode - secara umum diterima bahwa semakin sedikit baris kode yang ditulis, semakin produktif dan lebih baik. Pendapat saya berbeda secara mendasar, karena dengan menulis satu baris kode Anda dapat membuat kebocoran memori atau siklus abadi sehingga browser mati.
Kecepatan (kinerja) adalah kompleksitas komputasi yang disebut, yaitu, jumlah tindakan yang perlu dilakukan parser untuk menjalankan instruksi.
Kecepatan build - bukan rahasia lagi bahwa sekarang hampir tidak ada proyek yang dapat dilakukan tanpa pembangun seperti Webpack atau Gulp, oleh karena itu karakteristik ini menampilkan kebenaran pengaturan pembangun proyek. Percayalah, ketika server sedikit lebih pintar dari penggiling kopi, itu menjadi penting.
Penggunaan kembali kode - karakteristik ini menunjukkan seberapa baik arsitektur untuk menggunakan kembali fungsi, komponen, modul dibangun.
Pertimbangkan masing-masing kategori secara lebih rinci, kami akan menganalisis karakteristik apa yang dicakupnya dan bergantung pada apa.
Volume Kode:
- Dubbing. Berapa banyak kode dari jenis yang sama ditulis di tempat yang berbeda;
- Komentar Komentar dalam kode itu baik, tetapi saya telah menemukan proyek di mana ada lebih banyak komentar daripada kode;
- Kurangnya unifikasi. Contoh yang baik dari masalah seperti itu adalah fungsi yang serupa, yang memiliki nuansa tergantung pada beberapa properti.
- Kehadiran kode mati. Cukup sering dalam proyek ada fungsi debugging atau fungsi yang tidak digunakan sama sekali.
Kinerja:
- Menggunakan mekanisme caching browser;
- Optimasi kode berdasarkan pada lingkungan di mana ia akan dieksekusi;
- Adanya kebocoran memori;
- Menggunakan pekerja web;
- Menggunakan referensi ke elemen pohon DOM;
- Penggunaan variabel global;
- Kehadiran panggilan rekursif;
- Penyederhanaan perhitungan matematis.
Membangun kecepatan:
- Jumlah ketergantungan eksternal;
- Konversi kode. Ini mengacu pada jumlah potongan dan ukurannya, konversi css, perekatan file, pengoptimalan grafik, dan banyak lagi.
Penggunaan Kembali Kode:
- Jumlah komponen;
- Pengulangan komponen
- Fleksibilitas dan penyesuaian.
Seperti yang dikatakan dalam artikel sebelumnya, untuk mengubah sesuatu, Anda perlu menentukan titik awal dan mencari tahu seberapa buruk semuanya. Di mana harus memulai proses yang sangat produktif? Mulailah dengan hal yang paling sederhana: percepat perakitan dan memotong waktu kelebihan dari proyek. Anda bertanya mengapa layak memulai dengan ini? Karena kenyataan bahwa mereka saling bergantung. Mengurangi jumlah kode akan meningkatkan kecepatan membangun, dan, akibatnya, meningkatkan produktivitas Anda.
Optimalisasi waktu pembuatan tidak dapat dihindari memperkenalkan kita pada konsep “Dingin” - ini adalah proses ketika proyek dimulai dari awal dan sampai pada titik di mana semua ketergantungan dipengaruhi dan kode sepenuhnya dikompilasi ulang. Jangan bingung dengan Rebild - ini adalah membangun kembali kode klien tanpa menarik dependensi eksternal dan perada lainnya.
Untuk meningkatkan kecepatan build akan membantu:
- Menggunakan perakit modern. Teknologi tidak tinggal diam, dan jika Anda memiliki webpack pertama, maka ketika Anda pindah ke keempat Anda akan melihat peningkatan yang menyenangkan sudah tidak melakukan apa-apa;
- Menyingkirkan semua kecanduan yang mati. Dari waktu ke waktu, pengembang, berusaha menemukan kebenaran di dasar kaleng asam sulfat, lupa untuk membersihkan setelah eksperimen mereka sendiri. Kolega saya pernah bertanya: "Apakah dependensi yang ditulis dalam package.json, tetapi tidak diimpor di mana pun dalam kode, masuk ke dalam paket bundel? " Ya, mereka tidak akan dimasukkan dalam majelis itu sendiri, tetapi paket itu akan dikempiskan. Pertanyaannya adalah, mengapa?
- Bagilah rakitan menjadi beberapa profil tergantung pada kebutuhan Anda. Minimal dua: prod dan dev. Contoh kasus: kekaburan kode. Pada prod, ini wajib, karena lebih sedikit berat = pemuatan lebih cepat, tetapi pada kebingungan dev hanya mengganggu dan menghabiskan waktu build pada manipulasi yang tidak perlu;
- Paralelisasi langkah perakitan individu;
- Menggunakan klien npm yang dapat melakukan cache.
Mempercepat pembangunan kembali dan bangunan "dingin" akan membutuhkan memotong komentar yang tidak perlu dan potongan kode. Namun, apa yang harus dilakukan jika Anda memiliki proyek besar dan tidak mungkin untuk memeriksanya sendiri? Dalam kasus seperti itu, penganalisa kode datang untuk menyelamatkan.
Secara pribadi, saya secara berkala menggunakan SonarQube , bukan yang terbaik, tetapi fleksibel. Dapat diajarkan fitur-fitur proyek, jika ada. Dari waktu ke waktu ia melakukan hal-hal yang setidaknya berdiri, setidaknya jatuh, tetapi, seperti instrumen apa pun, ia harus dapat menggunakannya dan tidak lupa untuk bersikap skeptis tentang pernyataannya. Terlepas dari semua kelemahannya, ia berupaya keras untuk mencari kode mati, komentar, keberadaan copy-paste dan hal-hal kecil, seperti kurangnya perbandingan yang ketat.
Perbedaan utama antara SonarQube dan ESlint / TSLint / Prettier dan lainnya seperti mereka adalah bahwa ia memeriksa kualitas kode, mengisolasi dubbing, kompleksitas perhitungan, dan juga memberikan rekomendasi pada perubahan yang diperlukan. Analog cukup memeriksa kode untuk kesalahan, sintaksis dan format.
Dalam praktiknya, saya menemukan codacy , layanan yang bagus dengan berlangganan gratis dan berbayar. Ini akan berguna jika Anda perlu memeriksa sesuatu di samping, tanpa harus menggunakan 'pemanen' ini di rumah. Ini memiliki antarmuka yang intuitif, indikasi rinci tentang apa yang salah dengan kode dan banyak lagi.
Pada artikel ini saya tidak akan menyentuh pada topik pengaturan membangun, potongan dan sisanya, karena semuanya tergantung pada kebutuhan proyek dan pembangun yang diinstal. Mungkin saya akan membicarakan ini di artikel lain.
Manipulasi yang dilakukan membantu mempercepat perakitan - untung, tapi bagaimana selanjutnya? Karena analis dapat menemukan dubbing kode, akan berguna untuk menempatkannya dalam modul atau komponen terpisah, sehingga meningkatkan penggunaan kembali kode.
Hanya ada satu bagian yang tidak kami sentuh - kecepatan kode itu sendiri. Mekanisme untuk membawa produktivitasnya disebut oleh semua kata yang dibenci refactoring. Mari kita lihat lebih dekat apa yang layak dilakukan saat refactoring dan apa yang tidak.
Aturan hidup: jika berfungsi, jangan menyentuhnya, seharusnya tidak membimbing Anda dalam proses ini. Aturan pertama di IT: lakukan backup, maka Anda akan mengucapkan terima kasih pada diri sendiri. Di depan, sebelum melakukan perubahan, lakukan tes agar tidak kehilangan fungsionalitas di masa mendatang. Lalu tanyakan pada diri Anda - bagaimana menentukan waktu muat dan kebocoran memori?
Ini akan membantu DevTool. Itu tidak hanya akan menunjukkan kebocoran memori, memberi tahu Anda waktu buka halaman, drawdown pada animasi, dan jika Anda beruntung, itu akan melakukan audit untuk Anda, tetapi ini tidak akurat. DevTools juga memiliki fitur yang bagus, seperti membatasi kecepatan unduh, yang memungkinkan Anda untuk memprediksi kecepatan pemuatan halaman dengan Internet yang buruk.
Kami dapat mengidentifikasi masalah, sekarang mari kita selesaikan!
Untuk memulai, kami akan mengurangi waktu pemuatan menggunakan mekanisme caching browser. Browser dapat melakukan cache semua dan selanjutnya menyediakan data dari cache kepada pengguna. Penyimpanan lokal dan penyimpanan sesi tidak ada yang mengambil dari Anda. Mereka memungkinkan Anda untuk menyimpan beberapa data yang membantu mempercepat SPA selama unduhan berikutnya dan mengurangi permintaan server yang tidak perlu.
Diperlukan untuk mengoptimalkan kode berdasarkan lingkungan di mana ia akan dieksekusi, tetapi seperti yang ditunjukkan oleh praktik, ia memakan banyak waktu dan upaya, sementara tidak membawa peningkatan yang nyata. Saya mengusulkan untuk mempertimbangkan ini hanya sebagai rekomendasi.
Secara alami disarankan untuk menghilangkan semua kebocoran memori. Saya tidak akan fokus pada ini, saya pikir semua orang tahu bagaimana menghilangkannya, dan jika tidak, maka google saja.
Asisten kami yang lain adalah pekerja web. Pekerja web adalah utas yang dimiliki browser yang dapat digunakan untuk mengeksekusi kode JS tanpa memblokir loop acara. Pekerja web dapat melakukan tugas yang berat dan panjang secara komputasi tanpa memblokir aliran antarmuka pengguna. Bahkan, ketika digunakan, perhitungan dilakukan secara paralel. Di depan kami adalah multithreading yang nyata. Ada tiga jenis pekerja web:
- Pekerja yang Berdedikasi - Contoh pekerja web khusus dibuat oleh proses utama. Hanya proses itu sendiri yang dapat bertukar data dengan mereka.
- Pekerja Bersama (Pekerja Bersama) - Akses ke pekerja bersama dapat diperoleh dengan proses apa pun yang memiliki sumber yang sama dengan pekerja (misalnya, tab browser yang berbeda, iframe, dan pekerja bersama lainnya).
- Pekerja Layanan adalah pekerja yang didorong oleh peristiwa yang terdaftar menggunakan sumber dan jalur mereka. Mereka dapat mengontrol halaman web yang terhubung dengan mereka dengan mencegat dan memodifikasi perintah navigasi dan permintaan sumber daya, dan menyimpan data yang bisa dikontrol dengan sangat tepat. Semua ini memberi kami alat yang sangat baik untuk mengontrol perilaku aplikasi dalam situasi tertentu (misalnya, ketika jaringan tidak tersedia).
Cara bekerja dengan mereka dapat dengan mudah ditemukan di Internet.
Kami semacam mencari tahu pendekatan dan proubles pihak ketiga, sekarang saya mengusulkan untuk berbicara tentang kode itu sendiri.
Pertama-tama, cobalah untuk menyingkirkan panggilan langsung ke pohon DOM, karena ini adalah operasi yang memakan waktu. Mari kita bayangkan bahwa Anda terus-menerus memanipulasi semacam objek dalam kode Anda. Alih-alih bekerja dengan objek ini dengan referensi, Anda terus-menerus menarik pohon DOM untuk mencari elemen ini dan bekerja dengannya, dan kami menerapkan pola caching dalam kode.
Langkah kedua adalah menyingkirkan variabel global. ES6 memberi kami penemuan luar biasa dari umat manusia yang disebut variabel blok (dalam istilah sederhana, deklarasi variabel dari var ke let dan const ).
Dan akhirnya, yang paling enak. Di sini, sayangnya, tidak semua orang memiliki pengalaman yang cukup untuk memahami nuansa tersebut. Saya menentang penggunaan fungsi rekursif. Ya, mereka mengurangi jumlah kode tertulis, tetapi itu tidak dapat dilakukan tanpa tangkapan: seringkali fungsi rekursif seperti itu tidak memiliki kondisi keluar, mereka hanya dilupakan. Seperti dalam pepatah "Anda dapat mematahkan jari dengan palu, tetapi ini bukan masalah palu, tetapi pemilik jari" atau lelucon tentang kucing: fungsi rekursif tidak buruk, Anda harus dapat memasaknya.
Terlepas dari semua kekuatan aplikasi front-end modern, Anda tidak boleh melupakan dasar-dasarnya. Contoh yang jelas tentang pemborosan dan irasionalitas adalah penambahan elemen baru ke awal array. Siapa tahu, dia mengerti, dan dia yang tidak - sekarang saya akan memberi tahu. Semua orang tahu bahwa elemen array memiliki indeksnya sendiri, dan ketika kita akan menambahkan elemen array baru ke permulaannya, urutan tindakannya adalah sebagai berikut:
- Definisi panjang array
- Penomoran masing-masing elemen.
- Pergeseran setiap elemen array
- Masukkan item baru ke dalam array
- Mengindeks ulang elemen array.
Ringkasan:
Saatnya untuk mengakhiri, dan bagi mereka yang merasa nyaman dengan format memo, simpan daftar langkah-langkah berkat yang dapat Anda pahami pada tahap optimasi apa Anda sekarang dan apa yang harus dilakukan selanjutnya:
- Kami menentukan berapa banyak semuanya baik / buruk, hapus metrik.
- Kami memotong semua yang tidak perlu: dependensi yang tidak digunakan, kode mati, komentar yang tidak perlu.
- Kami menyesuaikan dan mempercepat waktu perakitan, mengonfigurasi profil yang berbeda untuk kontur.
- Kami menganalisis kode dan memutuskan bagian mana yang akan kami optimalkan dan tulis ulang.
- Kami sedang menulis tes untuk mencegah hilangnya fungsionalitas.
- Kami mulai refactoring, menyingkirkan variabel global, kebocoran memori, kode dubbing dan sampah lainnya, dan jangan lupa tentang caching.
- Kami menyederhanakan kerumitan perhitungan dan mengambil segala yang mungkin untuk pekerja web.
Semuanya tidak serumit kelihatannya pada pandangan pertama. Urutan Anda mungkin akan berbeda dari urutan saya, jika hanya karena Anda memiliki kepala sendiri di pundak Anda. Anda akan menambahkan item baru atau, sebaliknya, mengurangi jumlahnya, tetapi dasar dari daftar akan serupa. Saya secara khusus menggambarkan pembagian sehingga kegiatan ini dapat berjalan paralel dengan pekerjaan utama. Seringkali pelanggan tidak siap untuk membayar pengerjaan ulang, setuju?
Dan akhirnya.
Saya percaya pada Anda, dan bahwa Anda akan berhasil. Apakah Anda pikir saya naif? Saya kira Anda akan terkejut, tetapi karena Anda menemukan artikel ini, bacalah sampai akhir, itu berarti (saya punya kabar baik untuk Anda), Anda memiliki otak, dan Anda berusaha mengembangkannya. Saya berharap Anda sukses dalam usaha yang sulit seperti mengoptimalkan bagian depan!