Quais são as desvantagens de enviar XML para navegadores e deixá-los aplicar o XSLT?

Contexto

Trabalhando como desenvolvedor freelancer, frequentemente criava sites completamente baseados em XSLT. Em outras palavras, a cada solicitação, um arquivo XML é gerado, contendo tudo o que precisamos saber sobre o conteúdo da página: o nome do usuário atualmente conectado, as entradas do menu superior, se esse menu for dinâmico / configurável, o texto para exibido em uma área específica da página, etc. Em seguida, o processo XSL (armazena em cache etc.) na página HTML / XHTML para enviar ao navegador.

É um bom ponto para facilitar a criação de sites de pequena escala, especialmente com PHP. É um tipo de mecanismo de modelo, mas eu prefiro outros mecanismos de modelo porque é muito mais poderoso que a maioria dos mecanismos de modelo e porque eu o conheço melhor e gosto dele. Também é possível, quando necessário, fornecer acesso a dados XML brutos sob demanda para um acesso automatizado, sem a necessidade de criar APIs separadas.

Obviamente, ele falhará completamente em qualquer site de média ou grande escala, pois, mesmo com boas técnicas de cache, o XSL ainda diminui o desempenho geral do site e requer mais servidores da CPU.

Questão

Navegadores modernos têm a capacidade de pegar um arquivo XML e transformá-lo com um arquivo XSL associado declarado em XML como <?xml-stylesheet href="demo.xslt" type="text/xsl"?>. O Firefox 3 pode fazer isso. O Internet Explorer 8 também pode fazê-lo.

Isso significa que é possível migrar o processamento XSL do servidor para o lado do cliente para 50% dos usuários (de acordo com as estatísticas do navegador em vários sites nos quais posso implementar isso). Isso significa que esses 50% dos usuários receberão apenas o arquivo XML a cada solicitação, reduzindo a largura de banda dos servidores e dos servidores (o arquivo XML é muito menor que o analógico HTML processado) e a utilização da CPU do servidor.

Quais são as desvantagens dessa técnica?

Pensei em vários, mas não se aplica a esta situação:

• Implementação difícil e a necessidade de escolher, com base na solicitação do navegador, quando enviar XML bruto e quando transformá-lo em HTML. Obviamente, o sistema não será muito mais difícil que o atual. A única alteração a ser feita é adicionar um link de arquivo XSL a cada XML e adicionar uma verificação do navegador.
• Mais uso de E / S e largura de banda, pois o arquivo XSLT será baixado pelos navegadores, em vez de ser armazenado em cache pelo servidor. Eu não acho que será um problema, pois o arquivo XSLT será armazenado em cache pelos navegadores (como imagens, CSS ou arquivos JavaScript, na verdade, são armazenados em cache).
• Possivelmente alguns problemas no lado do cliente, como talvez problemas ao salvar uma página em alguns navegadores.
• Dificuldade para depurar código: é impossível obter uma fonte HTML que o navegador está realmente usando, pois a única fonte exibida é o XML baixado. Por outro lado, raramente vejo o código HTML no lado do cliente e, na maioria dos casos, é inutilizável diretamente (o espaço em branco está sendo removido).

Os navegadores não podem renderizar XSLT progressivamente

Isso significa que nada mais é carregado e nada é exibido até que todos os dados e toda a folha de estilo sejam carregados e processados.

Você está perdendo a renderização progressiva e a pré-busca de imagens, CSS e JS.

O carregamento inicial está atrasado por outra solicitação

Para arquivos ish pequenos (<20kb), o número de solicitações, e não a largura de banda, é o gargalo do desempenho do front-end, e a maioria das páginas e folhas de estilo se enquadra nessa categoria.

Se você tem páginas grandes, é ainda pior - veja o primeiro ponto.

Você provavelmente não está economizando largura de banda

O próprio XSLT é bastante detalhado e pode precisar conter modelos para todo o site e lógica para todos os casos raros, não apenas as coisas usadas na página atual.

Você ainda precisa incluir todos os dados marcados no arquivo XML principal que está enviando, por exemplo, se estiver enviando uma postagem no blog, não há mágica que o XSLT possa fazer para torná-la substancialmente menor. Se você estiver enviando dados complexos, haverá muitas marcações de qualquer maneira.

Os caches são superestimados

Caches de navegador não são tão bons :

40-60% dos usuários do Yahoo! Têm uma experiência de cache vazio e ~ 20% de todas as visualizações de página são feitas com um cache vazio.

e no celular, onde a latência torna as solicitações extras mais caras, os caches são ainda piores .

Verifique sua taxa de rejeição - são usuários que não se beneficiam do XSLT em cache e pagam um preço extra para fazer o download da folha de estilo e aguardar que ela seja processada.

gzip é um XSLT reverso

A maioria das transformações feitas via XSLT se resume a alterar a marcação concisa para uma mais detalhada e adicionar repetição. Mas o gzip é ótimo para remover repetição / redundância de arquivos!

Você deve usar o gzip de qualquer maneira (é um desperdício enviar XML descompactado). É muito provável que o tamanho compactado em gzip do documento processado seja mais ou menos o tamanho gzip de XML não processado - mas você não precisará enviar XSLT extra e os navegadores poderão iniciar a renderização assim que os primeiros pacotes chegarem.

Os clientes podem ficar lentos

Mesmo assumindo o melhor caso de carregamento do cache, o processamento XSLT no lado do cliente é mais rápido apenas se a CPU do usuário for mais rápida e seu mecanismo XSLT for mais rápido.

No lado do servidor, você pode executar todos os tipos de truques de otimização (por exemplo, fragmentos processados ​​em cache ou até páginas inteiras). Você pode usar o processador XSLT mais recente e mais rápido (os navegadores têm apenas o XSLT 1.0 e provavelmente não são muito otimizados). E seu servidor provavelmente possui uma CPU mais robusta do que muitos computadores, telefones etc.

Não há razão para fazer isso ao lado do servidor não escalar, além de gerar HTML diretamente. Também não há muito motivo para uma grande sobrecarga constante em comparação com o PHP. Aparentemente, existem compiladores XSLT> JVM / CLR e suponho que você possa traduzi-lo para código nativo.

No entanto, a ideia de transportar dados e estrutura de apresentação separadamente é boa como tal.
Pode economizar muita largura de banda e até desempenho do servidor. Mas pomeL mencionou vários pontos.

Para obter suporte adequado nos navegadores, o xslt.js pode ajudar.

Pessoalmente, como não sou fã de XML, usaria o JSON e um mecanismo de modelo JS, que será executado no navegador. Ou algum tipo de mecanismo de modelo, que converte a marcação de modelo em js executáveis ​​no lado do servidor, que é usado para renderização no lado do cliente.
O JavaScript é razoavelmente rápido e está disponível em praticamente qualquer lugar. JSON e JS são muito mais compactos que XML e XSLT.

Enviar XML compacto e ter um XSLT em cache no cliente pode até economizar sua largura de banda.

Você deixa de fora os navegadores que não suportam XSLT, como smartphones. Mas você deve criar uma versão especial para eles de qualquer maneira.

O problema principal costumava ser que apenas alguns navegadores suportavam isso muito bem, então não valia a pena criar uma nova plataforma para suportar. Além disso, as versões mais antigas do IE não suportavam isso muito bem, e se bem me lembro, pelo menos um IE tinha um dialeto XSLT diferente, causando todos os tipos de problemas divertidos.