Optimasi waktu pembuatan proyek

Di mana saya bekerja (di startup Spot.IM , yang ukurannya berkisar antara kecil dan menengah), Webpack digunakan untuk membangun berbagai proyek. Setelah 4 tahun bekerja pada produk utama kami, ketika begitu banyak orang telah berkontribusi pada kodenya sehingga tidak dapat dihitung, waktu perakitan awalnya mencapai selang waktu 90 detik, dan waktu pemasangan kembali - 14.

Ini adalah sekitar 14 detik untuk menunggu setelah setiap klik pada tombol "Simpan".

Setelah menggunakan beberapa optimasi sederhana, seperti siapa pun dapat menerapkan dalam proyek mereka, kami dapat mengurangi angka di atas menjadi 20 detik untuk perakitan dan 1 detik untuk membangun kembali proyek.



Pada artikel ini saya ingin berbicara tentang beberapa perubahan sederhana, yang membuat proyek dapat secara signifikan meningkatkan waktu perakitannya. Harap dicatat bahwa jika Anda menggunakan CreateReactApp (atau generator aplikasi modis lainnya), maka artikel ini mungkin tidak terlalu berguna untuk Anda. Tetapi jika Anda tidak menggunakan hal seperti itu, maka apa yang kami bicarakan di sini bisa sangat berguna bagi Anda.

Mengukur waktu yang dibutuhkan untuk membangun proyek

Sebelum melakukan optimasi apa pun, mari kita buat pengukuran indikator yang dengannya kita dapat menilai hasil pekerjaan. Untuk melakukan ini, gunakan paket -mengukur-webpack-plugin (SMP) paket:

const webpackConfig = require('./webpack.config') const SpeedMeasurePlugin = require('speed-measure-webpack-plugin') const smp = new SpeedMeasurePlugin({   disable: !process.env.MEASURE, }) module.exports = smp.wrap(webpackConfig) 

Kami meletakkan file konfigurasi Webpack di bungkus SMP (dengan memulai mekanisme untuk melakukan pengukuran kinerja menggunakan variabel lingkungan), dan setelah itu kami mentransfer objek konfigurasi Webpack. Setelah itu, kami memiliki laporan yang terlihat menyenangkan yang memungkinkan kami untuk mencari tahu berapa banyak waktu yang dibutuhkan untuk menyelesaikan bootloader selama pembuatan. Menggunakan SMP, kami mendapat manfaat ganda. Pertama, setelah melakukan perbaikan tertentu, kita dapat segera mengetahui bagaimana pengaruhnya terhadap waktu pembangunan proyek. Kedua, kami segera memiliki laporan lengkap tentang berapa banyak waktu yang dibutuhkan setiap bootloader (atau, lebih tepatnya, "rantai bootloader").


Laporan dihasilkan dengan pengukur kecepatan webpack-plugin

Meningkatkan waktu pembangunan awal suatu proyek

Setelah kami mulai menggunakan SMP, kami memiliki informasi tentang bagaimana waktu pembangunan proyek berubah ketika melakukan perbaikan pada proses pembangunan. Hal pertama yang kami mulai optimalkan adalah waktu pembuatan awal (yaitu, waktu yang dibutuhkan Webpack untuk membangun paket setelah diinisialisasi). Untuk mempercepat proses pembuatan awal, kami memutuskan untuk menggunakan bootloader cache-loader .

Cache-loader adalah loader yang menyimpan dan menyimpan ke disk (atau basis data) hasil kerja loader yang mengikutinya. Ini berarti bahwa lain kali Anda memulai Webpack, Anda dapat melihat peningkatan yang signifikan dalam kecepatan build, atau setidaknya Anda bisa berharap demikian.

Berikut ini sebuah contoh:

 {  rules: [    {      test: /\.jsx?$/,      use: [        'cache-loader',        'babel-loader',      ],    },    {      test: /\.scss$/,      use: [        'style-loader',        'cache-loader',        'css-loader',        'postcss-loader',        'sass-loader',      ],    },  ] } 

Menambahkan cache-loader sebelum css-loader (untuk CSS) dan sebelum babel-loader (untuk JS) memungkinkan kami untuk menghapus sekitar 75 detik dari waktu yang dihabiskan untuk pembangunan awal proyek.

