ウェブサイト分析: 5173 ホームページ フロントエンド パフォーマンス最適化の実践

計画からフロントエンドとバックエンドの開発、そしてテストとリリースまで、4か月かかりました。5173ホームページフロントエンドパフォーマンス最適化プロジェクトは最終的に成功し、期待されたパフォーマンス最適化目標を達成しました。このプロジェクトは改訂ではなく、元のホームページのデザインや機能はそのままに、再構築と最適化のみを行います。フロントエンドパフォーマンス最適化プロジェクトとはいっても、フロントエンドだけの仕事ではなく、徹底的に最適化するためにはフロントエンドとバックエンドの連携が必要です。

歴史的背景

旧ホームページは2009年に立ち上げられたはずです。ホームページは、さまざまな部門がリソースを競い合う場所でもあります。誰もがホームページに場所を持ちたがっており、各部門はホームページに独自の小さな豆腐を持っています。新しいプロジェクトが立ち上げられた場合、それらのほとんどはパッチの形をしており、機能の正常な動作を保証するための仕様のみです。パフォーマンスに関しては、それは非常に遠いものです。困るのは開発者です。ホームページに変更があるたびに、あれこれ変更したら問題が起きるのではないかと心配しています。歴史的な理由から、問題がどんどん増えています。

最初に我慢できなくなったのは、おそらくフロントエンドのスタッフだったでしょう。ホームページは頻繁に修正され、パフォーマンスが悪くなってフロントエンドのスタッフが恥ずかしい思いをしたからです。しかし、我慢できないというのは、我慢できないだけであり、さまざまな部門の利害が絡むため、実質的な改善策を講じることはできません。前述のように、最適化はフロントエンドだけの問題ではないため、フロントエンドの担当者は問題を上司に報告することしかできません。今年、私のリーダーたちはついに我慢できなくなりました。そのうちの一人が、海外にある弊社の818と5173のホームページを訪問しました。比較すると、前者のホームページは非常に高速でしたが（ちなみに、私は818のホームページのフロントエンド開発者です^_^）、後者のホームページは非常に遅いです。その差はかなり大きいです。そのため、指導部の推進と配慮の下、5173ホームページのフロントエンドパフォーマンス最適化プロジェクトが承認され、開発者はついに大胆に実行に移すことができました。

問題分析

始める前に、計画を立てる必要があります。計画を立てるには、まず現実的な問題を解決することから始める必要があります。まず、古いホームページの問題を見てみましょう。計画を立てる際に収集した関連データは次のとおりです。

1. リクエストが多すぎます。CSS 外部リンクが 12 個、JavaScript 外部リンクが 41 個あります。

2. ページの合計サイズが大きすぎ、多くの静的リソースが gzip 圧縮されておらず、動的サイトの JS も圧縮されていません。

3. リソースの使用量が深刻です。IE6 でページをスクロールすると、CPU 使用率が 80% を超え、メモリ リークも深刻です。

4. 広告システムでは、広告画像が document.write モードで読み込まれ、ページが深刻にブロックされます。

5. ページには 7 つの iframe があります。

6. データ ソース インターフェイスがわかりにくい。

7. ページの読み込み速度が遅すぎる、白い画面が表示される、最初の画面の読み込みが非常に遅い。

上記のデータは衝撃的かもしれませんが、最適化の余地がまだたくさんあることも示しています。問題が特定されると、具体的な実装の方向性を策定できます。つまり、従来の方法であろうと奇妙な技術であろうと、目標は「より速く、より速く」という 3 つの単語だけです。

具体的な実装

ページの内容は一見すると大したことないように見えますが、機能モジュールの作業には非常に時間と労力がかかります。私たちの上司は、「私はいつも面接官にこう質問します。5173 のホームページのフロントエンド作業を単独で行う場合、完了するまでにどのくらいの時間がかかりますか。答えが 1 週間だけなら、そのページを一度も見たことがないか、非常にプロ意識が低いかのどちらかです。」と言っています。ホームページのフロントエンド開発を単独で完了するのに、私は 1 か月以上かかりました。具体的な実装についてお話ししましょう。

HTMLとCSSのリファクタリング

ページのデザインと機能は変更されていませんが、HTML ページは完全に再構築する必要があります。ここでも、新しい HTML5 タグを使用してページをレイアウトしてみました。 CSS の再構築も当然のことです。元々外部リンク CSS は 12 個ありましたが、すべて削除する必要があります。一部のモジュールがホームページ以外にも使用されている場合は、モジュール化して公開ファイルに配置する必要があります。開発中は複数のモジュールに分割し、@import を使用して 1 つのファイルにまとめ、パッケージ化して公開するときに 1 つのファイルにマージすることができます。これには、キャッシュを合理的に使用し、単一のファイルが大きくなりすぎないようにし、モジュール化を実現するという適切なバランスが必要です。

