web-dev-qa-db-ja.com

リンクの代わりにスタイル/スクリプトをHTMLに埋め込んでみませんか？

CSSファイルとJavaScriptファイルを連結してHTTPリクエストの数を減らし、パフォーマンスを向上させます。結果は次のようなHTMLになります。

<link rel="stylesheet" href="all-my-css-0fn392nf.min.css">
<!-- later... -->
<script src="all-my-js-0fn392nf.min.js"></script>

これをすべて行うサーバー側/ビルドロジックがある場合は、さらに一歩進めて、それらの連結されたスタイルとスクリプトをHTMLに埋め込みませんか？

<style>.all{width:100%;}.my{display:none;}.css{color:white;}</style>
<!-- later... -->
<script>var all, my, js;</script>

これはHTTPリクエストが2つ少なくなりますが、実際にはこの手法を見たことがありません。何故なの？

javascripthtmlcssfront-end
41
GladstoneKeep

HTTPリクエストを保存することは、キャッシュを壊してそれを達成する場合にはほとんど役に立ちません。スタイルシートとスクリプトが別々に提供される場合、それらは非常によくキャッシュされ、非常に異なるページへの多くの多くのリクエストに渡って償却できます。それらが同じHTMLページに詰め込まれている場合、それらはすべてとともに再送信される必要があります。シングル。リクエスト。

たとえば、このページのHTMLは現在13 KBです。 180 KBのCSSがキャッシュをヒットし、360 KBのJSもキャッシュをヒットしました。両方のキャッシュヒットにかかる時間はわずかであり、実質的に帯域幅を消費しませんでした。ブラウザのネットワークプロファイラを取り出し、他のいくつかのサイトで試してみてください。

98
user7043

単純にWebパフォーマンスが本当に重要なためです！99％倍にすると、エンドユーザーの応答時間が速くなります。

Velocity Confのいくつかの試験問題を以下に示します。

  • Bing– 2秒遅いページの結果、ユーザーあたりの収益が4.3％減少しました。
  • Google– 400ミリ秒の遅延により、検索/ユーザーが0.59％減少しました。
  • Yahoo！ – 400ミリ秒のスローダウンにより、ページ全体のトラフィックが5〜9％減少しました。
  • Shopzilla–サイトを5秒高速化すると、コンバージョン率が7〜12％増加し、検索エンジンマーケティングのセッション数が2倍になり、数値が削減されました必要なサーバーの半分。
  • Mozilla–ランディングページから2.2秒の時間を節約することで、ダウンロードコンバージョンが15.4％増加しました。これにより、Firefoxのダウンロードが年間6,000万回増えると予測されています。
  • Netflix–単一の最適化、gzip圧縮を採用した結果、13-25％高速化し、送信ネットワークトラフィックを50％削減しました。

Webパフォーマンス最適化のパイオニアであるSteve Soudersから、

エンドユーザーの応答時間の80〜90％はフロントエンドで費やされます-最初にここから始めます。

JavaScriptファイルとCSSファイルはブラウザ/ネットワーク/プロキシ（キャッシュヘッダー付きのHTTPプロトコルで定義されている）によってキャッシュされるため、外部ファイルを使用するとより高速なページが生成されます。 HTMLドキュメントにインライン化されたJavaScriptとCSSは、HTMLドキュメントが要求されるたびにダウンロードされます。これにより、必要なHTTP要求の数は減りますが、HTMLドキュメントのサイズは大きくなります。 Jqueryのようなスクリプトを使用している場合、300 KBのスクリプトを参照するのは簡単であり、誰もが100 MBits/sの帯域幅と低遅延で、単一のアプリケーション（ブラウザ）を実行しているとは信じていません。 99％倍になり、エンドユーザーの応答時間が短縮されます。

リクエストされたHTMLドキュメントの数に対して、外部のJavaScriptおよびCSSコンポーネントがキャッシュされる頻度も重要です。サイトのユーザーがセッションごとに複数のページビューを持ち、多くのページで同じスクリプトとスタイルシート（バンドル）を再利用する場合、キャッシュされた外部ファイルから得られる潜在的なメリットが大きくなります。

ただし、インライン化は、セッションごとに1つの単一ページビューを使用する単一ページアプリケーションまたはWebサイトに-時--適しています。ゴールデンルールはありません。主にエンドユーザーのパフォーマンスに実際に関与している非常に特定のWebサイトに関係しているため、通常は忘れてください。

あなたは読むことができます ここ パフォーマンスが重要な理由（免責事項：私は著者です）

19
Cybermaxs - Betclic

HTTPの最新バージョンは1999年に作成されました。1999年に、everybodyがダイヤルアップでインターネットに接続しました。インターネットは非常に遅いものでした。 16年後、状況は大きく変わりましたが、私たちが使用するプロトコルは変わっていません。

「キャッシングに干渉するため」インライン化すべきではないという答えは、特に超高速インターネットの時代において、少し誤解を招くものです。実際に計算を行う場合、インライン化した場合、キャッシュウォームユーザーとキャッシュコールドユーザーの読み込み時間にはほとんど違いがありません。そこにがあるという事実は、インライン化したからではなく、HTTP/1.1の柔軟性のない設計のためです。