Sekarang mari kita bekerja pada waktu pemasangan kembali. Kami akan mencoba meningkatkan waktu ini dengan mengubah properti devtool .

Kartu Kode Webpack

Di pengaturan Webpack, Anda dapat menemukan properti devtool , yang, menurut dokumentasi, “memungkinkan Anda memilih gaya membuat kartu kode yang digunakan untuk meningkatkan kemampuan debug. Setpoint dapat sangat memengaruhi kecepatan perakitan dan pemasangan kembali. "

Dengan kata lain, memodifikasi properti devtool mempengaruhi kartu kode mana yang akan tersedia untuk pengembang setelah membangun proyek. Dan ini, pada gilirannya, tergantung pada berapa banyak waktu yang diperlukan untuk membuat kartu kode seperti itu.

Eksperimen dengan properti ini adalah sesuatu dari bidang yang secara permanen dapat mengubah kehidupan seorang programmer. Ini memiliki dampak besar pada kecepatan membangun proyek. Yaitu, kami mengubah nilai devtool dari source-map (mungkin ini adalah mode paling lambat) menjadi eval-source-map dan mampu mengurangi waktu pemasangan kembali proyek dari 14 menjadi 3,5 detik:

 {  devtool: process.env.NODE_ENV === 'development'    ? 'eval-source-map'    : 'source-map' } 

Properti devtool mampu menerima 12 varian nilai. CreateReactApp, misalnya, menggunakan peta -modul-sumber-murah . Karenanya, jika Anda akan mengonfigurasi properti ini, bereksperimen dan temukan nilai yang terbaik untuk Anda.

Perlu dicatat bahwa ketika menggunakan metode cepat untuk membuat kartu kode, kualitas kartu yang dihasilkan memburuk. Kerusakan ini bisa dirasakan dengan memulai debugging. Untungnya, peramban modern mengikuti TC39. Akibatnya (setidaknya selama pengembangan) tidak ada kebutuhan nyata untuk transpilasi sejumlah besar kode. Jika Anda mengkonfigurasi Babel sehingga alat ini mengangkut JavaScript ke tingkat yang dipahami oleh versi browser terbaru (seperti yang dilakukan dalam CRA ), maka dengan debugging kode, semuanya akan baik-baik saja, karena peta kode tidak akan jauh berbeda dari kode itu sendiri.

Inilah yang akan terlihat seperti babel.config.js jika Anda memutuskan untuk mengubah kode ke keadaan yang jelas ke versi terbaru dari berbagai browser:

 module.exports = {  presets: [    [      '@babel/preset-env',      {        targets: [          'last 1 chrome version',          'last 1 safari version',          'last 1 firefox version',        ].join(', '),      },    ],  ],  // ... } 

Itu saja. Tiga langkah sederhana, dan waktu pembangunan proyek kami sangat berkurang.

Saya ingin mencatat bahwa seseorang yang mulai memecahkan masalah yang sama mungkin memiliki keinginan untuk melihat dokumentasi Webpack terlebih dahulu dan membacanya dengan benar. Namun, ini bukan satu-satunya sumber pengetahuan.

Saya menemukan pendekatan lain untuk menemukan informasi berharga tentang membangun proyek. Pendekatan ini telah terbukti dalam praktiknya. Ini terdiri dalam menganalisis file webpack.config dari proyek open source yang ada. Secara khusus, file proyek CreateReactApp . Dengan seksama membaca file ini, Anda dapat menemukan banyak hal berguna.

Ringkasan

Pembaca yang penuh perhatian dapat memperhatikan bahwa pada awalnya itu adalah pertanyaan untuk mengurangi waktu reassembly menjadi 1 detik. Dan nilai terbaik dari indikator ini yang disebutkan dalam teks adalah 3,5 detik. Jelas, ada yang dihilangkan ketika menggambarkan kemajuan optimisasi proses perakitan. Begitulah. Dimungkinkan untuk meningkatkan waktu pemasangan kembali proyek menjadi 1 detik dengan memenangkan 2,5 detik lagi berkat pengoptimalan yang halus, yang sangat bergantung pada fitur proyek tertentu, yaitu Spot.IM. Karenanya, deskripsi perbaikan ini tidak disediakan di sini.

Pembaca yang budiman! Apakah Anda mengoptimalkan waktu pembuatan proyek Anda?