Existe algum raciocínio sólido sobre o motivo pelo qual os sites não devem ser desenvolvidos com a funcionalidade ajax que carrega partes principais de cada parte (assumindo que existem elementos como o cabeçalho, a navegação etc. que permanecem os mesmos)?

Certamente seria menos intensivo em recursos, pois o servidor não precisaria exibir o conteúdo que aparece em todas as páginas, beneficiando tanto o host quanto o usuário final.

Responda à pergunta levando em consideração:

• O comportamento javascript dos sites é degradado normalmente em todas as instâncias

• Para minha pergunta, estou falando de novos sites onde esse comportamento pode ser implementado desde o início, para que tecnicamente não custe dinheiro - não estamos retornando a um produto acabado para implementá-lo.

Se o conteúdo puder ser alcançado sem o JavaScript ativado, sua pergunta não fará sentido. Não é "totalmente Ajaxificado" se você puder acessar o conteúdo por outros meios. Realmente, o que você está perguntando é: "está tudo bem em melhorar a experiência do meu usuário através do Ajax?". A resposta é obviamente sim".

editar

Quando o Google lançou sua proposta rastreável do Ajax, ele foi considerado uma péssima idéia . Faz uma leitura interessante.

Primeiras coisas primeiro

Os prós

• O AJAX pode permitir que você use uma página "base" comum e apenas carregue as áreas de conteúdo, o que pode reduzir o tempo de carregamento para os usuários, uma vez que grande parte da página já está carregada.
• Pode permitir algum colírio para os olhos, como desbotar e desbotar a área de conteúdo.

Os contras

• Não funciona bem se a página for baixada.
• Pode mexer com dispositivos de deficiência.
• Os espectadores com o javascript desativado não poderão usar o conteúdo, a menos que uma versão não javascript também seja empregada.
• Muito mais trabalho (realmente precisa ser dito?).

Agora para sua pergunta

Supondo que o site seja degradado normalmente por quem não tem Javascript, a qualidade do resultado depende de como é feito. Por exemplo, se você apenas exibir um link para uma versão não-javascript do nada, é um inconveniente para esses visitantes clicarem em outro link. Por outro lado, se houver uma "página principal" noscript que usaria links tradicionais, funcione melhor para a maioria dos usuários, mas ainda não terá suporte para aqueles que usam dispositivos portadores de deficiência, instâncias em que o usuário procura uma "página" específica de um link etc.

Em suma, no mundo das conexões da Web cada vez mais rápidas, isso não justifica realmente cortar uma pequena quantidade de tamanho de arquivo (presumiremos que todo o próprio Javascript, o CSS e as imagens podem e serão armazenados em cache, deixando apenas a própria página "base" para salvar os bytes) pelos contras que ela pode oferecer, ou seja, a dificuldade extra (embora isso nem sempre seja um bom desafio) e a falta de suporte que ela pode oferecer para alguns usuários.

Em suma, eu diria que depende de você, provavelmente funcionaria muito bem e, para a grande maioria dos usuários, eles provavelmente verão o site como pretendido, mas pessoalmente, eu diria que não incomodar, como não vale a pena o esforço para uma melhoria tão marginal ao tamanho do arquivo.

Confira http://gawker.com/ - este site carrega quase completamente após o fato. Eles usam "hashbangs" ( http://mydomain.com/#!some_section) para determinar qual página de conteúdo deve ser carregada, a navegação principal permanece estática.

Confira http://mtrpcic.net/2011/02/fragment-uris-theyre-not-as-bad-as-you-think-really/ para obter um breve tutorial sobre o conceito usado por Gawker.

