👩🏼‍🤝‍👨🏾 👨‍👩‍👦‍👦 👩‍🏫 Analisis dan optimalisasi aplikasi Bereaksi 👨🏽‍✈️ 🐱 👨🏼‍🔬

Orang-orang seperti saya yang berjuang untuk situs berkinerja tinggi sering menghabiskan banyak waktu untuk hal ini. Jadi sekarang saya akan sekali dan untuk semua menyelesaikan masalah sumber daya web berkecepatan rendah yang antarmuka ditulis dalam Bereaksi. Yaitu, saya sarankan semua orang yang membaca ini harus berhenti menggunakan Bereaksi hari ini.

Penulis materi, terjemahan yang kami terbitkan hari ini, tentu saja, lelucon. Di sini kita akan berbicara tentang cara mengoptimalkan kinerja aplikasi Bereaksi. Ngomong-ngomong, sebelum Anda mulai, mari kita pikirkan mengapa optimasi situs web umumnya diperlukan. Mungkin kita dapat mengatakan bahwa itu diperlukan agar situs tersebut dapat digunakan oleh lebih banyak orang daripada sebelum optimasi.

Pendahuluan

Bagaimana cara mengoptimalkan situs? Bagaimana Anda dapat mengevaluasi manfaat pengoptimalan untuk pengguna situs? Dan mengapa Anda perlu memikirkan indikator seperti itu?

Kami akan mencoba menjawab pertanyaan-pertanyaan ini dengan melihat cara termudah untuk membuat aplikasi Bereaksi - menggunakan alat create-react-app (CRA). Proyek baru yang dibuat menggunakan alat ini memiliki dependensi berikut:

Pustaka react utama, yang memungkinkan Anda untuk bekerja dengan komponen Bereaksi: 2.5 Kb.
Pustaka react-dom , yang memungkinkan komponen untuk ditampilkan pada halaman, mengubahnya menjadi struktur yang cocok untuk dimasukkan ke dalam pohon DOM: 30,7 Kb.
Sejumlah kecil kode, termasuk template komponen pertama: sekitar 3 Kb.

Data ini diperoleh untuk React 16.6.3.

Untuk mengetahui berapa lama waktu yang dibutuhkan untuk mengunduh aplikasi CRA baru di ponsel Moto G4 Anda, Anda dapat menggunakan layanan WebPageTest .

Waktu buka situs web di Moto G4 menggunakan jaringan yang berbeda

Aplikasi ini, variasi dari "Hello, World", dihosting di hosting Firebase, sedang diselidiki memuatnya di browser Chrome menggunakan tiga jenis koneksi:

4G (9 Mbps)
3G (1,6 Mbps)
Koneksi 3G lambat (400 Kbps)

Di sini Anda perlu mempertimbangkan penundaan jaringan.

Mengapa saya menggunakan Moto G4 untuk percobaan? Ini adalah telepon murah yang sederhana, mirip dengan telepon yang, dalam bentuk perangkat dasar, digunakan oleh banyak orang di negara berkembang. Pada jaringan 4G, aplikasi dimuat dalam 2 detik. Dalam jaringan 3G yang lambat, butuh lebih dari 4 detik untuk dapat online.

Meskipun metrik ini cukup menarik, mereka tidak terlalu berguna jika Anda tidak tahu siapa pengguna Anda. Apa yang Anda definisikan sebagai "lambat" mungkin sama sekali berbeda dari apa yang saya atau orang lain anggap "lambat". Dan persepsi Anda tentang pemuatan "cepat" situs dapat terganggu oleh perangkat dan koneksi jaringan yang Anda gunakan. Jika Anda menyertakan komputer desktop yang terhubung ke Internet melalui koneksi kabel dalam percobaan ini, Anda dapat melihat seberapa besar perbedaannya antara “cepat” dan “lambat” memuat situs.

Waktu pemuatan situs di komputer desktop dan Moto G4

Untuk meningkatkan kinerja aplikasi Bereaksi, konstruksi yang menggunakan perpustakaan Bereaksi, seperti yang mereka katakan, "di luar kotak", perbaikan DOM React diuraikan, yang bertujuan menyederhanakan beberapa hal. Jadi, sistem acara berisi banyak polyfill, yang, untuk banyak browser baru, tidak diperlukan, dan tim pengembangan sedang mempertimbangkan opsi untuk menghapus atau menyederhanakannya, jika memungkinkan. Anda bisa menontonnya di sini .

