私たちのサイトでは、多くの jQuery を使用しています。現在、ベース ライブラリの上にある 340 行の jQuery コードを見ています。多すぎるとはどのくらいですか?さらに追加する予定ですが、いつコードを圧縮して最終的に OOP に移行しようとしますか?
9 に答える
行数は何の意味もありません。重要なのは、実際に何をしているかです。細心の注意を払って作成された 1000 行のコードよりもはるかに多くのダメージを与える 10 行の非常に非効率なコードを作成できます。
最適には、スクリプトのサイズをできる限り小さく保つ必要がありますが、今日の「Web 2.0」Web サイトでは、かなりの量の JavaScript コードが蓄積される可能性が高くなります。
重要なことは、Web サイトを展開する前に、スクリプト ファイルのサイズを可能な限り小さくするために、スクリプト ファイルを縮小およびgzipすることです。
Web サイトのパフォーマンスの最適化と改善に本当に関心がある場合は、Steve Souders のHigh Performance Web Sites: Essential Knowledge for Front-End Engineers をご覧になることを強くお勧めします。
どれだけ多すぎるかは、アプリケーションによって大きく異なります。
簡潔にするよう努めるべきですが、読みやすさやユーザー エクスペリエンスを犠牲にしてはなりません。
340 行では足りないので、いくつかのテレリック コントロールを使用してみてください...すぐに 15,000 行以上になります!
コード行よりもスクリプトの読み込み時間に注意を払います。ファイルが大きくなりすぎた場合は、ファイルをページまたはセクション固有のファイルに分割します。「多すぎる」は、アプリケーションのパフォーマンスと、ユーザーにとって許容できると見なされるもののみに基づいています。
取り組んでいるプロジェクトによって異なります。コードを効率的で読みやすいものに保つ必要があります。Web サイトをデプロイしたら、スクリプトを圧縮して gzip するだけで、パフォーマンスが向上します。
JavaScript の長さは気にしません。Packerを使用して JavaScript をリリース用に圧縮するなど、複数のオプションを利用できます(動作に関するいくつかのルールがあるため、いくつか練習する必要があります)。
コードが理解しやすく、保守が容易であることを確認することに重点を置いてください。Web サイトで JavaScript を頻繁に使用すると、急いで面倒なことになる可能性があります。
ページを短くしたり小さくしたりすることに気を遣うことは、ユーザーがページの読み込みに 1 秒余分に待たなければならない場合よりも、あなたを傷つける可能性があります。
開発では、コードを個別の .js ファイルに分離することが絶対に不可欠になります。そうしないと、面倒になります。
でも、
本番ページに大量のスクリプト参照を残さないでください。ほとんどのブラウザーでは、同時 HTTP 要求は 2 つに制限されています。これらのスクリプト参照は、ページの読み込みを遅くし、コンポーネントを個別にキャッシュすることの利点をはるかに上回ります。
JS Builder を使用して、開発ファイルを 1 つのファイルに連結できます。
http://code.google.com/p/js-builder/
編集: スクリプト参照とは、< script src="blah.js"> を意味します。ページの読み込み時に、これらのそれぞれを HTTP 経由で読み込む必要があります。
340 行の JavaScript はたいしたことではありませんが、JavaScript のコード ベースが大きくなるにつれて、JavaScript をその場で圧縮および連結するためのフレームワークを調べるのに時間を費やすことになります。Java を使用している場合は、 JAWRを使用することをお勧めします。これにより、開発モードでの複数の参照と、本番環境での単一の縮小されたスクリプトを切り替えることができます。ミニフィケーション アルゴリズムは、あいまいなケースでコードを台無しにする可能性があるため、本番環境に移行する前に必ずアプリをテストしてください (クリーンなコードを記述し、すべての行を ';' で終了することを忘れないでください)。 .
Java を使用していない場合、フレームワークについてはわかりませんが、似たようなものを自分で実装するのは実際にはそれほど難しくありません。PHPで書かれたeZ Publishでそれを行うためのコードがどこかにあると思います。