リンクする代わりにスタイル/スクリプトをHTMLに埋め込むのはなぜですか？

41

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つ少なくなりましたが、実際にはこの手法を見たことはありません。何故なの？

— グラッドストーン
ソース

12

キャッシングのせいだ。

98

HTTPリクエストの保存は、キャッシングを中断して達成する場合にはほとんど役に立たないためです。スタイルシートとスクリプトが別々に提供される場合、それらは非常にうまくキャッシュされ、非常に異なるページへの多くの多くのリクエストにわたって償却されます。同じHTMLページに表示されている場合は、毎回再送信する必要があります。シングル。要求。

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

1

単一ページのアプリスタイルのサイトを作成している場合、コードの大部分が1つのページに固有である場合、それはまだ意味をなすでしょうか。

— JohnB

3

ジョン：ページが1回だけアクセスされた場合、はい。複数回アクセスすると、すべての埋め込みコンテンツが1回だけではなく複数回送信されてキャッシュされます。

— コネラック

もう1つの良い注意点は、これらを個別に提供することで、リソースを小さくして、リソースのサイズを小さくできることです。

— maple_shaft

2

@maple_shaft詳細を説明してください。通常のようにリソースを縮小してから含めることができないのはなぜですか？

1

@JohnBは、ispでのCDNまたはローカルキャッシュの効果を忘れないでください。Googleのjavascriptに対する私のリクエストは、ローカルでキャッシュミスがあっても、Googleに届かない可能性があります。同じispを使用する別の人が既にispにデータをキャッシュさせるためです。

19

単にWebパフォーマンスが本当に重要だからです！ 99％倍にすると、エンドユーザーの応答時間が短縮されます。

Velocity Confのいくつかの例があります。

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

Webパフォーマンス最適化の先駆者であるSteve Soudersから、

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

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

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

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

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

— サイバーマックス-Betclic
ソース

3

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

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

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

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

— ブレンドン
ソース

2

興味深い答えですが、「レガシー」ではなく、現時点でインライン化しない理由は、現在のWebプロトコルインフラストラクチャに最適であるためです。HTTP / 2.0 / SPDYが完全にデプロイされているときに、誰もがn年後も同じことをしている場合はレガシーになります

— ;

2

引用を行ったり、計算をスケッチしたり、少なくとも「超高速」の球場番号を教えてもらえますか？文明化された最初の世界の国では、オンラインにかなりの金額を費やしている人（読む：顧客）は、1秒あたり数百メガバイト未満の帯域幅で閲覧することがあります。私の場合、3 MB / sを超えることはめったにありません。多くの場合、700 KB / s未満です。別のポイントとして、あなたはOPが示唆するような方法（実際には、あなたはその理由を与えるにインラインに理由を与えることはありませんしないように）、あなたはプロトコルを最適化するための理由を与えます。

1

私の3G接続は正確に「超高速」ではありませんし、私の電話代は不要なデータを認めません。忘れないでください-すべてのモバイルデータの使用がテザリングと3G対応のタブレット/ラップトップを備えた電話で行われるわけではありません。特にラップトップでは、ホームブロードバンド接続でのwifi / ethernetを想定しています。...リモートでテザリング時に認識されていなかっ

— AnonJr

3

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

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>

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

— JvR
ソース

1

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

すべてのスタイリングを分離することで、再利用と共有ファイルを有効にし、促進します。

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

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

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

— マイケル・デュラント
ソース

明確にするために、スタイルとコンテンツの分離は開発者に利益をもたらすのでしょうか、それともエンドユーザーのブラウザーのパフォーマンスに利益をもたらすのでしょうか？

会社にとっての全体的な利益は、通常、ビジネス用語でのリクエストの減少よりも大きな勝利であると言っています。

— マイケルデュラント

3

OPは、個別のファイルを使用して開発し、縮小、難読化、および「通常の」連結とともに、展開時にのみ連結することを提唱していることを理解していますか？保守可能なコードベースを取得し、パフォーマンス上のメリットも享受できます。これは、ソースコードの縮小や複数のJS / CSSファイルを1つに連結するなど、他のコードマングリング最適化の一般的な方法です。

私はそれを理解していません。「これらの連結されたスタイルとスクリプトをHTMLに埋め込む」という言葉。私を混乱させる。

— マイケルデュラント

明確にするために、彼のコメントで@delnanが私の代わりに明らかにしたことを提案するつもりでした。私の質問のフレージングがあいまいな場合は申し訳ありません。

— GladstoneKeep

1

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

— ナヤナ・アダスリヤ
ソース

0

HTMLにスタイル/スクリプトを埋め込むべきではありません。

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

これらのスタイルはブラウザでキャッシュできず、別のページで再利用できません。このため、できる限り最小限のCSS / JSを埋め込むことをお勧めします。

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

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

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

— プルビバロット
ソース