Rubyでサイトの読み込み時間を最適化するにはどうすればよいですか?

Question

私は、RoR を使用して Cake php フレームワークで書かれた軽量の写真ショーケース サイトを作成している初心者です。写真の表示とトランジション効果には、Scriptalicious ライブラリの効果と jQuery を使用する予定です。

サイトには写真が豊富に含まれるため、すべての写真やその他のページを迅速に読み込むにはどのようなプログラミング手順を実行できますか?

Answer 1

あなたは少し物事を混同していると思います。php/cake と混ぜるのはどうでしょうか？

それで、パフォーマンスについて。それは主に、何人のユーザーがいると考えているか、そのユーザーが誰で、何をしているかによって決まります。1時間あたり10回ですか、それとも1秒あたり100回ですか?画像を長時間見ているのでしょうか、それともページからページへと素早く移動しているのでしょうか?

ここでは、あまり技術的ではないヒントをいくつか紹介します。サーバー構成の最適化や memcached などはありません。常識を持ってパフォーマンスについて考え始めてください。それは聖杯ではありません。

• あなたのサイト/アプリケーションは遅すぎますか? ほとんどの場合、そうではありません。スピードを上げることに問題はありませんが、多くの場合、人々はパフォーマンスを気にします 過度に. 。常に覚えておいてください:それは速いということではなく、あるということです 十分に速い. 。ミリ秒が余分にあることに誰も気づきません。ページの読み込みに 1 秒かかる場合は 50% の高速化が顕著ですが、100 ミリ秒しかかからない場合はほとんど意味がありません。

• サイトが遅いかどうかを確認するには、 基準 それ。これを行う方法はたくさんありますが、そのうちの 1 つは自動化されたものです。 ab (Apache ベンチマーク)。サイトに接続する多数のユーザーをシミュレートし、応答までにかかった時間を適切に要約します。もう一つは:これを使って。ローカルネットワーク内ではありません。速度が遅いと感じたら、何かをしてください。

• 写真ショーケースは画像に大きく依存します。画像が大きいです。したがって、サーバーに十分な容量があることを確認してください 帯域幅 早く届けるために。

• 画像を拡大縮小する場合 (その可能性は非常に高いですが)、ページリクエストごとに画像のサイズを変更しないでください。 キャッシュ 拡大縮小した画像です！サムネイルもキャッシュします。すべてをキャッシュします。静的ファイルの処理と配信は、すべての処理を常に実行するよりもはるかに安価です。

• 画質を考えてください。画質よりも短納期が重要ですか？で遊んでみてください 画像サイズ - 圧縮率が向上すると、ファイル サイズが小さくなり、品質が低下し、配信が速くなります。

• について考える 使いやすさ. 。サムネイル ページがない場合、ユーザーはライブラリ内を順番に移動して、見たくない写真をたくさん見なければなりません。すでに画像が表示されている場合は、重要な画像に直接ジャンプできます (帯域幅の使用量と 1 秒あたりのリクエストが削減されます)。flickr について考えてみましょう。表示される画像のサイズ...それらは幅 500 ピクセルのスタンプのようなものですが、それでも人々は満足しています。より大きなバージョンが必要な場合でも、「すべてのサイズ」リンクをクリックします。

• トリック、トリック、トリック:以前は、ユーザーがモードを使用してサーフィンすると、低解像度/高圧縮の画像が転送されることがあったため、ユーザーは短時間で何かを得ることができました。最初のイメージがロードされた後にのみ、より大きなバージョンが開始されます。現在ではほとんどのユーザーがブロードバンドを利用しているため、追加の画像を送信することは単なる追加の作業負荷であるため、これはもはや一般的ではありません。

• について考える 聴衆. 。彼らは 14.4k モデムまたはブロードバンドを使用してサイトにアクセスするつもりですか?彼らはサイトの読み込みが遅いことに慣れていますか（写真家はおそらく慣れているでしょう）？統計をチェックしてそれらについて調べてください。

