CRAでは不十分な場合。Yandexレポート

複雑なインフラストラクチャを備えた大規模なプロジェクトは、Yandex検索インターフェイスの背後に隠されています。迅速に機能し、迅速に構築できる数十メガバイトのコードがあります。プロジェクトをReactとTypeScriptに変換する必要があるときは、Create React App、CRAから始めました。そして彼らはすぐに多くのことを改善する必要があることに気づきました。





Y.Subbotnik Proでの講演で、「標準的な最新プロジェクト」の組み立てとアーキテクチャで何をどのように終了したか、そしてどのような結果が得られたかを思い出しました。



-この1年半の間、私はSerpアーキテクチャチームで働いています。そこで、ReactとTypeScriptで新しいコードのランタイムとアセンブリを開発します。



この話で取り上げる私たちの共通の痛みについて話しましょう。Reactで小さなプロジェクトを作成する場合は、3文字と呼ばれる標準のツールセット（CRA）を使用する必要があります。これには、ビルドスクリプト、テストを実行するためのスクリプト、開発環境のセットアップが含まれ、すべてがすでに本番環境で実行されています。すべてはNPMスクリプトを介して非常に簡単に実行され、Reactの経験がある人なら誰でも知っているでしょう。



しかし、プロジェクトが大きくなり、コードが多く、開発者が多く、翻訳などのプロダクション機能が表示され、Create ReactAppが何も知らないとします。または、ある種の複雑なCI / CDパイプラインがあります。次に、Create React Appをベースとして使用し、独自のプロジェクトに合わせてカスタマイズすることを検討し始めます。しかし、この排出の背後で、そこで何が待っているのかは完全には明らかではありません。イジェクトすると非常に危険な操作だと言われるので、元に戻せないなど、とても怖いです。イジェクトを押した人は、多くの設定がそこにスローされることを知っています。これを理解する必要があります。一般的に、リスクは多く、何をすべきか明確ではありません。



どうだったかお話しします。まず、私たちのプロジェクトについて。私たちのフロントエンドプロジェクトは、Serp、検索エンジンの結果ページ、Yandexの検索結果ページです。 2018年以降、ReactとTypeScriptは移動していません。昨年、約12メガバイトのコードがすでにSerpaに書き込まれています。いくつかのスタイルと多くのTSおよびSCSSコードがあります。初めに、2018年に、私が書いていなかった、非常に少ない、非常に急激なジャンプがあった数がありました。







これがたくさんのコードであるかどうかを見てみましょう。 webpack-4のソースコードと比較すると、webpack-4のコードははるかに少なくなっています。 TypeScriptリポジトリでさえコードが少なくなっています。







しかし、vs-codeにはより多くのコードがあり、30メガバイトものTypeScriptコードを備えた優れたプロジェクトです。はい、それもTypeScriptで書かれており、Sickleは小さいようです。 2018年に開始し、2019年には12メガバイトがあり、70人の開発者が作業し、週に100回のプルリクエストを行いました。 1年で、彼らはこのサイズを3倍にし、正確に30メガバイトを受け取りました。今月測定を行いました。現在、合計30メガバイトのコードがあり、これはすでにvs-codeよりも多くなっています。







ほぼ同じですが、少し多いです。これが私たちのプロジェクトの順序です。







そして、最初にイジェクトを実行しました。これは、大量のコードがあり、Create ReactAppにある初期構成が機能しない可能性が高いことがすぐにわかったためです。しかし、同じ方法でCreate ReactAppから始めました。



それが物語の内容です。私たちの経験を共有したいと思います。YandexSerpを適切に機能させるためにCreateReactAppで何をしなければならなかったかを説明します。つまり、ブラウザでの読み込みと初期化を高速化する方法、ビルドの速度を落とさないようにする方法、これに使用した設定、プラグイン、その他のものです。そして当然、私たちが達成した結果は最後に来るでしょう。







どのように推論しましたか？当初のアイデアは、Sickleは非常に高速にレンダリングする必要があるページであるというものでした。これは、基本的に非常に単純なテキスト結果があり、サーバー側のテンプレートが必要であるためです。これが高速レンダリングを実現する唯一の方法だからです。つまり、クライアントで何かが初期化される前でも、何かを描画する必要があります。



