Webフロントエンドのパフォーマンス最適化

ウェブフロントエンド最適化のベストプラクティス: コンテンツ
Webフロントエンド最適化のベストプラクティス: サーバー
ウェブフロントエンド最適化のベストプラクティス: Cookie
Web フロントエンド最適化のベストプラクティス: CSS
Web フロントエンド最適化のベストプラクティス: JavaScript
ウェブフロントエンド最適化のベストプラクティス: 画像
Web フロントエンド最適化のベストプラクティス: モバイル (iPhone)

Yahoo! の Exceptional Performance チームは、Web フロントエンドに多大な貢献をしてきました。よく知られている最適化ルールの数も 13 から 14、そして 20、そして現在は 34 に増えており、まさに時代の変化に追随しています。最新の34件もさまざまな視点から分類されています。

現在、コンテンツ指向の最適化ルールは 10 個あります。

1. HTTPリクエストを減らす
最初のものはおそらく最も重要なものです。 Yahoo! リサーチ チームによるデータ分析によると、ユーザー訪問の大部分がこの項目から最も恩恵を受けることになります。実際に HTTP リクエストを削減する一般的な方法はいくつかあります。

•1) 複数の CSS ファイルを 1 つに結合するなど、ファイルを結合します。
•2) CSS スプライトは、CSS 背景関連要素を使用して背景画像を絶対配置します。参照: CSS スプライト: 画像スライスの死のキス
•3) イメージマップ
•4) インライン画像は、data: URL スキームを使用して、実際のページに画像データを埋め込みます。
2. DNSルックアップを減らす
DNS ルックアップは非常にコストがかかることを理解する必要があります。また、これはすべての Yahoo! サイトに共通する問題だと思います。Yahoo!メインサイトは十分に明白ではないかもしれませんが、いくつかのサブサイトには同様の明らかな問題があります。国内サイトの場合、外部ウィジェットを多用しすぎると、DNS ルックアップの問題が多発しやすくなります。

3. リダイレクトを避ける
絶対に避けるのではなく、減らすように努めることが大切です。さらに、不要なリダイレクトにも注意する必要があります。たとえば、Web サイトのサブディレクトリの後に / (スラッシュ) を追加すると、リダイレクトを効果的に回避できます。 http://www.dbanotes.net/archとhttp://www.dbanotes.net/arch/には違いがあります。 Apache サーバーの場合は、Alias または mod_rewrite または DirectorySlash を設定することでこの問題を解消できます。

4. Ajaxをキャッシュ可能にする
応答時間は Ajax にとって非常に重要です。応答時間が短いと、ユーザー エクスペリエンスは確実に低下します。応答時間を改善する効果的な方法はキャッシュです。これには他の最適化ルールもいくつか有効です。

5. ロード後のコンポーネント
6. コンポーネントのプリロード
厳密に言えば、上記の 2 つのポイントはどちらも非同期の考え方の柔軟な適用に関するものです。

7. DOM要素の数を減らす
8. ドメイン間でコンポーネントを分割する
主な目的は、ページ コンポーネントの並列ダウンロード機能を向上させることです。ただし、ドメイン名をあまり多く使用しないでください。そうしないと、2 番目のポイントと競合します。

9. iframeの数を最小限に抑える
SEO に詳しい友人は、iframe が SEO ではタブーであることを知っています。フロントエンドの最適化において、iframe には利点と欠点があります。2 つの観点から問題を見てみましょう。

10. http 404 エラーを排除する (404 なし)
ページ リンクを徹底的にテストし、Web サーバーのエラー ログを継続的に追跡することで、404 エラーを効果的に削減し、ユーザー エクスペリエンスを向上させることができます。 CSS と Java Script によって発生する 404 エラーは、見つけるのが少し「難しい」ため、見落とされやすいことが多いことに注意が必要です。

これらはコンテンツセクションの 10 項目です。具体的な指導内容は十分に詳細ではないと言わざるを得ません。自分の理解に基づいて徐々に追加していきます。

Webページ制作 poluoluo 記事紹介：Webフロントエンドのパフォーマンス最適化は大きなトピックであり、運用および保守担当者が継続的に追跡する価値のあるトピックであり、多くのWebサイトで容赦なく無視されているテクノロジーです。

Web フロントエンド最適化のベスト プラクティスの 2 番目の部分は、サーバー指向です。

現在、練習ルールは全部で6つあります。 [注: これは技術的なメモにすぎません。元のコンテンツを表示するには、「優れたパフォーマンス: Web サイトを高速化するためのベスト プラクティス」をご覧ください。]

