180

質問パートA▉（100の賞金、授与）
主な質問は、このサイトをより速くロードする方法でした。まず、これらの滝を読む必要がありました。ウォーターフォール読み出し分析に関するご提案ありがとうございます。ここに示されているさまざまなウォーターフォールグラフから明らかなのは、PHPで生成されたサムネイルという主なボトルネックです。DavidがアドバイスしたCDNからのプロトコルレスのjqueryの読み込みは、私のサイトを全体的に3％速くし、サイトの主なボトルネックに答えることはできませんでしたが、私の恩恵を受けました。私の質問を明確にするための時間、そして別の報奨金：

質問パートB▉（100の賞金、授与）
新しい焦点は、6つのjpg画像が抱えていた、読み込み遅延の大部分を引き起こしている問題を解決することでした。これらの6つの画像は、PHPで生成されたサムネイルで、小さく、わずか3〜5 kbですが、読み込みが比較的遅くなります。さまざまなグラフの「最初のバイトまでの時間」に注意してください。問題は未解決のままでしたが、賞金はジェームズに行きました。ジェームズは、RedBotが下線を引いたヘッダーエラーを修正しました。。

質問パートC▉（私の最後の報奨金：250ポイント）
残念ながら、REdbot.orgヘッダーエラーでさえ修正された後、PHPで生成された画像によって引き起こされた遅延はそのままでした。これらの小さな3〜5Kbのサムネイルは一体何を考えているのでしょうか。そのヘッダー情報はすべて、ロケットを月に送り返したりすることができます。このボトルネックに関する提案は、私がすでに7か月間このボトルネックの問題に悩まされているため、非常に高く評価され、可能な回答として扱われます。

[私のサイトのいくつかの背景情報：CSSが一番上にあります。下部のJS（Jquery、JQuery UI、購入したメニューawm / menu.jsエンジン、タブjsエンジン、ビデオswfobject.js）2番目の画像の黒い線は、何をロードするかを示しています。怒っているロボットは私のペット「ZAM」です。彼は無害で、しばしば幸せです。]

ロードウォーターフォール：時系列| http://webpagetest.org ここに画像の説明を入力してください

グループ化された並列ドメイン| http://webpagetest.org ここに画像の説明を入力してください

サイト-パフォーマンスの滝| http://site-perf.com ここに画像の説明を入力してください

PingdomToolsウォーターフォール | http://tools.pingdom.com

ここに画像の説明を入力してください

GTmetrixウォーターフォール | http://gtmetrix.com

ここに画像の説明を入力してください

4

19 に答える 19

61

まず、これらの複数のドメインを使用するには、いくつかのDNSルックアップが必要です。リクエストを拡散するのではなく、これらの画像の多くをスプライトに結合する方がよいでしょう。

次に、ページを読み込むと、all.jsでほとんどのブロッキング（〜1.25s）が表示されます。それはjQuery（の古いバージョン）で始まることがわかります。ロード時間を短縮するだけでなく、HTTPリクエストを完全に回避するために、 GoogleCDNからそれを参照する必要があります。

具体的には、最新のjQueryおよびjQuery UIライブラリをこれらのURLで参照できます（なぜ省略したのか興味がある場合は、この投稿http:を参照してください）。

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

//ajax.googleapis.com/ajax/libs/jqueryui/1.8.9/jquery-ui.min.js

デフォルトのjQueryUIテーマの1つを使用している場合は、そのCSSと画像をGoogleCDNから取得することもできます。

jQueryホスティングを最適化したら、1つのファイルに結合する必要もありawmlib2.jsますtooltiplib.js。

これらのことに取り組むと、大幅な改善が見られるはずです。

于 2011-01-27T09:12:39.570 に答える
17

数日前に同様の問題が発生し、head.jsが見つかりました。これは、すべてのJSファイルを並列にロードできるJavascriptプラグインです。お役に立てば幸いです。

于 2011-01-30T21:44:58.697 に答える
12

私は専門家からはほど遠いですが...

これに関して：「If-Modified-Since条件付きリクエストは完全なコンテンツを変更せずに返しました。」と私のコメント。

サムネイルの生成に使用されるコードは、次のことをチェックする必要があります。

  1. サムネイルのキャッシュバージョンはありますか？
  2. キャッシュされたバージョンは元の画像よりも新しいですか。

