レベル: 中級 Judith Myerson (jmyerson@bellatlantic.net), Systems engineer and architect
2007年 10月 30日 開発者にとって、ブラウザー、コンピューター・モデル、そして Ajax アプリケーション・ユーザーのどれもがすべて同じだったら楽だと思いませんか? それはそうかもしれませんが、現実は違います。開発者がブラウザー、コンピューター、個々のユーザー設定の違いに関わらず、期待どおりに振る舞うアプリケーションを開発しようとするときには、数え切れないほどの難問に直面します。例えばユーザーがあるブラウザーからタイプの異なるブラウザーに Ajax アプリケーションを対応させる場合 (特に、Ajax アプリケーションを Web サービス・ポータルへ移す場合)、同じブラウザー・エクスペリエンスは保証されません。ブラウザーにはそれぞれ固有の制約があるためです。この記事では著者の Judith Myerson がブラウザー固有の制約と避けなければならない落とし穴、そしてブラウザー間の違いを克服するために役立つソリューションを簡単に説明します。
はじめに
あらゆるタイプのコンピューター、ブラウザー、ユーザーを対象に最適化した Ajax アプリケーションを開発するときには、いくつかの難問に直面することを把握しておいてください。ユーザーと開発者の双方が複数のブラウザーを扱うのは珍しいことではありませんが、ユーザーがタイプの異なるブラウザーへのアプリケーションの対応を頻繁に行うとなると、Ajax 開発者にとっては問題になります。それぞれのブラウザーには元々備わった固有の制約があり、それによって Web ページ上での Ajax アプリケーションの表示の仕方 (さらにはパフォーマンスでさえ) が影響されるため、ユーザーにブラウザー間での完全な等価性を提供することができないからです。
一般的なブラウザーとしては Microsoft® Internet Explorer®、Opera、Firefox、Konquerer などが挙げられます。Linux® 上でのみ動作する Konquerer は除き、以上のブラウザーは Windows®、Linux、そして Apple の Mac OSX で動作します。このように今日ではさまざまなブラウザーが使用されているため、開発者としては、よく使われるブラウザー間に存在する数多くの違いをしっかりと理解しておくことがプラスになります。この記事は、コンピューターのタイプによるハードウェア上の違い (メモリー、ディスク・サイズ、USB ポートの数を含む)、そしてソフトウェア上の制約 (フォントの可用性、HTML 拡張機能、フォーム要素など) を認識する上で役に立ちます。この記事では各コンピューター・システムでのパフォーマンス上の問題を検討した後、ユーザーがアプリケーションをタイプの異なるブラウザーに対応させる際にブラウザー間の違いを克服するためのソリューション、そして Ajax アプリケーションを Web サービス・ポータルにする場合に考えられるソリューションを説明します。さらに、Ajax 開発で陥りがちな落とし穴 (そしてその回避方法) についても学びます。
あまりにも多くのコンピューター･タイプに限られた時間で対応するには
開発者の多くは PC を使用して Web ページを Ajax ポータルに変換しますが、Macintosh ユーザーもこの種の変換は行います。同じブラウザーの最新バージョンを使用して、PC と Macintosh システムの両方で Web ページを表示してみると、それぞれのコンピューターでページの表示が異なっていることに気付くはずです。さらに、PC と Macintosh のどちらも、モデルによって画面サイズおよび対応するキャンバスは異なります。そのため、特定モデルの Macintosh コンピューターと特定の PC モデルとでは、設定が同じであってもキャンバス・サイズと解像度が大幅に異なってきます。このようなコンピューターのタイプとモデルによる違いは、フォントの表示だけでなく、その他多くの設定にも影響を与える可能性があります。
 | | ユーザーがどのブラウザー、オペレーティング・システム、コンピューター製品を選ぶかに関わらず、常に一貫して振る舞い、期待どおりのユーザー・インターフェースを表示する Ajax アプリケーションを作成するには、検討すべき事項がたくさんあります。この記事から、アプリケーションを最適化して最大限のパフォーマンスと使いやすさを引き出すために念頭に置いておくべき事項に関するヒントを得てください。 |
