著者: Fenng | 転載する場合は、必ず記事の出典と著者情報、および著作権表示を URL: 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 オプションを設定することで、事前に圧縮されたファイルを自動的に処理できます。また、この機能が一部の古いバージョンのブラウザで問題を引き起こす可能性があることも指摘しています
。圧縮 JavaScript の場合、主な手段の 1 つはコンテンツの圧縮です。これは、コメントを減らしたり、スペースを結合したり、コンパクトな構文やその他のトリックを使用したりすることで実現できます (もちろん、すべての Google スクリプトは非常に読みにくく、非常にコンパクトですが、同様の考え方が採用されています)。この方法で処理する JavaScript には、解析が難しい括弧が多数含まれている場合があります。Flickr は Dojo Compressor を使用して解析ツリーを構築します。 Dojo Compressor はオーバーヘッドが非常に低く、エンド ユーザーに対して透過的です。JavaScript 処理メソッドが導入されており、単純な正規表現置換 (複数のスペースを 1 つのスペース文字に置き換えるなど) によって、CSS 処理を実行できます。圧縮率が 50% に達します。
キャッシュの最適化 Flickr 開発者は、HTTP 1.1 仕様で定義された Etag および Last-Modified メカニズムを最大限に活用して、キャッシュの効率を向上させました。つまり、Cal が負荷分散条件下で e-Tag トリックを導入したことは注目に値します。ファイル調整時間とファイル サイズを通じて E-Tag を取得するように Apache を設定できます。デフォルトでは、Apache はファイル ノードを通じて e-Tag を取得します。もちろん、これは if-modified-since に影響するため、完璧ではありません。
mod_rewrite の柔軟な使い方 Flickr Web サイトのアプリケーションは毎日ビルドされる (Daily Build) と言われています。 これは柔軟なメカニズムがなければ考えられません。さらに、Flickr のようなサイトでは、コンテンツの変更を同期するのが頭の痛い問題です。彼らの武器は、mod_rewrite の柔軟な使用です。 URL 書き換えルールを設定することで、異なる環境への切り替えが簡単になります。非常に簡単に思えますが、特定の Web テクノロジーのスキルがなければ、これを実行するのはどれほど簡単でしょうか?!
これらの主な方法を適用することで、夢のような高性能の Flickr が完成しました。
ところで: Flickr には中国にサーバーがないため、本土ユーザーのアクセス速度について言及することはできません :(
--終了。
この記事 [Flickr 開発者のための Web アプリケーション最適化のヒント] は dbanotes.net からのものです。