Dapatkah saya mengukur tingkat kinerja situs web saat ini?

Aplikasi Bereaksi yang khas dapat berisi banyak komponen dan pustaka pihak ketiga. Ini berarti bahwa kinerja aplikasi "Halo, Dunia" tidak memberi kami informasi yang sangat berharga tentang bagaimana aplikasi yang sebenarnya dimuat. Apakah ada cara untuk mengetahui seberapa tinggi kinerja sebagian besar situs yang dibangun menggunakan beberapa teknologi (seperti React)?

Sumberdaya Arsip HTTP dapat membantu kami menjawab pertanyaan ini. Ini adalah platform sumber terbuka yang berfokus mengamati bagaimana web dibangun. Ini dilakukan dengan merayapi jutaan situs secara bulanan, menganalisisnya menggunakan WebPageTest dan merekam informasi tentangnya. Informasi ini mencakup jumlah kueri, metrik tentang pemuatan data, ukuran data yang dikirimkan, dan indikator lainnya.

Berikut alat menarik lainnya - ekstensi untuk Chrome yang disebut Library-Detector-for-Chrome . Ini memungkinkan Anda untuk mencari tahu pustaka JavaScript mana yang digunakan pada halaman tersebut. Baru-baru ini dimasukkan sebagai alat audit halaman di Lighthouse. Ini menunjukkan bahwa informasi yang disediakan ekstensi ini dapat diperoleh untuk banyak situs yang informasinya disimpan di Arsip HTTP. Ini dapat membantu mereka yang ingin menganalisis hasil uji ribuan situs yang menggunakan pustaka JavaScript tertentu (mekanisme untuk menentukan Bereaksi ada di sini ).

Dataset Arsip HTTP lengkap tersedia untuk umum dan dapat ditemukan di BigQuery . Setelah meneliti 140.000 situs menggunakan Bereaksi untuk memuatnya dalam lingkungan seluler yang disimulasikan secara buatan (dataset 2019_01_01 ), kami berhasil mengetahui hal berikut:

Median indikator First Meaningful Paint (tampilan signifikan pertama, waktu untuk menggambar elemen-elemen penting) adalah 6,9 s.
Indikator median Time to Interactive (waktu untuk interaktivitas, waktu memuat elemen interaksi) adalah 19,7 detik.

Anda dapat menjelajahi data ini sendiri.

Diperlukan hampir 20 detik bagi pengguna untuk mulai berinteraksi dengan situs. Dan ini, secara umum, sedang terjadi, sehingga untuk berbicara, di sini dan sekarang, meskipun mungkin terlihat tidak masuk akal. Ini dapat dilihat di situs besar ketika bekerja dengan mereka dari perangkat yang lemah pada jalur komunikasi lambat. Selain itu, sekarang saya ingin menyuarakan beberapa alasan mengapa data ini harus dipertimbangkan dengan tingkat skeptis.

Ada banyak faktor yang mempengaruhi kinerja situs. Diantaranya - jumlah kode JavaScript yang dikirim ke pengguna, jumlah gambar dan bahan lain yang ditampilkan di halaman, dan sebagainya. Ini akan secara keliru membandingkan kinerja situs berbasis Bereaksi dengan kinerja halaman berlabel "Halo, Dunia" jika faktor-faktor lain tidak diperhitungkan.
Jika Anda mencoba untuk mendapatkan data dengan mengganti nama beberapa perpustakaan lain dalam permintaan Bereaksi, Anda akan mendapatkan nomor yang sangat mirip.

Untuk mendapatkan data yang akurat tentang kinerja seperti apa yang secara realistis ditunjukkan oleh situs yang menggunakan perpustakaan tertentu, banyak pekerjaan yang harus dilakukan.

Pertumbuhan kode JavaScript

Masalah umum dari situs web modern, tidak terikat pada perpustakaan tertentu, terkait dengan jumlah kode JavaScript yang biasanya dimuat oleh klien saat menjelajah. Arsip HTTP sudah memiliki akun yang bagus tentang ini. Singkatnya, inilah nilai median volume JavaScript yang diunduh dari situs web pada tahun yang berbeda seperti:

74,7 Kb - halaman web seluler, 15 Desember 2011.
384,4 Kb - halaman web seluler, 15 Desember 2018.

