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

14

Contexto

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

Tem um bom ponto para facilitar a criação de sites de pequena escala, especialmente com PHP. É uma espécie de motor de template, mas eu prefiro a outros motores de templates porque é muito mais poderoso do que a maioria dos motores de template, 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.

Naturalmente, ele falhará completamente em qualquer site de médio ou grande porte, já que, mesmo com boas técnicas de armazenamento em cache, o XSL ainda degrada o desempenho geral do site e requer mais servidores da CPU.

Pergunta

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 fazer isso.

Isso significa que é possível migrar o processamento de 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 em que posso querer implementar isso). Isso significa que esses 50% dos usuários receberão apenas o arquivo XML em cada solicitação, reduzindo assim a largura de banda deles e do servidor (sendo o arquivo XML muito menor do que o analógico HTML processado) e reduzindo o uso da CPU do servidor.

Quais são os inconvenientes desta técnica?

Eu pensei em vários, mas isso não se aplica nesta 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 do que o real. A única alteração a ser feita é adicionar o link do arquivo XSL a cada XML e adicionar uma verificação do navegador.
  • Mais uso de IO 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, uma vez que o arquivo XSLT será armazenado em cache pelos navegadores (como imagens, ou CSS, ou arquivos JavaScript 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 esteja realmente usando, já que a única fonte exibida é o XML baixado. Por outro lado, raramente vou olhar para código HTML no lado do cliente e, na maioria dos casos, é inutilizável diretamente (espaço em branco sendo removido).
por Arseni Mourzenko 27.12.2010 / 13:20
fonte

4 respostas

26

Os navegadores não podem renderizar progressivamente XSLT

Isso significa que nada mais carrega 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 & JS.

A carga inicial é atrasada por outra solicitação

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

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

Você provavelmente não está salvando nenhuma 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 você está enviando um post de blog, então não há mágica que o XSLT possa fazer para torná-lo substancialmente menor. Se você estiver enviando dados complexos, ele terá muita marcação de qualquer maneira.

Caches são superestimados

Os caches de navegador são não tão bons :

40-60% of Yahoo!’s users have an empty cache experience and ~20% of all page views are done with an empty cache.

e no celular, onde a latência torna as solicitações extras mais caras, 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 o processamento.

gzip é um XSLT reverso

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

Você deveria estar usando o gzip de qualquer maneira (é um desperdício enviar XML descompactado). É muito provável que o tamanho gzipped do documento processado seja aproximadamente o mesmo que o tamanho gzipped do XML não processado - mas você não terá que enviar XSLT extra, e os navegadores poderão começar a renderizar assim que os primeiros pacotes chegarem.

Os clientes podem estar lentos

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

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

    
por 27.12.2010 / 14:17
fonte
3

Não há motivos para que esse servidor não seja dimensionado, além de gerar HTML diretamente. Também não há muita razão para uma grande sobrecarga constante em comparação com o PHP. Aparentemente há XSLT > Compiladores JVM / CLR e eu suponho que você poderia até 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é mesmo o desempenho do servidor. Mas o pomeL mencionou vários pontos.

Para suporte adequado em navegadores, o xslt.js pode ajudar.

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

    
por 27.12.2010 / 16:16
fonte
2

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

Você deixa de fora qualquer navegador que não suporte XSLT, como smartphones. Mas você deve criar uma versão especializada para isso de qualquer maneira.

    
por 27.12.2010 / 13:33
fonte
1

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

    
por 27.12.2010 / 13:40
fonte