私は少し静的なHTMLを使用し、JavaScriptに依存してアプリケーションデータをJSONとしてロードし、そこから動的にWebページ要素を作成する小さなWebアプリケーションに取り組んでいます。
最初の質問:これは根本的に悪い考えですか?サーバーサイドでのHTMLの生成を完全に不要にするWebサイトとWebアプリケーションの数は不明です。 (JSのみのWebアプリには、優雅な低下/漸進的な機能強化と検索エンジンに優しいという点で明らかな欠点がありますが、これらがこの特定のアプリの問題であるとは思いません。)
2番目の質問:静的HTML、JS、CSSを管理する最良の方法は何ですか?私の「開発ビルド」では、縮小されていないサードパーティのコード、整理を容易にするための複数のJSおよびCSSファイルなどが必要です。「リリースビルド」では、すべてを縮小し、連結する必要があります。サーバー側でHTMLを生成する場合、Webフレームワークで、開発とリリースの異なるHTMLを生成するのは簡単です。しかし、私は静的HTMLしか実行していないことを考えると、これを管理する最良の方法は何ですか? (私は [〜#〜] erb [〜#〜] またはPerlと一緒に何かをハッキングできることを理解していますが、標準的な解決策があるかどうか疑問に思っています。)
特に、サーバー側のHTML生成を行わないため、静的HTMLを設定する簡単で準標準的な方法があります。次のようなコードが含まれていること
<script src="js/vendors/jquery.js"></script>
<script src="js/class_a.js"></script>
<script src="js/class_b.js"></script>
<script src="js/main.js"></script>
開発時および
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>
<script src="js/entire_app.min.js"></script>
リリース用?
少なくともJava webappsの場合)、必要なものの一部を実行しているように見えるツールの1つは、 Webリソースオプティマイザーfor Java (wro4j)です。
フリーでオープンソースのJavaほとんどすべての最新のWebツールをまとめたプロジェクト:JsHint、CssLint、JsMin、Google Closureコンプレッサー、YUI Compressor、UglifyJs、Dojo Shrinksafe、Css変数サポート、JSON圧縮、 Less、Sass、CoffeeScriptなど、同時に、アプリケーション固有のニーズに簡単に適合させるために、可能な限りシンプルで拡張可能なものにすることを目的としています。
Webアプリケーションの読み込み時間を簡単に改善します。プロジェクトのWebリソース(jsとcss)を適切に整理し、マージして、実行時(単純なフィルターを使用)またはビルド時(mavenプラグインを使用)に縮小し、Webリソースを処理するときに役立つ可能性のある多数の機能を備えています。 。
RequireJS をチェックして、特定の環境でクライアントがダウンロードする必要があるjsファイルを定義するのに役立つかどうかを確認することもできます。
RequireJSはJavaScriptファイルおよびモジュールローダーです。ブラウザー内での使用に最適化されていますが、RhinoやNodeなどの他のJavaScript環境でも使用できます。 RequireJSのようなモジュラースクリプトローダーを使用すると、コードの速度と品質が向上します。
指定したように、この特定のケースでJavaScriptを無効にしたユーザーと検索エンジンをサポートすることが重要でない場合、私が目にできる唯一の欠点はmightパフォーマンスである。
mightを意図的に使用しています。
理論的には:
サーバーはクライアントよりもはるかに強力であり、
サーバー側の言語はJavaScriptよりも高速で、
一方、実際には:
あるものは別のものよりも速くあるべきだという開発者のほとんどの信念は間違っています。プロファイラーだけが真実を知っています。
一部のホスティングプロバイダーが最も高価なオファーを除くすべてのコンピューターを使用するコンピューターよりもはるかに高速なコンピューターを使用している人はたくさんいると思います。
JavaScriptが10年前に遅くなった場合は、通常のブラウザの最近のバージョンではもはや当てはまりません。 IEでさえ、JavaScriptは最新バージョンではかなり高速です。
HTMLの代わりにJSONのみを送信することで、帯域幅の使用量を減らすことができます(これが特定のケース、使用するキャッシュテクニックなどに大きく依存する場合でも)。
縮小化についての質問と、実行時に実行できないことについては、アプリケーションをサーバーにデプロイするときに実行してください。たとえば、ステージング環境でアプリをテストしたり、本番環境にデプロイしたりする前に、JavaScriptコードを Closure Compiler で変換し、同様のツールでCSSを縮小します(または [〜#〜 ] less [〜#〜] これが当てはまる場合、縮小されたCSSに)など.
このプロセスも簡単に自動化できます。
難しいのは、HTMLコードを変換して、複数のCSSまたはJavaScriptファイルへの呼び出しを、1つの縮小されたCSSと1つの縮小されたJavaScriptへの呼び出しに置き換えることです。テンプレートを使用したくないため(たとえば、 [〜#〜] ssi [〜#〜] を使用できますが、ローカルサーバーなしでローカルにアプリを使用することはできません)汚いハックは、デプロイする前にHTMLコード自体を変更することです。
警告:汚いハック。
あなたが持っているとしましょう:
<!--Start calls to JavaScript-->
<script src="js/vendors/jquery.js"></script>
<script src="js/class_a.js"></script>
<script src="js/class_b.js"></script>
<script src="js/main.js"></script>
<!--End calls to JavaScript-->
ソースHTMLおよび
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>
<script src="js/entire_app.min.js"></script>
js-compact.txt
。
自動化ツールは、<!--Start calls to JavaScript-->
と<!--End calls to JavaScript-->
を検索し、コメントを含むブロック全体を削除してから、js-compact.txt
の内容で置き換えることができます。
より複雑なバージョンでは、HTMLを解析し、JavaScriptへのすべての呼び出しを見つけて削除し、それらを縮小コードへの呼び出しに置き換えることができます。
小さな静的HTMLを使用し、JavaScriptに依存してアプリケーションデータをJSONとしてロードし、そこから動的にWebページ要素を作成する小さめのWebアプリケーション。
これには何の問題もありません。ほとんどのGmailはこの方法で機能します。少量のデータの周りに多くのHTMLがある場合の最適化手法として、JavaScriptから意図的にページを作成します。
注意すべき点の1つは、クライアント側でセキュリティを実装できないことです。一部のセキュリティ(入力検証やエラーメッセージなど)がクライアント側で複製されている場合でも、すべてのセキュリティはサーバー側で行う必要があります。
誰でも何でも編集できるWikipediaでも、すべてのアクティビティを追跡し、バックアップを作成して、変更を簡単に取り消すことができます。また、匿名ユーザーが新しい記事を作成することもできなくなります。アプリケーションが更新を行う場合は、権限を制御するサーバー側コンポーネントが必要です。このコンポーネントには、ほぼ確実に、特定の要求に対してシステムを使用しているユーザーを追跡する方法が必要です。悪意のあることをしたクライアントをだれでも作成できるため、これはクライアント側を信頼できるものではありません(具体的には、マシンにコードを持っています)。
「無駄にしたくない」は、CSSおよびJavaScript圧縮への私の最初のアプローチでしょう。ダウンロードする最初の画像は、CSSとJavaScriptを合わせたものよりも大きくなる場合があります。 HTTPSを使用している場合、HTTPSはブラウザーのキャッシュを無効にし、サーバーへの1つの要求を保存するため、CSSとJavaScriptをすべてのページに組み込む方が高速です。それでも、フレームに一般的なルーチンを配置し、parent.myMethod(x)
として各ページから呼び出すことができます。 HTTPの場合、ブラウザがキャッシュする個別のファイルに、一般的なJavaScriptとCSSを配置できます。私は圧縮ツールを使用して、他のすべてが最先端のときと同じように最適化し、その後、ページの作成のタイミングを調整して、違いが確実にもたらされるようにします。
毎回のリターン}
は、圧縮されたCSSを非常に読みやすくします。時にはオプションの最後の末尾;
追加の属性を追加するときのバグを防ぎます。多くの属性を必要とするスタイルでは、改行を追加できますが、不要なスペースはありません。これにより、圧縮ユーティリティを使用しなくても、可能な最大圧縮の95〜98%が得られます。
JavaScriptに注意する場合は、同じページの作成に使用されるHTMLよりも小さくする必要があります。読みやすいままにしておきます。スペースの代わりにタブを使用するか、一度に2つのスペースをインデントします。空白はコードの20%以上を占めません。たぶん、読みやすい変数名がさらに5%増加します。バグがあると、何をしているのかを簡単に確認できるので、少しだけ余分なサイズを追加する価値があります。
速度低下の最も一般的な理由は、サーバー側の問題と画像のダウンロードです。クエリを最適化すると、ページの読み込みが30秒以上から1秒未満に短縮されます。それがゲームでなければ、1秒未満の合計応答時間に人々はそれほど敏感ではありません。また、ほとんどの人のインターネット接続は、1/2秒未満の応答時間では信頼できません。そのため、確実に収益が減少するポイントがあります。コードを完全に読めなくして、0.01秒の処理時間を短縮することは価値がありません。また、サーバーは圧縮に0.005秒かかる場合があるため、事前に圧縮するか、CSSとJavaScriptをオンザフライで圧縮する動作が圧縮によるパフォーマンスの向上に影響を与えないことを確認してください。