同時に、余分なものをロードせず、初期化も高速になるように、スタティックの最小サイズを作成したかったのです。つまり、最初のレンダリングを高速にし、初期化を高速にする必要があります。







Create React Appは何を提供しますか？残念ながら、サーバーのレンダリングについては何も提供されていません。



Create ReactAppではサーバーレンダリングがサポートされていないことを直接示しています。さらに、Create React Appには、アプリケーション全体に対して1つのエントリしかありません。つまり、デフォルトでは、多種多様なページすべてに対して1つの大きなバンドルが収集されます。これはたくさんあります。 30メガバイトのうち、約半分がTSタイプであることは明らかですが、それでも多くのコードが直接ブラウザーに送られます。



同時に、Create React Appにはいくつかの適切な設定があります。たとえば、webpackランタイムは別のチャンクでそこに移動します。個別にロードされ、通常は変更されないため、キャッシュできます。



さらに、node_modulesのモジュールも個別のチャンクに収集されます。また、変更されることはめったにないため、ブラウザによってもキャッシュされます。これはすばらしいことです。保存する必要があります。しかし同時に、Create ReactAppの翻訳については何もありません。



私たちの場合、プラットフォームの機能のリストがどのように見えるかについてのリストをまとめましょう。まず、先ほど言ったように、北向きのレンダリングですばやくレンダリングする必要があります。さらに、検索結果ごとに個別のエントリファイルが必要です。







たとえば、Serpaに計算機がある場合、計算機付きのバンドルを配信する必要があり、トランスレータ付きのバンドルを迅速に配信する必要はありません。これらすべてが1つの大きなバンドルに集められている場合、これらの半分が特定の問題に関係していなくても、すべてが常に実行されます。



さらに、すでにロードされているものをロードしないように、共通のモジュールを別々のチャンクで提供したいと思います。







これがシックルの別の例です。計算機があり、計算機バンドルがあります。一般的なコンポーネントがあります。それらはクライアントに配信されました。その後、別の機能が登場しました-マップ。マップのバンドルを運転し、他の一般的なコンポーネントから、すでに配信されているものを除いたものを運転しました。



共通のコンポーネントが個別に収集されている場合、最適化の絶好の機会があり、必要なものだけが提供され、diffだけが提供されます。そして、常にページ上にある最も人気のあるモジュール、たとえば、このインフラストラクチャ全体で常に必要とされるWebpackランタイムは、常にロードする必要があります。







したがって、別のチャンクに収集することは理にかなっています。つまり、これらの一般的なコンポーネントは、常に必要とは限らないコンポーネントと、常に必要とされるコンポーネントに分類することもできます。ボタン/リンクなどのこれらの一般的なコンポーネントはあまり頻繁に変更されないため、これらは別のファイルに収集して常にロードし、キャッシュすることもできます。一般に、キャッシュから利益を得ることができます。







同時に、翻訳の組み立てについて決定を下す必要があります。







ここではすべてが十分に明確です。ターキッシュセルプに行く場合、これは余分なコードであるため、トルコ語の翻訳のみをダウンロードし、他のすべての翻訳はダウンロードしないようにします。



私たちは何をしましたか？まず、サーバーコードについてです。それに関しては、生産のための構築と開発のための立ち上げという2つの方向性があります。







一般に、最初にTypeScriptについてそのような別個のステートメントを作成する必要があります。通常、プロジェクトでは、私が聞いたように、babelを使用します。しかし、新しいTypeScript機能がより早く到達すると信じていたため、すぐに標準のTypeScriptコンパイラを使用することにしました。したがって、私たちはすぐにbabelを放棄し、tscを使用しました。



したがって、これは現在のコードサイズである30メガバイトで、ラップトップ上で3分でコンパイルされます。かなりの。型チェックを拒否し、各コンパイル中にtscフォークを使用する場合（残念ながら、TSCには型チェックを無効にする設定がないため、フォークする必要がありました）、時間を2倍節約できます。コードのコンパイルには1分半しかかかりません。



