大企業でフロントエンド コードを開発およびデプロイする方法_html/css_WEB-ITnose

これは非常に興味深い非主流のフロントエンド分野で、私はそれ以来、エンジニアリング手法を使用してフロントエンド開発とデプロイメント最適化の包括的な問題を解決する方法を探求しています。業界に入りました。

私の印象では、Facebook はこの分野の元祖です。興味があり、はしごを持っている学生は、Facebook ページのソースコードを見て、エンジニアリングとは何かを体験することができます。

次に、原則から始めたいと思います。長くなりますので、辛抱強く読んでいただければ幸いです。


----------------------------- 私は境界線です ---------------------- --- ---------------

初心に戻り、本来のフロントエンド開発から始めましょう。上の図は、「かわいい」index.html ページとそのスタイル ファイル a.css です。テキスト エディターを使用してコードをローカルでプレビューし、OK を確認してサーバーにスローし、ユーザーのアクセスを待ちます。フロントエンドはとてもシンプルで、とても楽しく、敷居が低いので、数分で習得できます。



次に、ページにアクセスして効果を確認し、ネットワーク リクエストを再度確認します。200!悪くない、とても完璧です！以上で研究開発は終了となります。 。 。 。すでに？

待って、これはまだ終わっていません!大企業の場合、これらの異常なトラフィック量とパフォーマンス指標により、フロントエンドはまったく「楽しく」なくなります。

a.css リクエストを見てください。ユーザーがページにアクセスするたびにロードする必要がある場合、パフォーマンスに影響を及ぼし、帯域幅を無駄にしますか?


ブラウザーに 304 を使用させるのが最適です。ローカルキャッシュ。しかし、これで十分でしょうか？いいえ！ 304 はネゴシエーション キャッシュと呼ばれます。これはまだサーバーと通信する必要があります。最適化レベルは異常なレベルなので、このリクエストは次のようになります。


ブラウザにローカル キャッシュを使用させる (キャッシュ- control/expires)、サーバーと通信しません。さて、リクエストの最適化が異常なレベルに達しました。そこで質問です: ブラウザーにリソース リクエストを送信させない場合、キャッシュはどのように更新しますか?

とても良いですね、誰かが方法を考えたと思います: ページ内で参照されているリソースパスを更新することで、ブラウザが積極的にキャッシュを放棄して新しいリソースをロードできるようにします。次のようになります:


次回オンラインにアクセスするときに、リンク アドレスを新しいバージョンに変更すると、リソースが更新されますよね? OK、問題は解決しましたか? ！もちろん違います！大企業の倒錯が再びここに来ています。次の状況を考えてください。


ページは 3 つの CSS を参照しており、特定のオンライン起動中に変更されたのは a.css だけです。すべてのリンクが更新されると、b.css につながります。 c.cssのキャッシュも無駄ではないでしょうか。 ！

異常モードを再度開くと、この問題を解決するには、URL の変更をファイルのコンテンツに関連付ける必要があることが簡単にわかります。つまり、ファイルのコンテンツの変更のみが、対応する URL の変更につながります。により、ファイルレベルの正確なキャッシュ制御が実現します。

ファイルの内容と何が関係していますか?ファイルの要約情報を取得するために「データ要約アルゴリズム」を使用することを当然考えます。要約情報はファイルの内容に 1 対 1 に対応しており、単一の粒度まで正確に処理できるキャッシュ制御基盤があります。ファイル。さて、URL を概要情報のあるものに変更しましょう:


今度は、ファイルに変更があった場合、そのファイルに対応する URL のみが更新されると考えると完璧なようです。これで十分だと思いますか？大企業はこう言います：パターンは崩れています！

ああ~~~~、一息入れましょう

現代のインターネット企業は、Web サイトのパフォーマンスをさらに向上させるために、静的リソースと動的 Web ページをクラスターにデプロイします。静的リソースは CDN ノードにデプロイされ、リソースは参照されます。 Web ページでは、対応するデプロイメント パスにもなります:


静的リソースを更新したいときは、次のように HTML 内の参照も更新します:


このリリースではページ構造も変更されました. とスタイル、そして静的リソースに対応する URL アドレスも更新されました。次に、コードをリリースしてオンラインにする必要があります。最初にオンラインにするべきか、それとも最初にオンラインにするべきかを教えてください。 、それとも静的リソースですか?

