つまり、パフォーマンスは本当に重要です。
私のゴールデン ルールは非常に単純です。すべてを測定し、すべてを最適化する必要があります。これは純粋な技術的な課題であるだけでなく、ビジネス チームにも関係します。以下は、Velocity Conf の典型的な例です。
- Bing – ページが 2 秒遅くなると、ユーザーあたりの収益が 4.3% 減少しました。
- Google – 400 ミリ秒の遅延により、ユーザーあたりの検索数が 0.59% 減少しました。
- ヤフー!– 400 ミリ秒の速度低下により、ページ全体のトラフィックが 5 ~ 9% 減少しました。
- Shopzilla – サイトを 5 秒高速化すると、コンバージョン率が 7 ~ 12% 向上し、検索エンジン マーケティングのセッション数が 2 倍になり、必要なサーバーの数が半分になりました。
- Mozilla – ランディング ページを 2.2 秒短縮したことで、ダウンロード コンバージョンが 15.4% 増加しました。これにより、Firefox の年間ダウンロード数が 6,000 万回増加すると見積もられています。
- Netflix – 単一の最適化である gzip 圧縮を採用した結果、13 ~ 25% のスピードアップが実現し、アウトバウンド ネットワーク トラフィックが 50% 削減されました。
業界全体で一般的に測定されるものは何ですか?. いつ行うべきかについて、何か推奨事項はありますか?
Web パフォーマンス最適化のパイオニアである Steve Souders によると、「エンドユーザーの応答時間の 80 ~ 90% はフロントエンドで費やされています」 最初にここから始めてください: 要求が多すぎる、最適化されていない画像、縮小されていないコンテンツ (js/css) 、cdn を介して静的を配布しないでください。これは一般的なエラーです。
一方、バックエンドを忘れないでください。この部分は負荷とアクティビティに大きく依存するためです。一部のサイトは、バックエンドの問題により、最大のパフォーマンス税を支払っています。ページ生成時間はユーザーの負荷に比例して増加するため、アプリのスループットのピークを見つけて、独自の SLA で問題ないかどうかを確認する必要があります。
同じためのツールの推奨事項はありますか?
すべてのトピックをカバーする魔法のツールはありませんが、アプリの特定の部分に役立つ優れたツールはたくさんあります。
- ページ レンダリング: Google Chrome SpeedTracer または IE 11 UI 応答性ツール
- フロントエンド : PageSpeed、YSlow、WebPageTest.org (オンライン)、GtMetrix (オンライン)、Pingdom (オンライン)
- バックエンド: asp.net Mini-Profiler、Glimpse、Visual Studio Profiler & Visual Studio Web/Load Tests
- RUM 向け Google アナリティクス (リアル ユーザー モニタリング)
クライアントが応答を受信した後、Visual Studio Web テストを使用して、Web ページの読み込み/レンダリング時間に関するパフォーマンスを測定できますか? それとも単に http 応答時間ですか?
いいえ、Visual Studio Web & Load Test は HTTP 要求のみに焦点を当てています。Javascript は実行されず、仮想ユーザーは仮想ブラウザではありません。ページのロード/レッドナー時間を測定することは不可能です。私の会社では、統合テストと負荷テストにのみ使用しています。
もっと読みたい場合は、この投稿を見ることができます(免責事項: 私は著者です)。もう 1 つの興味深いリンクは、Jeff Atwood (StackOverflow の共同創設者) からのものです。Performance is a feature です。
パフォーマンスは膨大なトピックであり、ここではごく一部しか取り上げませんが、出発点としては適切です。