• あなたの バックエンドスクリプト言語 それはおそらくあなたの問題ではありません。たとえば、C、Java、ocaml と比較すると、php も実際には速くありませんし、ruby もそれほど高速ではありません。フレームワークは、手作業で作成され、最適化されたコードよりも遅くなります。コードをデバッグして、遅い部分がどこにあるかを確認します。私の推測？画像のサイズ変更とデータベースへのアクセス。これは、別の言語に切り替えたり、コードを最適化したりしても変わりません。

ウェブサイトの速度について

多くの要因が関係しています。そのうちのいくつかは次のとおりです。

1. サーバー側の処理:アプリケーションは高速ですか、ハードウェアは高速ですか?

2. 配達：リクエストとファイルがクライアントからサーバーに、またはその逆に転送される速度はどれくらいですか?(帯域幅に応じて)

3. クライアント側のレンダリング:ブラウザの速度はどのくらいですか? 実行する必要がある作業量はどれくらいですか?

4. ユーザーの悩み:クライアントはスピードを必要としているのでしょうか？場合によっては、遅いページが問題にならない場合もあります。例:クリックせずにそこで長い時間を過ごした場合。Flash ゲーム サイトについて考えてみましょう。Flash ゲームを 1 時間プレイしたとしても、ページが 3 秒で読み込まれるか 5 秒で読み込まれるかにはおそらく気付かないでしょう。

知覚される速度 (4 つすべてを組み合わせたもの) が重要な指標です。

本当に遅すぎることがわかった場合は、必ず適切な部分を最適化してください。サーバーが十分に高速である場合、サーバー側スクリプトの最適化は役に立ちませんが、ページがブラウザーで表示されるのに時間がかかります。帯域幅が詰まっている場合でも、レンダリング時間を最適化する必要はありません。

最適化に関して

パフォーマンスはアプリケーションを構築する際に不可欠な部分です。本当に高速なものが必要な場合は、最初から速度を計画する必要があります。速度を重視して設計されていない場合、多くの場合、効果的な最適化は不可能です。

Web アプリは水平方向に簡単に拡張できるため、これは必ずしも当てはまりません。つまり、次のことを意味します。それにハードウェアを投げます。
何事にもお金がかかります。あなた（またはあなたの上司）にとってお金が重要なら、それを忘れないでください。アプリケーションの 2 週間の最適化にはどれくらいの費用がかかりますか?たとえば、最適化にはあなた (またはあなたの上司) X ユーロ (私はヨーロッパ人です) の給与がかかります。ここで、別のサーバーの購入を検討してください。費用は Y ユーロ (セットアップを含む) です。Y < X の場合は、サーバーを購入するだけで問題ありません。

ランダムな流行語

最後に大事なことを言い忘れましたが、ランダム (順序なし) の流行語をいくつか紹介します。何か役立つかもしれません。グーグルで調べてください。役立つはずです...

コンテンツ配信ネットワーク、(インテル) SSD、スプライト (リクエストを保存するための画像の結合)、ページ圧縮 (gzip、deflate)、memcached、APC (PHP のバイトコード キャッシュ)、複数の CSS ファイルと JS ファイルの縮小とマージ、HTTP の意識的な処理ステータス コード (変更なし)、静的コンテンツと動的コンテンツの分離 (異なるサーバーとドメイン)、AJAX による段階的な読み込み (重要なコンテンツが最初)、...

もうアイデアが尽きました。

編集/更新

忘れたもの/テクニック:

• プログレスバーまたはそれに相当するものを実装して、ユーザーが少なくとも何かが起こっていることを感じられるようにします。JavaScript のみを使用している場合はプログレスバーを使用できませんが、少なくとも何らかのアニメーションの砂時計や時計を表示する必要があります。Flash を使用すると、実際の進行状況バーを表示できます。

• AJAX またはフラッシュを使用すると、完全なページのリロードをスキップできます。必要なデータのみをロードします。これは Flash イメージ ギャラリーで実装されているのをよく見かけます。画像と説明をロードするだけです。

• プリロード:ユーザーが 1 つの画像を長時間見ている場合、すでに次の画像の読み込みを開始できるため、ユーザーが継続するとブラウザーにキャッシュされます。

免責事項

