ウェブサイトの静的処理 - CSI

CSI はブラウザー側の動的および静的統合ソリューションです。私の記事が公開された後、友人から、CSI テクノロジーは ajax を介してデータをロードするものなのかと尋ねられました。そのときの私の答えは、あなたの理解が少し一方的だった、というものでした。ではCSIとは一体何なのでしょうか?これは実際には、動的リソースと静的リソースを統合するという観点から定義する必要があります。

CSI テクノロジーは、ページを動的と静的に分離した後、実際にページの読み込みを 2 つのステップに分割します。最初のステップでは静的リソースがロードされ、2 番目のステップでは動的リソースがロードされます。ただし、この定義はまだ不完全です。この不完全な部分は、静的リソースを効果的にキャッシュするために、動的リソースと静的リソースを分離するという目的を強調する必要があるということです。ページ上では、静的リソースがどのようにキャッシュされるかにかかわらず、静的リソースの読み込みを高速化することが目的です。リソースが効率的になると、CSI フォームを使用してページをデザインしたとしても、実際には CSI の利点を活用せず、CSI の欠点を誤って導入することになります。では、CSIの欠点は何でしょうか？詳細は以下の通りです:

CSIの欠点1: CSIはページのSEO、つまり検索エンジンの最適化に役立ちません。検索エンジンの Web クローラーは通常、URL に基づいてページにアクセスし、ページのコンテンツを取得し、CSS スタイルや JS スクリプトなどの不要な情報を削除して、ページ コンテンツの一部を分析する必要があります。この読み込みコントロールは JavaScript コードで完了する必要があるため、Web クローラーによってクロールダウンされたページでは非同期読み込み操作を実行できません (一部の高度なクローラーは、非同期操作を実行して非同期コンテンツをキャプチャできると聞きました。これを使用すると、このテクノロジーでは、ほとんどの主流のクローラーは依然として JavaScript コードと非同期で読み込まれるコンテンツを無視します)。そのため、クローラーによってクロールされたページ内の一部の情報が失われるため、CSI は SEO にはあまり適していません。ただし、この欠点を注意深く分析すると、動的および静的分離戦略をうまく実行できれば、動的リソースは基本的にキャッシュできないコンテンツになる可能性があります。これらの変更の内容は Web クローラーによってクロールされる必要はありません。クロールされたとしても、このページをクリックすると検索結果が見つかりません。ページのキーワードで、検索エンジンを使用しているときに多くの友人がこの状況に遭遇すると思います。ただし、開発者が CSI を正しく使用しない場合、この問題を特にうまく処理できない可能性があるため、この欠点は依然として簡単に発生すると思います。

CSIの欠点2: ページの読み込みを速くするために、ウェブサイトを静的にするために非常に多くの時間と労力を費やしています。ページの読み込みを2つのステップに分けているだけなので、本当に高速です。これは必ずしも真実ではありません。実際、動的と静的を分離する方法は、以前のシリーズで説明したデータベースの読み取りと書き込みの分離と似ており、読み取りと書き込みの関連付けを分割することで実現されます。元のテーブルの書き込み 読み取りのボトルネックの問題を解決するには、静的リソースは簡単に最適化できるため、Web ページを動的と静的に分離する必要があります。したがって、動的リソースと静的リソースを分離し、静的リソースを最適化しない場合、ページの読み込みを高速化するための操作が欠けていることが一目瞭然であるため、ページの読み込みが高速化できるかどうかを判断するのは非常に困難です。非同期読み込みには JavaScript コードの実行が必要ですが、静的リソースを読み込む場合、JavaScript スクリプトがブロックされる可能性が高く、ブロックされたスクリプトが非同期読み込み部分である場合、結果は以前よりも遅くなるだけです。

先ほど述べた SSI および ESI テクノロジは、ブラウザ側で CSI テクノロジを活用するために非常に必要であり、静的リソースと動的リソースを分離してより効率的にロードできることがわかります。これにより、CSI 操作の最初のステップも効率的になり、最初のステップが処理された後は、ページの非同期読み込みに対するスクリプトのブロックの影響を制御するだけで、全体の読み込み効率を向上させるという目的を達成できます。ページです。さらに、CSI が SEO に重大な影響を与えるというのは誤った命題だと思います。CSI の使用によって SEO の結果が悪くなる場合は、CSI 計画の設計が適切に行われていないと考えられます。