1. コンテンツ配信ネットワークを使用する
国内の CDN はまだ広く使用されていません。ただし、China Telecom と China Netcom の間には固有の問題があります。これを最適化すれば、基本的に CDN または同様の効果が得られます (そう見せかけます)。 [Tin氏は、CDNは中国で広く使用されていると述べました。CDNベンダーの市場を見れば、まだ一般家庭には浸透していないことがわかります。]

2. Expires または Cache-Control ヘッダーを追加する
各ブラウザには特定のソリューションがあります。Apache の例 [注: 次の例は十分に詳細ではないため、特定の環境に合わせて調整する必要があります]。

有効期限有効日
ExpiresByType image/gif "変更後 1 週間" Lighttpd が mod_expire モジュールを有効にした後:

$HTTP["url"] =~ "\.(jpg|gif|png)___FCKpd___1quot; {
expire.url = ( "" => "アクセス1年" )
Nginx の例の参照:

場所 ~* \.(jpg|gif|png)$ {
if (-f $リクエストファイル名) {
有効期限が最大になります。
壊す;
}
}

3. Gzip コンポーネント
ほとんどのサイトにとって、これはネットワーク トラフィックの負荷を効果的に軽減するために必要な手順です。 CPU 圧縮が CPU に与える影響を心配する人もいるかもしれません。心配しないでください。実行してください。大丈夫です。 Nginx の例:

gzip オン;
gzip_types text/plain text/html text/css ext/javascript; 参照:

IIS で Gzip 圧縮を有効にする方法は?
4. ETagsを構成する
Etag は、ほとんどの Web サイト管理者が見落としがちなものかもしれません。この一連の最適化ルールが登場する前は、インターネット上のほとんどのサイトはおそらくこの問題を無視していました。もちろん、Etag はほとんどのサイトのパフォーマンスに大きな影響を与えません。ただし、RSS 指向のサイトでは除きます。 [簡潔に書かれていると批判する友人がいて、IE は ETag をサポートしていないと言っていました。明確に言うと、IE は ETag をサポートしていますが、IIS を使用する場合は、関連する Etag バグに注意する必要があります。 】

補足: 私が言いたいのは、「多くのウェブサイトは注意を払わずに Etag をオンにしており、どのウェブサイトも Etag の使い方を気にしておらず、知らないうちにリソースを消費している」ということです。これは Etag が悪いという意味ではありません。Etag を適切に使用すれば、間違いなく良いメリットが得られます。

5. バッファを早めにフラッシュする
これについて長い間考えてみた結果、このアイデアはまだ非同期であるように思われます。ユーザーエクスペリエンスは向上しますか?

6. AJAXリクエストにGETを使用する
XMLHttpRequest POST には 2 つのステップが必要ですが、GET には 1 つのステップのみが必要です。ただし、IE で GET が処理できる URL の最大長は 2K であることに注意してください。

Webページ制作 poluoluo 記事紹介：Webフロントエンドのパフォーマンス最適化は大きなトピックであり、運用および保守担当者が継続的に追跡する価値のあるトピックであり、多くのWebサイトで容赦なく無視されているテクノロジーです。

Web フロントエンド最適化のベスト プラクティスの 3 番目の部分は、Cookie に焦点を当てています。現在、実践ルールは 2 つだけです。

1. クッキーのサイズを小さくする
クッキーは興味深いトピックです。 RFC 2109 によれば、各クライアントは最大 300 個の Cookie を保持でき、ドメイン名ごとに最大 20 個の Cookie を保持できます (実際、ほとんどのブラウザではこれより多くの Cookie を保持しており、Firefox では 50 個です)。各 Cookie は最大 4K です。ここでの 4K は、ブラウザによっては厳密には 4096 ではないことに注意してください。話がそれないようにします。クッキーに関して最も重要なことは、クッキーのサイズを制御し、無駄な情報を詰め込まないようにすることです。

2. コンポーネントにはCookieフリーのドメインを使用する
このトピックは、Web イメージ サーバーの議論の中で以前にも言及されています。ここで言う Web コンポーネントとは、主に画像や CSS などの静的ファイルを指します。Yahoo! の静的ファイルはすべて yimg.com にあります。クライアントが静的ファイルを要求すると、プライマリ ドメイン名 (yahoo.com) での繰り返しの Cookie 送信の影響が軽減されます。

「When the Cookie Crumbles」という記事から、MySpace と eBay の Cookie が小さくないことがわかります。これは、両社がユーザーの行動をより重視しているために違いありません。 eBay は最近、Cookie の制限から脱却するように設計されたパーソナライゼーション プラットフォームを構築しました。

Webページ制作 poluoluo 記事紹介：Webフロントエンドのパフォーマンス最適化は大きなトピックであり、運用および保守担当者が継続的に追跡する価値のあるトピックであり、多くのWebサイトで容赦なく無視されているテクノロジーです。

Web フロントエンド最適化のベスト プラクティスの 4 番目の部分は CSS に焦点を当てています。

現在、練習ルールは全部で6つあります。 Mozilla Developer Centerの記事「効率的なCSSの書き方」も参照してください。

1. スタイルシートを先頭に配置する
公式の説明は少し曖昧だと思います。これは実際にはユーザーのアクセス期待に関連しています。 CSS を先頭に配置することで、ブラウザは HTML ページを上から下までターゲットを絞って解析し、レンダリングできるようになります。誰も待つのは好きではありません。ブラウザはこれを考慮に入れています。

2. CSS式を避ける
個人的には、CSS 式でできることは、リスクの少ない他の手段でもできると思います。

3. JavaScriptとCSSを外部化する
ストリップ後、圧縮やキャッシュ戦略などの別の処理戦略をターゲットを絞って適用できます。

4. JavaScriptとCSSを縮小する
おそらく、JavaScript と CSS がないほうが良いでしょう。しかし、これは不可能なので、小さくするようにしてください。文法は省略できます。

5. @import ではなく <link> を選択する
IE では、@import ディレクティブは HTML の下部にリンク タグを配置することと同じです。これは最初の点に反します。

6. フィルターを避ける

Webページ制作 poluoluo 記事紹介：Webフロントエンドのパフォーマンス最適化は大きなトピックであり、運用および保守担当者が継続的に追跡する価値のあるトピックであり、多くのWebサイトで容赦なく無視されているテクノロジーです。

Web フロントエンド最適化のベストプラクティス: JavaScript

このセクションには 6 つのルールがあり、そのうちのいくつかは CSS セクションで繰り返されます。フロントエンド最適化のベストプラクティスで最も重要なのは「実践」です。理解するのは簡単ですが、重要なのは「実践し」、「実行し」、「フィードバックを与え」、利益を得ることです。

1. スクリプトを一番下に置く
スクリプトのダウンロード中、ブラウザは他の操作 (シリアル化) を実行できません。だから、最後まで投げて対処してください。一部の機能スクリプトでは実装が難しい場合があります。ただし、国内のウェブサイトの場合、ウェブサイトのデータを分析するために Google アナリティクス サービスを使用しているものが多くあります。この点に関して、絶対に実現可能な提案はページの下部に掲載されています。

2. JavaScriptとCSSを外部化する
CSS記事の説明を参照してください

3. JavaScriptとCSSを縮小する
CSS記事の説明を参照してください

4. 重複したスクリプトを削除する
これは、一部の歴史的なサイトやフォーラムタイプの Web サイトでは非常に一般的です。引き継ぎ前と引き継ぎ後の保守担当者の交代が多すぎて、それぞれが独自のルールを持っています。これは潜在的なトラブルにつながる可能性があります。

5. DOMアクセスを最小限に抑える
指針となる提案は 3 つあります。

•アクセスされた要素への参照をキャッシュする
•ノードを「オフライン」で更新し、ツリーに追加します
•JavaScriptでレイアウトを修正するのは避けてください。これはCSSで行う必要があります。
6. スマートイベントハンドラを開発する
英語の説明に加えて、Java Script のメモリ リークの問題に注意するよう促すリマインダーもここにあります。

また、「JavaScript スクリプトのパフォーマンスを最適化する方法」という記事もおすすめです。Ajax の最適化に関するガイドラインについては、「Ajax アプリケーションのパフォーマンスの向上と Web サービスの脆弱性の回避」を参照してください。

追記 1): 整理がほぼ終わったところで、インターネット上に「Yahoo! ウェブサイトのパフォーマンスを最高にするための 34 の黄金律」という記事があり、その翻訳版がすでにあることを知りました。いくつかの作業が重複しているようです。

追記2): CSS/JavaScriptには最適化ルールがあります。しかし、Flash の最適化手法が不足しているようです。

Webページ制作 poluoluo 記事紹介：Webフロントエンドのパフォーマンス最適化は大きなトピックであり、運用および保守担当者が継続的に追跡する価値のあるトピックであり、多くのWebサイトで容赦なく無視されているテクノロジーです。

