CSSやJavaScriptなどのWebアセットを縮小することを提案するのに、マークアップを縮小することを提案しないのはなぜですか?CSSとJavaScriptは、マークアップが毎回読み込まれる間、さまざまなページで使用できるため、マークアップの縮小がはるかに重要になります。
6 に答える
ここに書かれている答えは非常に時代遅れであるか、時には意味をなさないことさえあります。2009年の古いものから多くのことが変わったので、私はこれに適切に答えようとします。
簡単な答え-HTMLを確実に縮小する必要があります。今日は些細なことで、約5%のスピードアップが得られます。より長い答えについては、答え全体を読んでください
昔は、人々はcss / jsを手動で縮小していました(それを縮小するために特定のツールを実行することによって)。プロセスを自動化するのはちょっと大変で、確かにいくつかのスキルが必要でした。現在でも多くの高レベルのサイトがgzipを使用していないことを知っているので(これは些細なことです)、人々がhtmlの縮小に消極的だったことは理解できます。
では、なぜ人々はjsを縮小したのに、htmlは縮小しなかったのでしょうか。JSを縮小するときは、次のことを行います。
- コメントを削除
- 空白(タブ、スペース、改行)を削除します
- 長い名前を短い(
var isUserLoggedIn
にvar a
)に変更する
昔でもかなりの改善がありました。しかし、htmlでは、長い名前を短く変更することはできませんでした。また、その間、コメントすることはほとんどありませんでした。したがって、残ったのはスペースと改行を削除することだけです。これはほんの少しの改善しか与えません。
ここに書かれている間違った議論の1つは、コンテンツはgzipで提供されるため、縮小は意味がないということです。これは完全に間違っています。はい、gzipで縮小の改善が減少することは理にかなっていますが、コメント、空白を適切にトリミングして重要な部分のみをgzipで圧縮できるのであれば、なぜgzipでコメントする必要があるのでしょうか。これは、アーカイブするフォルダに、決して使用しないがらくたがあり、クリーンアップして圧縮するのではなく、単に圧縮することにした場合と同じです。
縮小を行うことが無意味であるもう1つの議論は、それが退屈であるということです。これは2009年に当てはまるかもしれませんが、この時間の後に新しいツールが登場しました。今のところ、マークアップを手動で縮小する必要はありません。Gruntのようなものでは、grunt-contrib-htmlminをインストールし、htmlを縮小するように構成するのは簡単です。必要なのは、うなり声を学び、すべてを構成するための2時間のようなものです。その後、すべてが1秒未満で自動的に実行されます。1秒( grunt-contrib-watchで何もしないように自動化することもできます)は、(gzipを使用しても)約5%の改善にはそれほど悪くないようです。
もう1つの議論は、CSSとJSは静的であり、HTMLはサーバーによって生成されるため、事前に縮小することはできないということです。これは2009年にも当てはまりましたが、現在、サーバーがシンでクライアントがすべてのルーティング、テンプレート、その他のロジックを実行しているシングルページアプリのように見えるサイトが増えています。したがって、サーバーはJSONのみを提供し、クライアントはそれをレンダリングします。ここには、ページとさまざまなテンプレートのHTMLがたくさんあります。
だから私の考えを終えるために:
- グーグルはhtmlを縮小しています。
- pageSpeedはhtmlを縮小するように求めています
- するのは簡単です
- 約5%の改善が得られます
- gzipと同じではありません
考えられる理由の1つは、マークアップは通常、はるかに頻繁に変更され、ページが読み込まれるたびに縮小する必要があることです。たとえば、特定のStack Overflowページには、ページの読み込みごとに変更される可能性のあるタイムスタンプ、ユーザー名、担当者数があります。つまり、ページの読み込みごとに縮小する必要があります。cssやjavascriptのような「静的」ファイルを使用すると、縮小する頻度がはるかに少なくなるため、一部の人にとっては、事前に作業する価値があります。
また、すべての主要なWebサーバーとブラウザーがgzipをサポートしていることも考慮してください。これにより、とにかくその場ですべてのマークアップが(すばやく)圧縮されます。ミニファイはとにかくgzipするよりも遅く、効果がはるかに低いため、ウェブマスターは、ページの読み込みごとにミニファイすることは処理コストの価値がないと判断する可能性があります。
このことを考慮:
HTML:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Demo</title>
<link rel="stylesheet" type="text/css" href="nonminify.css"/>
</head>
<body>
<div title="My non minifiable page">
<p class="http://www.example.com/classes/class/lorem-ipsum">
Lorem ipsum dolor sit amet, consectetur adipisicing elit,
sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris
nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in
reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
</p>
</div>
</body>
</html>
このcssファイルで:
div[title="My non minifiable page"]
p[class~="http://www.example.com/classes/class/lorem-ipsum"]
{
white-space:pre;
}
それを考えると、HTMLファイルしか見ることができないHTMLミニファイアが、安全にミニファイできるものを見つけることは事実上不可能です。
Page Speedは、マークアップを縮小することを推奨しています。
http://code.google.com/speed/page-speed/docs/payload.html#MinifyHTML
Doctypeによっては、書式設定に空白などが使用されることがあるため、難しいと思います。
最近、マークアップは動的に生成される傾向があり、静的な場合でも、通常は多数のページがあります。JavaScriptとCSSは通常、サイトごとに1つのファイルで縮小されるため、手動(またはスクリプト)で縮小する方がはるかに簡単です。