web-dev-qa-db-ja.com

HTML / CSS / JS最適化プロセスのガイドライン

現在、HTML/CSS/JSコードを記述する開発サーバーがあります。コンプレッサー/ミニファイアを使用してコードを最適化することはありません。したがって、開発から本番へのデプロイプロセスは、開発サーバー上のファイルを本番サーバーにコピーするだけです。

しかし今、私たちはコンプレッサー/ミニファイアーを使用することを計画しています。私たちは従うべきプロセスについて混乱しています。現在、common.jsと呼ばれる単一のJSファイルとcommon.cssと呼ばれる単一のCSSファイルを使用しています。また、reset.css、common.cssなどの複数のCSSファイルをDevで使用することを計画しており、それらを本番環境にデプロイするときに、それらを1つのCSSファイルに結合します。

私が考えることができる最も簡単なプロセスは次のとおりです。

  1. 開発サーバー上の開発ファイルの正確なコピーを作成します。以降の手順でコピーを使用します。
  2. すべてのCSSファイルを1つのCSSファイル（common.cssなど）に結合します。 JSファイルと同じです。 reset.cssなどの他のファイルを削除します。
  3. Common.cssとcommon.jsをcommon.min.cssとcommon.min.jsに圧縮/縮小します。 common.cssとcommon.jsを削除します。
  4. すべてのHTMLファイルで、common.cssとcommon.jsを除くすべてのリンクタグとスクリプトタグを削除します
  5. すべてのHTMLファイルで、スクリプトsrcを変更し、hrefをcommon.jsからcommon.min.jsに、common.cssをcommon.min.cssにリンクします。
  6. すべてのファイルを本番サーバーにコピーします。
  7. コピーを削除する

これは私たちには退屈すぎるように見えます。より良いプロセスは何でしょうか？最適化（上記の手順）を自動的に実行できるツールはありますか？上記のすべての手順を実行するスクリプトを作成することはそれほど難しくないようです。しかし、自分で開発するのではなく、既存のツールを使いたいと思います。そのようなツールが存在しない場合にのみ努力したいと思います。

また、テストは一般的にいつ実行されますか？最適化されたファイルで実行する必要があると思います（コンプレッサーにバグがある場合に備えて）。ただし、Test-Bugfixサイクルごとに上記のプロセスを繰り返す必要があるため、このプロセスはより面倒になります。

web-developmentjavascripthtmlcssoptimization
2
Cracker

私はあなたの状況に非常に近いプロジェクトに取り組みました。要件は次のとおりです。

  1. 開発側では、各ページに1つまたは複数のJavaScriptファイルと1つまたは複数のCSSファイルを含めることができます。これらのファイルはすべてローカルです。
  2. 本番環境では、JavaScriptファイルとCSSファイルが1つだけ存在する必要があります。これらの2つのファイルは、離れたサーバーでホストされ、静的ファイル用に最適化され、クライアント側とサーバー側のキャッシュ用に構成されています。
  3. 各ページには、開発環境と本番環境の両方でGoogleCDNでホストされているJQueryへのリンクがあります。
  4. 展開プロセスは自動化する必要があります。
  5. デプロイメントプロセスでは、圧縮のためにJavaScriptファイルとCSSファイル以外のファイルを変更してはなりません。
  6. WebサイトはASP.NETで記述されています。
  7. ウェブサイトのすべてのページは同じCSSと同じJavaScriptを使用しています。
  8. 開発側では、CSSファイルとJavaScriptファイルは常に特定の事前定義されたディレクトリにあります。

ここでは、プロジェクトのこの部分に取り組んだ同僚が行ったことを説明します。

  1. JQueryを除くすべてのファイルは縮小され、g.cssとg.js、g for globalの2つのファイルに結合されます。これは、特定のディレクトリをたどってそれらのファイルを検索するだけで実行できます。それらを縮小した後、最後の展開以降に変更された場合、2つのファイルは静的コンテンツサーバーに送信されます。
  2. 展開時にのみ実行する方法が見つからなかったため、プロセスはすべてのビルドで実行されます。結局のところ、すべてのファイルをウォークスルーして、最後のビルド以降に変更されたかどうかを確認するのに数ミリ秒かかるため、問題ではありません。
  3. 元のJavaScriptファイルとCSSファイルを除いて、Webサイトはそのまま展開されます。本番環境では必要ありません。
  4. マスターページ（ASP.NET内）には、コンテキストに応じてJavaScriptファイルとCSSファイルへの呼び出しを調整する特定のメソッドが含まれています。

この方法は次のようなものです。

public string MakeCssCalls(IList<string> cssFiles)
{
    // ...
}

開発環境では、cssFiles引数内のCSSファイルへのリンクを返しました。本番環境では、この引数を無視し、"<link rel="stylesheet" href="http://static.example.com/g.css" type="text/css" />"を返しました。マシン名をWeb.configファイル内の名前のリストと比較することにより、本番と開発の違いを生み出しました。一部のマシンは開発マシンとして構成されました。このリスト外のすべてのマシンは、実稼働サーバーと見なされました。

パフォーマンス面では、本番用に別のWeb.configファイルを用意する方が賢明です。これは、実際に本番環境にあることを示します（たとえば、静的サーバーへの正確なリンクをこれらのファイルで正確に評価します。ハードコーディングされていたので、それは最悪です）。このプロジェクトの要件の1つは、すべての環境に対して単一のWeb.configファイルを用意することであったため、この方法では実行できませんでしたが、可能であれば実行してください。

また、テストは一般的にいつ実行されますか？最適化されたファイルで実行する必要があると思います（コンプレッサーにバグがある場合に備えて）。

縮小されていないバージョンのファイルでWebサイトをテストしました。 Google Closure（または自家製のくだらないCSSミニファイア）からバグが発生したことはありません。

2
Arseni Mourzenko

Apacheで実行している場合、（私の経験では）優れたソリューションは mod_pagespeed です。これは、ページを自動的に分析し、CSS/JSファイルと画像を縮小、インライン化、圧縮するApacheプラグインです。また、適切なCache-Controlヘッダーを確実に取得し、並列サイズのダウンロードもサポートします（サーバーを指すように複数のホスト名を設定した場合）。

基本的に、それはあなたのために「難しい」仕事の多くを自動的に行います。

もちろん、欠点はサーバーに少し余分なCPU負荷がかかることです（すべてのHTMLを分析/再書き込みする必要があるため）が、私の経験では、ほとんどのWebサーバーはCPUにバインドされていないため、これは許容範囲です。 。

0
Dean Harding