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コードを見ることはほとんどなく、ほとんどの場合、直接使用できません（空白が削除されます）。