CSIには欠点があると考える人もいますが、これは実際には設計の問題であり、良いか悪いかは個人の操作習慣によって決まります。他の人が思うこの欠点は何ですか？ CSI テクノロジーを使用すると、ページの読み込みは速くなりますが、動的コンテンツ部分で読み込みプロンプトが表示される場合があり、実際にはこの同期読み込みと非同期読み込みのマッシュアップ操作がページの利便性の低下につながります。ほとんどすべての大きなポータル、電子商取引 Web サイト、および無数の Web サイトが同期と非同期の混合読み込み方法を使用している場合、これらの Web サイト (ホームページの読み込みなど) は間違いなくそうなると思います。ウェブページの多くはコンテンツが多すぎて、画像が少し圧倒されるため、同期と非同期の読み込み方法を組み合わせて使用​​する必要があるため、画像やフラッシュなどの多くの静的リソースでも、血を吐くほど遅いです。ロードメソッドも非同期になります。そうは言っても、ページの読み込み中に表示されるプロンプトが気に入らないと感じる人もいるかもしれません。しかし、Web ページでは CSI の利点が非常に必要です。この問題は簡単に解決できます。まず、CSI テクノロジを使用する意思がある場合は、ユーザーが非同期ロード テクノロジを使用する意思があることを意味します。それが気に入らない場合は、ロードのプロンプトが表示されます。これは、ユーザーが同期読み込み操作を実行するときに非同期操作を混在させたくないことを意味します。ajax テクノロジーは現在非常に普及していますが、ajax テクノロジーの同期読み込みを解決する方法はありません。つまり、ブラウザーに Web サイトの URL を入力します。したがって、上記の要件に直面して、必要なのは、この同期操作が 1 つだけであることを確認することだけです。非同期読み込みを行わずに純粋な同期操作を使用するだけです。この解決策は実装が簡単なので、ここでは説明しません。詳細はこちら。

動的と静的を分離した後、静的リソースをキャッシュします。前の記事ではサーバー側での静的リソースのキャッシュについて説明しました。CSI がブラウザー側に登場したので、ブラウザーについて話さなければなりません。キャッシュ操作。ページのキャッシュ操作は、HTTP の有効期限とキャッシュ制御を使用することです。まず次の記述を見てみましょう:

<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="cache-control" content="no-cache">
<meta http-equiv="expires" content="0">

これは、私が現在取り組んでいる Java Web プロジェクトの jsp ファイルと vm ファイルの両方で使用されるメタ構成です。その目的は、ブラウザによってページがキャッシュされるのを防ぐことですが、CSI テクノロジーが使用され、動的と静的分離がうまく行われると、実際にはページのヘッダーにこれを記述することができなくなります。ページが適切な時間範囲内でブラウザによってキャッシュされると、将来そのページにアクセスしたときの Web ページの読み込み効率が向上します。

ここには別の問題があります。Web サイトを最適化するための Yahoo の提案では、Web ページの並列読み込み特性を最大限に活用するために、画像、外部 JS ファイル、CSS ファイルを別の静的 Web コンテナーまたは CDN に配置することがよくあります。これらのファイルはブラウザによってキャッシュされることがよくありますが、ブラウザがキャッシュできるようにするにはどうすればよいでしょうか?ここでは、Apache を例として取り上げます。ブラウザで静的リソースをキャッシュできるようにするには、Apache で mod_expires モジュールを使用し、次の設定を Apache 設定ファイルに追加する必要があります。このApache、ブラウザ上の静的リソース サーバー上の画像、js、cssファイルはブラウザにキャッシュされます。

http 応答コードが 304 の場合、ブラウザはキャッシュからリソースを読み取ります。なぜキャッシュされたリソースに対して http リクエストが送信されるのか疑問に思う人もいるでしょう。これを理解するには、キャッシュの仕組みを理解する必要があります。キャッシュの意味は、一時的な保存であるため、有効期限が必要です。つまり、キャッシュの定義は http によって行われます。キャッシュの有効期限が切れているかどうかも http によって判断する必要があるため、キャッシュを使用するたびに、サーバーはリソースの有効期限が切れているかどうかを確認する必要があります。サーバーは 304 応答コードを返します。304 応答には http メッセージ本文が含まれていないため、この http 要求の戻りデータは非常に小さいため、サーバーがリソースの有効期限が切れていることが判明した場合でも、この http 効率は依然として非常に高くなります。実際、リソースの有効期限が切れているかどうかを検出するこのリクエストには、条件付き Get リクエストと呼ばれる正式な名前があります。サーバーがチェック操作を完了する方法については、このシリーズで Web フロントエンドの最適化について説明するときに詳しく説明するので、ここでは詳しく説明しません。これを見て、なぜブラウザ側でキャッシュの有効期限を判断できないのかという疑問を持つ友人もいるかもしれません。これは主に、ユーザーのコンピューターの時計が正確でない可能性があるため、ブラウザーのチェックが非常に不正確であるため、またはユーザーのコンピューターの時計がサーバーの時計と一致していないためです。タイムゾーンを追加すると、さらに面倒になるため、それが最善です。キャッシュされた有効期限の正確性を保証するために、サーバー上のキャッシュを無効化します。 html5 の登場により、ブラウザのキャッシュ機能が大幅に強化されましたが、私はキャッシュにおける html5 テクノロジの使用については詳しく調べていないため、ここでは説明しません。興味のある方はご自身で調べてください。

さて、CSI のテーマは終わりました。CSI テクノロジーとブラウザに関しては、このシリーズのもう 1 つの重要な内容を開始できます。これは、次の記事のトピックです。フロントエンドとバックエンドの分離については、ブログで何度も取り上げますが、今回は、私が長年にわたって研究してきたフロントエンドとバックエンドの分離についてのまとめです。