Menemukan cara terbaik untuk mengatur materi proyek web bisa menjadi tugas yang menakutkan. Ada banyak skenario berbeda untuk pengguna yang bekerja dengan proyek, banyak teknologi dan faktor lain yang perlu diperhitungkan.
Penulis materi, terjemahan yang kami terbitkan hari ini, mengatakan bahwa ia ingin memberi tahu semua yang perlu Anda ketahui di sini untuk persiapan materi proyek web yang kompeten untuk pekerjaan. Pertama, tentang bagaimana memilih strategi untuk memisahkan file situs yang paling cocok untuk proyek tertentu dan bagi penggunanya. Kedua, cara menerapkan strategi yang dipilih akan dipertimbangkan.
Informasi umum
Menurut
Glosarium Webpack , ada dua strategi berbagi file. Ini adalah pemecahan berkas dan pemecahan kode. Istilah-istilah ini tampaknya digunakan secara bergantian, tetapi tidak.
- Memisahkan bundel adalah teknik untuk memecah bundel besar menjadi beberapa bagian, yaitu file yang lebih kecil. File seperti itu, dalam hal apa pun, seperti ketika bekerja dengan satu bundel, akan diunduh oleh semua pengguna situs. Kekuatan dari teknik ini adalah untuk meningkatkan penggunaan mekanisme caching berbasis browser.
- Pemisahan kode adalah pendekatan yang melibatkan pemuatan kode secara dinamis saat diperlukan. Ini mengarah pada fakta bahwa pengguna hanya mengunduh kode yang ia perlukan untuk bekerja dengan bagian tertentu dari situs pada titik waktu tertentu.
Pemecahan kode tampaknya jauh lebih menarik daripada pemecahan kode. Dan, pada kenyataannya, ada perasaan bahwa dalam banyak artikel tentang topik kita, fokus utamanya adalah pada pemisahan kode, teknik ini dianggap sebagai satu-satunya cara yang bermanfaat untuk mengoptimalkan materi situs.
Namun, saya ingin mengatakan bahwa bagi banyak situs itu adalah strategi pertama yang jauh lebih berharga - pemisahan bundel. Dan, mungkin, secara harfiah semua proyek web dapat menang dari implementasinya.
Mari kita bicarakan ini secara lebih rinci.
Pemisahan bundel
Teknik untuk memisahkan bundel didasarkan pada ide yang sangat sederhana. Jika Anda memiliki satu file besar dan Anda mengubah satu baris kode di dalamnya, pengguna biasa harus mengunduh seluruh file saat berikutnya dia mengunjungi situs. Namun, jika Anda membagi file ini menjadi dua file, maka pengguna yang sama hanya perlu mengunduh satu yang telah diubah, dan file kedua akan diambil dari cache browser.
Perlu dicatat bahwa karena pengoptimalan materi situs dengan memisahkan bundel terkait dengan caching, pengguna yang mengunjungi situs untuk pertama kali harus mengunduh semua materi, sehingga tidak ada bedanya bagi mereka apakah materi ini akan disajikan sebagai satu file atau beberapa .
Menurut saya terlalu banyak bicara tentang kinerja proyek web didedikasikan untuk pengguna yang mengunjungi situs untuk pertama kalinya. Mungkin demikian, sebagian, karena pentingnya kesan pertama bahwa proyek akan membuat pada pengguna, serta fakta bahwa jumlah data yang dikirimkan kepada pengguna ketika mereka pertama kali mengunjungi situs itu sederhana dan nyaman untuk diukur.
Ketika datang ke pengunjung reguler, mungkin sulit untuk mengukur dampak teknik pengoptimalan materi yang diterapkan pada mereka. Tetapi kita harus tahu tentang konsekuensi dari optimasi tersebut.
Untuk menganalisis hal-hal ini, Anda memerlukan sesuatu seperti spreadsheet. Anda juga perlu membuat daftar kondisi yang ketat di mana kami dapat menguji setiap strategi caching yang dipelajari.
Berikut ini adalah skrip yang sesuai dengan deskripsi umum yang diberikan pada paragraf sebelumnya:
- Alice mengunjungi situs kami seminggu sekali selama 10 minggu.
- Kami memperbarui situs seminggu sekali.
- Setiap minggu, kami memperbarui halaman daftar produk.
- Selain itu, kami memiliki halaman dengan detail produk, tetapi kami belum mengerjakannya.
- Pada minggu kelima, kami menambahkan paket npm baru ke materi proyek.
- Pada minggu kedelapan, kami memperbarui salah satu paket npm yang sudah digunakan dalam proyek.
Ada orang (seperti saya) yang akan mencoba membuat skenario sedemikian realistis mungkin. Tetapi Anda tidak perlu melakukan itu. Skenario nyata di sini tidak terlalu penting. Mengapa demikian - kita akan segera tahu.
▍ Kondisi awal
Misalkan ukuran total paket JavaScript kami adalah 400 Kb dan kami, dalam kondisi saat ini, mentransfer semua ini kepada pengguna sebagai file
main.js tunggal. Kami memiliki konfigurasi Webpack, yang, secara umum, mirip dengan yang berikut (Saya menghapus hal-hal yang tidak relevan dengan percakapan kami):
const path = require('path'); module.exports = { entry: path.resolve(__dirname, 'src/index.js'), output: { path: path.resolve(__dirname, 'dist'), filename: '[name].[contenthash].js', }, };
Webpack memberi nama file
main.js dihasilkan ketika ada satu entri dalam konfigurasi.
Jika Anda tidak memiliki ide bagus untuk bekerja dengan cache, perlu diingat bahwa setiap kali saya menulis
main.js sini, saya sebenarnya berarti sesuatu seperti
main.xMePWxHo.js . Urutan karakter yang gila adalah hash dari isi file, apa yang disebut
contenthash dalam konfigurasi. Menggunakan pendekatan ini mengarah pada fakta bahwa, ketika mengubah kode, nama file juga berubah, yang memaksa browser untuk mengunduh file baru.
Sesuai dengan skenario di atas, ketika kami membuat beberapa perubahan pada kode situs setiap minggu, garis konten
contenthash dari paket berubah. Akibatnya, setiap minggu mengunjungi situs kami, Alice terpaksa mengunggah file baru 400 Kb.
Jika kami membuat tablet yang bagus (dengan garis hasil yang tidak berguna sejauh ini) yang berisi data volume mingguan pemuatan data per file ini, maka kami mendapatkan yang berikut.
Jumlah data yang diunggah oleh penggunaHasilnya, ternyata pengguna, dalam 10 minggu, mengunduh kode 4,12 MB. Indikator ini dapat ditingkatkan.
▍Paket paket pihak ketiga dari kode utama
Bagilah paket besar menjadi dua bagian. Kode kita sendiri akan berada di file
main.js , dan kode pihak ketiga di file
vendor.js . Sangat mudah untuk melakukan ini, konfigurasi Webpack berikut akan membantu kami dengan ini:
const path = require('path'); module.exports = { entry: path.resolve(__dirname, 'src/index.js'), output: { path: path.resolve(__dirname, 'dist'), filename: '[name].[contenthash].js', }, optimization: { splitChunks: { chunks: 'all', }, }, };
Webpack 4 mencoba membuat hidup semudah mungkin bagi pengembang, jadi dia melakukan semua yang dia bisa, dan tidak mengharuskannya untuk diberi tahu persis bagaimana memecah bundel menjadi beberapa bagian.
Jenis perilaku otomatis dari program ini mengarah pada beberapa kesenangan, seperti: "Wah, betapa menariknya Webpack ini", dan banyak pertanyaan dalam semangat: "Apa ini dilakukan dengan bundel saya?".
Bagaimanapun, menambahkan
optimization.splitChunks.chunks = 'all' ke konfigurasi konfigurasi memberitahu Webpack bahwa kita memerlukannya untuk mengambil semuanya dari
node_modules dan memasukkannya ke file
vendors~main.jsSetelah kami membuat pemisahan dasar bundel itu, Alice, yang secara teratur mengunjungi situs kami setiap minggu, akan mengunduh file
main.js sebesar 200 Kb setiap kali dia mengunjungi. Tapi dia akan mengunduh file
vendor.js hanya tiga kali. Ini akan terjadi selama kunjungan di minggu pertama, kelima dan kedelapan. Berikut adalah tabel terkait, di mana, dengan kehendak nasib, ukuran
vendor.js dan
vendor.js dalam empat minggu pertama bertepatan dan sama dengan 200 Kb.
Jumlah data yang diunggah oleh penggunaHasilnya, ternyata jumlah data yang diunduh oleh pengguna selama 10 minggu adalah 2,64 MB. Artinya, dibandingkan dengan apa yang sebelum pemisahan bundel, volumenya menurun sebesar 36%. Bukan hasil yang buruk yang dicapai dengan menambahkan beberapa baris ke file konfigurasi. By the way, sebelum membaca lebih lanjut - melakukan hal yang sama dalam proyek Anda. Dan jika Anda perlu memutakhirkan dari Webpack 3 ke 4 - lakukan dan jangan khawatir, karena prosesnya cukup sederhana dan masih gratis.
Tampaknya bagi saya bahwa peningkatan yang dipertimbangkan di sini terlihat agak abstrak, karena ini berlangsung lebih dari 10 minggu. Namun, jika kami mempertimbangkan jumlah data yang dikirim ke pengguna yang loyal, maka ini adalah pengurangan jujur dalam volume ini sebesar 36%. Ini adalah hasil yang sangat bagus, tetapi dapat ditingkatkan.
▍ Sorot paket dalam file terpisah
File
vendor.js menderita masalah yang sama dengan
main.js Terdiri dari kenyataan bahwa mengubah paket apa pun yang termasuk dalam file ini mengarah pada kebutuhan pengguna biasa untuk mengunduh kembali seluruh file.
Mengapa kita tidak membuat file terpisah untuk setiap paket npm? Tidak sulit untuk melakukan ini, jadi mari kita dekomposisi
react kita,
lodash ,
lodash ,
moment , dan sebagainya menjadi file terpisah. Konfigurasi Webpack berikut akan membantu kami dalam hal ini:
const path = require('path'); const webpack = require('webpack'); module.exports = { entry: path.resolve(__dirname, 'src/index.js'), plugins: [ new webpack.HashedModuleIdsPlugin(), // ], output: { path: path.resolve(__dirname, 'dist'), filename: '[name].[contenthash].js', }, optimization: { runtimeChunk: 'single', splitChunks: { chunks: 'all', maxInitialRequests: Infinity, minSize: 0, cacheGroups: { vendor: { test: /[\\/]node_modules[\\/]/, name(module) { // , node_modules/packageName/not/this/part.js // node_modules/packageName const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1]; // npm- , , // URL, @ return `npm.${packageName.replace('@', '')}`; }, }, }, }, }, };
Dalam
dokumentasi Anda dapat menemukan penjelasan yang sangat baik tentang konstruksi yang digunakan di sini, tapi saya masih mencurahkan waktu untuk menceritakan beberapa hal, karena saya butuh banyak waktu untuk menggunakannya dengan benar.
- Webpack memiliki instalasi standar yang cukup masuk akal, yang, pada kenyataannya, tidak begitu masuk akal. Misalnya, jumlah maksimum file output diatur ke 3, ukuran file minimum adalah 30 KB (yaitu, file yang lebih kecil akan digabung). Saya mendefinisikannya kembali.
cacheGroups adalah tempat kami menetapkan aturan tentang bagaimana Webpack harus mengelompokkan data dalam file output. Saya punya satu grup di sini, vendor , yang akan digunakan untuk modul apa saja yang diambil dari node_modules . Biasanya nama untuk file output diberikan sebagai string. Tapi saya memberi name sebagai fungsi yang akan dipanggil untuk setiap file yang diproses. Lalu saya mengambil nama paket dari jalur modul. Akibatnya, kami mendapatkan satu file untuk setiap paket. Misalnya, npm.react-dom.899sadfhj4.js .- Nama paket, sehingga mereka dapat dipublikasikan dalam npm, harus sesuai untuk digunakan dalam URL , jadi kita tidak perlu melakukan operasi
encodeURI pada nama packageName . Namun, saya mengalami masalah bahwa server .NET menolak untuk bekerja dengan file yang namanya mengandung simbol @ (nama tersebut digunakan untuk paket dengan cakupan nama tertentu, paket lingkup yang disebut paket), jadi saya, dalam korespondensi fragmen kode, saya menyingkirkan karakter tersebut.
Konfigurasi Webpack di atas bagus karena Anda dapat mengonfigurasinya sekali, lalu lupakan. Itu tidak perlu merujuk ke paket spesifik dengan nama, oleh karena itu, setelah dibuat, itu, bahkan ketika mengubah komposisi paket, tetap relevan.
Alice, pengunjung tetap kami, masih
main.js 200-kilobyte setiap minggu, dan pertama kali ia mengunjungi situs tersebut, ia dipaksa untuk mengunduh 200 KB paket npm, tetapi ia tidak harus mengunduh paket yang sama dua kali.
Di bawah ini adalah versi baru tabel dengan informasi tentang volume unduhan data mingguan. Secara kebetulan aneh, ukuran setiap file dengan paket npm adalah 20 Kb.
Jumlah data yang diunggah oleh penggunaSekarang volume data yang diunduh dalam 10 minggu adalah 2,24 Mb. Ini berarti bahwa kami telah meningkatkan tarif dasar sebesar 44%. Hasilnya sudah sangat layak, tetapi muncul pertanyaan apakah mungkin untuk mencapai hasil yang melebihi 50%. Jika ini terjadi, itu akan menjadi luar biasa.
▍ Memecah kode aplikasi menjadi beberapa bagian
Kami kembali ke file
main.js , yang harus selalu diunduh Alice yang malang.
Seperti yang saya katakan di atas, ada dua bagian terpisah di situs web kami. Yang pertama adalah daftar produk, yang kedua adalah halaman dengan informasi terperinci tentang produk. Ukuran kode, unik untuk masing-masing, adalah 25 Kb (dan 150 Kb kode digunakan di sana dan di sana).
Halaman informasi produk tidak dapat berubah, karena kami telah menyempurnakannya. Karenanya, jika kami mengekstrak kodenya ke file terpisah, file ini, sebagian besar waktu bekerja dengan situs, akan diunduh ke browser dari cache.
Selain itu, ternyata, kami memiliki file SVG built-in besar yang digunakan untuk rendering ikon, yang beratnya mencapai 25 KB dan jarang berubah.
Sesuatu harus dilakukan dengan ini.
Kami secara manual membuat beberapa titik masuk, memberi tahu Webpack bahwa diperlukan untuk membuat file terpisah untuk masing-masing entitas ini.
module.exports = { entry: { main: path.resolve(__dirname, 'src/index.js'), ProductList: path.resolve(__dirname, 'src/ProductList/ProductList.js'), ProductPage: path.resolve(__dirname, 'src/ProductPage/ProductPage.js'), Icon: path.resolve(__dirname, 'src/Icon/Icon.js'), }, output: { path: path.resolve(__dirname, 'dist'), filename: '[name].[contenthash:8].js', }, plugins: [ new webpack.HashedModuleIdsPlugin(), // ], optimization: { runtimeChunk: 'single', splitChunks: { chunks: 'all', maxInitialRequests: Infinity, minSize: 0, cacheGroups: { vendor: { test: /[\\/]node_modules[\\/]/, name(module) { // , node_modules/packageName/not/this/part.js // node_modules/packageName const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1]; // npm- , , // URL, @ return `npm.${packageName.replace('@', '')}`; }, }, }, }, }, };
Webpack yang bekerja keras, di samping itu, akan membuat file untuk apa yang umum, misalnya,
ProductList dan
ProductPage , yaitu, tidak akan ada kode duplikat.
Apa yang baru saja kami lakukan akan memungkinkan Alice menghemat lalu lintas 50 Kb hampir setiap minggu. Harap perhatikan bahwa kami mengedit file deskripsi ikon pada minggu keenam. Ini meja tradisional kami.
Jumlah data yang diunggah oleh penggunaSekarang hanya dalam sepuluh minggu, hanya 1.815 MB data telah diunduh. Ini berarti bahwa penghematan lalu lintas adalah 56% yang mengesankan. Sesuai dengan skenario teoretis kami, pengguna biasa akan selalu bekerja dengan tingkat penghematan ini.
Semua ini dilakukan karena perubahan yang dilakukan pada konfigurasi Webpack. Kami tidak mengubah kode aplikasi untuk mencapai hasil seperti itu.
Sebelumnya, saya berbicara tentang fakta bahwa skenario spesifik di mana tes semacam itu dilakukan, pada kenyataannya, tidak memainkan peran khusus. Ini dikatakan karena fakta bahwa, terlepas dari skenario yang digunakan, kesimpulan dari semua yang kita bicarakan akan sama: membelah aplikasi menjadi file kecil yang masuk akal dalam aplikasi untuk arsitekturnya memungkinkan kita untuk mengurangi volume data situs, dimuat oleh pengguna regulernya.
Segera kita akan mulai berbicara tentang pemisahan kode, tetapi pertama-tama saya ingin menjawab tiga pertanyaan yang mungkin Anda pikirkan sekarang.
▍ Pertanyaan nomor 1. Apakah kebutuhan untuk melakukan banyak permintaan tidak merusak kecepatan memuat situs?
Anda dapat memberikan jawaban singkat sederhana untuk pertanyaan ini: "Tidak, itu tidak berbahaya." Situasi serupa menghasilkan masalah di masa lalu, ketika protokol HTTP / 1.1 digunakan, dan ketika menggunakan HTTP / 2, ini tidak lagi relevan.
Meskipun, perlu dicatat bahwa dalam artikel
ini , yang diterbitkan pada 2016, dan dalam artikel Khan Academy 2015 ini, kesimpulan ditarik bahwa bahkan ketika menggunakan HTTP / 2, menggunakan terlalu banyak file memperlambat pengunduhan. Tetapi dalam kedua materi ini, "terlalu banyak" berarti "beberapa ratus." Oleh karena itu, perlu diingat bahwa jika Anda harus bekerja dengan ratusan file, pembatasan pemrosesan data paralel dapat memengaruhi kecepatan unduhan mereka.
Jika Anda tertarik, dukungan HTTP / 2 tersedia di IE 11 pada Windows 10. Selain itu, saya melakukan studi komprehensif di antara mereka yang menggunakan sistem yang lebih lama. Mereka dengan suara bulat menyatakan bahwa kecepatan memuat situs web mereka tidak terlalu mengkhawatirkan.
▍ Pertanyaan nomor 2. Bundel Webpack memiliki kode pembantu. Apakah ini membuat beban tambahan pada sistem?
Ya itu.
▍ Pertanyaan nomor 3. Ketika bekerja dengan banyak file kecil, tingkat kompresinya memburuk, bukan?
Ya itu juga benar. Sebenarnya, saya ingin mengatakan ini:
- Lebih banyak file berarti lebih banyak kode pembantu Webpack.
- Lebih banyak file berarti lebih sedikit kompresi.
Mari kita mencari tahu untuk memahami seberapa buruk ini.
Saya baru saja melakukan tes di mana kode dari file 190 Kb dipecah menjadi 19 bagian. Ini menambahkan sekitar 2% ke jumlah data yang dikirim ke browser.
Akibatnya, ternyata pada kunjungan pertama ke situs, pengguna akan mengunggah 2% lebih banyak data, dan pada kunjungan berikutnya - 60% lebih sedikit, dan ini akan berlanjut untuk waktu yang sangat, sangat lama.
Jadi, apakah itu layak untuk dikhawatirkan? Tidak, tidak sepadan.
Ketika saya membandingkan sistem menggunakan 1 file dan sistem dengan 19 file, saya mengujinya menggunakan berbagai protokol, termasuk HTTP / 1.1. Tabel di bawah ini sangat mendukung gagasan bahwa memiliki lebih banyak file berarti lebih baik.
Data tentang bekerja dengan 2 versi situs yang di-host pada hosting statis Firebase, yang kodenya berukuran 190 Kb, tetapi, dalam kasus pertama, itu diolah menjadi 1 file, dan yang kedua itu dibagi menjadi 19Saat bekerja di jaringan 3G dan 4G, mengunduh situs dengan 19 file membutuhkan waktu 30% lebih sedikit daripada mengunduh situs dengan satu file.
Ada banyak suara dalam data yang disajikan dalam tabel. Misalnya, satu sesi mengunduh situs dengan 4G (Jalankan 2 dalam tabel) mengambil 646 ms, yang lain (Jalankan 4) - 1116 ms, yang merupakan 73% lebih lama. Oleh karena itu, ada perasaan yang mengatakan bahwa HTTP / 2 adalah "30% lebih cepat" agak tidak jujur.
Saya membuat tabel ini untuk melihat apa yang diberikan oleh penggunaan HTTP / 2. Tetapi, pada kenyataannya, satu-satunya hal yang dapat dikatakan di sini adalah bahwa penggunaan HTTP / 2 mungkin tidak terlalu mempengaruhi pemuatan halaman.
Dua baris terakhir dalam tabel ini adalah kejutan nyata. Berikut adalah hasil untuk bukan versi Windows terbaru dengan IE11 dan HTTP / 1.1. Jika saya mencoba memprediksi hasil tes di muka, saya pasti akan mengatakan bahwa konfigurasi seperti itu akan memuat bahan jauh lebih lambat daripada yang lain. Benar, koneksi jaringan yang sangat cepat digunakan di sini, dan saya, untuk tes seperti itu, mungkin harus menggunakan sesuatu yang lebih lambat.
Dan sekarang saya akan menceritakan satu cerita kepada Anda. Untuk menjelajahi situs saya pada sistem yang sangat kuno, saya mengunduh mesin virtual Windows 7 dari
situs web Microsoft. IE8 diinstal di sana, yang saya putuskan untuk ditingkatkan ke IE9. Untuk melakukan ini, saya pergi ke halaman Microsoft yang dirancang untuk mengunduh IE 9. Tapi saya tidak bisa melakukan ini.
Nasib buruk itu ...Omong-omong, jika kita berbicara tentang HTTP / 2, saya ingin mencatat bahwa protokol ini diintegrasikan ke dalam Node.js. Jika Anda ingin bereksperimen, Anda dapat menggunakan
server HTTP / 2 kecil yang saya tulis dengan dukungan untuk cache respons, gzip dan brotli.
Mungkin, saya mengatakan semua yang saya inginkan tentang metode pemisahan bundel. Saya pikir satu-satunya minus dari pendekatan ini, ketika menggunakan pengguna mana yang harus mengunggah banyak file, pada kenyataannya, bukan "minus".
Sekarang mari kita bicara tentang pemisahan kode.
Pemisahan kode
Gagasan utama dari teknik pemecahan kode adalah: "Jangan mengunduh kode yang tidak perlu." Saya diberitahu bahwa menggunakan pendekatan ini hanya masuk akal untuk beberapa situs.
Saya lebih suka, ketika datang ke pemisahan kode, untuk menggunakan aturan 20/20 yang baru saja saya rumuskan. Jika ada beberapa bagian dari situs yang dikunjungi oleh hanya 20% pengguna, dan fungsinya disediakan oleh lebih dari 20% dari kode JavaScript situs, maka kode ini perlu diunduh hanya atas permintaan.
Ini, tentu saja, bukan angka absolut, mereka dapat disesuaikan dengan situasi tertentu, dan pada kenyataannya ada skenario yang jauh lebih kompleks daripada yang dijelaskan di atas. Yang paling penting di sini adalah keseimbangan, dan sangat normal untuk tidak menggunakan pemisahan kode sama sekali, jika ini tidak masuk akal untuk situs Anda.
▍ Pisahkan atau tidak?
Bagaimana menemukan jawaban untuk pertanyaan apakah Anda memerlukan pemisahan kode atau tidak? Misalkan Anda memiliki toko online, dan Anda berpikir untuk memisahkan dari sisa kode, kode yang digunakan untuk menerima pembayaran dari pelanggan, karena hanya 30% pengunjung yang membeli sesuatu dari Anda.
Apa yang bisa saya katakan? Pertama, Anda harus berupaya mengisi toko dan menjual sesuatu yang akan menarik lebih banyak pengunjung ke situs. Kedua, Anda perlu memahami berapa banyak kode yang benar-benar unik untuk bagian situs tempat pembayaran diterima. Karena Anda harus selalu melakukan "bundle splitting" sebelum "code splitting", dan semoga Anda melakukannya, Anda mungkin sudah tahu ukuran kode apa yang kami minati.
Mungkin kode ini ternyata lebih kecil dari yang Anda pikirkan, jadi sebelum Anda bersukacita pada kesempatan baru untuk mengoptimalkan situs Anda, Anda harus menghitung semuanya dengan aman. Jika Anda, misalnya, memiliki situs Bereaksi, maka repositori, reduksi, sistem perutean, tindakan akan dibagikan oleh semua bagian situs. Unik untuk berbagai bagian kode situs akan diwakili terutama oleh komponen dan fungsi tambahan untuk mereka.
Jadi, Anda mengetahui bahwa kode yang benar-benar unik dari bagian situs yang digunakan untuk membayar pembelian membutuhkan 7 Kb. Ukuran kode situs lainnya adalah 300 Kb. Dalam situasi seperti itu, saya tidak akan melakukan pemisahan kode karena beberapa alasan:
- Jika Anda mengunduh 7 Kb ini sebelumnya, situs tidak akan melambat. Ingat bahwa file diunduh secara paralel dan coba ukur perbedaan yang diperlukan untuk mengunduh 300 Kb dan 307 Kb kode.
- Jika Anda mengunduh kode ini nanti, maka pengguna harus menunggu setelah mengklik tombol "Bayar". Dan inilah saat ketika Anda perlu segalanya berjalan semulus mungkin.
- Pemisahan kode memerlukan perubahan pada aplikasi. Dalam kode, di tempat-tempat di mana semuanya dilakukan secara sinkron sebelumnya, logika asinkron muncul. Tentu saja, tidak ada kesulitan kosmik dalam transformasi kode seperti itu, tetapi ini masih merupakan pekerjaan tambahan, yang menurut saya, harus dilakukan demi peningkatan nyata dalam pengalaman pengguna dengan situs.
Faktanya, kami membahas alasan mengapa pemisahan kode mungkin tidak cocok untuk Anda.Sekarang perhatikan beberapa contoh penerapan teknologi ini.OlPolyphylls
Saya mulai dengan contoh ini, karena apa yang akan kita lihat di sini hanya diterapkan dan berlaku untuk sebagian besar situs.Saya menggunakan di situs saya banyak alat bermanfaat dalam bentuk polyfill. Oleh karena itu, saya memiliki file di mana semua ini terhubung. Ini terdiri dari delapan baris berikut: require('whatwg-fetch'); require('intl'); require('url-polyfill'); require('core-js/web/dom-collections'); require('core-js/es6/map'); require('core-js/es6/string'); require('core-js/es6/array'); require('core-js/es6/object');
index.js , :
import './polyfills'; import React from 'react'; import ReactDOM from 'react-dom'; import App from './App/App'; import './index.css'; const render = () => { ReactDOM.render(<App />, document.getElementById('root')); } render(); // ,
Webpack , , npm-. 25 , 90% , .
Webpack 4
import() (
import ), :
import React from 'react'; import ReactDOM from 'react-dom'; import App from './App/App'; import './index.css'; const render = () => { ReactDOM.render(<App />, document.getElementById('root')); } if ( 'fetch' in window && 'Intl' in window && 'URL' in window && 'Map' in window && 'forEach' in NodeList.prototype && 'startsWith' in String.prototype && 'endsWith' in String.prototype && 'includes' in String.prototype && 'includes' in Array.prototype && 'assign' in Object && 'entries' in Object && 'keys' in Object ) { render(); } else { import('./polyfills').then(render); }
, , , — . —
render() . , Webpack npm-, ,
render() .
,
import() Babel
dynamic-import . , Webpack,
import() , .
, . .
▍ React,
. , , , .
, npm- . , , 100 .
, , URL
/admin ,
<AdminPage> . Webpack ,
import AdminPage from './AdminPage.js' .
. , ,
import('./AdminPage.js') , Webpack , .
, .
, ,
AdminPage , , URL
/admin . , :
import React from 'react'; class AdminPageLoader extends React.PureComponent { constructor(props) { super(props); this.state = { AdminPage: null, } } componentDidMount() { import('./AdminPage').then(module => { this.setState({ AdminPage: module.default }); }); } render() { const { AdminPage } = this.state; return AdminPage ? <AdminPage {...this.props} /> : <div>Loading...</div>; } } export default AdminPageLoader;
. (, URL
/admin ),
./AdminPage.js , .
render() ,
<AdminPage> ,
<div>Loading...</div> ,
<AdminPage> , .
,
react-loadable ,
React .
Ringkasan
, , (, , CSS). :
Pembaca yang budiman! ?