各部分の主要部分をロードするajax機能を使用してサイトを開発してはならない理由について、確かな理由はありますか（ヘッダー、ナビゲーションなどの要素が同じであると想定しています）。

確かに、サーバーがすべてのページに表示されるコンテンツを提供する必要がなく、ホストとエンドユーザーの両方にメリットがあるため、リソースの消費は少なくなります。

考慮して質問に答えてください：

• サイトのJavaScriptの動作は、すべてのインスタンスで適切に低下します

• 私の質問では、この動作を最初から実装できる新しいサイトについて話しているので、技術的に費用はかかりません。完成した製品に戻って実装するわけではありません。

JavaScriptを有効にせずにコンテンツにアクセスできる場合、質問は意味がありません。他の方法でコンテンツにアクセスできる場合は、「完全にAjax化」されていません。本当に、あなたが求めているのは、「Ajaxを通じてユーザーエクスペリエンスを向上させても大丈夫ですか？」です。答えは明らかに「はい」です。

編集する

Googleがクロール可能なAjaxの提案を発表したとき、それは本当に悪いアイデアとして取り上げられていました。興味深い読み物になります。

まず最初に

長所

• AJAXを使用すると、共通の「ベース」ページを使用してコンテンツ領域のみをロードできます。これにより、ページの大部分がすでにロードされているため、ユーザーのロード時間を短縮できます。
• コンテンツ領域をフェードイン/フェードアウトするなど、目を楽しませることができます。

短所

• ページがダウンロードされた場合、うまく再生されません。
• 障害のあるデバイスを混乱させることができます。
• JavaScriptがオフになっているビューアは、JavaScript以外のバージョンも使用されていない限り、コンテンツをまったく使用できません。
• さらに多くの作業（本当に言われる必要がありますか？）。

今あなたの質問のために

Javascriptを使用していないサイトでサイトが正常に機能すると仮定すると、どれだけうまくいくかは、その実行方法によって異なります。たとえば、JavaScript以外のバージョンへのリンクを突然表示するだけの場合、それらの視聴者が別のリンクをクリックしなければならないのは不便です。一方、従来のリンクを使用するnoscript "メインページ"がある場合、それはほとんどのユーザーにとってはうまく機能しますが、障害デバイスを使用するユーザーに対するサポートはまだありません。リンクなど

全体として、ますます高速になるWeb接続の世界では、少量のファイルサイズを切り捨てるだけの正当な理由はありません（Javascript自体、CSS、および画像をすべてキャッシュできると想定し、バイトを節約するための「ベース」ページ自体）、つまり、追加の難点（つまり、常にコンというわけではない-挑戦は良い）と、一部のユーザーに提供できるサポートの欠如。

全体として、それはあなた次第だと思います。おそらくかなりうまくいくでしょう。そして大多数のユーザーにとって、彼らはおそらく意図したとおりにサイトを見るでしょうが、個人的にはそうではないと思いますファイルサイズをこのようにわずかに改善しても問題はありません。

http://gawker.com/をチェックしてください -このサイトは事実の後にほぼ完全にロードされます。「ハッシュバング」（http://mydomain.com/#!some_section）を使用して、ロードするコンテンツページを決定します。メインナビゲーションは静的なままです。

Gawkerが使用した概念に関する短いチュートリアルについては、http：//mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/を確認してください。

長所と短所があり、検索エンジン（http://code.google.com/web/ajaxcrawling/docs/getting-started.htmlを参照）、JavaScriptが無効になっている人々を検討し、多くのテストを行う必要があります。

そうは言っても、ユーザーに対する最大の議論は、ユーザーがページが読み込まれるのを待ってから、さらに読み込まれるのを待たなければならない場合、焦る可能性があるということです。私の見解では、ベストプラクティスは、メインサイト、ナビゲーション、およびプライマリコンテンツを1回のパスで（要求に応じて）ロードし、AJAXを重要でない付随物用に保存することです。これは、プログレッシブエンハンスメントのアイデアで機能し、両方のアプローチのベストを組み合わせます。

それはおそらく必要ないからです。
基本的なHTMLドキュメントの読み込みはシンプルで機能します。Ajaxの導入により、ブラウザー、コード、Javascriptの保守、バックエンドスタッフ、奇妙なハッシュバングURLなどのプロセスのレイヤー全体が追加されます。正当化できる場合もあれば、そうでない場合もあります。それはあなたにいくつかのサーバーリソースを節約するかもしれません（かもしれません）が、それは維持を相殺するのに十分でしょうか？プロジェクトごとに評価する必要があります。

例として、Twitterが最新の再設計を行ったとき、彼らはそれが単なるWeb（ページ）サイトではなくアプリケーションであり、全体がAjaxベースであるというアプローチを採用しました。通常のページリクエストで処理されます。Ajaxで何かが失敗したために、現在ははるかに少ないですが現在も発生している最大の問題の1つは、そこに到着して空白のページが表示されることです。