コンパイル時の型チェックができないのはなぜですか？たとえば、事前コミットフックでそれらをチェックできるからです。型チェックのみを実行するリンターを作成すると、型チェックなしでアセンブリ自体を実行できます。私たちはこの決定をしました。



開発でどのように実行しますか？ Devは通常、webpackと一緒にbabelのバンドルも使用しますが、ts-nodeのようなツールを使用します。







これは非常にシンプルなツールです。それを実行するには、そのようなrequire（ts-node）を入力JavaScriptファイルに書き込むだけで十分であり、プロセスの後半でTSコード全体のrequire-sをオーバーライドします。また、TSコードが途中でこのプロセスにロードされると、その場でコンパイルされます。とても簡単なことです。



当然、このプロセスでファイルがまだロードされていない場合は、ファイルを再コンパイルする必要があるという事実に関連する小さなオーバーヘッドがあります。しかし実際には、このオーバーヘッドは最小限であり、一般的に許容されます。



さらに、このリストにはさらに興味深い行がいくつかあります。 1つ目は、サーバー側のテンプレート作成にスタイルが必要ないため、スタイルを無視することです。 HTMLを取得するだけで済みます。したがって、このようなモジュール（ignore-styles）も使用します。さらに、ts-nodeの作業を高速化するために、TSCで行ったのとまったく同じように型チェック（トランスパイルのみ）をオフにします。



クライアントコードに移ります。 Webpackでtsコードを収集するにはどうすればよいですか？ ts-loaderとtranspileOnlyオプション、つまりほぼ同じバンドルを使用します。 babel-loaderの代わりに、多かれ少なかれ標準のts-loaderおよびtranspileOnlyツール。



残念ながら、インクリメンタルビルドはts-loaderでは機能しません。つまり、結局のところ、ts-loaderは完全に標準的なツールではなく、TypeScriptを実行するのと同じ人によって作成されたものでもありません。したがって、すべてのコンパイラオプションがそこでサポートされているわけではありません。たとえば、インクリメンタルビルドはサポートされていません。



インクリメンタルビルドは、開発に非常に役立つ可能性のあるものの1つです。同様に、これらのキャッシュをパイプラインに追加できます。一般に、変更が小さい場合、すべてのTypeScriptを完全に再コンパイルすることはできず、変更されたものだけを再コンパイルできます。それは非常に効果的に機能します。



一般に、インクリメンタルビルドなしで行うには、キャッシュローダーを使用します。これはwebpackの標準ソリューションです。すべてが非常に明確です。 TypeScriptコードがWebpackビルド中に接続を試みると、コンパイラによって処理され、キャッシュに追加されます。次に、ソースファイルに変更がない場合、キャッシュローダーはts-loaderを実行せず、キャッシュから取得します。つまり、ここではすべてが非常に単純です。



何にでも使用できますが、特にTypeScriptの場合、ts-loaderはかなり重いローダーであるため、ここではキャッシュローダーが非常に適しているため、これは便利です。







ただし、キャッシュローダーには1つの欠点があります。それは、ファイルの変更時に機能します。これがソースコードの抜粋です。そして、それは私たちにとってはうまくいきませんでした。







パイプラインでキャッシュローダーを使用するのに適していないため、ファイルコンテンツのハッシュに基づいてキャッシュアルゴリズムをフォークしてやり直す必要がありました。



実際、複数のプルリクエスト間でビルド結果を再利用する場合、このメカニズムは機能しません。なぜなら、たとえば、アセンブリがずっと前だった場合です。次に、前回収集されたファイルを変更しない新しいプルリクエストを作成しようとします。



しかし、彼らのmtimeはもっと最近のものです。したがって、キャッシュローダーはファイルが更新されたと見なしますが、これは変更時間ではなくチェックアウト時間であるため、実際にはそうではありません。そして、このようにすると、コンテンツのハッシュが比較されます。内容は変更されておらず、古い結果が使用されます。