これらのいずれかがfalseの場合、サムネイルが生成され、何があっても返されます。それらが両方とも真である場合は、次のチェックを行う必要があります。

  1. HTTP_IF_MODIFIED_SINCEヘッダーはありますか
  2. キャッシュされたバージョンの最終変更時刻はHTTP_IF_MODIFIED_SINCEと同じですか

これらのいずれかがfalseの場合、キャッシュされたサムネイルが返されます。

これらの両方が真の場合、304httpステータスが返されます。必要かどうかはわかりませんが、304とともに、Cache-Control、Expires、Last-Modifiedヘッダーも個人的に返します。

GZippingに関しては、GZip画像は必要ないとのことですので、コメントのその部分は無視してください。

編集：あなたの投稿への追加に気づきませんでした。

session_cache_limiter('public');
header("Content-type: " . $this->_mime);
header("Expires: " . gmdate("D, d M Y H:i:s", time() + 2419200) . " GMT");
// I'm sure Last-Modified should be a static value. not dynamic as you have it here.
header("Last-Modified: " . gmdate("D, d M Y H:i:s",time() - 404800000) . " GMT");

また、コードがHTTP_IF_MODIFIED_SINCEヘッダーをチェックし、それに反応する必要があることも確信しています。これらのヘッダーと.htaccessファイルを設定するだけでは、必要な結果は得られません。

私はあなたがこのようなものが必要だと思います：

$date = 'D, d M Y H:i:s T'; // DATE_RFC850
$modified = filemtime($filename);
$expires = strtotime('1 year'); // 1 Year

header(sprintf('Cache-Control: %s, max-age=%s', 'public', $expires - time()));
header(sprintf('Expires: %s', date($date, $expires)));
header(sprintf('Last-Modified: %s', date($date, $modified)));
header(sprintf('Content-Type: %s', $mime));

if(isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) {
    if(strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) === $modified) {
        header('HTTP/1.1 304 Not Modified', true, 304);
        // Should have been an exit not a return. After sending the not modified http
        // code, the script should end and return no content.
        exit();
    }
}
// Render image data
于 2011-02-09T13:40:05.337 に答える
6

うわー、その画像を使用して物事を説明するのは難しいです..しかし、ここでは、いくつかの試みがあります：

  • ファイル33〜36は、swf内で動的にロードされ、追加のコンテンツをロードする前にswf（25）が最初に完全にロードされるため、ロードが遅くなります。
  • ファイル20と21は、 all.js（11）によってロードされるライブラリである可能性があります（コードがわからないためわかりません）が、11が実行されるまで、ページ全体（およびアセット）を待機します。ロードする（これをdomreadyに変更する必要があります）
  • ファイル22〜32は、これら2つのライブラリによってロードされ、完全にロードされた後に再度ロードされます。
于 2011-01-26T22:39:03.807 に答える
4

サイト/ページでY！SlowおよびPage Speedテストを実行し、ガイドラインに従って、パフォーマンスのボトルネックの可能性を整理してください。Y！SlowまたはPage Speedでスコアを上げると、パフォーマンスが大幅に向上するはずです。

これらのテストは、何が間違っているのか、何を変更するのかを教えてくれます。

于 2011-01-27T08:55:05.923 に答える
4

この種の分析には多くのA/Bテストが必要なため、単純な推測です。.chドメインに到達するのは難しいようです（最初のバイトが到着する前の長い緑色の帯）。

これは、.ch Webサイトのホストが不十分であるか、ISPがそれらへの適切なルートを持っていないことを意味します。

ダイアグラムを考えると、これはパフォーマンスへの大きな打撃を説明する可能性があります。

ちなみに、リソースの読み込みの順序に応じて物事を整理するのに役立つこのクールなツールcuzillionがあります。

于 2011-01-26T22:41:36.070 に答える
4

では、PHPスクリプトは、ページが読み込まれるたびにサムネイルを生成しているのでしょうか。まず、サムネイル化されている画像がそれほど頻繁に変更されない場合、ページが読み込まれるたびに画像を解析する必要がないようにキャッシュを設定できますか？次に、PHPスクリプトimagecopyresampled()はサムネイルの作成に似たものを使用していますか？これは重要なダウンサンプルであり、PHPスクリプトは、物事を縮小するまで何も返しません。imagecopymerged()代わりに使用すると、画像の品質は低下しますが、プロセスは高速化されます。そして、あなたはどのくらいの削減をしていますか？これらのサムネイルは元の画像の5％のサイズですか、それとも50％のサイズですか？元の画像のサイズを大きくすると、PHPスクリプトが元の画像を縮小して小さなサムネイルを出力する前にメモリに取得する必要があるため、速度が低下する可能性があります。