Harus diingat bahwa data ini diperoleh setelah memproses jutaan halaman. Mungkin ada ribuan situs atipikal yang mengubah indikator ini. Ini adalah ide yang bagus. Karena itu, kami akan mencoba mencari tahu bagaimana indikator ini terlihat untuk 10.000 situs pertama dari peringkat Alexa:

381.5 Kb - halaman web seluler, 15 Desember 2018 (ini permintaannya ).

Semua ini memungkinkan kami untuk menyimpulkan bahwa saat ini situs web sedang dibuat yang mencakup lebih banyak kode JS daripada situs yang dibuat beberapa tahun lalu. Ini adalah pengamatan penting. Situs menjadi lebih besar, mereka menjadi lebih interaktif dan lebih kompleks, dan volume JS-code dari situs-situs ini secara bertahap tumbuh setiap tahun. Anda mungkin sudah pernah mendengar tentang ini, tetapi semakin banyak kode JavaScript yang Anda kirim ke browser, semakin banyak waktu yang dibutuhkan untuk menguraikan, mengkompilasi, dan menjalankannya. Akibatnya, ini memperlambat situs.

Penting untuk dicatat bahwa setiap situs unik, serta basis pengguna setiap situs. Banyak pengembang, yang situsnya memasukkan lebih dari 300 KB kode JS, tidak menghadapi kenyataan bahwa sebagian besar penggunanya menderita masalah kinerja, dan ini sepenuhnya normal. Namun, jika Anda khawatir akan sulit bagi pengguna Anda untuk melihat situs Bereaksi Anda, untuk menilai situasi sebenarnya, yang terbaik adalah memulai dengan membuat profil.

Pembuatan profil dan analisis halaman

Membuat profil dan menganalisis aplikasi Bereaksi dapat dilihat dari dua perspektif:

Pertama, ini tentang mengevaluasi kinerja komponen. Ini memengaruhi cara pengguna berinteraksi dengan situs. Misalnya, jika daftar ditampilkan dengan mengklik tombol, ini harus dilakukan dengan cepat, tetapi jika ratusan komponen dirender ulang selama operasi ini, meskipun tidak perlu, operasi ini akan dianggap lambat.
Kedua, kita berbicara tentang seberapa cepat aplikasi dibawa ke dalam kondisi kerja. Artinya, berapa lama setelah dimulainya memuat situs, pengguna akan dapat berinteraksi dengannya. Jumlah kode yang dikirim ke pengguna selama pemuatan halaman pertama situs adalah contoh faktor yang mempengaruhi seberapa cepat pengguna dapat mulai bekerja dengan aplikasi tersebut.

Penilaian kinerja dan optimalisasi komponen

Mari kita coba untuk mengekspresikan dalam satu kalimat makna dari algoritma rekonsiliasi Bereaksi, atau esensi dari apa yang disebut “virtual DOM”. Akan terlihat seperti ini: "Bereaksi mengambil langkah-langkah untuk membedakan antara pohon DOM baru dan pohon lama untuk memahami apa sebenarnya di antarmuka pengguna harus diperbarui ketika data dalam komponen berubah." Ini menciptakan beban yang jauh lebih rendah pada sistem daripada merender ulang seluruh aplikasi untuk setiap perubahan status atau properti (di sini Anda dapat membaca tentang perbedaan antara O (n ³ ) dan O (n)). Ini adalah artikel oleh Dan Abramov, di mana Anda dapat menemukan penjelasan tentang rekonsiliasi.

Bahkan dengan mempertimbangkan fakta bahwa optimasi ini dibangun ke dalam mekanisme internal Bereaksi, kita selalu dapat menghadapi masalah ketika komponen dalam aplikasi diberikan berulang kali ketika hal ini seharusnya tidak terjadi. Dalam aplikasi kecil, ini mungkin tidak terlihat, tetapi ini dapat secara serius mempengaruhi kinerja aplikasi yang menampilkan ratusan komponen pada halaman mereka.

Pengubahan komponen yang tidak perlu dilakukan karena berbagai alasan. Misalnya, fungsi yang bekerja di dalam komponen mungkin tidak seefektif mungkin, atau mungkin seluruh daftar komponen digambar ulang ketika hanya satu elemen baru ditambahkan ke daftar ini. Ada alat yang dapat Anda gunakan untuk mengetahui komponen pohon yang telah dirender terlalu lama. Di antara mereka, berikut ini dapat dicatat:

Dasbor Alat Pengembang Chrome.
Bereaksi Profil Alat Pengembang.

▍ Analisis kinerja menggunakan panel kinerja Alat Pengembang Chrome

