XMLをブラウザに送信し、XSLTを適用できるようにすることの欠点は何ですか？

環境

フリーランスの開発者として働いていた私は、多くの場合、完全にXSLTに基づいたWebサイトを作成しました。つまり、リクエストごとに、ページコンテンツについて知る必要があるすべてのものを含むXMLファイルが生成されます。現在ログインしているユーザーの名前、トップメニューエントリ、このメニューが動的/設定可能な場合、ページの特定の領域などに表示します。次に、XSLプロセス（キャッシュなど）をHTML / XHTMLページに送信して、ブラウザに送信します。

特にPHPを使用して小規模なWebサイトを簡単に作成できるようにすることには良い点があります。これは一種のテンプレートエンジンですが、他のテンプレートエンジンよりも、ほとんどのテンプレートエンジンよりもはるかに強力であり、私はそれをより良く知っており、気に入っているため、他のテンプレートエンジンよりも好みます。また、必要に応じて、個別のAPIを作成することなく、自動アクセスの要求に応じて生のXMLデータにアクセスできるようにすることもできます。

もちろん、中規模または大規模のWebサイトでは完全に失敗します。これは、優れたキャッシュ手法を使用しても、XSLがWebサイト全体のパフォーマンスを低下させ、サーバー側により多くのCPUを必要とするためです。

質問

最近のブラウザには、XMLファイルを取得し、XMLで宣言された関連するXSLファイルで変換する機能があります<?xml-stylesheet href="demo.xslt" type="text/xsl"?>。Firefox 3でできます。Internet Explorer 8でも可能です。

これは、50％のユーザーのXSL処理をサーバーからクライアント側に移行できることを意味します（これを実装する可能性のあるいくつかのWebサイトのブラウザー統計による）。つまり、これらの50％のユーザーは各リクエストでXMLファイルのみを受信するため、ユーザーとサーバーの帯域幅が削減され（XMLファイルは処理されたHTMLアナログよりもはるかに短い）、サーバーのCPU使用率が削減されます。

この手法の欠点は何ですか？

いくつか考えましたが、この状況には当てはまりません。

• 困難な実装と、ブラウザのリクエストに基づいて、いつ生XMLを送信し、代わりにHTMLに変換するかを選択する必要性。明らかに、システムは実際のシステムよりもそれほど難しくありません。行う唯一の変更は、すべてのXMLにXSLファイルリンクを追加し、ブラウザーチェックを追加することです。
• XSLTファイルはサーバーによってキャッシュされるのではなく、ブラウザーによってダウンロードされるため、IOおよび帯域幅の使用量が増えます。XSLTファイルはブラウザによってキャッシュされるため（画像、CSS、またはJavaScriptファイルが実際にキャッシュされるため）、これが問題になるとは思いません。
• 一部のブラウザでページを保存するときの問題など、クライアント側の問題の可能性があります。
• コードのデバッグの難しさ：表示されるソースはダウンロードされたXMLのみであるため、ブラウザーが実際に使用しているHTMLソースを取得することはできません。一方、クライアント側でHTMLコードを見ることはほとんどなく、ほとんどの場合、直接使用できません（空白が削除されます）。

ブラウザはXSLTを段階的にレンダリングできません

これは、すべてのデータとスタイルシート全体がロードおよび処理されるまで、他に何もロードされず、何も表示されないことを意味します。

プログレッシブレンダリングと画像のプリフェッチ、CSS＆JSを見逃しています。

別のリクエストにより初期ロードが遅延しています

小規模なファイル（<20kb）では、帯域幅ではなくリクエスト数がフロントエンドパフォーマンスのボトルネックであり、ほとんどのページとスタイルシートがこのカテゴリに分類されます。

大きなページがある場合、さらに悪いことになります。最初のポイントを参照してください。

おそらく帯域幅を節約していません

XSLT自体は非常に冗長であり、現在のページで使用されているものだけでなく、サイト全体のテンプレートとすべてのまれなケースのロジックを含める必要がある場合があります。

送信するメインXMLファイルにマークアップされたすべてのデータを含める必要があります。たとえば、ブログの投稿を送信する場合、XSLTがそれを大幅に小さくするための魔法はありません。複雑なデータを送信する場合、とにかく多くのマークアップがあります。

キャッシュが過大評価されています

ブラウザのキャッシュはそれほど大きくありません：

Yahoo!のユーザーの40〜60％が空のキャッシュエクスペリエンスを持ち、すべてのページビューの約20％が空のキャッシュで実行されています。

また、モバイルでは、遅延により余分なリクエストが最も高価になるため、キャッシュはさらに悪化します。

直帰率を確認します。キャッシュされたXSLTの恩恵を受けないユーザーであり、スタイルシートをダウンロードして処理されるのを待つために追加料金を支払うユーザーです。

gzip 逆XSLTです

XSLTを介して行われるほとんどの変換は、簡潔なマークアップをより冗長なものに変更し、繰り返しを追加することになります。しかし、gzipはファイルから繰り返し/冗長性を取り除くのに優れています！

とにかくgzipを使用する必要があります（XMLを非圧縮で送信するのは無駄です）。処理されたドキュメントのgzip圧縮されたサイズは、未処理のXMLのgzip圧縮されたサイズとほぼ同じである可能性が非常に高くなります。

クライアントが遅い可能性があります

キャッシュからの読み込みのベストケースを想定しても、クライアント側でのXSLT処理は、ユーザーのCPUが速く、XSLTエンジンが速い場合にのみ高速になります。

サーバー側では、あらゆる種類の最適化のトリックを実行できます（たとえば、処理されたフラグメントまたはページ全体をキャッシュする）。最新の最速のXSLTプロセッサーを使用できます（ブラウザーにはXSLT 1.0のみがあり、最適化されていない可能性があります）。そして、あなたのサーバーはおそらく、多くの安価なオフィスのコンピューター、電話などよりもCPUが強力です。

このサーバーサイドを実行しても、HTMLを直接生成するのと同じようにスケーリングしない理由はありません。また、PHPと比較して大きな一定のオーバーヘッドが生じる理由はあまりありません。どうやらXSLT> JVM / CLRコンパイラがあり、ネイティブコードに変換することもできると思います。

ただし、データとプレゼンテーション構造を別々に転送するという考え方は、そのように優れています。
帯域幅を大幅に節約し、サーバーのパフォーマンスも節約できます。しかし、pomeLは多くのポイントに言及しています。

ブラウザ間で適切にサポートするには、xslt.jsが役立ちます。

個人的に、私はXMLのファンではないので、代わりにJSONとブラウザーで実行されるJSテンプレートエンジンを使用します。または、テンプレートマークアップをサーバー側で実行可能なjsに変換し、クライアント側でのレンダリングに使用する、何らかのテンプレートエンジン。
JavaScriptはかなり高速で、事実上どこでも利用できます。JSONとJSは、XMLとXSLTよりもはるかにコンパクトです。

コンパクトなXMLを送信し、クライアントにXSLTをキャッシュすると、帯域幅を節約できます。

スマートフォンのように、XSLTをサポートしないブラウザーは除外します。しかし、とにかくこれらの特別なバージョンを作成する必要があります。

これまで主な問題は、少数のブラウザのみがこれをサポートしていたことでした。したがって、基本的にサポートする新しいプラットフォームを作成するのに苦労する価値はありませんでした。さらに、IEの古いバージョンはこれを十分にサポートしていませんでした。正しく思い出せば、少なくとも1つのIEがさまざまな楽しい問題を引き起こす異なるXSLT方言を持っていました。