于 2011-02-07T20:31:04.687 に答える
4

あなたのウェブサイトのURLを見つけ、ホームページから個々のjpgファイルを確認しました。読み込み時間は現在（161ms）妥当ですが、126ms待機しています。これは長すぎます。

最終的に変更されたヘッダーはすべて、2011年1月1日土曜日12:00:00 GMTに設定されています。これは、実際の生成日には「丸い」ように見えます;-)

Cache-controlは「public、max-age = 14515200」であるため、最終的に変更された任意のヘッダーにより、168日後に問題が発生する可能性があります。

とにかく、これは遅延の本当の理由ではありません。

サムネイルがすでに存在する場合にサムネイルジェネレータが何をするか、そして画像のチェックと配信に非常に多くの時間を費やす可能性があるものをチェックする必要があります。

xdebugをインストールして、スクリプトのプロファイルを作成し、ボトルネックがどこにあるかを確認できます。

たぶん、すべてがフレームワークを使用するか、無料でデータベースに接続します。一部のサーバーでmysql_connect（）が非常に遅いのを確認しました。これは主に、ソケットではなくTCPを使用して接続しており、DNSの問題が発生する場合があるためです。

有料のジェネレーターをここに投稿できないことは理解していますが、考えられる問題が多すぎるのではないかと思います...

于 2011-02-23T23:14:21.153 に答える
4

本当に正当な理由がない場合（通常はありません）、画像はPHPインタープリターを呼び出さないでください。

ファイルシステムで画像が見つかった場合に画像を直接サーバーするWebサーバーの書き換えルールを作成します。そうでない場合は、PHPスクリプトにリダイレクトして画像を生成します。画像を編集するときは、画像のファイル名を変更して、キャッシュされたバージョンを持つユーザーが新しく編集された画像をフェッチするように強制します。

少なくとも機能しない場合は、画像の作成方法やチェック方法とは何の関係もありません。

于 2011-02-24T21:27:00.607 に答える
3

私はあなたのコードを見ていないので、これは単なる推測ですが、セッションがここで役割を果たしているのではないかと思います。以下は、PHPマニュアルのエントリからのものsession_write_close()です。

セッションデータは通常、スクリプトが終了した後、session_write_close（）を呼び出さなくても保存されますが、セッションデータは同時書き込みを防ぐためにロックされているため、一度に1つのスクリプトのみがセッションを操作できます。フレームセットをセッションと一緒に使用すると、このロックによりフレームが1つずつ読み込まれることがあります。セッション変数へのすべての変更が完了したらすぐにセッションを終了することにより、すべてのフレームをロードするために必要な時間を短縮できます。

私が言ったように、私はあなたのコードが何をしているのかわかりませんが、それらのグラフは奇妙なことに疑わしいようです。マルチパートファイルサービング関数をコーディングしたときに同様の問題が発生し、同じ問題が発生しました。大きなファイルを提供するとき、ダウンロードが完了するまでマルチパート機能を動作させることも、別のページを開くこともできませんでした。電話をsession_write_close()かけると、両方の問題が解決しました。

于 2011-03-04T21:38:37.147 に答える
3

PHPのセッションデータの使用状況を調査します。たぶん（たぶん）、画像生成PHPスクリプトは、まだレンダリング中のメインページまたは他の画像レンダリングスクリプトによってロックされているセッションデータのロックを取得するのを待っています。これにより、ブラウザがサーバーを待機しているため、すべてのJavaScript/ブラウザの最適化はほとんど無関係になります。

PHPは、セッション処理が開始された瞬間からスクリプトが終了した瞬間、またはsession_write_close（）が呼び出された瞬間まで、実行中のすべてのスクリプトのセッションデータをロックします。これは効果的に物事をシリアル化します。セッションのPHPページ、特にこのようなコメントを確認してください。

于 2011-02-11T23:31:16.213 に答える
2

PHPで生成されたツムネイルを通常の画像に置き換えて、違いがあるかどうかを確認しましたか？問題は次のようなものである可能性があります-サーバーの呼び出しごとにサムネイルの再生成につながるphpコードのバグ-時計の問題に関連するコードの遅延（sleep（）？）-非常に悪い競合状態を引き起こすhardriveの問題すべてのサムネイルが同時にロード/生成されるためです。

于 2011-02-25T02:13:39.150 に答える
2