Bereaksi menggunakan Timing API Pengguna untuk mengukur waktu yang diambil pada setiap langkah siklus hidup komponen. Informasi kinerja untuk aplikasi Bereaksi dapat dikumpulkan dan dianalisis menggunakan Alat Pengembang Chrome. Ini memungkinkan Anda untuk memahami seberapa efektif komponen terhubung, ditampilkan pada halaman dan terputus selama interaksi pengguna dengan halaman atau ketika itu dimuat ulang.

Analisis Kinerja Komponen

Berikut adalah beberapa materi bagus tentang topik ini, yang didedikasikan untuk meneliti kinerja aplikasi yang ditulis menggunakan React 16 menggunakan alat pengembang Chrome.

API Pengaturan Waktu Pengguna hanya digunakan selama pengembangan. Itu, dalam produksi, dimatikan. Dalam kondisi seperti itu, implementasi yang lebih cepat dari mekanisme tersebut dapat digunakan, tanpa berdampak serius pada kinerja. Kebutuhan akan mekanisme seperti itu yang menjadi salah satu alasan untuk pengembangan API Profiler yang lebih baru.

Nal Analisis kinerja menggunakan profiler dari alat pengembang Bereaksi

Dengan merilis perpustakaan react-dom 16.5 di alat Bereaksi pengembang, panel baru bernama Profiler dapat digunakan. Ini memungkinkan Anda untuk menganalisis kinerja rendering komponen. Ini dilakukan dengan menggunakan API Profiler, yang mengumpulkan informasi tentang waktu pelaksanaan operasi untuk semua komponen yang dirender ulang.

Panel Profiler adalah tab mandiri di alat Bereaksi pengembang. Di sini, seperti halnya panel Kinerja toolbar Alat Pengembang Chrome, Anda dapat merekam informasi tentang tindakan pengguna dan pemuatan ulang halaman untuk mengumpulkan data untuk menganalisis kinerja komponen.

Mengumpulkan data dengan Bereaksi Alat Pengembang

Setelah pengumpulan data selesai, apa yang disebut "grafik berapi-api" akan ditampilkan, menunjukkan waktu yang diperlukan untuk membuat komponen pada halaman.

Jadwal Flaming Profiler

Di sini Anda dapat beralih di antara berbagai komit, atau status, saat simpul DOM ditambahkan, dihapus, atau diperbarui. Ini memungkinkan Anda untuk mendapatkan informasi lebih lanjut tentang berapa banyak waktu yang dihabiskan untuk berbagai operasi dengan komponen.

Lihat informasi komit di profiler

Tangkapan layar yang disajikan di sini mewakili data yang diperoleh sebagai hasil dari perekaman tindakan pengguna yang dilakukan dalam aplikasi sederhana. Aplikasi mengunduh daftar repositori GitHub yang sedang tren saat tombol diklik. Seperti yang Anda lihat, hanya ada dua komitmen di sini:

Salah satunya adalah untuk indikator pemuatan, yang ditampilkan selama pemuatan daftar item.
Lain mewakili saat ketika panggilan ke API selesai dan daftar ditampilkan di DOM.

Gambar di sebelah kanan menunjukkan metadata berguna yang mencakup informasi komit atau data komponen, seperti properti dan status.

Metadata

Saat bekerja dengan React profiler, Anda juga dapat melihat data lain yang diwakili oleh berbagai grafik. Anda dapat membaca lebih lanjut tentang profiler Bereaksi dalam posting ini dari blog Bereaksi.

Untuk sedikit menyulitkan contoh kita, pertimbangkan situasi yang serupa, tetapi sekarang kita akan melakukan banyak panggilan API untuk mengunduh repositori yang sedang tren dalam berbagai bahasa pemrograman (seperti Golang, JavaScript, dan sebagainya). Seperti yang Anda harapkan, dengan pendekatan ini, kami memiliki lebih banyak komitmen yang kami miliki.

Meningkatkan jumlah komitmen sambil mempersulit skema bekerja dengan aplikasi

Komit kemudian dibedakan berdasarkan jadwal yang lebih panjang, mereka memiliki lebih banyak warna kuning. Ini berarti bahwa waktu yang diperlukan untuk semua komponen untuk menyelesaikan rendering bertambah seiring dengan bertambahnya ukuran daftar elemen pada halaman. Ini disebabkan oleh fakta bahwa setiap komponen dalam daftar mengalami rendering ulang dengan setiap panggilan baru ke API. Ini membantu mengidentifikasi masalah yang dapat dengan mudah diselesaikan. Solusinya adalah bahwa item dalam daftar tidak perlu dirender lagi ketika item baru ditambahkan ke daftar.

