Quali sono gli svantaggi di inviare XML ai browser e lasciarli applicare XSLT?

Naviga le tue risposte
14

Contesto

Lavorando come sviluppatore freelance, creavo spesso siti web completamente basati su XSLT. In altre parole, su ogni richiesta, viene generato un file XML, contenente tutto ciò che dobbiamo sapere sul contenuto della pagina: il nome dell'utente attualmente loggato, le voci del menu principale, se questo menu è dinamico / configurabile, il testo da visualizzare in un'area specifica della pagina, ecc. Quindi il processo XSL (cache, ecc.) alla pagina HTML / XHTML da inviare al browser.

Ha un buon punto per rendere più facile la creazione di siti Web su piccola scala, specialmente con PHP. È una sorta di motore di template, ma preferisco altri motori di template perché è molto più potente della maggior parte dei template engine e perché lo conosco meglio e mi piace. È anche possibile, quando necessario, fornire un accesso ai dati XML non elaborati su richiesta per un accesso automatico, senza la necessità di creare API separate.

Ovviamente, fallirà completamente su qualsiasi sito web su scala media o su larga scala, poiché, anche con buone tecniche di memorizzazione nella cache, l'XSL degrada ancora le prestazioni complessive del sito web e richiede più CPU serveride.

Domanda

I moderni browser hanno la possibilità di prendere un file XML e di trasformarlo con un file XSL associato dichiarato in XML come <?xml-stylesheet href="demo.xslt" type="text/xsl"?> . Firefox 3 può farlo. Internet Explorer 8 può farlo anche.

Significa che è possibile migrare l'elaborazione XSL dal server al client per il 50% degli utenti (in base alle statistiche del browser su diversi siti Web in cui potrei voler implementarlo). Ciò significa che il 50% degli utenti riceverà solo il file XML ad ogni richiesta, riducendo così la larghezza di banda di loro e del server (il file XML è molto più breve dell'analogo HTML elaborato) e riducendo l'utilizzo della CPU del server.

Quali sono gli svantaggi di questa tecnica?

Ho pensato a diversi, ma non si applica a questa situazione:

  • Difficile implementazione e necessità di scegliere, in base alla richiesta del browser, quando inviare XML non elaborato e quando invece trasformarlo in HTML. Ovviamente, il sistema non sarà molto più difficile di quello attuale. L'unica modifica da fare è aggiungere il collegamento file XSL a ogni XML e aggiungere un controllo del browser.
  • Più utilizzo di I / O e larghezza di banda, poiché il file XSLT verrà scaricato dai browser, invece di essere memorizzato nella cache dal server. Non penso che sarà un problema, dal momento che il file XSLT verrà memorizzato nella cache dai browser (come immagini, o CSS, o i file JavaScript sono effettivamente memorizzati nella cache).
  • Forse alcuni problemi sul lato client, come forse problemi nel salvataggio di una pagina in alcuni browser.
  • Difficoltà di eseguire il debug del codice: non è possibile ottenere una sorgente HTML utilizzata dal browser, poiché l'unica sorgente visualizzata è l'XML scaricato. D'altra parte, raramente guardo il codice HTML dal lato client e, nella maggior parte dei casi, è inutilizzabile direttamente (lo spazio viene rimosso).
posta Arseni Mourzenko 27.12.2010 - 13:20
fonte

4 risposte

26

I browser non possono rendere progressivamente XSLT

Ciò significa che nulla viene caricato e non viene visualizzato nulla finché tutti i dati e l'intero foglio di stile non vengono caricati ed elaborati.

Ti stai perdendo il rendering progressivo e il prefetch delle immagini, CSS & JS.

Il caricamento iniziale è ritardato da un'altra richiesta

Per i file di piccole dimensioni (< 20kb) il numero di richieste, non la larghezza di banda, è il collo di bottiglia per le prestazioni front-end e la maggior parte delle pagine e dei fogli di stile rientrano in questa categoria.

Se hai pagine grandi, allora è anche peggio: vedi il primo punto.

Probabilmente non stai risparmiando larghezza di banda