|
Ajax アプリケーションを開発するときには、ユーザーによって解像度の設定が大幅に異なる (800x600 と 1024x768 など) という前提で、ページの幅と高さ、そしてアプリケーションの表示方法を検討することが必要です。高解像度の設定で適切に表示されるアプリケーションの場合、コンピューターの解像度を低く設定しているユーザーは始終スクロールしなければならなくなります。けれどもアプリケーションに必要なスクロール操作が多すぎると、サイトにアクセスする人が減ってしまう恐れがあります。
メモリーとディスク・スペースの違い
ユーザーのメモリーが複雑な計算を実行するには足りない場合、コンピューターは計算を完了するためにディスク上のスペースを探します。計算処理が完了する前にメモリーあるいはディスク・スペースのいずれかの割り当て部分が使い果たされてしまうと、ユーザーはメモリーまたはディスク・スペースが不足したというエラー・メッセージを受け取ることになります。
Ajax アプリケーション内でこのような問題が発生する根本的な原因は、Ajax アプリケーションがどのようにメモリー、ディスク･スペース、そしてその他のシステム・リソースを扱うかに関わっています。開発者が取り得る手段は、計算を完了するために必要なシステム・リソースへの負荷を軽減するか、あるいはアプリケーションを修正するかのいずれかです。システム過負荷の原因と考えられる負荷を軽減するには、例えば不要なファイルをクリーンアップしたり、サイズの大きな Ajax アプリケーションを保管および実行するための外部 USB ディスク・ドライブを接続する必要があります。一方、アプリケーションを修正する場合には、例えばアプリケーションを複数のモジュールに分割し、それぞれのモジュールごとに例外処理を行うようにします。こうすると、問題の原因が特定しやくなります。
USB ポート
コンピューターに搭載された USB ポートが多ければ多いほど、接続できる USB デバイスの数も増えます。最適なコンピューターには、より強力な USB デバイスに対応するポートが少なくとも 2 つは必要になります。USB デバイスの一例は Y ケーブルで外付けする 120MB USB 外部ディスク・ドライブで、このデバイスは Ajax アプリケーションを保管および実行するための内部ディスク・スペースが足りなくなった場合に役立ちます。コンピューターで提供可能な最大 USB ポート数より多くのポートが必要な場合は、USB ハブを使用するという手もあります。ハブに Y ケーブルが付属していれば、両方ともコンピューター上の USB ポートに接続することができます。
注: アダプターが付属していないハブに大容量の外部ディスク・ドライブを接続した場合、ハブが外部ドライブに必要な電力を十分に供給できないと、外部ドライブも Web サービス・ポータルもどちらも機能しないことになります。外部ドライブを機能させるには、アダプターによりもっと大きな電力を供給可能な USB ハブが必要です。
フォントに関する問題
フォントの 2 つの問題、可用性と互換性について考えてみましょう。
フォントの可用性
Windows 対応 Internet Explorer と Macintosh 対応 Internet Explorer (または Navigator) とでは、同じテキストでもその表示は異なってきます。具体的には、特定のフォント・サイズに設定されたテキストは、Macintosh コンピューターでは PC で表示された場合よりも小さく見えます。開発者として知っておかなければならないのは、同じテキスト・サイズ変更手段を使用した場合に PC と Macintosh コンピューターのそれぞれで設定可能な最大テキスト・サイズです。また、ある特定の PC ユーザーが設定したブラウザーの表示フォントが、他の PC モデルや Macintosh コンピューターでは使用できない可能性もあります。特定のフォントが特定のコンピューターで使用できない場合、フォントは該当するコンピューターでのデフォルト・タイプに設定されます (Windows PC でフォントの可用性を判断するには、スタート・メニューのコントロール パネルからフォント・アイコンを選択してください)。
フォントの互換性
大多数の開発者は、ブラウザーやプラットフォーム間でテキストを同じサイズにするのは難しいと考えます。問題は、フォント・サイズの調整方法がブラウザーによって異なるという点です。例えば Windows 環境の Internet Explorer に用意されているのは、最大、大、中、小、最小という 5 つのサイズです。Mozilla Firefox ではユーザーがフォント・サイズを拡大縮小したり、元のサイズに戻したりすることができます。一方、Opera ではユーザーがリストからパーセンテージを選択してフォント・サイズを調整します。そのため、アプリケーションに書き込まれたフォント・サイズが変更されると、結果的なフォントのサイズはブラウザーによってまちまちになります。
フォント・サイズを記述的な値 (中など) に設定したとしても、ブラウザーによって表示結果は異なります。複数のブラウザーでテキストを同じサイズにするために取れる 1 つの手段は、カスケーディング・スタイル・シート (CSS) でフォントのサイズをパーセンテージまたは em 値のいずれかで変更することです。それでも上手くいかない場合は、最後の手段として画面解像度を基準とした相対ピクセル・サイズを使用してください。
HTML 標準
Ajax アプリケーションは JavaScript および XML の他、HTML、DHTML、DOM (Document Object Model) を使用します。HTML を使用する目的は Web フォームを作成するため、そして DHTML を使用する目的は HTML にマークアップを追加してフォームが動的に更新されるようにするためです。DOM は HTML とサーバーから返された XML の構造を扱います。そこで問題となるのが、新しくなった標準とフォーム要素は普遍的ではないということです。
最新バージョンの HTML
HTML 標準の新しく更新された部分によって表示される Web ページは、新しいブラウザー・バージョンでのほうが見栄えがいいため、ほとんどのユーザーは自分たちのお気に入りのブラウザーをアップグレードします。しかし、ブラウザーがその最新バージョンで新しい標準を完全にサポートしていないことは珍しくありません。実際のところ、これらの標準は通常、ブラウザーがサポートする内容より高度になっているためです。最新バージョンの HTML 標準を 100% サポートするブラウザーはまだありませんが、一部のブラウザーは他よりも完全サポートに近づいています。
最新 HTML タグのサポートはまだ一般的になっていないため、すべてのブラウザーが理解するわけではない言語のパーツでページを作成してしまう可能性があります。ブラウザーがページの一部を変換できなければ、ブラウザーは期待通りにページを表示できません。一例として、Internet Explorer でオーバーラップ層を使用すると、同じブラウザーの前のバージョンや異なるタイプのブラウザーではこれらの層が正しく変換されないことがあります。例えば Opera と Firefox では、Internet Explorer では表示されないオーバーラップ層の一部分が表示されるといった事態です。ページを一般使用に向けてリリースする前に、Web 開発ソフトウェア (Microsoft Expression® Web など) を利用して複数のブラウザーでページをプレビューすることをお勧めします。
フォーム要素
HTML 標準のバージョンだけではなく、使用しているブラウザーによってもフォーム要素のサイズ、スペーシング、そしてタイポグラフィーは異なる場合があります。フォーム要素は、プルダウン・メニューやテキスト入力フィールド、そして他のフォーム要素がどれだけのスペースを占有できるかを左右します。あるブラウザーではページ上でのフォーム要素の表示に満足したとしても、同じフォーム要素を別のブラウザーで使ってみると、フォーム要素が思ったように表示されないという可能性はあります。
パフォーマンス上の問題
アプリケーションを実用に向けてリリースする前には、検討しなければならないパフォーマンス上の考慮事項がいくつかあります。そのなかに含まれるのが、使用するブラウザーの処理速度、大きな XML ファイルのサイズ、そしてアドオンの影響です。
ブラウザーの処理速度
私の考えでは、Windows アプリケーションで最も優れたパフォーマンスを発揮するブラウザーは Opera です。Firefox と Internet Explorer を比べると、速度の点ではそれほど変わりませんが、標準のサポート、セキュリティー、機能という点で Firefox のほうが賢い選択だと思います。ただし、Opera の速度には及びません。Linux アプリケーションの場合はどうかと言うと、KDE で基本的なページを開いて表示する際には Konqueror が最も短時間で処理すると思いますが、スクリプトや画像が関わってくると途端に Opera のほうが速くなります。Firefox のパフォーマンスは全体的に優れているとは言え、スクリプト、キャッシュの処理、あるいは画像ベースのページの処理速度にかけては Opera に追いつきません。Mac OS X では、Opera と Safari はどちらも非常に高速です。具体的には、Safari 2 は CSS のレンダリングに優れている一方、Opera は表、スクリプト、履歴のレンダリングの点で勝っています。Navigator は、Mac OS X アプリケーションでは Firefox や Internet Explorer よりも人気が高いようです。
Opera はアプリケーションを実行するには最もパフォーマンスに優れたブラウザーだと思いますが、入力サイズを調整するズーム機能の使いやすさに関しては、Internet Explorer の入力サイズ・オプションや Firefox の Ctrl オプションに及びません。また、Microsoft Expressions Web 設計ツールを使って Web ページをプレビューする場合、Opera はオプションとしてリストされません。
XML ファイルのサイズ
サイズが大きなテキスト・ベースの XML ファイルを使用すると、ブラウザーの応答時間が遅くなったり、ネットワーク・トラフィックが停滞してしまうこともあるため十分注意してください。大規模なテキスト・ベースの XML ファイルの代わりに使用できるのは、バイナリー XML です (「参考文献」セクションに記載した私の記事、「Web サービスの脆弱性を避けながら Ajax アプリケーションをスピードアップさせる」で詳細を説明しています)。
ブラウザーのアドオン
ポップアップ・ブロッカー、タブ・マネージャー、UI テーマなど、ブラウザーに用意された多くのアドインは、Ajax アプリケーションに意外な形で影響することがあります。例えば、ポップアップ・ブロッカーを設定して新しいブラウザー・ウィンドウが開かないようにすることができます。しかし、すぐには気付かないかもしれませんが、ポップアップ・ブロッカーはブラウザーのウィンドウ領域を使用するため、アプリケーションを部分的に隠してしまいます。ブラウザーが部分的に使用されると、Ajax アプリケーションが意図されたように表示されなくなる恐れがあります。
10 のヒントと落とし穴
以下に、最適化した Web ページを作成するために役立つヒント、そして注意しなければならない落とし穴をリストします。これらの提案は、Ajax アプリケーションのユーザーにとっても役に立つはずです。
-
開発者: HTML 拡張機能は使用しないようにして、主要なブラウザーのすべてでサポートされているとは限らない最先端の言語機能は慎重に使用すること。
-
開発者: 最新バージョンのブラウザーがサポートする HTML 機能を早速使ってページを作成しようとしないこと。
-
開発者: 主要なブラウザーの 1 つ前のバージョンにも有効なページを設計すること。
-
開発者: メモリー、ディスク、そしてその他のシステム・リソースの消費を最小限に抑えて負荷を軽減すること。
-
開発者およびユーザー: Ajax アプリケーションの更新が必要な場合には、Ajax アプリケーションを再起動して更新すること。最終手段としては、コンピューターをリブートすること。
-
開発者およびユーザー: アプリケーションを最適な状態で実行するために、未使用または不要なコンピューター・ファイルを定期的に削除してディスク・スペースを解放すること。
-
開発者およびユーザー: メモリーを増設するか、120MB の外部 USB ハード・ドライブを接続すること。
-
開発者: Ajax ポータルを対象に Web ページを設計する際には、層のオプションを単純化すること。
-
開発者: 問題の原因を特定しやすくするために Ajax アプリケーションをモジュール化すること。Ajax アプリケーションには例外処理も組み込むこと。
-
開発者: テキスト・サイズの問題を避けるために、アプリケーションのフォント・サイズは CSS を使ってパーセンテージまたは em 単位の値で設定すること。最後の手段としては、ピクセル・サイズを使用すること。
まとめ
Ajax 開発者が Ajax アプリケーションの開発をする際、また Ajax アプリケーションを Web サービス・ポータルにする際には、開発者、テスター、システム管理者、潜在的ユーザーからの情報がブラウザーの違いを克服する助けとなるはずです。ブラウザー間の違いが構築する Ajax アプリケーションに与える影響を最小限に抑えるには、作成、テスト、そしてデプロイメントについての十分な計画が不可欠であり、そうすることによってアプリケーションの最適なパフォーマンス、そして最大限の予測可能性を達成することができます。
参考文献 学ぶために
製品や技術を入手するために
-
IBM製品の試用版のダウンロード: 次期開発プロジェクトの構築に、developerWorks から直接ダウンロードできるIBM の試用版ソフトウェアをご利用ください。
議論するために
著者について | | | Judith M. Myerson はシステム・アーキテクト兼システム・エンジニアです。ミドルウェア・テクノロジー、企業単位のシステム、データベース・テクノロジー、アプリケーション開発、ネットワーク管理、セキュリティー、RFID テクノロジー、そしてプロジェクト管理を含む数多くの分野を得意としています。 |
記事の評価
| 