▍ Meminimalkan operasi rendering komponen yang tidak perlu

Ada banyak cara untuk menghilangkan operasi yang tidak perlu untuk rendering ulang komponen React, atau setidaknya untuk meminimalkan jumlah operasi tersebut. Mari kita pertimbangkan beberapa di antaranya.

Anda dapat menggunakan metode siklus hidup komponen shouldComponentUpdate () :
```
 shouldComponentUpdate(nextProps, nextState) { // true        } 
```

Anda dapat menggunakan PureComponent untuk membangun komponen berbasis kelas:

 import React, { PureComponent } from 'react'; class AvatarComponent extends PureComponent { }

Untuk komponen fungsional, Anda dapat menggunakan memo :

 import React, { memo } from 'react'; const AvatarComponent = memo(props => { });

Anda dapat memoize penyeleksi Redux (misalnya, menggunakan pilih kembali ).
Anda dapat mengoptimalkan output dari daftar yang sangat panjang dengan menggunakan virtualisasi (misalnya, menggunakan jendela reaksi ).

Di sana - sini - beberapa video berguna, yang membahas penggunaan profiler Bereaksi untuk menemukan hambatan dalam aplikasi.

Penilaian kinerja dan pengoptimalan aplikasi

Selain menganalisis mutasi DOM dan operasi rendering komponen, ada fenomena tingkat tinggi lainnya yang perlu ditelusuri. Untuk penilaian kinerja situs yang komprehensif, Anda dapat menggunakan Mercusuar .

Ada tiga cara untuk menguji halaman web menggunakan Mercusuar:

Menggunakan Antarmuka Baris Perintah Node.js.
Menggunakan ekstensi Chrome.
Gunakan bilah alat Audit dari Alat Pengembang Chrome.

Inilah yang terlihat seperti Lighthouse di panel Audit.

Mercusuar di panel Audit

Mercusuar biasanya tidak memerlukan banyak waktu untuk mengumpulkan semua data yang dia butuhkan dari halaman dan untuk melakukan banyak pemeriksaan data ini. Setelah operasi ini selesai, Mercusuar menampilkan laporan dengan informasi ringkasan.

Untuk memahami bahwa memuat halaman ke browser melibatkan memuat terlalu banyak kode JavaScript, dan untuk menyimpulkan bahwa jumlah kode ini harus dikurangi, Anda perlu memperhatikan frasa berikut dari laporan:

Hilangkan sumber pemblokiran render
Waktu boot JavaScript terlalu tinggi
Hindari muatan jaringan yang sangat besar

Jika Lighthouse melaporkan masalah ini karena halaman menggunakan terlalu banyak bundel JS, hal pertama yang perlu dipertimbangkan sebagai cara untuk memperbaiki masalah adalah dengan memisahkan bundel. Faktanya adalah jika kode dapat dibagi menjadi beberapa bagian, beberapa di antaranya hanya diperlukan untuk bekerja dengan halaman-halaman tertentu di situs, maka kami tidak punya alasan untuk tidak menggunakan kesempatan ini.

Separation Pemisahan bundel JS

Salah satu cara untuk membagi kode menjadi beberapa bagian adalah dengan menggunakan impor dinamis:

   import('lodash.sortby')   .then(module => module.default)   .then(module => doSomethingCool(module))

Sintaks impor mungkin terlihat seperti pemanggilan fungsi, tetapi memungkinkan Anda untuk mengimpor modul apa pun secara tidak sinkron menggunakan mekanisme janji. Dalam contoh ini, metode sortby pertama-tama diimpor dari pustaka lodash , dan kemudian metode doSomethingCool() .

Aplikasi untuk menyortir angka

Dalam contoh ini, berikut ini terjadi:

Pengguna mengklik tombol untuk mengurutkan tiga angka.
lodash.sortby diimpor.
Metode doSomethingCool() , yang mengurutkan angka dan menampilkannya di simpul DOM yang baru.

Ini adalah contoh buatan yang sangat sederhana, karena jika seseorang perlu mengurutkan angka pada halaman web, maka ia mungkin hanya akan menggunakan metode Array.prototype.sort() . , , .