ここで、babelを使用していた場合、babel-loaderにはデフォルトで内部にキャッシュメカニズムがあり、mtimeではなく、コンテンツからのハッシュですでに作成されていることに注意してください。したがって、多分私たちはもう少し考えて、バベルに目を向けるでしょう。



次に、チャンクのアセンブリについて説明します。







webpackがデフォルトで何をするかについて少し話しましょう。入力インデックスファイルがある場合、コンポーネントはそれに接続されています。また、コンポーネントなどもあります。さらに、React、React-dom、lodashなどの共通モジュールが接続されています。



したがって、デフォルトでは、誰もが知っているように、webpackは、念のために繰り返しますが、すべての依存関係を1つの大きなバンドルに収集します。







同時に、node_modulesを介して接続されているすべてのものは、外部としてアセンブルするか、個別のスクリプトでロードするか、webpackで特別なoptimization.splitChunks設定を設定することで個別のチャンクにまとめることができます。私の意見では、デフォルトでも、これらのベンダーモジュールは別のチャンクに収集されます。 CRAには、このsplitChunksのわずかに調整されたバージョンがあります。







runtimeChunksとは何かを覚えておきましょう。私は彼に言及した。これは、クライアントでのモジュラーシステムの動作を保証するスクリプトと関数をロードするこのような「ヘッダー」を含む種類のコードです。そして、実際にはモジュールを含む配列（またはキャッシュ）。







なぜ私はこれについてあなたに話しましたか？ Create React Appは、このruntimeChunksを別のファイルに収集する設定を引き続き使用するためです。このファイルは、元の正常なバンドルではなく、別のファイルに貼り付けられます。ブラウザなどにキャッシュできます。



では、Create React Appで何が機能しないのでしょうか？







デフォルトでそこで使用されるこのsplitChunksは、node_modulesのみを個別のチャンクに収集します。しかし、実際には、プロジェクトレベルにある共通のコンポーネント、共通のライブラリがあります。また、おそらくほとんど変更されないので、それらを別々のチャンクに収集したいと思います。 node_modulesにあるものだけに制限するのはなぜですか？



さらに、runtimeChunksに関しては、最初に説明したように、ランタイム自体に加えて、常に必要な同じチャンクにモジュールを収集することも素晴らしいと言えます。同じボタン/リンク。 Serpには常にリンクがあります。いつもリンクを集めたいです。つまり、Webpackランタイムだけでなく、いくつかの非常に人気のあるコンポーネントもあります。



これはCreateReactAppにはありません。どうやってやったの？







splitChunksを微調整して、すべての標準動作を無効にし、node_modulesにあるものだけでなく、プロジェクトの共通コンポーネントとプロジェクトのライブラリコード、src / libにあるものを共通のコードに収集するように依頼しました。 、src /コンポーネントに含まれています。



さらに、動的インポートを介して接続されているものと、通常は非同期チャンクと呼ばれるものを別々のチャンクに収集します。



ここでは、2つのオプションに注意を払う必要があります。 1つは強制で、もう1つは初期です。一般に、enforceは非常に便利な設定であるため、splitChunksの複雑なヒューリスティックを無効にします。



デフォルトでは、splitChunksは、要求されているモジュールの量を理解し、これらの統計を分割で考慮に入れようとします。しかし、これに従うことは困難であり、モジュールの需要は時々変化する可能性があり、モジュールはチャンク間で「ジャンプ」します。一般的なチャンクから機能バンドルまで、そしてその逆。つまり、これは非常に予測不可能な動作であるため、無効にします。



つまり、テストフィールドの条件を満たすすべてのものを常に言い、共通のチャンクに入ります。ヒューリスティックは必要ありません。



しかし、チャンク：初期も良いことです。これらの同期モジュール、つまり動的インポートを介して接続されるモジュールは、さまざまな場所でさまざまな方法で接続できるという事実についてです。つまり、動的インポートまたは通常のインポートのいずれかによって同じモジュールを接続できます。



また、初期値を使用すると、同じモジュールを2つの方法で構築できます。つまり、非同期と同期の両方でアセンブルされるため、両方の方法で使用できます。十分に便利です。これにより、収集された統計のサイズがわずかに大きくなりますが、任意のインポートを使用できます。