私はパフォーマンスが重要なアプリを実装したことはありません (2 つの例外を除いて)。そのため、上に書いたことのほとんどは推測と他の人の経験です。今日あなたは、成功したスタートアップと、1 日のユーザー数が 100 人から数十億人に増加する状況にどのように (パフォーマンス面で) 対処したか、そしてそれらすべての問題を常に解決するために気の利いたトリックをどのように使用したかについての記事を読んでいます。
でもそれがあなたに起こるでしょうか？おそらくそうではありません。誰もがそれについて話しますが、実際にそれを必要とする人はほとんどいません （でも、知っておくと良いことは認めます）.

私の現実世界での経験 (はい、私は長い答えを書くのが好きです):

かつて私は、CMS (typo3) を使用し、単一の専用サンプルサーバー (中古の 10 年前の Solaris サーバーを思い浮かべてください) で実行されている、1 日に数千人のユニーク訪問者がいる Web サイトの一部を作成したことがあります。 GHzではありません!)。アパートを検索すると、フォームには結果が何件表示されるかが表示されます (例:20～40㎡：400 ヒット、30 ～ 60 平方メートル:600 ヒット）iframe をリロードすることにより オンクリック. 。非常に遅かったです (それでもユーザーは使用していました)。常に100％の負荷。その問題を解決するのが私の仕事でした。
私は何をしましたか？まず、なぜこれほど遅かったのかを調べます。私の最初の推測は正しかった、オンクリック リクエスト また typo3 を使用しました (もちろんキャッシュなし)。この単一のアクションを、typo3 をバイパスしてデータベースに直接クエリするだけのカスタム スクリプトに置き換えることで、問題は解決されました。負荷はほとんどゼロになりました。約2時間かかりました。

もう 1 つのプロジェクトには、1 日に約 1500 人のユニーク訪問者がいて、Oracle データベースによって提供される数百万行のデータと、実行に永遠 (= 数秒) かかる複雑な結合を表示していました。私には Oracle の最適化の経験はあまりありませんでしたが、次のことは知っていました。データベースは週に 1 回か 2 回しか更新されませんでした。私の解決策:HTMLをファイルシステムに書き込んでコンテンツをキャッシュしただけです。更新後（真夜中に）キャッシュをクリアし、再構築を開始しました。したがって、高価なクエリの代わりに、安価なファイルシステムの読み取りだけを実行しました。問題が解決しました。

両方の例から、Web 開発のパフォーマンスは重要であることがわかりました。 ない ロケット科学。ほとんどの場合、解決策は簡単です。そして：99% の場合、はるかに重要な他の部分があります。 開発コスト そして 安全.

Answer 2

質問はかなりあいまいです。ページの取得に費やされる時間のほとんどは通常、静的コンテンツの取得です。言語やフレームワークに依存せずに読み込み時間を短縮するためのいくつかの経験則があります：

1. firefox用の YSlowプラグインをインストールします
2. CSSスプライトを使用
3. 静的コンテンツ用の軽量のhttpサーバー、 nginx または lighttpd
4. 別のドメインまたはサブドメインで静的コンテンツを提供します。これにより、より多くの同時http要求が可能になります
5. javascriptとcssの最小化
6. できるだけ多くのページをキャッシュする
7. httpリクエストの数を少なく保つ
8. 画像で pngcrush またはjpegtranを実行します

当然、これは氷山の一角にすぎません。これらは良い最初のステップです。

Answer 3

ライブラリの数を減らしてください。jquery+ scriptaliciousを使用してよろしいですか。単純なことに固執し、複雑なアニメーションを探しないでください。

高速読み込み=＆gt;キャッシュ、写真付きのページはキャッシュに適しています。

ユーザーの速度感覚が心配な場合は、ユーザーのアクションを見越してバックグラウンドで画像をプリロードすることをお勧めしますが、これによりサーバーの負荷が増大する可能性があると考えてください。これは、帯域幅が適切に契約されている場合にのみ実行してください。

1日2回の変更など、非常に静的なサムズフロントページを作成できる場合は、スプライトテクニックを使用して、多くのサムをロードする待ち時間を短縮できます。

http://websitetips.com/articles/css/sprites/