ポイント 1 は、Citrix サーバーから Citrix クライアントへのホップには役立ちません。Citrix サーバーでのページの読み込みが速くなるという意味では役立ちますが、HDX を介してクライアントに再送信されると、クライアントに表示されるページを取得する速度はまったく同じになります。
したがって、#1 は価値がありますが、Citrix を介して配信するのではなく、Web ページの任意のクライアントにこの最適化を適用するという一般的な意味でのみです。
ポイント 2 はポイント 1 と多少似ているため、同じコメントが適用されます。ただし、グラフィックスを再レンダリングして HDX パイプに送信すると、確実にパフォーマンスに影響します。これを拡張して、使用するグラフィックスの量 (数とサイズ) を減らし、使用する画像の複雑さも減らしてください (つまり、単純な画像ほど圧縮しやすい)。また、ページの変更を最小限に抑えます。たとえば、アニメーションなどはパフォーマンスを低下させます。
HDX は独自の画像圧縮を行うため、ページの視覚的な複雑さを軽減するために行うことはすべて、HDX によるより良い圧縮を可能にします。
ポイント 3: Web コンテキストでの遅延読み込みに慣れていない。そうでなければ画面にレンダリングされる視覚要素をロードしていない場合は、確かに役立ちます。ただし、必ずしもページを視覚的により複雑にするわけではないバックグラウンド データの読み込みについて話している場合、それは役に立ちません。
簡単に言えば、HDX は Web ページの画像をキャプチャし、それらの画像を再送信するものと考えてください。これらの「画像」の視覚的な複雑さを軽減し、圧縮可能にするために行うことはすべて、パフォーマンスを向上させます。ただし、画像の再送信は、HDX にとって最悪のケースです。可能な場合は最適化を試みて適用します。たとえば、アプリ (この場合はブラウザー) が GDI を使用してレンダリングを行う場合、適用できる最適化のクラスがあります。また、Web ページでの画像スクロールをより効率的にするための IE 固有の拡張機能もあります。
確かに、プロトコルは長年にわたって強化され、改善されているため、前回見たものよりもパフォーマンスが向上していることを期待する必要があります. また、XenApp コンソールでポリシーを試してみてください。操作できるポリシー (画像圧縮など) は多数あります。