Web アプリケーション最適化のヒント_PHP チュートリアル-PHPチュートリアル-php.cn

Web アプリケーション最適化のヒント_PHP チュートリアル

WBOY

リリース： 2016-07-13 17:36:41

オリジナル

770 人が閲覧しました

著者: Fenng|転載可能です。転載する場合は、必ず記事の出典、著者情報、著作権表示をハイパーリンクの形式で明記してください。
ウェブサイト: http://www.dbanotes.net/web/ flickr_web_tech.html
Cal Henderson は有名な Flickr Web サイトの開発者の 1 人です。 Serving JavaScript Fast という記事で、Flickr サイトアプリケーションを最適化するためのテクニックが紹介されており、読んで非常に有益だと感じました。「他人のパンを噛む」、記事の主な内容を要約します。

Flickr は Web 2.0 の代表的なサイトです。一般的な Web サイトに共通するコンテンツの最適化に加えて、直面するネットワークの問題は、JavaScript や CSS の頻繁な変更によって引き起こされる展開と配布の複雑さにも柔軟に対処する必要があります。

ファイルサイズ戦略を設定するときに最初に直面する問題は、すべての JavaScript と CSS を 1 つのファイルに入れるか、それとも複数のファイルに分割するかということです。ネットワークリクエストを減らすという観点から見ると、前者はより良く、後者はより悪くなります。ただし、並行して見ると、IE と Firefox は両方とも、デフォルトでは 1 つのドメインから同時に 2 つのリソースしか要求できません。これにより、多くの場合、ユーザーに不快な思いが生じます。すべてのファイルをダウンロードする必要があります。適切なページを参照してください。ファイル数をできるだけ少なくしながら JavaScript と CSS を複数のサブファイルに分割することで妥協策を講じていますが、これにより開発は複雑になりますが、パフォーマンスは大幅に向上します。

圧縮最適化の問題サイトコンテンツの圧縮が比較的一般的な Web 最適化方法であることは疑いの余地がありません。ただし、常に望ましい効果が得られるとは限りません。その理由は、mod-gzip モジュールはサーバー側の CPU リソースを消費するだけでなく、クライアント側の CPU リソースも消費するためです。さらに、mod_gzip がファイルを圧縮した後に作成される一時ファイルがディスク上に配置され、これも重大な問題を引き起こすためです。ディスク IO には Flickr Httpd 2.x 以降でサポートされている mod_deflate モジュールが使用されます。圧縮操作はすべてメモリ内で実行されます。 mod_deflate は Httpd 1.x では使用できませんが、RAM ディスクを作成することで間接的にパフォーマンスを向上させることができます。

もちろん、mod_gzip が役に立たないわけではありません。また、圧縮を使用する場合は、画像ファイルを圧縮する必要はありません (Flickr には多くの画像があります)。利点) Flickr は JavaScript と CSS のみを圧縮します。mod_gzip の新しいバージョンでは、mod_gzip_update_static オプションを設定することで、事前に圧縮されたファイルを自動的に処理できます。また、この機能が一部の古いバージョンのブラウザーで問題を引き起こす可能性があることも指摘しています。

もう 1 つの主な圧縮手段は、JavaScript の場合、コメントの削減、スペースの結合、コンパクトな構文の使用などの小さなトリックを実行できます (もちろん、すべての Google スクリプトは非常に読みにくく、非常にコンパクトですが、同様の考え方をしています)。 , この方法で処理された JavaScript には、解析が難しい括弧が多数含まれている可能性があります。Flickr は Dojo Compressor を使用して解析ツリーを構築します。 Dojo Compressor はオーバーヘッドが非常に低く、エンドユーザーに対して透過的です。JavaScript 処理メソッドが導入されており、単純な正規表現置換 (複数のスペースを 1 つのスペース文字に置き換えるなど) によって、CSS 処理を実行できます。圧縮率が 50% に達します。

キャッシュの最適化 Flickr 開発者は、HTTP 1.1 仕様で定義された Etag および Last-Modified メカニズムを最大限に利用して、キャッシュの効率を向上させました。Cal が負荷分散条件下で e-Tag トリックを導入したことは注目に値します。ファイル調整時間とファイルサイズを通じて E-Tag を取得するように設定できます。デフォルトでは、Apache はファイルノードを通じて e-Tag を取得します。もちろん、これは if-modified-since に影響するため、完璧ではありません。

mod_rewrite を柔軟に活用する Flickr Web サイトのアプリケーションは毎日ビルドされる (Daily Build) と言われています。柔軟な仕組みがなければ、これは考えられないことだと思います。さらに、Flickr のようなサイトでは、コンテンツの変更を同期するのが頭の痛い問題です。彼らの武器は、mod_rewrite の柔軟な使用です。 URL 書き換えルールを設定することで、異なる環境への切り替えが簡単になります。簡単そうに聞こえますが、特定の Web テクノロジーのスキルがなければ、これを実行するのはどれほど簡単でしょうか?!

これらの主要なメソッドを適用することで、夢のような高性能な Flickr が完成しました。

ところで: Flickr には中国にサーバーがないため、本土ユーザーのアクセス速度について言及することはできません:(

--終わり

この記事 [Flickr 開発者のための Web アプリケーション最適化のヒント] は dbanotes.net からのものです

http://www.bkjia.com/PHPjc/486629.html