シングルページアプリケーション(SPA)の負荷テスト

シングルページアプリケーション(SPA)は、時にはシングルページインターフェース(SPI)とも呼ばれ、個別のページに「収まり」、ページを動的に更新するウェブアプリケーションまたはウェブサイトです。新しいページを読み込む代わりに更新されます。SPAの主な利点は、より反応が良くスムーズなユーザー体験を提供することです。SPAのコンセプトは15年以上前から存在していますが、ここ数年でようやく注目を集めています。技術とフレームワークの進歩により、SPAは開発者や組織にとって現実的な選択肢となりました。シングルページアプリケーションはクライアントサイドレンダリングとAPIコールに大きく依存しているため、正確なパフォーマンス測定には実ブラウザベースの負荷テストが不可欠です。

AngularJS、Ember、Ext JS、Knockout、React、そしてVueなどのウェブブラウザのJavaScriptフレームワークはすべてSPAの原則をサポートしています。世界最大級の企業のいくつかもSPAを利用しており、Google(Gmail)、Netflix、Facebook、Trello、Twitterなどが含まれます。

LoadViewによるJMeter負荷テスト

LoadViewでJMeter負荷テストの制限を克服

マルチページアプリケーション: 簡単なまとめ

ほとんどのウェブサイトやアプリケーションは次のように動作します。ユーザーはブラウザを使ってインターネットにアクセスし、ウェブアドレスを入力します。その時、ブラウザはサーバーにリクエストを送り、ホームページを送ってもらいます。ページが読み込まれた後、ユーザーはページ内をナビゲートしながらサーバーに追加のリクエストを送ります。クリックや検索などのアクションは別のページリクエストの結果となります。この方法はマルチページアプリケーション(MPA)として知られており、多くのウェブサイトやアプリケーションが今日もこのように構築されています。

シングルページアプリケーション: 次の大きなトレンド

Testing Page Applications
一方、シングルページアプリケーションは全く異なるアプローチを使用します。通常のユーザーは違いに気付かないこともあります。もし気付くとすれば、初期ページが読み込まれた後でブラウザのリフレッシュボタンを押しても再読み込みされないことに気付くでしょう。SPAではブラウザがJavaScriptプログラムを瞬時にダウンロードし、保存し、バックグラウンドで実行します。これはユーザーがコンピューターにアプリケーションをダウンロードしてインストールしたかのような完全なアプリケーションですが、今回はブラウザ内で動作しています。

このアプリケーションが動作している限り、ページは再読み込みする必要はありません。プログラムがユーザーに見せるすべてを制御し、必要に応じてサーバーと通信します。ページは実際には再読み込みされず、DOMの一部だけが変わります。これにより多くの帯域幅、時間が節約され、最も重要なのはユーザーにより滑らかな体験を提供します。さらに、SPAが読み込まれた後は一般的にインターネット接続がない場合でもブラウザ内で動作可能です。負荷テストにはナビゲーション、フィルタリング、動的更新といったユーザーインタラクションを含め、実際の使用パターンを反映させるべきです。

MPAとSPAの比較: 利点と欠点

素晴らしいことに聞こえますよね?ではSPAに欠点はないのでしょうか?人生のすべてと同様に、いくつかの欠点があり、ここではそのうちのいくつかを紹介します。

  • SPAはSEOに問題を抱えやすい
    • SPAはページのコンテンツを非同期に読み込むため、ページの更新なしにアプリケーション内のデータが更新されます。SEOクローラーはJavaScriptに依存しているためこれを好みません。SPAの場合、ページが読み込まれた時点でクローラーの作業は終了と見なされ、クローラーはユーザーがページをナビゲートするとデータが変わることや、そのデータが最終的にページにレンダリングされることを認識しません。
  • SPAはJavaScriptなしでは動作しない
    • ほとんどのページでJavaScriptは有効ですが、もしJavaScriptがオフの場合、ページは機能しません。
  • SPAは最新のブラウザを優先する傾向がある
    • 可能な限り多くのブラウザバージョンで対応させたい場合は制限になる可能性があります。対応していない環境に直面することもあります。こうした場合、MPAの方がより良い選択肢となり、既存のフレームワークやベストプラクティスも豊富です。新しい開発者にとってはMPAでの開発の方が扱いやすいでしょう(とはいえ、MPAでもSPAでもAPIの監視は重要です)。

結論: SPAの負荷テストに最適な選択とは?

ご覧の通り、MPAかSPAかを決める前にアプリケーションの目的を考慮する必要があります。サイトをシングルページ体験として開発できるならSPAがおそらく最適です。複数のカテゴリや豊富なコンテンツを持つオンラインショップの場合はMPAの方が適しているかもしれません。いずれにせよ、アプリケーションを本番環境に投入する前には、特に負荷テストやストレステストを実施し、ユーザー体験がスムーズであることを確認しなければなりません。

SPAの目標は、応答性が高く機能重視のユーザー体験を提供することです。SPA開発にかけた労力が無駄にならないように、SPAは本番環境に近い負荷下での最高のユーザー体験を保証するために負荷テストを行うことが重要です。訪問者に最高の体験を提供するために、アプリケーションが要求に耐えられるか必ず確認しましょう。

LoadViewプラットフォームは他のウェブアプリケーションと同様にSPAをテストでき、JavaScriptフレームワークやAJAX、Flash、HTML5、WebSocketsなどのプロトコルと技術をサポートしています。多段階のアクションや動作をすばやく簡単にスクリプト化し、仮想ユーザーを起動し、実ブラウザで負荷をかけてそれらのタスクを実行できます。これにより最高品質のレポートデータが得られ、お客様や訪問者の要求に耐えられるアプリケーションであることが保証されます。

モダンアプリケーション向けのパフォーマンステスト

市場にある他の負荷テストツールは、例えばJMeterを利用するものがあり、プロトコルベースのリクエスト実行には十分ですが、JMeterはブラウザではなくプロトコルレベルで動作しJavaScriptを実行できないため、SPAの負荷テストには適していません。回避策はありますが、熟練エンジニアや開発者がいても時間とリソースがより多く必要になります。これはLoadViewのようなソリューションを使うよりも直感的でも簡単でもありません。ハードウェアリソースの設定やローカルデバイスからの負荷注入器の作成はもう不要です。従来のウェブパフォーマンスツールは最新のフレームワークや技術での訪問者視点からの体験をシミュレートできません。LoadViewは重要なユーザーシナリオのスクリプト作成から負荷テストの設定および実行を20以上の世界中のロケーションから簡単に行えます。

本日から無料トライアルで始めて、初回の負荷テストに最大5回の無料テストを提供します。またはLoadViewソリューションのデモをご希望でしょうか?パフォーマンスエンジニアチームがLoadViewソリューション全体をご案内いたします。ご都合の良い日時を選択していただければ、チームがご質問に全てお答えします。今すぐデモを予約してください!