ちなみに、ドキュメントからは、これを理解するのは非常に困難です。私は最近ウェブパックのドキュメントを読み直しましたが、イニシャルについては通常のことは何も書かれていません。







これは、splitChunksで行ったことです。ここで、runtimeChunksで何をしましたか。 runtimeChunksでランタイムのみを収集するのではなく、非常に人気のあるコンポーネントをそこに追加したいと思います。



そこで、MainChunkPluginという独自のプラグインを作成しました。そして、それは非常に些細な設定です。そこに収集する必要のあるモジュールのリストがあり、人気があると考えました。



A / Bテストツールやさまざまなオフラインツールを使用するだけで、検索結果に最も頻繁に表示されるコンポーネントを特定できました。それは彼らがちょうどそのようなフラットリストに書かれたところです。そして最後に、私たちのプラグインは、リストからこれらのコンポーネント、ライブラリ、およびこの標準のoptimization.splitChunksを収集するwebpackランタイムを収集します。







ちなみに、ここにランタイムを接着するコードがあります。また、プラグインを作成するのがそれほど簡単ではないことを示すのはそれほど簡単ではありませんが、それが何をもたらしたかを見てみましょう。







一般的に言えば、webpackにはDLLPluginと呼ばれるこれを行うための標準的なメカニズムがあることにも注意してください。また、依存関係のリストを使用して個別のチャンクを収集することもできます。しかし、それにはいくつかの欠点があります。たとえば、runtimeChunksは含まれていません。つまり、runtimeChunksには常に個別のチャンクがあり、DLLPluginによってアセンブルされたチャンクがあります。これはあまり便利ではありません。



また、DLLPluginには別のアセンブリが必要です。つまり、DLLPluginを使用して最もパーカッシブなコンポーネントでこの個別のチャンクを構築する場合は、2つのアセンブリを実行する必要があります。



つまり、この個別のチャンクをマニフェストファイルでアセンブルし、アセンブリの残りの部分は、マニフェストファイルを差し引くだけで他のすべてを収集し、人気のあるコンポーネントでチャンクにすでに入っているものを収集しません。また、DLLPluginの実装にローカルで7秒かかったため、ビルドが遅くなります。それは多いです。また、厳密な順次実行のため、最適化できません。



さらに、ある時点で、CSSを使用せず、JSのみを使用して、この主要なチャンクを構築する必要がありました。 DLLPluginはそれを行いません。インポートを通じてrequireを通じて利用可能なものはすべて常に収集します。つまり、CSSを含めると、常にヒットします。それは私たちにとって不快でした。しかし、これがあなたにとって問題ではなく、そのようなトリッキーなコードを書きたくないのであれば、DLLPluginはごく普通の解決策です。彼は主な問題を解決します。つまり、最も人気のあるコンポーネントを別のファイルで提供します。使用できます。







それで、私たちは何を得ましたか？私たちの機能は、同じ名前の特別なプラグインによって組み立てられたMainChunkの非常に人気のあるコンポーネントを使用できます。さらに、あらゆる種類の共通コンポーネントを含む共通チャンクがあり、動的インポートによってロードされる非同期チャンクがあります。



残りのコードは機能バンドルに含まれています。原則として、これはチャンク構造です。







翻訳の組み立てについて。私たちの翻訳は、翻訳が必要なコンポーネントの隣にあるtsファイルです。ここに9つの言語があり、ここに9つのファイルがあります。







翻訳は次のようになります。これは、キーフレーズと翻訳されたフレーズの意味を含む単なるオブジェクトです。







これは、翻訳がコンポーネントに接続される方法であり、特別なヘルパーが使用されます。







これらの翻訳はどのように収集できますか？私たちは、翻訳を収集し、インターネットを見て、彼らが何を書いているのか、どうすればそれができるのかを知る必要があると考えています。



彼らはインターネット上で言う：マルチコンパイルを使用する。つまり、1つのWebpackビルドを実行する代わりに、言語ごとにWebpackビルドを実行するだけです。しかし、彼らは、キャッシュローダーがあり、TypeScriptでのこの一般的な作業、またはあなたが持っているものはすべてキャッシュされるので、すべてがうまくいくと言います。したがって、長くはありません。



