Quali sono gli svantaggi dell'invio di XML ai browser e di consentire loro di applicare XSLT?

Contesto

Lavorando come sviluppatore freelance, ho spesso realizzato 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 connesso, le voci di menu in alto, se questo menu è dinamico / configurabile, il testo in visualizzare in un'area specifica della pagina, ecc. Quindi, l'elaborazione XSL (cache, ecc.) nella pagina HTML / XHTML da inviare al browser.

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

Ovviamente, fallirà completamente su qualsiasi sito Web di medie o grandi dimensioni, poiché, anche con buone tecniche di memorizzazione nella cache, XSL degrada ancora le prestazioni complessive del sito Web e richiede più CPU sul lato server.

Domanda

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

Ciò significa che è possibile migrare l'elaborazione XSL dal server al lato client per il 50% degli utenti (in base alle statistiche del browser su diversi siti Web in cui è possibile che sia necessario implementarlo). Ciò significa che il 50% degli utenti riceverà solo il file XML ad ogni richiesta, riducendo così la larghezza di banda del proprio e del server (essendo il file XML molto più breve del suo 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 in questa situazione:

• Implementazione difficile 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 apportare è l'aggiunta del collegamento al file XSL a ogni XML e l'aggiunta di un controllo del browser.
• Maggiore utilizzo di IO e larghezza di banda, poiché il file XSLT verrà scaricato dai browser, anziché 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, oppure i file JavaScript vengono effettivamente memorizzati nella cache).
• Forse alcuni problemi sul lato client, come forse problemi durante il salvataggio di una pagina in alcuni browser.
• Difficoltà nel debug del codice: è impossibile ottenere una fonte HTML che il browser sta effettivamente utilizzando, poiché l'unica fonte visualizzata è l'XML scaricato. D'altra parte, raramente vado a vedere il codice HTML sul lato client e, nella maggior parte dei casi, è direttamente inutilizzabile (lo spazio bianco viene rimosso).

I browser non possono eseguire il rendering progressivo di XSLT

Ciò significa che non viene caricato nient'altro e non viene visualizzato nulla fino a quando non vengono caricati ed elaborati tutti i dati e l'intero foglio di stile.

Ti stai perdendo il rendering progressivo e il prefetching di immagini, CSS e JS.

Il caricamento iniziale è ritardato da un'altra richiesta

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

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

Probabilmente non stai salvando alcuna larghezza di banda

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

Devi ancora includere tutti i dati contrassegnati nel file XML principale che stai inviando, ad esempio se stai inviando un post sul blog, allora non c'è magia che XSLT possa fare per renderlo sostanzialmente più piccolo. Se stai inviando dati complessi, avrà comunque un sacco di markup.

Le cache sono sopravvalutate

Le cache del browser non sono eccezionali :

Il 40-60% degli utenti di Yahoo! ha un'esperienza di cache vuota e circa il 20% di tutte le visualizzazioni di pagina viene eseguita con una cache vuota.

e sui dispositivi mobili, dove la latenza rende le richieste extra più costose, le cache sono persino peggiori .

Controlla la frequenza di rimbalzo: si tratta di utenti che non beneficiano della XSLT memorizzata nella cache e addirittura pagano un prezzo aggiuntivo per scaricare il foglio di stile e attendere che venga elaborato.

gzip è un XSLT inverso

La maggior parte delle trasformazioni effettuate tramite XSLT si riduce alla modifica del markup abbreviato in uno più dettagliato e all'aggiunta di ripetizioni. Ma gzip è eccezionale nel rimuovere ripetizioni / ridondanze dai file!

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

I clienti 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 loro motore XSLT è più veloce.

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

Non c'è motivo per cui fare questo lato server non dovrebbe ridimensionarsi così come generare direttamente HTML. Non ci sono inoltre molte ragioni per un grande sovraccarico costante rispetto a PHP. Apparentemente ci sono compilatori XSLT> JVM / CLR e suppongo che potresti persino tradurlo in codice nativo.

Tuttavia, l'idea di trasportare separatamente i dati e la struttura di presentazione è buona in quanto tale.
Può risparmiare molta larghezza di banda e persino le prestazioni del server. Ma pomeL ha citato alcuni punti.

Per un adeguato supporto attraverso i browser, xslt.js potrebbe essere d'aiuto.

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

L'invio di XML compatto e la presenza di una XSLT memorizzata nella cache sul client può persino far risparmiare la larghezza di banda.

Esci da tutti i browser che non supportano XSLT, come gli smartphone. Ma dovresti comunque creare una versione speciale per questi.

Il problema principale era che solo pochi browser lo supportavano bene, quindi non valeva la pena essenzialmente creare una nuova piattaforma da supportare. Inoltre, le versioni precedenti di IE non supportavano così bene e, se ricordo bene, almeno un IE aveva un dialetto XSLT diverso che offriva tutti i tipi di problemi divertenti.