そのサムネイルジェネレータスクリプトを使用する代わりに、TinySRCに高速でクラウドでホストされるサムネイル生成を試してみる必要があると思います。非常にシンプルで使いやすいAPIを備えており、次のように使用できます。-

http://i.tinysrc.mobi/ [高さ] / [幅] /http://domain.tld/path_to_img.jpg

[幅]（オプション）：-これはピクセル単位の幅です（アダプティブサイズまたはファミリーサイズをオーバーライドします）。接頭辞が「-」または「x」の場合、決定されたサイズから減算するか、パーセンテージに縮小します。

[高さ]（オプション）：-幅も存在する場合、これはピクセル単位の高さです。また、アダプティブサイジングまたはファミリーサイジングをオーバーライドし、接頭辞「-」または「x」を付けることができます。

ここでAPIの概要を確認できます

よくある質問

tinySrcの費用はいくらですか？

何もない。

tinySrcの使用はいつ開始できますか？

今。

サービスの信頼性はどれくらいですか？

tinySrcサービスについては保証しません。ただし、主要な分散クラウドインフラストラクチャで実行されるため、世界中で高可用性を提供します。それはあなたのすべてのニーズに十分なはずです。

どれくらい速いですか？

tinySrcは、サイズ変更された画像をメモリとデータストアに最大24時間キャッシュし、毎回元の画像を取得することはありません。これにより、ユーザーの観点から見て、サービスが非常に高速になります。（そして、素晴らしい副作用としてサーバーの負荷を軽減します。）

幸運を。uはコードを表示していないので、単なる提案です：p

于 2011-03-04T20:43:28.567 に答える
2

一部のブラウザはドメインごとに2つのパラレルダウンロードしかダウンロードしないため、2〜3つの異なるホスト名でリクエストをシャーディングするためにドメインを追加することはできません。例：1.imagecdn.com 2.imagecdn.com

于 2011-03-11T16:32:51.700 に答える
1

まず、If-Modified-Sinceジェームズが言ったように、リクエストなどを適切に処理する必要があります。そのエラーは次のように述べています。「その画像が前回から変更されているかどうかをサーバーに尋ねると、単純なyes/noではなく画像全体が送信されます」。

接続から最初のバイトまでの時間は、通常、PHPスクリプトの実行にかかる時間です。そのスクリプトが実行を開始すると、何かが起こっていることは明らかです。

  1. プロファイリングを検討しましたか？いくつかの問題があるかもしれません。
  2. 上記の問題と組み合わせると、スクリプトが必要以上に何度も実行される可能性があります。理想的には、元の画像が変更された場合にのみサムを生成し、他のすべてのリクエストに対してキャッシュされたサムを送信する必要があります。スクリプトが不必要に（たとえば、リクエストごとに）画像を生成していることを確認しましたか？

アプリケーションを介して適切なヘッダーを生成するのは少し注意が必要です。さらに、サーバーによって上書きされる可能性があります。また、キャッシュなしのリクエストヘッダーを送信すると、サムネイルジェネレータが継続的に実行される（負荷が高くなる）ため、悪用される可能性があります。したがって、可能であれば、生成されたサムを保存し、保存された画像をページから直接呼び出し、からヘッダーを管理してみてください.htaccess。.htaccessこの場合、サーバーが適切に構成されていれば、何も必要ありません。

これら以外に、リソースをCookieのないサブドメインに分割するなど、Webサイトを正しい方法で実行する方法について、この全体的な優れたSO質問のパフォーマンス部分からの明るい最適化のアイデアのいくつかを適用できます。読み込みに1秒もかからないはずです。これは、グラフの他の項目と比較すると明らかです。最適化する前に、問題を特定するようにしてください。

于 2011-02-10T09:49:01.590 に答える
1

画像やスタイルシートなどの静的データを提供するために、NGINX Webサーバーの下にいくつかのサブドメインを特別に設定しようとしましたか？このトピックには、すでに役立つものがあります。

于 2011-02-22T00:49:05.597 に答える
1

遅延したサムネイルについては、サムネイル生成スクリプトのheader（）を最後に呼び出した直後にflush（）を呼び出してみてください。完了したら、ウォーターフォールグラフを再生成し、遅延がヘッダーではなく本体にあるかどうかを確認します。その場合は、画像データを生成および/または出力するロジックを詳しく調べる必要があります。

サムネイルを処理するスクリプトは、提供している画像に対して実行するアクションが絶対に必要な場合にのみ発生するように、何らかのキャッシュを使用する必要があります。サムネイルを提供するたびにコストのかかる操作が行われているため、スクリプトからの出力（ヘッダーを含む）が遅れているようです。