以前のホームページでは、CSS セレクタが長すぎるという問題が多くありました。CSS セレクタの組み合わせが 6 ～ 7 個になることも珍しくありませんでした。CSS セレクタが長すぎると、パフォーマンスに影響するだけでなく、CSS の重みの関係により、後のメンテナンスにも大きな問題が生じました。クラスを使用してセレクターをより頻繁に定義し、タグセレクターの組み合わせを追加する必要があります。最大 3 つのセレクターの組み合わせで、ほとんどのニーズを満たすことができます。また、id セレクターと !important は CSS の記述では禁止されています。適切な CSS 記述習慣を身に付けることが重要です。

JavaScript リファクタリング

JavaScript の再構築が急務です。JavaScript の外部リンク ファイルは 41 個あります。もちろん、これらの外部リンクには 15 個の広告外部リンクも含まれています。広告の最適化については後で説明しますが、まだ 26 個の外部リンク JavaScript が残っています。これらの肥大化した JavaScript ファイルは、ページの読み込みをブロックする原因となるだけでなく、システム リソースを占有する寄生虫でもあり、プロジェクト全体の難しさの 1 つとなっています。

4 レベル リンク検索のビジネス ロジックが再編成され、4 レベル リンク検索のインタラクティブ機能が最適化されて、ユーザー エクスペリエンスが向上しました。このモジュールには多くの ajax 相互作用機能があり、最大の JSON データ パケットは 94.4 KB です。このとき、現在のページのキャッシュ機能 ($.fn.data) を合理的に使用することが非常に重要です。ページ Dom Ready の後に最大の JSON データ パケットがロードされ、最初の画面の HTML コードが組み立てられてキャッシュされます。ユーザーがアルファベット順のインデックスでゲームを選択すると、ロードされた JSON データ パケット内で対応するデータが検索されて HTML コードが組み立てられ、インデックスの HTML コードがキャッシュされます。次にリージョン、サーバー、トランザクションタイプを選択すると、サーバーにアクセスして対応するJSONデータを取得し、HTMLコードに組み立ててキャッシュします。このとき、最後に選択した結果のみがキャッシュされます。

コンビニエンス センターも、ホームページ上で非常に複雑なビジネス ロジックを備えたモジュールであり、多くの Ajax 対話とフォーム操作を伴います。各 TAB のフォームは、要求された JSON データに基づいて HTML 構造を生成します。元々は、TAB がクリックされるたびにデータが 1 回要求され、その後 HTML 構造が生成されていました。TAB が切り替えられるたびに、要求してから生成する必要があり、これは非常に不合理でした。同じデータと構造は、一度だけ要求され、一度だけ生成されればよいのです。この繰り返し操作は、リソースの無駄遣いです。このモジュールの JavaScript は、もともと動的サイトのファイルを要求していました。キャッシュや圧縮は行われず、各ページの読み込みはここでしばらくブロックされていました。サーバー側のデータ ソース インターフェイスも非常に乱雑であり、開発者には標準化されたデータ インターフェイスの概念が欠けています。ここには問題が多すぎて、文句を言うのに疲れました。最後に、面倒なビジネス ロジックを再編成し、コードをリファクタリングしました。

最初の画面の読み込み速度を上げるために読み込みを遅らせる

ユーザーが非常に長い Web ページを開くと、最初の画面のコンテンツの読み込みによって最も直感的な速度エクスペリエンスが実現します。したがって、最初の画面をできるだけ早く読み込むことは、ユーザーがページが十分に「速い」かどうかを判断するための最も重要な要素でもあります。 5173のホームページでは、基本的に以下の位置に写真が集中しています。以下の写真の読み込みを全て遅らせることで、最初の画面の読み込み速度を最大限まで上げることができます。一般的な画像遅延読み込み技術については誰もがよくご存知だと思いますので、ここでは繰り返しません。 TAB コンテンツには画像も多く含まれており、TAB メニューが起動されるとここに読み込まれます。 HTML コードで画像に固定サイズを追加することも簡単です。とても簡単？いいえ！

画像には、ビジネス構成画像だけでなく、サードパーティの広告システムからの画像（最初の画面のカルーセル画像を含む）も含まれます。これらの広告画像の URL は、document.write を使用して広告画像を読み込むコードを含む JavaScript リンクです。一部の TAB には、iframe を使用してページに埋め込まれたパートナー サイトのコンテンツも含まれます。広告画像と iframe はページの読み込みをブロックする原因となります。