Existem prós e contras, você deve considerar os mecanismos de pesquisa (consulte http://code.google.com/web/ajaxcrawling/docs/getting-started.html ), pessoas com javascript desativado e faça muitos testes.

Com tudo isso dito, o maior argumento contra eles é provavelmente que, quando um usuário aguarda o carregamento de uma página e precisa esperar mais carregamento, ele pode ficar impaciente. Na minha opinião, a melhor prática é carregar o site principal, a navegação e o conteúdo principal de uma só vez (mediante solicitação) e salvar o AJAX para os acessórios não essenciais. Isso funciona com a idéia de aprimoramento progressivo e combina o melhor das duas abordagens.

Porque provavelmente não é apenas necessário.
Carregar documentos HTML básicos é simples e funciona. A introdução do Ajax adiciona toda uma outra camada de processo para navegadores, código e manutenção do Javascript, material de back-end, URLs estranhos de hashbang e assim por diante. Às vezes isso pode ser justificado, às vezes não. Isso pode economizar alguns recursos do servidor (pode), mas será suficiente para compensar a manutenção? Você precisa avaliar esse por projeto.

Como exemplo, quando o Twitter recebeu sua última reformulação, eles adotaram a abordagem de que não era apenas um site (página), mas um aplicativo, e a coisa toda é fortemente baseada no Ajax, mesmo que a maior parte do que ele possa fazer ser tratado com solicitações de página regulares. Um dos maiores problemas, que ainda acontece agora, embora muito menos, é chegar lá e ser recebido com uma página em branco porque algo no Ajax falhou.

Na prática, é muito trabalho produzir um site 'totalmente AJAX', especialmente para sites importantes que são muito complicados. Alguns sites que tentam isso são o Google e o Facebook, mas nem eles fazem isso perfeitamente.

Os problemas comuns são a navegação (ou seja, para frente e para trás) e os favoritos, mas existem muitos outros erros com os quais muitos desenvolvedores preferem não ter que lidar. E isso basicamente significa criar duas versões do site para ser compatível com usuários Javascript e não-javascript (e correções para todos os navegadores com suporte ruim para AJAX).

Sim, deve ser, no entanto, deve ser o contrário.

As partes comuns da página devem ser enviadas por HTTP. Em seguida, um pequeno controle ajax (ou ainda melhores websockets) carrega o conteúdo dinâmico de forma assíncrona.

Obviamente, você precisa primeiro detectar se o javascript está ativado (por cookie) e usar esse método apenas se estiver ativado.

Portanto, você precisa da rota HTTP completa normal e, em seguida, uma rota dos websockets. Isso requer duplicação de código, a menos que você use uma ferramenta como o node.js

A maioria das pessoas "pensa" que simplesmente não vale o esforço extra. E às vezes não é.

Como um aparte, muitas pessoas ajaxificam páginas erradas. Na verdade, eles decidem que você não precisa de uma versão não-javascript e de todos esses URLs de hash bang estranhos e botões avançados de avançar / voltar. Fazer o ajax corretamente requer o histórico HTML5 (o IE9 não o possui). Também requer que o desenvolvedor complete as versões do seu site.

Como você afirmou que seria degradado normalmente para visitantes com Javascript desativado, só consigo ver dois problemas reais (e um possível) que podem surgir.

Ruim para Acessibilidade

Os leitores de tela e outras tecnologias assistivas geralmente são desencorajados por alterações dinâmicas do DOM. Eles processam e leem a página de maneira linear, e a alteração do conteúdo da página depois que ela é carregada pode não ser tratada corretamente.

Pode haver técnicas para contornar isso, mas ainda não o examinei completamente.

Maior complexidade

Manter esse tipo de site pode ser complicado. Por exemplo: se você criou um novo layout e alterou o ID da área de conteúdo que estava substituindo pelos seus links AJAX, isso poderia interromper seu esquema de navegação de uma maneira bastante desconcertante.

Esse tipo de comportamento do AJAX também complicaria qualquer análise de tráfego que você esteja fazendo; O Google Analytics não registraria corretamente essas cargas de AJAX sem uma chamada manual para pageTracker._trackPageview('this_page');.

Adicionar mais complexidade ao funcionamento da sua página também eleva a fasquia para novos desenvolvedores; qualquer pessoa que trabalhe no site provavelmente precisará ser informada de como esse comportamento afeta o carregamento da página.

Possível: Carregamento de página mais lento na visita inicial

Dependendo de como você estrutura as coisas, esta página que busca o código AJAX somente poderá entrar após o carregamento completo do documento. Portanto, somente depois que o visitante baixasse a página inteira e, em seguida, o Javascript (se fosse um arquivo externo) e o navegador deles renderizassem e buscassem o conteúdo via AJAX, eles veriam o conteúdo da página.

Cada link subsequente clicado seria mais rápido, mas a busca da primeira página visitada pelo usuário levaria mais tempo que uma versão estática.

O motivo pelo qual eu rotulei isso como um possível problema é que você sempre pode enviar a primeira página estaticamente (já que você terá a versão estática como um fallback) e depois usar o AJAX para os links subsequentes.

Pelo que vale, isso não me parece uma péssima idéia, especialmente para usos sensíveis à largura de banda, como páginas para celular. Você teria que ponderar cuidadosamente as desvantagens para garantir que valesse a pena no seu caso.

Ter elementos ajax em uma página é bom quando você tem uma pequena base de usuários, mas quando você tem mais tráfego; você deseja usar uma abordagem mais estática para diminuir o abuso de recursos.

Por exemplo: digamos que você tenha 200 pessoas tentando acessar uma página por segundo. Você tem cerca de 7 consultas ao banco de dados para suas chamadas ajax; isso é 1400, o banco de dados chama um segundo, o que pode atolar um site.

Um site que precisa ser projetado para um tráfego mais alto deve ter páginas externas estáticas, para conteúdo que possa ser exibido de maneira estática. Isso é obtido usando um script do lado do servidor que é executado a cada segundo para reconstruir a página estática, que é buscada pelo usuário final e, assim, você reduziu sua carga de 1400 chamadas de banco de dados por segundo para 7.

É uma abordagem SOA para a criação de sites.