ウェブフロントエンド最適化のベストプラクティスパート6：画像

現在、このセクションには 4 つのルールがあります。最近の Velocity 2008 テクノロジー カンファレンスでは、Yahoo! の Stoyan Stefanov による「Image Optimization: How Many of These 7 Mistakes Are You Making」も非常に価値のある参考資料です。一緒にそれらについて話しましょう。

1. 画像を最適化する
GIF、JPG、PNG 形式の画像のうちどれを使用すればよいですか? 可能な限り、GIF に比べて機能が豊富でサイズが小さい PNG 形式の画像を使用してください。

PNG 画像の場合は、Pngcrush または同様のツールを使用して最適化することを検討してください。一般的なツールを以下に示します。

•pngcrush http://pmt.sourceforge.net/pngcrush/
•pngrewrite http://www.pobox.com/~jason1/pngrewrite/
•OptiPNG http://www.cs.toronto.edu/~cosmin/pngtech/optipng/ (参照: チュートリアル)
•PNG出力http://advsys.net/ken/utils.htm
参照: PNG 画像を効果的に使用するための 5 つのヒント

JPEG 画像の最適化ツール:

•jpegtran ( http://jpegclub.org/ )
画像デザインを学ぶ学生は、Web 用の画像をデザインすることを考慮し、許容サイズを超える画像をデザインしないようにする必要があることを強調する必要があります。これは優れたスキルではなく、習慣であるべきです。覚えておく必要があります。

2. CSSスプライトを最適化する
前にも述べたように、簡単に言えば、「CSS の背景関連要素を使用して背景画像を絶対的に配置」し、複数の HTTP 呼び出しを 1 つの呼び出しに変換することです。詳細については、「CSS Sprites: Image Slicing's Kiss of Death」を参照してください。

追加: このテクニックを悪用する人を見たことがあります。 HTTP 呼び出しを減らすために、複数の背景画像を 1 つに結合することをお勧めします。ただし、この大きな画像は「重すぎる」ものであってはならないことに注意してください。100K を超える背景画像を見たことがあります。 1 つの画像により、サイト全体の速度が低下する可能性があります。良い例は、Yahoo の関係を示すこのグラフで確認できます。

更新: CSS スプライトを使用すると、クライアントがより多くのメモリを消費するという副作用が生じる可能性があります (参照)。

3. HTMLで画像を拡大縮小しない
多くの場合、写真が適切なサイズで作成されないのは、怠惰のせいかもしれません。写真をバッチ処理する場合は、ImageMagic コマンド (convert) で実行できる可能性があります。醜い引き伸ばされた画像のあるページをあまりにも多く見てきたことを述べなければなりません。これらのページを保存してください。

4. favicon.ico を小さくしてキャッシュ可能にする
小さくてキャッシュ可能なので、どちらも問題にならないかもしれません。問題は、favicon.ico をまったく持っていないサイトが多すぎることです。場合によっては、独立したドメイン名を持つブログがプロフェッショナルかどうかを判断するには、基本的に favicon.ico があるかどうかを確認するだけで十分です。

--終了--

補足: ビジュアル デザイナーは画像のサイズを制御するように努めるべきであり、200K 未満にすることが推奨されます。これはナンセンスではありません。ページを参照してください。

Webページ制作 poluoluo 記事紹介：Webフロントエンドのパフォーマンス最適化は大きなトピックであり、運用および保守担当者が継続的に追跡する価値のあるトピックであり、多くのWebサイトで容赦なく無視されているテクノロジーです。

Web フロントエンドの最適化に関するベスト プラクティスの最後の部分は、モバイル アプリケーションに関するものです。実際には、これは iPhone のみを対象としており、現時点ではルールは 2 つしかありません。

1. コンポーネントを25K以下に抑える
これはiPhoneのみを対象に調査されているようです。個々の Web データ オブジェクトは 25K 未満に抑えることをお勧めします。なぜ 25K なのでしょうか? Apple の公式情報によると、メモリにキャッシュできる Web オブジェクトの最大サイズは 10M ですが、テストの結果、約 25K であることがわかりました。

市場における iPhone の優れたパフォーマンスにより、Web 開発者は iPhone を最適化する方法を検討せざるを得なくなりました。この部分のコンテンツも常に変化していると思います。

2. コンポーネントをマルチパートドキュメントにまとめる
Web ページのコンポーネントを複数の部分からなるドキュメントにパッケージ化します。その目的は、HTTP リクエストを削減することです。この部分はあまり詳細ではありませんので、次のアップデートをお待ちください。