当初のアイデアは広告システムを再開発し、広告の読み込み方法を変更することでしたが、開発コストが高すぎました。最後に、textarea を使用して広告と iframe の読み込みを遅らせることを考えました。Yu Bo が提供した方法は非常に便利です。 Textarae は良いものです。通常の HTML コードでも、CSS、JavaScript コードでも、それを Textarae に投入して遅延読み込みを実現できます。広告画像の最適化はかなり複雑なので、別の記事で詳しく紹介しています。テキストエリアでは、画像と同様に多くのコンテンツを遅延読み込みできます。TAB コンテンツ内の iframe も、TAB メニューがトリガーされたときに読み込むことができます。

コンテンツの読み込みを遅らせるさまざまなトリックにより、Web ページの最初の画面の読み込み速度が最大化されます。ただし、コンテンツの読み込みが遅れることによる副作用については説明する必要があります。さらに重要なコンテンツについては、SEO への影響を考慮する必要があります。

サーバー側の最適化

フロントエンドで何ができるかについては基本的に説明が終わりましたので、次はサーバー側での最適化作業についてお話しします。サーバーからフロントエンドに提供されるデータ ソースは、すべてさまざまなサイトからのものであることがわかりました。フロントエンドはさまざまな部門の開発者に対応する必要があり、提供されるデータ ソースのパフォーマンスも比較的低速です。交渉の結果、さまざまなデータソースを中間サーバーに集約することが決定されました。フロントエンドはこの中間サーバーからデータを均一に取得し、サーバー間の通信に一定のキャッシュ時間が追加されます。これにより、データソースが遅く一貫性がないという問題が解決されます。

ページが大きすぎるという問題を解決するには、コードをリファクタリングすることでサイズを大幅に削減できます。さらに、すべての静的リソースを gzip で圧縮する必要があります。gzip を追加するだけで、パフォーマンスが大幅に向上します。

ブラウザのキャッシュを適切に使用することも非常に重要です。ログイン情報や Cookie などのより適時性の高いリクエストに加えて、キャッシュ制御を追加できるすべてのリクエストには、最大有効期限が追加されます。ブラウザ側でキャッシュを追加することに関しては、より詳しい記事「可能な場合はキャッシュしてください」があります。キャッシュを追加すると更新時にも問題が発生するため、キャッシュをクリアし、静的リソースのリクエストにタイムスタンプを追加する対応するメソッドが必要です。

また、国内の大規模サイトでは珍しいと思われる、キャッシュ高速化サーバーとしてVarnishを大胆に採用しました。

結果を最適化する

ここまでの作業が終わったら、最適化の結果を見てみましょう。まずは、一連のデータの比較を見てみましょう。

最適化前後のリクエスト数の比較:

リクエスト数が大幅に減少したため、サーバーにかかる負荷が軽減され、多くのサーバーを削除できるようになりました。

Ajax データなどの他のファイルのサイズを除いた、最適化前後の静的リソースのファイル サイズの比較:

ファイルサイズの比較から、最適化によりダウンロード量が 494KB 節約されます。1 日の PV1000000 (推定値、実際の値はこの値よりはるかに大きいため、公開するのは不便です) に基づいて計算すると、毎日 470GB のトラフィックを節約できます。

最適化前後の読み込み時間の比較。これは、同じネットワーク環境で Taobao と Paipai を同時にテストすることによって行われます。テスト ソフトウェアは IE9 ベースの webWatch です。テストごとにキャッシュをクリアし、複数のテストから平均値を取得します。

読み込み速度の分析について言えば、TaobaoとPaipaiは第一画面の写真が多いため、第一画面の速度は速いですが、総読み込み時間ははるかに長くなっています。もちろん、ダウンロード量もはるかに大きいです。5173の第一画面はDOM数が大きく、ダウンロード量がはるかに少ないため、総時間と第一画面の時間がかなり近いです。ここで言う総ダウンロード量は、ページが最初に読み込まれた時点で完了した総ダウンロード量です。遅延読み込み技術を使用しているため、スクロールダウン時に画像の読み込みが発生しますが、この時間は含まれません。

ウェブページの読み込み速度をどのように測定すればよいでしょうか。今回の最適化では、yslow や pagespeed などのテストスコア ソフトウェアは使用しませんでした。代わりに、実際の読み込み速度を最適化の目標としました。最初の画面の読み込み速度を改善するのが最も実用的な説明です。ウェブサイトが開いても画面が真っ白のまま長時間表示された場合、ほとんどの人は動作が遅いと感じると思います。これは実際の経験であり、スコアリング ソフトウェアでは反映できません。

元々は Yuye Daidao のブログに掲載されました

この記事へのリンク: http://stylechen.com/5173homepage-optimized.html

転載する場合は、リンクの形で元の出典または元のアドレスを明記してください。

元のタイトル: ウェブサイト分析: 5173 ホームページ フロントエンド パフォーマンス最適化の実践

キーワード: ウェブサイトのスコア、5173 の最初のページ、フロント ページ、端末のパフォーマンス、最適化、実装、策定、計画、開発、ウェブマスター、ウェブサイトのプロモーション、収益化