于 2011-02-28T19:11:23.110 に答える
1

遅い問題の大部分は、TTFB（最初のバイトまでの時間）が高すぎることです。これは、サーバーの構成ファイル、コード、および基盤となるハードウェアに精通せずに取り組むのは難しいものですが、すべての要求で横行していることがわかります。緑のバーが多すぎ（悪い）、青いバーが非常に少ない（良い）。フロントエンドの最適化を少しやめたほうがいいかもしれません。その分野で多くのことを成し遂げたと思います。「エンドユーザーの応答時間の80％〜90％がフロントエンドに費やされている」という格言にもかかわらず、あなたの応答時間はバックエンドで発生していると思います。

TTFBは、バックエンドのもの、サーバーのもの、出力およびハンドシェイクの前の前処理です。

遅いデータベースクエリのような遅いものを見つけるためにコード実行の時間を計り、遅い関数を見つけるために関数/メソッドを出入りする時間を計ります。phpを使用する場合は、Firephpを試してください。セッション情報の取得や認証の確認など、起動時または初期化時に実行される1つまたは2つの遅いクエリである場合があります。クエリを最適化すると、パフォーマンスが向上する可能性があります。場合によっては、コードはphpprependまたはsplautoloadを使用して実行されるため、すべてで実行されます。また、設定が正しくないapache confや微調整が、1日を節約する場合もあります。

非効率的なループを探します。障害のあるディスクドライブまたは高いディスクスペース使用量が原因で、キャッシュの呼び出しが遅いか、I/O操作が遅いかどうかを確認します。メモリ使用量と使用されているものと場所を探します。同じ場所ではなく、世界中のさまざまな場所からの最初のビューのみを使用して、単一の画像またはファイルに対して10回の実行のWebページテストを繰り返しテストします。また、アクセスログとエラーログを読んでください。あまりにも多くの開発者がそれらを無視し、出力された画面上のエラーのみに依存しています。あなたのウェブホストがサポートを持っているなら、彼らに助けを求めてください、彼らがとにかく彼らに丁寧に助けを求めなければ、それは害にはなりません。

DNSプリフェッチを試して、多くのドメインやリソースと戦うことができます。http：//html5boilerplate.com/docs/DNS-Prefetching/

サーバーはあなた自身の良い/まともなサーバーですか？より良いサーバーが多くの問題を解決できる場合があります。私は「ハードウェアは安い、プログラマーは高い」という考え方のファンです。チャンスとお金があれば、サーバーをアップグレードできます。および/またはmaxcdnやcloudflareなどのCDNを使用します。

幸運を！

（ps私はこれらの会社のいずれでも働いていません。また、上記のcloudflareリンクは、TTFBはそれほど重要ではないと主張します。私は、別のテイクを取得できるように、そこにそれを投げました。）

于 2012-07-24T01:34:56.683 に答える
-1

申し訳ありませんが、提供するデータはほとんどありません。そして、あなたはすでにいくつかの良い提案をしました。

それらの画像をどのように提供していますか？PHPを介してそれらをストリーミングしている場合、それらがすでに生成されている場合でも、非常に悪いことをしています。

PHPで画像をストリーミングしないでください。使用方法に関係なく、サーバーの速度が低下します。

意味のあるURIを使用して、アクセス可能なフォルダーに配置します。次に、実際のURIを使用して直接呼び出します。オンザフライ生成が必要な場合は、要求画像が欠落している場合にのみジェネレータphp-scriptにリダイレクトする.htaccessをimagesディレクトリに配置する必要があります。（これは、キャッシュオンリクエスト戦略と呼ばれます）。

そうすることで、phpセッション、ブラウザプロキシ、キャッシング、ETAGSなどを一度に修正できます。

WP-Supercacheは、適切に構成されている場合、この戦略を使用します。

私はこれを少し前に書きました（http://code.google.com/p/cache-on-request/source/detail?r=8）、最後のリビジョンは壊れていますが、8以下で動作するはずです。物事をテストするためだけに例として.htaccessを入手してください（ただし、以前よりも.htaccessを構成するためのより良い方法があります）。

この戦略については、このブログ投稿（http://www.stefanoforenza.com/need-for-cache/）で説明しました。それはおそらくひどく書かれていますが、それは物事を明確にするのに役立つかもしれません。

さらに読む： http： //meta.wikimedia.org/wiki/404_handler_caching

于 2011-03-06T17:21:22.447 に答える