導入

Material-UI 人気のあるコンポーネントライブラリReactstrap それは反応を統一します、そしてMaterial Design , Googleによって構築されたデザインシステム.
反応する開発者として、私は無数のprojetで物質的なUIを使用しました、そして、私はそれがその格子システム、構成要素の多くとともに来るすばらしい図書館であると言わなければなりません、そして、一貫したUISをかなり速く構築するのを助けます.
私は個人的なオープンソースプロジェクトのためにそれを使用するまで、私はそれに満足していたAmmo .

Quick parenthesis about Ammo: it's an open source projects which aims at capturing http requests and turn them into stress test engines scripts (such as Gatling). Not the focus of this article though, I won't dive into more details.

文脈

私の不幸を材料UIで公開する前に、私の闘争を見ましょう.
ammoでは次のような項目のリストがあります.

リスト内の各項目は、折りたたみ/展開できません.

あなたがここで見ることができるように、解凍されたアイテムがいくつかのものを明らかにするとき、しかし、何も空想的でなくて、複雑でありません.左側では、テキストを基本的なHTML divをoberveすることができます.右側にはコードスニペット(フォーマット/prettified感謝)を持っていますReact syntax highlighter ).
しかし、私は非常に迅速にアプリケーションの全体的なパフォーマンスは絶対に恐ろしいことに注意してください.
何?

最初の一連の措置

機能を強調しているコードスニペットを開発した後に、ちょうど機能で100 %幸せであるために、私はリストにカップルアイテムを投げようとして、構文強調表示図書館がアプリのパフォーマンスを壊さないと確認しました.
パフォーマンスは、パフォーマンスが恐ろしいことが判明したとして関連性が証明された.
どれだけ悪かったかを説明するために、インターフェイスに50個の項目を追加するときに、どのようなものがうまくいくかのGIFです.

あなたが見ることができるように、アプリケーションは地獄と実際の痛みのように使用するように遅れている.だけで50項目!
画像、アニメーション、サウンドエフェクト＆musics、60 fpsで背景などの複数の層を表示する必要があるゲームの背景から来て、HTMLのdivをレンダリングするためだけにそのような遅れを見てあまりにも耐えることができなかった.そこでプロファイリングを行います.

魔女狩り：反応版

私の最初の直観は、何か間違った反応があったということでした.結局のところ、私は見ていた(として、正直にしてください)不要なレンダリングとパフォーマンスの賢明な貧しい実践と過去の多くのアプリで.なので最初に作ったことは、リストが最適化されていることを確認することでした.

非インデックス、リスト内の各項目に一意のキーを与える

既にレンダリングされた項目をメモして、新しいものを追加するときに再レンダリングしないようにします.使用するmemo でもuseMemo と同じです.

その後、アプリを提出した.

注意してください.

まず第一に、回想は非常にうまく働いているようです.我々は、すでにレンダリングされたアイテムがグレーアウトされていることを見ることができます

新たに導入されたアイテムが実際にいくつかのレンダリング時間を取っていることがわかります

しかし、私が心配したことは、右上隅にあるグラフです.ご覧の通り、貸し手は時間とともに遅くなっています.新しいアイテムのレンダリングは約100 msを取るオフに起動しますが、リストが長くなると、それは500 msまでかかります.
何?
まず第一に、リストの項目の数は、新しいアイテムのレンダリング時にどんな影響を及ぼすのか?そして、500 msはいくつかの基本的なdivをレンダリングする!ホースクラップ!
つの項目のレンダリングのプロファイリングを拡大しましょう.

私は2つのことを強調したイメージで:

右側では、私たちの反応の構文の高いライター、私の最初の心配のソースは、すべての悪いパフォーマンスに責任がないことがわかります.それは断然速く

かなりの時間がかかっているように思われるものは「ヘッダー」(左)です.

明らかにすると、これは"ヘッダ"です.

それは本当に何も、ちょうど2つのインラインテキスト!どうしてそんなに遅いの?ちょうど私のポイントをさらに証明するために、ここでは<Header> コンポーネント

<Box className={classes.values}>
    <Typography variant="subtitle2">
        <span>{key}</span> :
        <span className={classes.headerValue}>
            "{value}"
        </span>
    </Typography>
</Box>

ここに空想はない.いいえ隠されたパフォーマンスcaveheat、それはちょうどいくつかの基本的なdivです!

それはすべての材料のUIになる

非常に絶望的な、私は多くのことを試みた、フォーラムの多くを通過し、まだどのように反応を把握しようとして、これはひどく物事を混乱させる可能性があります.それから、考えから抜け出して、私は<Box> コンポーネント<div> :

<div className={classes.values}>
    <Typography variant="subtitle2">
        <span>{key}</span> :
        <span className={classes.headerValue}>
            "{value}"
        </span>
    </Typography>
</div>

驚いたことに、パフォーマンスの改善を見ました!私はさらに少し行って、可能な限り多くの材料UIコンポーネントを取り除くことを試みました<Box> and <Typography> ) 私はこうなった.

あなたがその権利を読むならば

このテストは500アイテム(〜1000レンダリング)で行われます.そしてそれは流体です!

最高のレンダリングピークは〜110 ms(50項目の代わりに50項目)です

時間をレンダリングする項目は一貫性があり、リスト内の項目の数と共に増加しません

それで、それは大きい勝利です!今すぐアプリは10倍以上のアイテムと厳格に流体です!そして、そのパフォーマンスは一貫しています!

結論

材料UIは素晴らしい図書館であり、過去数年で私の背中を持っています、しかし、現在、あなたのアプリケーションがパフォーマンス挑戦を示すかもしれないならば、私は強くそれを使うことに忠告します.単純な形または標準的なウェブページは問題ではありません、しかし、まだ、それを心に留めておいてください.
もちろん、私はこれらの問題を見つける最初の1つではない、いくつかの問題がgithubに開いているthis one for example ).
また、すべてのこの最適化の後、あなたはまだ1つのアイテムのための110 msのレンダリング時間がまだ巨大であると主張することができました、そして、私は同意します、しかし、私は当分の間ここでものを残します.更なる最適化は、新しい記事の良い話題でなければなりません!