SPDYプロトコルはサーバープッシュと呼ばれるものを実装します。これは基本的に、HTMLドキュメント自体からインライン化し、プロトコルに組み込みます。インテリジェントサーバーは、クライアントが既に持っているリソースを認識します。ダムサーバーは、関係なくすべてを送信するだけです。それでもパフォーマンスは向上しますが、帯域幅の点でコストがかかる可能性があります。ブラウザのコンテンツがキャッシュにある場合は、受信したコピーを破棄できます。サーバーは、追加のリソースを送信する前に、HTMLが読み込まれるまで待機します。理論的には、ブラウザーはサーバーのプッシュをキャンセルする信号を送信できます。

HTTP/2.0はSPDYに基づいており、サーバープッシュを実装する可能性が最も高いですが、理論上は今日からSPDYの使用を開始できます。したがって、インライン化しない本当の理由は、レガシーの1つです。現在存在するプロトコルは古く、「プロトコルレベルのインライン化」を実現するのに十分な柔軟性を備えていません。

3
Brendon

他の回答が提起するキャッシングと取得の懸念に加えて、私は別の、より曖昧な問題を強調したいと思います：解析。

HTMLに表示されるJavaScriptは、次の例のように、解析の問題に遭遇する可能性があります。

<html>
<head>
<script>
function myfunc() {
    if ("</style> isn't a problem")
        return "but </script> is"
}
</script>
<style>
body::after {
  content: '</script> is okay, but not </style>'
}
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

...つまり、HTMLでトリガーされる一部の文字をエスケープするには、スクリプトを変換する必要があります。 CSSとJavaScriptを外部リソースとして提供すると、「親」解析コンテキストを考慮する必要がなくなるため、この問題はなくなります。

コンテンツをXMLとして提供する場合は、CDATAセクションを使用することでこれを回避できます。ただし、CDATAにも同様の問題があります。

<?xml version="1.0" encoding="utf-8"?>
<html>
<head>
<script>
// <![CDATA[
function myfunc() {
    if ("</script> is no longer a problem")
        return "but ]]> is"
}
// ]]>
</script>
<style>
<![CDATA[
body::after {
  content: 'same ]]> issue here'
}
]]>
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

ライナーは注意してください。

3
JvR

プレゼンテーションのスタイルからコンテンツを分離することは、通常、少ないHTTPリクエストよりも大きな利点です。

すべてのスタイルを分離することで、ファイルの再利用と共有が可能になり、奨励されます。

また、ファイルのコンテンツはより静的になり、サーバーとクライアントの両方で、そのページとアクセスした他のページの両方のキャッシュに使用できます。

ただし、特定の質問については...サーバー自体が最小化を行うように作成されている場合、資産の維持と問題のデバッグが難しくなります。ただし、多くのフレームワークはこれをファイルレベルで実行します。すべてのcsおよびすべてのjs。たとえば、Ruby on Railsフレームワークは、資産を生産用に最小化します。通常、5〜10の追加のHTTPリクエストはボトルネックではなく、100 + httpリクエスト（画像でよく取得する）。

ページ自体にコードを実際に含めるという追加の手順には、ダウンロードシーケンスを慎重に管理する必要がある大きなページと、残りの（現在は大きな）ページがなければコンテンツを頻繁に表示できないという欠点があります。ダウンロード中。

1
Michael Durrant
  1. 重複するコーディングを最小限に抑えます。時間を節約します（1ページにコーディングされたスタイルとJS関数を再利用できます）。
  2. 変更の労力を最小限に抑えます。 （クライアントからWebサイトのボタンの色を変更するように求められた場合は、1ページずつ移動する必要があります）。
  3. 読み込み時間を短縮します（CSSとJSが重複している場合、個々のページのサイズが大きくなり、ダウンロードに時間がかかりますが、一般的なCSS JSを何度もダウンロードする必要はありません）。
  4. リモートでの使用。 （共通のCSS js JSを離れた場所に配置できます。同じホストサーバーではありません）
  5. バグ修正時間を短縮します。 1つの関数にバグがある場合は、ページごとに移動して、埋め込みJSおよびCSSのバグを修正する必要があります。
  6. SEOを向上させる（コンテンツをメタデータで単純に分離する）
  7. よりクリーンでわかりやすいコード（すべてを1つのファイルに組み込んだ場合、デバッグとコードの明確さがなくなり、各ページは非常に長いページになります）。
  8. さらに、これは製品のサイズを小さくするのに役立ちます。
  9. しかし、それでも、同じページに最もユニークなものを埋め込むことを検討できます。
1
Nayana Adassuriya

スタイル/スクリプトをHTMLに埋め込まないでください

ページリクエストごとに埋め込みスタイル/スクリプトをダウンロードする必要があります：

これらのスタイルをブラウザでキャッシュして、別のページで再利用することはできません。このため、できるだけ少ない量のCSS/JSを埋め込むことをお勧めします。

リンクを使用してcss/scriptsをバインドする場合は、代わりにリンクcozを使用します

複数のページリクエストでサイトの速度が向上します：

人が最初にWebサイトにアクセスすると、ブラウザは現在のページのHTMLとリンクされたCSSおよびJSファイルをダウンロードします。別のページに移動した場合、ブラウザは新しいページのHTMLをダウンロードするだけで済み、CSS/JSファイルがキャッシュされるため、再度ダウンロードする必要はありません。これは、特にスタイルとスクリプトファイルが大きい場合に大きな違いを生む可能性があります。

0
Purvi Barot