Visualforce のパフォーマンス
のベストプラクティス
Salesforce, Summer ’18
@salesforcedocs
最終更新日: 2018/04/20本書の英語版と翻訳版で相違がある場合は英語版を優先するものとします。
© Copyright 2000–2018 salesforce.com, inc. All rights reserved. Salesforce およびその他の名称や商標は、salesforce.com, inc. の登録商標です。本ドキュメントに記載されたその他の商標は、各社に所有権があります。
目次
Visualforce のパフォーマンスのベストプラクティス
. . . 1 このドキュメントについて . . . 1 パフォーマンス上の問題の検出およびテスト方法 . . . 1 Visualforce のパフォーマンス上の問題の調査 . . . 1 一般的な Web 設計のベストプラクティスの確認 . . . 2 Visualforce ページのテスト . . . 2 Visualforce のパフォーマンスを最適化するベストプラクティス . . . 3 アプリケーションパフォーマンスの一般的な設計ガイドラインに従う . . . 4 標準機能の使用とカスタムコードの作成 . . . 4 データサイズの制御 . . . 4 遅延読み込み . . . 5 非同期タスクへの処理のオフロード . . . 5 カスタム設定へのグローバルデータのキャッシュ . . . 5 効率的な Apex および SOQL の記述 . . . 6 効率的な getter メソッドの記述 . . . 6 ビューステートの最適化 . . . 6 コンポーネント階層の最適化 . . . 7 ポーリングの最適化 . . . 7 HTML の最適化 . . . 8 CSS の最適化 . . . 8 JavaScript の最適化 . . . 9 画像の利用の最適化 . . . 9 Internet Explorer のページの最適化 . . . 10 Visualforce のパフォーマンスの最適化に関する事例 . . . 10 その他のリソースおよびツール. . . 10Visualforce のパフォーマンスのベストプラクティス
このドキュメントについて
このドキュメントには、Visualforce ページのパフォーマンスを最適化するベストプラクティスが記載されてい ます。この内容は、『Visualforce 開発者ガイド』のベストプラクティスからの抜粋です。対象利用者
このドキュメントは、Visualforce ページを実装する開発者およびアーキテクトを対象とします。前提条件
このドキュメントは Visualforce および関連した Lightning Platform 技術の基本を理解していることを前提としてい ます。
パフォーマンス上の問題の検出およびテスト方法
このドキュメントに記載されているベストプラクティスに従う前に以下の作業を行ってください。 • パフォーマンス上の問題の原因を判断します。 • パフォーマンス上の問題が Visualforce に起因するものではないときは、ページが Web 設計の一般的なベスト プラクティスに従っていることを確認します。 • パフォーマンス上の問題の範囲と影響をテストします。Visualforce のパフォーマンス上の問題の調査
Lightning Platform 開発者コンソールを使用して、ページ上の Visualforce マークアップおよびその他の Lightning Platform 機能のパフォーマンスを調査します。 開発者コンソールには、サーバが要求を処理する際、要求のパフォーマンスを詳細に記録するデバッグログが あります。この詳細には、メソッド、クエリ、ワークフロー、コールアウト、DML、検証、トリガ、ページの 各実行ステップがそれぞれ種類と時間ごとに表示されるため、次の作業に役立ちます。 • 何がシステムリソースを消費しているのかを確認する • コードの問題を特定する 「開発者コンソールの使用」を参照してください。 1
一般的な Web 設計のベストプラクティスの確認
パフォーマンス上の問題が Visualforce に起因するものではないときは、ページが Web 設計の次の一般的なベス トプラクティスに従っていることを確認します。 • JavaScript および CSS を縮小する • Web 画像を最適化する • できる限り iframe の使用を避ける さらに、HTML、CSS、JavaScript のプロファイルツールやデバッグツールを使用して、ネットワーク待ち時間や 読み込み時間、JavaScript コードの効率性などを把握します。 Google Chrome™開発者ツール Chrome 開発者ツールを使用すると、Chrome™ブラウザやブラウザで実行しているアプリケーションのバッ クグラウンドで何が起きているかを確認できます。 FirebugMozilla® Firefox®のアドオンであるFirebugを使用すると、現在のライブ Web ページをすべて開いたまま、次の
内容を操作および監視できます。
• CSS
• HTML
• JavaScript
YSlow
Yahoo!®のアドオンであるYSlowを使用すると、Web ページのパフォーマンスを向上させる推奨事項が自動表
示されます。 メモ: YSlow を使用するには Firebug をインストールしておく必要があります。 WebPagetest WebPagetestを使用すると、Web ページのパフォーマンスを次の基準で判断できます。 • テスト場所 • ブラウザ • 接続速度
Visualforce ページのテスト
Visualforce ページにパフォーマンス上の問題が生じている場合は、そのページを複数のマシンおよび複数のブ ラウザでテストし、問題が単一ユーザのコンピュータに限定されていないことを確認します。また、他のSalesforce ページやその他の Web サイトの読み込み時間も確認します。Salesforce ページの読み込みに時間がかか
る場合は、http://trust.salesforce.com/trust/status/で Salesforce サーバの状況を確認します。どの Web ページも読み込 みに時間がかかる場合は、ネットワーク設定を確認します。 パフォーマンスをテストして不具合を回避する手順は、次のとおりです。 • HP LoadRunner、Seleniumなどのツールを使用して、一貫性に欠ける結果の原因であると思われる冗長または 複雑なフローのテストを自動化します。自動化されたテストでは、リンクのクリック、データの入力およ び取得、実行時間の記録が行われます。自動テストにより、手動のテストでは見つからなかったボトルネッ クや不具合が検出されることがあります。 2 一般的な Web 設計のベストプラクティスの確認 Visualforce のパフォーマンスのベストプラクティス
• できるだけ多くのブラウザおよびバージョンでテストします。 • ページが無制限のデータを回避し、ページネーションを実装し、関連データのみを表示するものであって も、大量のデータでテストします。これらのテストで、特定のユーザがアクセスするレコードが多すぎた 場合にデータのスキューが生じるシナリオが明らかになることがあります。 • パフォーマンス上の問題が開発者のマシンにはっきりと表れない可能性があるため、実際のモバイルデバ イスでテストします。モバイルクライアントは、プロセッサが低速である、メモリに制限がある、ネット ワーク接続が遅いなどの理由により、それぞれパフォーマンスプロファイルが異なります。また、Salesforce
Mobile Classicアプリケーションが Visualforce Mobile ページを起動する各種の組み込みブラウザは、メーカーや
デバイス、バージョンごとに搭載機能が異なります。 ヒント: モバイルブラウザを初めてテストするときにはWebPagetestなどのツールを使用し、詳しいテ ストには実際のデバイスを使用します。
Visualforce のパフォーマンスを最適化するベストプラクティス
Visualforce ページのパフォーマンスを向上させる次のベストプラクティスを検討します。 • 一般的なガイドラインに従ってVisualforce ページを設計する。 • 標準オブジェクトと宣言機能を使用する。 • Visualforce ページに表示するデータ量を制限する。 • コストのかかる計算やデータの読み込みは後回しにする。 • 非同期タスクに処理をオフロードする。 • カスタム設定のグローバルデータをキャッシュする。 • 効率的に記述する: – Apex と SOQL – getter メソッド • 最適化する: – ビューステート – コンポーネント階層 – ポーリング – HTML – CSS – JavaScript – 画像の利用 – Internet Explorer のページ 3 Visualforce のパフォーマンスを最適化するベストプラク ティス Visualforce のパフォーマンスのベストプラクティスアプリケーションパフォーマンスの一般的な設計ガイドラインに従
う
Visualforce ページを設計するときは、パフォーマンスへの影響を回避する次の一般的なガイドラインに従いま す。 • 特定のタスクを中心に、ワークフローやタスク間の移動が実用的になるようにページを設計します。 • ページに機能やデータを詰め込み過ぎないようにします。Visualforce ページに無制限のデータや、多数のコ ンポーネント、行、項目などがあると、使い勝手やパフォーマンスが低下し、ビューステート、ヒープサ イズ、レコード制限、合計ページサイズなどがガバナ制限に達するおそれがあります。 • 必須ではない機能を含める要求は後回しにします。 • 懸念を確認するプロトタイプを構築します。標準機能の使用とカスタムコードの作成
Lightning Platformプラットフォームのプログラム機能により、容易に機能性をカスタマイズできますが、可能な 限り標準オブジェクトと宣言機能を使用するようにします。承認プロセス、視覚フロー、ワークフローなどの 標準オブジェクトや宣言機能はすでに高度に最適化されているため、通常、ガバナ制限の対象になりません。 概して、標準オブジェクトや宣言機能により、データモデルが簡素化され、ビジネスプロセスに必要な Visualforce ページの数が削減されます。データサイズの制御
Visualforce ページは、15 MB の標準応答制限を超えることはできませんが、それよりも小さなページサイズでも 読み込み時間に影響します。 読み込み時間を最小化するには、次の手法を使用して、各ページに表示されるデータ量をさらに制限します。 絞り込み 絞り込みを使用して、SOQL がコールするデータおよび Apex コントローラが返すデータを制限します。たとえば、WHERE句でANDステートメントを使用したり、null の結果を削除したりします。
キーワード
Apex コントローラを作成する場合、with sharingキーワードを使用して、ユーザがアクセスできるレ
コードのみを取得します。 StandardSetController組み込みページネーション リストコントローラの組み込みページネーション機能を使用して、リストビューに無制限にデータが表示 されないようにします。無制限にデータが表示されると、データセットが増加するにつれ読み込み時間が 長くなったり、ガバナ制限に達したり、使用できなくなったりする可能性があります。デフォルトでは、 リストコントローラはページに 20 レコードを返しますが、多くの開発者は一度に 100 レコードまで表示さ れるようにリストビューを設定します。 ヒント: ページごとに表示するレコード数を制御するには、コントローラ拡張を使用してpageSize を設定します。 SOQL OFFSETページネーション
SOQL OFFSET句を使用して、結果の特定のサブセットにページ設定するロジックを SOQL 内に記述します。
4
アプリケーションパフォーマンスの一般的な設計ガイド ラインに従う Visualforce のパフォーマンスのベストプラクティス
また、編集可能な項目を含む多くのレコードを表示するデータグリッドを使用しないようにします。データグ リッドでは、1 つのページに何千もの入力コンポーネントが展開され、最大ビューステートサイズを超えるこ とも少なくありません。その結果、Visualforce コンポーネントツリーの処理が遅くなります。 Visualforce ページにデータグリッドが必要な場合、次の作業を実行します。 • ページネーションや絞り込みを使用する。 • 可能な場合は、データを参照のみにしてビューステートサイズを削減する。 • 指定されたレコードに不可欠なデータのみを表示し、Ajax ベースの詳細ボックスまたは個別ページのリン クを提供して残りのデータを表示する。
遅延読み込み
コストの高い計算またはデータ読み込みを削減したり、遅延させたりするには、遅延読み込みを使用します。 この手法を使用すると、必要な機能が最初にページに読み込まれ、残りの機能は一時的に遅延されるか、その 情報を必要とするアクションをユーザが実行するまで遅延されます。この手法では、ユーザは必要な機能にす ばやくアクセスできるため、ページ全体を読み込む合計時間は同じでも、大きなページの見かけ上の応答性が 向上します。 Visualforce ページの一部を遅延読み込みするには、次の作業を実行します。 • Visualforce コンポーネントのrerender属性を使用して、ページ全体ではなくコンポーネントを更新する。• JavaScript Remoting を使用して、JavaScript でコントローラの関数をコールし、補助データまたは静的データを
取得する。 • カスタムコンポーネントを作成し、ユーザアクションに応じてデータの表示/非表示を行う。 ページを遅延読み込みする場合、ページを使用することが想定されるユーザ数およびデータ量を考慮し、同時 API コール制限などの制限に注意します。たとえば、ナビゲーションツリーで必要な要素のみが読み込まれる 場合、クエリ数とデータの調和がとれていない状態になる可能性があります。
非同期タスクへの処理のオフロード
コストの高い処理がページにとってあまり重要でない場合、非同期タスクを使用してオフロードします。たと えば、ユーザがボタンをクリックして、長時間実行されるタスクが完了して確認メッセージが表示されるまで 待機するのではなく、非同期で処理できるように、長時間実行されるタスクをキューに入れて、すぐに制御を ユーザに返すことを検討してください。タスクが完了したらメールまたはその他の方法でユーザに通知するよ うにページを設定します。カスタム設定へのグローバルデータのキャッシュ
Visualforce ページでは、グローバルに計算結果が使用される場合があります。つまり、ページでユーザおよび 要求に同じデータが使用されます。このようなページでは、カスタム設定に計算結果をキャッシュして、結果 を要求ごとではなく定期的に更新することで、パフォーマンスが向上します。カスタム設定は、アプリケー ションキャッシュの一部であるため、取得するときにデータベースクエリは必要ありません。このアプローチ とカスタムキャッシュデータの更新時間のバランスを取るようにしてください。 5 遅延読み込み Visualforce のパフォーマンスのベストプラクティス効率的な Apex および SOQL の記述
Visualforce ページで活用する Apex および SOQL は、ページの全体的なパフォーマンスに影響します。 Visualforce ページで使用するために Apex または SOQL を記述する場合、次の作業を実行します。
• 可能な場合は、Apex ではなく、SOQL で計算を実行する。
• ループ内で DML を実行しない。
• SOQL、Apex、Visualforce の順に絞り込む。
たとえば、次のように処理しないでください。
<apex:pageBlockTable value="{!positions}" var="position"> <apex:column value="{!position.name}"
rendered="{!IF(position.Status__c == 'Open - Approved', true, false)}"/> <apex:column value="{!position.Location__c}"
rendered="{!IF(position.Status__c == 'Open - Approved', true, false)}"/> <apex:column value="{!position.Job_Description__c}"
rendered="{!IF(position.Status__c == 'Open - Approved', true, false)}"/> </apex:pageBlockTable> 『Apex 開発者ガイド』および『大量のデータを使用するリリースのベストプラクティス』を参照してくださ い。
効率的な getter メソッドの記述
Visualforce は、評価式、アクション属性、およびその他のメソッドコールを要求します。クラスで複数回 getter メソッドをコールする場合もあります (特に postback (フォーム登録) の場合)。プロパティの計算値をキャッシュ して、プロパティにアクセスする他のコールでキャッシュ値を使用できるようにし、オブジェクトが null の場 合にのみデータをクエリする getter を Apex クラスに設定します。ビューステートの最適化
Visualforce ページの状態を維持するために、Lightning Platform プラットフォームは、コンポーネントの状態、項
目値、およびコントローラの状態を非表示のフォーム要素に格納します。この暗号化された文字列がビュース テートで、135 KB の制限があります。ビューステートが大きいほど、各要求 (逐次化、並列化、暗号化、復号 化など) の処理時間が長くなります。ビューステートのサイズを縮小すると、ページがより迅速に読み込まれ、 表示が停止する頻度が減少します。 開発モードフッターの [View State (ビューステート)]タブを使用して、ビューステートのパフォーマンスを監視 し、次の対処法を実行します。 • 状態の維持に不可欠ではなく、ページの更新時にも不要な変数には、Apex コントローラでtransientキー ワードを使用する。 • ビューステートの大部分をコントローラまたはコントローラ拡張で使用されているオブジェクトから取得 していることが分かった場合は、Visualforce ページに関連するデータのみを戻すように SOQL コールの絞り込 みを検討する。 • ビューステートが大規模なコンポーネントツリーの影響を受けている場合は、ページが依存しているコン ポーネント数の削減を試みる。 6 効率的な Apex および SOQL の記述 Visualforce のパフォーマンスのベストプラクティス
ビューステートを削減する手順は、次のとおりです。 • 絞り込みやページネーションを使用して、データを必要とする状態を減らす。 • 変数が現在の要求にのみ役立つ場合は、transient キーワードを使用してインスタンス変数を宣言する。ビュー ステートには、コントローラと拡張機能のすべての非 transient メンバー、およびこれらの非 transient メン バーからアクセスできるオブジェクトが含まれます。一部のデータを参照のみにすることができ、 <apex:inputField>の代わりに<apex:outputText>コンポーネントを使用できるかどうかを決定しま す。 • 開発モードフッターで [View State (ビューステート)] タブを表示できるように「開発モード」および「開発 モードでビューステートを表示」権限セットを設定する。タブには、ビューステートの配分が表示されま す。各ページのビューステートサイズを把握し、大量のデータでテストして、リリース後に問題が発生す るかどうかを確認してください。
• JavaScript Remoting を使用する。<apex:actionFunction>コンポーネントとは異なり、JavaScript Remoting で
はフォームコンポーネントは必要ありません。この手法でページのビューステート全体を削減することは できませんが、多くの場合、ビューステートを転送、逐次化、および並列化することなくページのパフォー マンスを向上させることができます。このトレードオフとして、re-render 属性を失い、コールバックを処理 する JavaScript コードが増加します。 https://developer.salesforce.com/page/An_Introduction_to_Visualforce_View_Stateを参照してください。
コンポーネント階層の最適化
フラットコンポーネント構造は深い階層コンポーネント構造よりもすばやく処理できます。そのため、カスタ ムコンポーネントのネストを制限して論理的に機能を編成し、ロジックが再利用または別のパッケージに含め ることを目的とする場合にのみカスタムコンポーネントを活用します。広大な階層では、Visualforce は要求全 体でコンテキストを維持することになり、コンポーネント階層のトラバースによって時間やリソースを消費す るため、サーバ側の管理および処理時間が増加します。コンポーネントのネストが深いと、処理コストが高く なります。広大な階層の場合も、ページでヒープサイズのガバナ制限に達する危険性があります。ポーリングの最適化
<apex:actionPoller>コンポーネントは、Ajax 要求を行うタイマーです。<apex:actionPoller>コンポー
ネントを使用するページでは、サーバに対して連続要求を行います。これらの同時要求は、長時間実行される トランザクションになり、他の待機中のトランザクションをブロックする可能性があります。ユーザが長期間 ページを開いたままにしたり、複数の取引先の詳細を取得する場合などに同じページで複数のウィンドウを開 いたりすると、パフォーマンスが低下します。
サーバの負荷を軽減して、ガバナ制限に達しないようにするには、<apex:actionPoller>コンポーネント
のinterval 属性の値を増やして、Visualforce ページから Apex をコールする間隔を延長します。
たとえば、interval属性を 5 秒ではなく 15 秒に調整します。また、Ajax を使用して不要なロジックを非同期 コードブロックにすべて移動したり、同時にタブまたはウィンドウを開いた状態でページをテストして、同じ コンピュータから複数のポーリングがきていないかを確認したりします。 <apex:actionPoller>コンポーネントは、処理コストの高くないページに適していますが、計算により多 くのサーバ時間が必要なページの場合は、代わりに<apex:actionFunction>コンポーネントと JavaScript 7 コンポーネント階層の最適化 Visualforce のパフォーマンスのベストプラクティス
Remoting を組み合わせて使用することを検討してください。この代替方法では、より多くのコードが必要にな
りますが、柔軟性と効率性が向上します。
「Two Visualforce Pages: ActionFunction and JavaScript Remoting (Visualforce の 2 つのページ: ActionFunction と JavaScript Remoting)」 を参照してください。
HTML の最適化
Visualforce ページの HTML を最適化して、Visualforce がページの正確性を検証するサーバ側と、ユーザのブラウザ でのパフォーマンスの応答性を高めるクライアント側の両方で効率的な処理が行われるようにします。 • Visualforce コンポーネントを生成する HTML を確認します。Visualforce ページには有効な HTML が必要です。コ ンパイル時に無効な HTML が修正されている場合、HTML が意図しない方法で表示されることがあります。 たとえば、<apex:page>タグの内側に<head>または<body>タグがあると、実行時に Visualforce ページによってそのタグが削除されます。
• Ajax コードを確認します。Ajax 要求中に、サーバが受信 HTML を検証して修正し、返答が DOM に正確に適合
するようにします。Visualforce ページに有効なマークアップがある場合や修正が不要な場合は、この処理が スピードアップします。 • HTML の膨張を軽減します。ブラウザは HTML とコンパイルされた Visualforce タグをキャッシュしますが、こ れらをキャッシュから取得するとパフォーマンスに影響します。また、不要な HTML によってもコンポーネ ントツリーのサイズや、Ajax 要求の処理時間が増大します。
CSS の最適化
CSS スタイルを使用すると Visualforce ページの外観が向上しますが、かなり重たくなる可能性があります。 Visualforce ページの CSS を最適化して、クライアントに効率的に配信し、キャッシュを向上させ、ブラウザの ページ表示を加速する次のヒントに従います。 • スタイルシートの外部化を検討します。つまり、スタイルをページ自体から切り離し、別個の CSS ファイ ルに配置します。この処理により、初回の HTTP 要求数は増えますが、個々のページサイズは小さくなりま す。ブラウザがスタイルシートをキャッシュした後、全体的な要求サイズが減少します。 • すべての CSS ファイルを 1 つのファイルにまとめて、HTTP 要求数を削減します。 • コメントや空白 (スペース、改行、タブ) を削除後にファイルを圧縮して、ダウンロード時間を短縮します。 • CSS ファイルや、画像、JavaScript、その他の不変のファイルには静的リソースを使用します。スタイルシー トやその他のアセットに静的リソースを用いると、キャッシュや、Salesforce に組み込まれたコンテンツ配 信ネットワーク (CDN) を有効に活用することができます。• Salesforce の CSS ファイルを使用しないページについては、<apex:page>タグのshowHeaders属性と standardStylesheets属性をfalseに設定します。この処理により、標準の Salesforce の CSS ファイル
が、生成されるページヘッダーから除外されます。 ヒント: JavaScript と CSS の場合、開発中に変更を行い、それを処理してパッケージ化し、リリースすると 負担になることがあります。こうした処理については、スクリプトを使用して自動化することを検討し ます。 8 HTML の最適化 Visualforce のパフォーマンスのベストプラクティス
JavaScript の最適化
JavaScript を最適化して、クライアントに効率的に配信し、キャッシュを向上させ、ブラウザのページ表示を加 速します。 • JavaScript ファイルの外部化を検討します。この処理により、初回の HTTP 要求数は増えますが、個々のペー ジサイズが小さくなり、ブラウザのキャッシュを利用することができます。 • 必要な関数に限定した JavaScript ライブラリのカスタムバージョンを構築します。jQuery など、多くのオープ ンソースの JavaScript ライブラリにはこうしたオプションがあり、ファイルサイズを大幅に縮小できます。 • すべての JavaScript ファイルを 1 つのファイルにまとめて、HTTP 要求を減らし、重複する関数を削除します。 関数が重複すると、複数の HTTP 要求が処理され、JavaScript が無駄に実行されることがあります。 • コメントや空白 (スペース、改行、タブ) を削除後にファイルを圧縮して、ダウンロード時間を短縮します。 • スクリプトをページの下部に配置します。終了タグ</body>のすぐ前にスクリプトを読み込むと、ページ に他のコンポーネントが最初にダウンロードされ、ページを順次表示できます。 メモ: ページにマイナスの影響を及ぼさない確信がある場合にのみ、JavaScript をページの下部に移動 してください。たとえば、document.writeを必要とする JavaScript のコードスニペットやイベントハ ンドラは<head>要素に配置したままにする必要があります。 • JavaScript ファイルを含める場合に、<apex:includeScript>を使用するのではなく、終了タグ </apex:page>のすぐ前に標準の HTML の<script>タグを使用することを検討します。<apex:includeScript>タグにより、JavaScript が終了要素</head>のすぐ前に配置されます。この処理
により、ブラウザが他のコンテンツをページに表示する前に JavaScript の読み込みを試行します。 • JavaScript ファイルや、画像、CSS、その他の不変のファイルには静的リソースを使用します。JavaScript やそ の他のアセットに静的リソースを用いると、キャッシュや、Salesforce に組み込まれたコンテンツ配信ネッ トワーク (CDN) を有効に活用することができます。 ヒント: JavaScript と CSS の場合、開発中に変更を行い、それを処理してパッケージ化し、リリースすると 負担になることがあります。こうした処理については、スクリプトを使用して自動化することを検討し ます。
画像の利用の最適化
画像は Web ページ最大のコンポーネントであることが多く、パフォーマンスに多大な影響を及ぼします。 パフォーマンスへの影響を最小限に抑えるために、画像に関する以下のヒントに従います。 • 使用する画像数を減らすと同時に背景のテクスチャを小さくし、可能な場合は画像の代わりに CSS を使用 します。 • 個別の画像の代わりに、CSS スプライトを使用します。CSS スプライトを使うと、ボタンやアイコンなどよ く似たサイズのグラフィックを 1 つのファイルにまとめ、CSS のbackground-imageプロパティや background-positionプロパティを使用して、1 つにまとめた画像を部分ごとに表示できます。この技 法により使用する画像数が減ると、HTTP 要求数も減ります。さらに、画像をまとめたスプライトファイル は通常、極めて簡単にキャッシュされます。 9 JavaScript の最適化 Visualforce のパフォーマンスのベストプラクティス• 画像のほか、CSS、JavaScript、その他の不変のファイルには静的リソースを使用します。画像やその他のア セットに静的リソースを用いると、キャッシュや、Salesforce に組み込まれたコンテンツ配信ネットワーク (CDN) を有効に活用することができます。 • 画像を圧縮します。グラフィックツールは通常、圧縮することよりも視覚的に正確であることを優先する デフォルト設定を使用し、画像の保存時にメタデータを追加します。画像圧縮ツールを使うと、画質を損 なうことなく画像ファイルを 10～30% 圧縮できます。 ヒント: 開発ワークフローに画像アセットを圧縮するスクリプトの追加を検討します。
Internet Explorer のページの最適化
組織で Microsoft® Internet Explorer®を使用している場合は、Visualforce ページを次の方法で最適化します。
• AlphaImageLoader条件は使用しないでください。この条件によって表示が妨げられ、画像のダウンロー
ド中にブラウザがフリーズします。また、メモリの消費量が増え、メモリが画像ごとではなく要素ごとに 適用されるため問題が倍増します。
• 追加のスタイルシートを含めるには、@importの代わりに<link>を使用します。@importを使用する
と、ダウンロードの順序が変更され、順次表示が阻害されます。 • CSS 式は回避します。この式により CSS プロパティを動的に設定できますが、Internet Explorer はこの式を予想 を上回る頻度で評価します。
Visualforce のパフォーマンスの最適化に関する事例
実際の状況でこれらのベストプラクティスがどのように連携するのかを理解するために、顧客がデータグリッ ドを備えた Visualforce ページを使用して売上予測を収集する場合を考えます。売上予測のデータモデルには、 マルチレベルのオブジェクト階層が含まれています。ページには、ピボットデータを表示するための計算も含 まれています。平均的なユーザの場合、グリッドに約 1,500 個のセルが含まれるため、ページの読み込みが遅 くなり、ヒープおよびビューステートの制限に達します。 同じような状況でページのパフォーマンスを最適化するには、次の作業を実行します。 • ページのタスクに集中させて、入力用のみに使用する。入力と一部の集計レポートの両方にページを使用 すると、必要以上に作業が複雑になります。 • カスタムオブジェクトを作成して、レポートの集計データを保持する。集計情報の表示に必要な数式を削 除して、ヒープサイズを削減します。 • 一部の設計要件 (特にページネーション) を緩和する。 • 1 つのページにすべての取引先を表示しないようにする。この方法により、ページ読み込み速度とビュース テートサイズの両方を改善できます。 • データグリッドセルを参照のみにする。編集はセルをクリックして、編集の保存は Ajax を使用して行うよ うにします。これらの方法は、ビューステートに大きな影響を与えます。その他のリソースおよびツール
Web ページのパフォーマンスの最適化についての詳細は、次を参照してください。 10 Internet Explorer のページの最適化 Visualforce のパフォーマンスのベストプラクティス• Steve Souders のブログ「High Performance Web Sites (高パフォーマンスの Web サイト)」 • Exceptional Performance team - Yahoo! (卓越したパフォーマンスチーム - Yahoo!) Developer Network
• Two Visualforce Pages: ActionFunction and JavaScript Remoting (Visualforce の 2 つのページ: ActionFunction と JavaScript Remoting) • An Introduction to Visualforce View State (Visualforce ビューステートの概要)
11
その他のリソースおよびツール Visualforce のパフォーマンスのベストプラクティス