実際には、特に非常に複雑な主要なWebサイトの場合、「完全にAJAX」のWebサイトを作成するには多くの作業が必要です。これを試みているウェブサイトのいくつかはグーグルとフェイスブックですが、彼らはそれを完全にはしません。

一般的な問題は、ナビゲーション（つまり、前方および後方）とブックマークですが、多くの開発者が対処する必要がない多くのバグがあります。そしてそれは基本的に、JavaScriptユーザーと非JavaScriptユーザーと互換性のあるWebサイトの2つのバージョンを作成することを意味します（そしてAJAXがサポートされていないすべてのブラウザーの修正）。

はい、そうでなければなりませんが、逆になります。

ページの共通部分はHTTP経由で送信する必要があります。次に、小さなajax（またはさらに優れたWebSocket）コントロールが動的コンテンツを非同期でロードします。

もちろん、まずJavaScriptが有効かどうか（Cookieによって）を検出し、有効になっている場合にのみこのメソッドを使用する必要があります。

したがって、通常の完全なHTTPルートが必要で、次にWebSocketsルートが必要です。node.jsなどのツールを使用しない限り、コードの複製が必要です。

ほとんどの人は、余分な努力をするだけの価値はないと考えています。そして時にはそうではありません。

余談ですが、多くの人がページを間違ってajax化しています。彼らは実際にはあなたが非JavaScriptバージョンを必要とせず、これらすべての奇妙なハッシュバングURLと壊れた進む/戻るボタンが必要だと決定しました。ajaxを適切に行うには、HTML5の履歴が必要です（IE9にはありません）。また、開発者がWebサイトのバージョンを完成させる必要もあります。

Javascriptを無効にした訪問者にとっては問題なく機能が低下するとのことですが、実際に発生する可能性のある問題は2つ（および1つの問題）しかありません。

アクセシビリティが悪い

スクリーンリーダーやその他の支援技術は、動的なDOMの変更によって破棄されることがよくあります。それらはページを直線的に処理して読み取り、ロードされた後のページのコンテンツの変更は正しく処理されない場合があります。

これを回避するテクニックはあるかもしれませんが、私はそれを徹底的に調べていません。

複雑さの増大

この種のサイトを維持するのは難しいかもしれません。たとえば、新しいレイアウトを作成し、AJAXリンクで置き換えるコンテンツ領域のIDを変更した場合、ナビゲーションスキームがかなり複雑に壊れる可能性があります。

この種のAJAX動作は、実行している可能性のあるトラフィック分析も複雑にします。Googleアナリティクスは、手動でを呼び出さないと、これらのAJAXロードを適切に登録しませんpageTracker._trackPageview('this_page');。

ページの操作方法をさらに複雑にすることで、新しい開発者のレベルも上がります。サイトで作業している人はおそらく、この動作がページの読み込みにどのように影響するかを認識しておく必要があります。

可能性：最初のアクセス時のページの読み込みが遅い

構成方法に応じて、AJAXコードをフェッチするこのページは、ドキュメントが完全に読み込まれた後にのみ起動できます。したがって、ビジターがページ全体をダウンロードし、Javascript（外部ファイルの場合）をダウンロードし、ブラウザがそれをレンダリングしてAJAX経由でコンテンツをフェッチした後にのみ、ページコンテンツが表示されます。

後続の各リンクをクリックする方が高速ですが、ユーザーがアクセスした最初のページを取得することは、実際には静的バージョンよりも時間がかかります。

これを考えられる問題としてラベル付けした理由は、最初のページを常に静的に送信し（静的バージョンが既にフォールバックとして用意されているため）、その後のリンクにAJAXを使用できるためです。

それだけの価値があるので、これは私にはひどい考えのようには聞こえません。特に、モバイルページのような帯域幅を重視する用途ではそうです。ただし、欠点を慎重に検討して、ケースに見合う価値があるかどうかを確認する必要があります。

ユーザーベースが小さい場合はページにajax要素を配置しても問題ありませんが、トラフィックが多い場合はそうです。リソースの悪用を減らすために、より静的なアプローチを使用したい場合。

たとえば、1秒間に200人がページにアクセスしようとしているとします。ajax呼び出しに対して約7つのデータベースクエリがあります。つまり、1400データベースは1秒を呼び出しますが、これはWebサイトを停止させる可能性があります。

トラフィックを増やすように設計する必要があるWebサイトには、静的な方法で表示できるコンテンツのために、静的な外向きのページが必要です。これは、毎秒実行されるサーバー側のスクリプトを使用して静的ページを再構築することで実現され、静的ページはエンドユーザーのためにフェッチされるため、1秒あたりのデータベース呼び出しが1400から7に減ります。

それはウェブサイト構築へのSOAアプローチです。