落胆しないでください。これが9回の実際のWebパックの実行になるとは思わないでください。そうではないでしょう、それは良いでしょう。



修正が必要なのは、ReplacementPluginモジュールを追加することだけです。これは、すべての言語を接続するインデックスファイルの代わりに、特定の言語に置き換えます。すべてが非常に些細なことであり、はい、出力を修正する必要があります。ここで、言語ごとに個別のバンドルを収集する必要があることがわかりました。







このレシピの図は次のとおりです。翻訳者がいました。彼は翻訳者の翻訳を結びつけました。彼は言語を接続し、この1つの構造を収集する代わりに、言語ごとに複製し、個別の構造を取得して、それぞれを個別のコンパイルとして収集しました。







残念ながら、それは機能しません。現在の30MBコードに対してこのマルチコンパイルオプションを実行しようとしましたが、1時間半待ったところ、このエラーが発生しました。















それは非常に長く、不可能です。これで何をしましたか？別のプラグインを作成しました。出力ファイルをディスクに保存しようとしているときに、同じ構造を使用してWebpackの作業に取り組みます。この構造を言語の数だけコピーし、それぞれに1つの言語を接着します。そして、その時だけファイルを作成します。







同時に、コンパイルの依存関係をバイパスするためにwebpackが行う主な作業は繰り返されません。つまり、最後の段階でくさびを入れているので、速くなることを期待できます。







しかし、プラグインコードは複雑であることが判明しました。これは文字通りプラグインの8分の1です。私はそれがどれほど難しいかを示しているだけです。そして、そこには定期的に小さな不快なバグがあります。しかし、それを実装するのは簡単ではありませんでした。しかし、それは非常にうまく機能します。







つまり、エラーが発生した1時間半ではなく、このプラグインを使用して5分間のアセンブリを取得します。



今配信と初期化。







配信と初期化は簡単です。別々のリソースにロードするものは、他の人と同じようにプリロードを使用していると思います。次に、CSS、JS、実際にはコンポーネントのHTMLを含め、これらのリソースをロードしますが、非同期は使用しません。



実験しました。非同期を使用すると、対話性の開始時間が遅れますが、これは望ましくありません。したがって、プリロードを使用して、ページの最後にロードするだけです。一般的に、特別なことは何もありません。







同時に、他のすべてをインライン化します。つまり、これはMainChunkであり、CSSをインライン化します。一般的なコンポーネント、スタイル、一般的に、スライドに書かれているすべてのものをインライン化します。これは、「インライン」が最初のレンダリングと対話性の開始に対して最良の結果をもたらすことを示した一連の実験でもありました。



そして今、数字に。数値について話すには、メトリックについて2つの単語を言う必要があります。







すべてのフロントエンドコードを効率的に機能させることに専念する専任のスピードチームがあります。これは、サーバー側のテンプレート化、リソースのロード、およびクライアントでの初期化に関係します。一般的には、これらすべてです。



プロダクションから特別なロギングシステムに送信されるメトリックがたくさんあります。これはA / B実験で制御できます。私たちはオフラインツールを持っています、一般的に、私たちはこれすべてを非常に積極的にフォローしています。



そして、ReactとTypeScriptでこの新しいコードを実装するときに、これらのツールを使用しました。







オフラインツールを使用して追跡しましょう（すべてのメトリックを使用する正直なオンライン実験をまとめることができなかったため）。現在のソリューションからこれらの主要な指標でReactAppを作成するようにロールバックするとどうなるか見てみましょう。



このツールは非常に簡単に機能します。すべてのSerpがまだReactで書き換えられていないため、リクエストのスライスが取得されます。この場合、Reactの機能を備えたリクエストが取得されます。次に、テンプレートが攻撃され、測定値が収集され、これらの結果とメトリックを比較して見つける特別なユーティリティに挿入されます。この場合、統計的に有意な結果のみが残ります。一般的に、すべてがそこに合理的です。



しばらく様子を見てみましょう。