1. 最初にページをデプロイし、次にリソースをデプロイします: 2 つのデプロイの間の時間間隔中に、ユーザーがページにアクセスすると、古いリソースが新しいページ構造に読み込まれ、古いバージョンのリソースがキャッシュ後の結果は、ユーザーが不規則なスタイルでページにアクセスし、手動で更新しない限り、ページはリソース キャッシュが期限切れになるまでエラーを実行し続けます。
2. 最初にリソースをデプロイしてからページをデプロイします: デプロイ間隔内で、古いバージョンのリソースのローカル キャッシュを持つユーザーが Web サイトにアクセスします。要求されたページは古いバージョンであるため、リソース参照は変更されておらず、ブラウザーは直接アクセスします。ローカル キャッシュを使用すると、ページは正常に表示されますが、ローカル キャッシュを持たないユーザーまたはキャッシュの期限が切れた場合、古いバージョンのページが新しいバージョンのリソースをロードし、ページ実行エラーが発生します。ページが展開されると、これらのユーザーは再び Web サイトにアクセスできなくなり、通常の状態に戻ります。

さて、上記の分析から言いたいことは、誰も最初にデプロイすることはできないということです。これにより、展開プロセス中にページが混乱する可能性があります。したがって、アクセス数がそれほど多くないプロジェクトの場合、研究開発の学生は、熱心に取り組んで深夜まで待って、最初に静的リソースをアップロードしてからページをデプロイすることができ、問題は少ないと思われます。

しかし、大企業というのは極めて異常で、そのような「絶対的な低ピーク期」は存在せず、「相対的な低ピーク期」があるだけです。安定したサービスを提供するためには、完璧を追求し続けなければなりません。

この奇妙な問題は、リソースの
オーバーレイ リリース に起因しており、これには、公開リソースをカバーするためにリリースされるリソースを使用することが含まれます。簡単な解決策は、対象外リリースを実装することです。

上の図を見て、ファイルの概要情報を使用してリソース ファイルの名前を変更し、その概要情報をリソース ファイルのリリース パスに配置します。このようにして、内容が変更されたリソースが新しいファイルになり、公開されます。オンラインでは、既存のリソース ファイルは上書きされません。オンライン プロセスでは、最初に静的リソースが完全にデプロイされ、次にページがグレースケールでデプロイされるため、問題全体が完全に解決されます。

したがって、大企業の静的リソース最適化計画では、基本的に次のことを実装する必要があります:

長期的なローカル キャッシュを構成する?? 帯域幅を節約し、パフォーマンスを向上させる
キャッシュ更新の基礎としてコンテンツの概要を使用する? ? 正確なキャッシュ制御
静的リソース CDN の展開?? ネットワーク リクエストの最適化
スムーズなアップグレードを実現

完了すると、比較的完全な静的リソース キャッシュ制御ソリューションになります, また、静的リソースのキャッシュ制御には、すべての静的リソースがフロントエンドにロードされる場所でそのような処理が必要であることにも注意してください
。はい、全員！ jsやcssはもちろん、jsやcssファイル内で参照されているリソースのパスも含まれるため、参照先のリソースの概要情報によって参照先のファイル自体の内容も変化し、カスケードが形成されます。概要の変更点の概略図は次のとおりです。
さて、フロントエンド エンジニアリングにおける静的リソース キャッシュが直面する最適化とデプロイメントの問題についてはすぐに学びました。エンジニアはどのようにコードを記述すべきでしょうか? ！ ！

最適化とエンジニアリングを組み合わせるというアイデアを説明するには、モジュール開発、リソースの読み込み、リクエストのマージ、フロントエンド フレームワークなどに関連する一連のエンジニアリングの問題が取り上げられます。上記はほんの始まりにすぎません。解決策が肝心ですが、言いたいことが多すぎるので、時間があるときにゆっくり説明します。または、私のブログにアクセスして解体の一部を確認することもできます: fouber/blog · GitHub


つまり、フロントエンドのパフォーマンスの最適化は間違いなくエンジニアリングの問題です。

上記は私のものではありません。Baidu または Facebook ページと静的リソースのソース コードを観察して、リソース参照パスの処理と、ネットワーク内の静的リソースのキャッシュ制御部分を確認できます。改めてFacebookのフロントエンドエンジニアリングの構築レベルに感心し、舐めています。

フロントエンドエンジニアはフロントエンドエンジニアリングの分野にもっと注目することをお勧めします自分のプロダクトは小さいのでそこまで変態する必要はないと考える人もいるかもしれませんが、必要になる可能性が非常に高いです。いつかそのような変化を起こすために。そして、物事を極端にできるなら、そうしてみませんか?

また、これらは運用保守エンジニアやバックエンドエンジニアが解決する必要がある問題だと考えないでください。それを他の役割で解決してしまうと、
みんな自分のどうでもいい問題を他人に丸投げしてしまう
、フロントエンドエンジニアの開発プロセスが大幅に制限されてしまうこの状況は、一部の大企業でも珍しくありません。