, JavaScript TC39. Chrome Safari , Webpack , Rollup Parcel .
React, , . — React.lazy :

 import React, { lazy } from 'react'; const AvatarComponent = lazy(() => import('./AvatarComponent'));

, , , . Suspense , , «» . React.lazy , , , :

 import React, { lazy, Suspense } from 'react'; import LoadingComponent from './LoadingComponent'; const AvatarComponent = lazy(() => import('./AvatarComponent')); const PageComponent = () => ( <Suspense fallback={LoadingComponent}>   <SomeComponent /> </Suspense> )

Suspense . React-, , , , React, loadable-components .

 import React from 'react'; import loadable from '@loadable/component' import LoadingComponent from './LoadingComponent'; const AvatarComponent = loadable(() => import('./AvatarComponent'), {   LoadingComponent: () => LoadingComponent });

LoadingComponent loadable-component .

, , loadable-components , - .

, . , , . React , React Suspense .

▍ , ?

, react-loadable-visibility , loadable-components -API Intersection Observer. , .

 import React from 'react'; import loadableVisibility from 'react-loadable-visibility/loadable-components' const AvatarComponent = loadableVisibility(() => import('./AvatarComponent'), { LoadingComponent: Loading, })

▍ ,

- — -, . - , , . , , , -, -, , .

Workbox — , -, . CRA 2.0 , , src/index.js . - .

   import React from 'react'; //... //   ,          //    ,     // unregister()  register().    ,     - //    . //     : http://bit.ly/CRA-PWA serviceWorker.unregister();

- Workbox .

▍

- HTML-, , , . , , , , , JS-, .

, , DOM-, , , (, hydrate() React). , , , , .

React 16, . renderToString() HTML-, renderToNodeStream() Readable- Node.

HTML- , . , , .

React , , , renderToStaticNodeStream .

▍ ,

- , , , , - , , . , , .

, , , . HTML- , .

, react-snap , Puppeteer .

, .

▍ , CSS-in-JS

React-, , CSS-in-JS- emotion styled-components . , , , , , . CSS-in-JS , , , . , , JavaScript- , , . , , , .

, ( )

- , . emotion styled-components . Readable- Node. Glamor , .

, .

Preact-, ( )

, CSS-in-JS — , , , , , astroturf . , , , , .

▍

«», , . , , .

, Lighthouse. , React-, React A11y .

, react-axe , , JSX-.

▍

? -, , ? , ?

, - . «» . , — , .

create-react-app -:

 { "short_name": "React App", "name": "Create React App Sample", "icons": [   {     "src": "favicon.ico",     "sizes": "64x64 32x32 24x24 16x16",     "type": "image/x-icon"   } ], "start_url": ".", "display": "standalone", "theme_color": "#000000", "background_color": "#ffffff" }

, . , , . — . Kenapa begitu? , , .

▍Atomic CSS

CSS- (Atomic CSS) , . , , :

 <button class="bg-blue">Click Me</button>

padding :

 <button class="bg-blue pa2">Click Me</button>

Dan sebagainya. class DOM, , , CSS-, . , . Tachyons .

. tachyon-components API, API styled-components :

 import styled from 'tachyons-components' const Button = styled('button')` bg-blue pa2 ` <Button>Click Me</Button>

, , CSS- «» , CSS-, , .

▍

, , . — :

 import { useState } from 'react'; function AvatarComponent() { const [name, setName] = useState('Houssein'); return (   <React.Fragment>     <div>       <p>This is a picture of {name}</p>       <img align="center" src="avatar.png" />     </div>     <button onClick={() => setName('a banana')}>       Fix name     </button>   </React.Fragment> ); }

, ( useState ).
, ( useEffect ).
.

, . , , recompose .

React Conf, .

, , JavaScript- . , React , 1.5 ( ). , - , , , , , , , .

Ringkasan

, React-. , , :

, :
- Performance Chrome.
- React.
- , , shouldComponentUpdate() .
- , , PureComponent .
- React.memo .
- Redux (, reselect ).
- (, react-window ).
Lighthouse.
, :
- — React.lazy .
- — loadable-components .
- - , . Workbox .
- — ( renderToNodeStream renderToStaticNodeStream ).
- ? react-snap .
- , CSS-in-JS.
- , . React A11y react-axe .
- - , , , .

, React, , :

API, , .
, , , .

« » . -, .

Pembaca yang budiman! React-?

Analisis dan optimalisasi aplikasi Bereaksi