サーバーの CPU と RAM が軽量なブラウザを使用している場合でも、この場合、制限要因はネットワークであることは否定できません [1]。避けたいのは、不要な画面レンダリングです。
- 「スムーズ スクロール」などの機能をオフにします。選択できる場合は、継続的にスクロールする代わりに PgUp/PgDn を使用してください (ページ全体を表示するためだけに 30 回の画面更新よりも 1 回の画面更新の方がはるかに高速です)。
- ブラウジング ウィンドウは小さくしてください (ただし、それほど小さくないため、前のポイントのようにスクロールする回数が多くなります)。
- アニメーション素材をブロックします (アニメーション GIF は最近ではあまり一般的ではないため、フラッシュをブロックするだけで十分です)。
- 画像転送を巧妙に圧縮する VNC の使用を検討してください。これにより、低速の接続で GUI を使用する必要がある場合に、よりスムーズなエクスペリエンスが得られます。
- すぐにやらなければならないことがある場合、テキストベースのブラウザを過小評価しないでください サーバー。
- SSH を介したプロキシおよび/またはポート トンネリングは、問題を完全に回避します。情報を転送するだけで、プレゼンテーション レイヤー全体を転送する必要はありません。
[1]:とても 高速接続 (私の経験では ~100Mbps);そうすれば、ブラウザをローカルで使用するよりも煩わしくならずに、おそらくどのブラウザでもうまくいくでしょう。私は遠隔地のニーズにこれに恵まれています.
X11forwarding が遅延を示している主な理由は、実際のブラウザー自体ではなく、接続に使用している暗号によるものです。
暗号化をarcfourまたはblowfishに変更すると、パフォーマンスが大幅に向上します.
私は同じ問題を抱えていましたが、これによりすべてのラグがほとんど解消されたことがわかりました.欠点は、これらの暗号が一般的なデフォルトである AES ほど安全ではないことです。
パテを使用している Windows マシンを使用している場合は、 Connection/SSH/ で暗号化の選択ポリシーを変更できます。また、同じ画面で圧縮を有効にして、ロードしている接続のデフォルトとして保存する必要があります。
ある Linux マシンから別の Linux マシンに接続している場合、接続文字列は次のようになります:ssh -XC4c arcfour,blowfish-cbc hostnameorip
X11 転送よりも少し (かなり) 優れたブラウザーがいくつかあります。
Midori は軽量のタブ付きブラウザで、問題なく動作します。
Xlinks2 は、X11 転送でもうまく動作するはずです。
uzbl と surf はどちらも私が使用したブラウザーで、非常に最小限であるため、X11 で問題なく動作するはずです。