XSLT stesso è piuttosto prolisso e potrebbe essere necessario contenere modelli per l'intero sito e logica per tutti i rari casi, non solo per le cose usate nella pagina corrente.

Devi ancora includere tutti i dati marcati nel file XML principale che stai inviando, ad es. se stai inviando un post sul blog, allora non c'è magia che XSLT possa fare per renderlo sostanzialmente più piccolo. Se invii dati complessi, comunque ci saranno molti markup.

Le cache sono sopravvalutate

Le cache del browser sono non così grandi :

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

e su dispositivi mobili, dove la latenza rende più costose richieste extra, le cache sono anche peggio .

Verifica la frequenza di rimbalzo: si tratta di utenti che non beneficiano dell'XSLT memorizzato nella cache e pagano persino un prezzo aggiuntivo per scaricare il foglio di stile e attendere che venga elaborato.

gzip è un XSLT inverso

La maggior parte delle trasformazioni eseguite tramite XSLT si riducono alla modifica del markup terso a quello più dettagliato e all'aggiunta della ripetizione. Ma gzip è ottimo per rimuovere la ripetizione / ridondanza dai file!

Dovresti comunque usare gzip (è inutile inviare XML non compresso). È molto probabile che la dimensione gzip del documento elaborato sia all'incirca uguale alla dimensione gzip di XML non elaborato, ma non sarà necessario inviare XSLT extra e i browser potranno avviare il rendering non appena arrivano i primi pacchetti.

I client potrebbero essere lenti

Anche ipotizzando il miglior caso di caricamento dalla cache, l'elaborazione XSLT sul lato client è più veloce solo se la CPU dell'utente è più veloce e il suo motore XSLT è più veloce.

Sul lato server è possibile eseguire tutti i tipi di trucchi di ottimizzazione (ad es., cache di frammenti elaborati o anche intere pagine). Puoi utilizzare il processore XSLT più recente e più veloce (i browser hanno solo XSLT 1.0 e probabilmente non sono ottimizzati). E il tuo server probabilmente ha una CPU più robusta rispetto a molti computer, telefoni, ecc. Economici

    
risposta data 27.12.2010 - 14:17
fonte
3

Non c'è motivo per cui questo serveride non debba scalare e generare direttamente HTML. Inoltre non c'è molta ragione per un grande sovraccarico costante rispetto a PHP. Appaiono in effetti XSLT > Compilatori JVM / CLR e suppongo che potresti persino tradurlo in codice nativo.

Tuttavia l'idea di trasportare dati e strutture di presentazione separatamente è buona.
Può risparmiare molta larghezza di banda e persino le prestazioni del server. Ma PomeL ha menzionato un certo numero di punti.

Per un supporto adeguato sui browser, xslt.js potrebbe aiutare.

Personalmente, non sono fan di XML, quindi userei invece JSON e un motore di template JS, che verrà eseguito nel browser. O una sorta di motore di template, che converte il markup del template in js eseguibile sul lato server, che viene utilizzato per il rendering sul lato client.
JavaScript è abbastanza veloce e disponibile praticamente ovunque. JSON e JS sono molto più compatti di XML e XSLT.

    
risposta data 27.12.2010 - 16:16
fonte
2

L'invio di XML compatto e l'esecuzione di un XSLT memorizzato nella cache sul client possono persino salvare la larghezza di banda.

Tralascia i browser che non supportano XSLT, come gli smartphone. Ma dovresti comunque creare una versione speializzata per questi.

    
risposta data 27.12.2010 - 13:33
fonte
1

Il problema principale era che solo pochi browser lo supportavano bene, quindi non valeva la pena di creare essenzialmente una nuova piattaforma da supportare. Inoltre le versioni precedenti di IE non supportavano questo bene, e se ricordo correttamente almeno un IE aveva un dialetto XSLT diverso che creava ogni sorta di problemi divertenti.

    
risposta data 27.12.2010 - 13:40
fonte

Leggi altre domande sui tag

Perché la parola chiave "finale" è utilizzata così poco nel settore? [chiuso] Perché inseriamo le funzioni dei membri privati nelle intestazioni?