実際、必要な翻訳だけでなくすべての翻訳を収集するMultiPluginを無効にしても、統計的に有意な変化は見られませんでした。



最初は少し動揺していましたが、実際には、これは問題ではないことに気付きました。現在、多くの翻訳がReactに変換されている機能があまりないためです。したがって、そのような機能がさらにある場合、これらの重要な変更は間違いなく表示されます。現在、主にロシアで表示されている機能があり、翻訳がありません。また、コンポーネントに含まれるコードの量は、翻訳の量を大幅に上回っています。したがって、すべての翻訳が進行中であることは認識できません。



正直な実験が行われた場合、おそらくそれはより正直な実験で顕著になるでしょう。しかし、オフラインツールはこれらの変更を表示しませんでした。







MainChunkPluginを無効にすると、対話機能の開始時間が遅くなり、HTMLの読み込みも大幅に遅くなります。したがって、それは非常に必要です。



個別のリソースによってこの個別のチャンクにロードされていたすべてのコードがHTMLにインライン化されるようになったため、HTMLのロードが遅くなるのはなぜですか。すべてをインライン化するようなものですが、対話性も遅くなります。原則として、かなり期待されています。



そして今、質問：すべてを1つのバンドルに入れ、共通のコンポーネントでチャンクを使用しないとどうなるでしょうか。これはまったく幸せな絵ではないことがわかりました。







最初のレンダリングは劇的に遅くなります。インタラクティブ性もほぼ2倍になりました。これにより、すべてのコードが別のリソースで配信され始めるため、HTMLが小さくなります。しかし、ご覧のとおり、対話性は役に立ちません。



そして組み立て。最後のスライド。











現在のプロジェクトのCreateReact Appのビルド時間は、ラップトップで3分かかります。そして、私たちのすべての鐘と笛で-5分。長いです？







しかし、実際には、1つのバンドルにまとめると、3分になります。 MultiPluginなしでビルドすると、Create ReactAppよりもさらに高速になります。ただし、前のスライドで示したように、元のビルドスクリプトに対するこれらの変更を拒否することはできません。これがないと、速度メトリックが非常に悪くなるためです。



それでは、このレポートから学ぶのに役立つことを見ていきましょう。







TypeScriptを使用する方法はBabelだけではありません。 TSC、ts-nodeおよびts-loaderを使用できます。それは非常にうまく機能します。



そうは言っても、TypeScriptチェック、タイプチェックは、ビルドするたびに実行する必要はありません。これにより、速度が大幅に低下します。覚えているように、2回です。したがって、そのようなものを別々のチェック、たとえば事前コミットフックに配置することをお勧めします。



頻繁に使用するコンポーネントを別のチャンクに収集することをお勧めします。共通のコンポーネントを別々のチャンクに収集することも望ましいです。これにより、必要なものだけをロードでき、diffだけをロードできるからです。



最も重要なことは、すべてのページですべてのコードを使用していない場合は、コードを個別のエントリに分割し、個別のバンドルを収集して、ユーザーに対応するタイプの検索結果が表示されたらダウンロードする必要があることです。必要なファイルのみをダウンロードしてください。あなたが見てきたように、これは最大の結果をもたらします。かなり明白なことですが、まだCreate React Appに残っているため、全員がこれを行うかどうかはわかりません。



マルチコンパイルは非常に長いです。マルチコンパイルは問題なく、内部のどこかにあるキャッシュでこれらすべてを処理できると誰かが言っても、信じないでください。プリロードとインラインを使用しても結果が得られます。



シックルに関するいくつかのリンク：

• clck.ru/PdRdhとclck.ru/PdRjb-ReactでSerpを書き直すことに関する2つのレポート。これは最初の段階であり、どのようにしてこれに到達したのか、なぜそれを始めたのかについてです。2番目のレポートは、管理の観点からこれらすべてをどのように計画および実行したか、ステージはどのようなものであったかについてです。
• clck.ru/PdRnr-速度メトリックに関するレポート。オンラインツールがどのように機能するのか、他に何があるのか​​と突然疑問に思った人向けです。

ありがとうございます。