Які недоліки надсилання XML у браузери та дозволити їм застосовувати XSLT?

Контекст

Працюючи позаштатним розробником, я часто робив веб-сайти повністю на основі XSLT. Іншими словами, при кожному запиті генерується XML-файл, що містить усе, що нам потрібно знати про вміст сторінки: ім'я користувача, який наразі увійшов у систему, записи верхнього меню, якщо це меню динамічне / налаштоване, текст до відображення в певній області сторінки тощо. Потім XSL обробляє (кешує тощо) його на сторінку HTML / XHTML, щоб відправити в браузер.

Це має гарний момент спростити створення невеликих веб-сайтів, особливо з PHP. Це свого роду двигун шаблонів, але який я віддаю перевагу іншим двигунам шаблонів, тому що він набагато потужніший, ніж більшість шаблонів, і тому, що я знаю це краще і подобається. Також за потреби можна надати доступ до необроблених XML-даних на вимогу для автоматизованого доступу без необхідності створення окремих API.

Звичайно, він не зможе повністю вийти на будь-який веб-сайт середнього або масштабного масштабу, оскільки, навіть маючи хороші методи кешування, XSL все ж погіршує загальну ефективність веб-сайту та вимагає більшої кількості процесорних серверів.

Питання

Сучасні браузери мають можливість приймати XML-файл і трансформувати його з пов'язаним файлом XSL, оголошеним у XML <?xml-stylesheet href="demo.xslt" type="text/xsl"?>. Firefox 3 може це зробити. Internet Explorer 8 теж може це зробити.

Це означає, що можна перемістити обробку XSL з сервера на клієнтську частину для 50% користувачів (згідно зі статистикою браузера на кількох веб-сайтах, де я, можливо, захочу це впровадити). Це означає, що ті 50% користувачів отримуватимуть лише XML-файл при кожному запиті, таким чином зменшуючи пропускну здатність їх та сервера (файл XML значно коротший, ніж оброблений аналог HTML), і зменшуючи використання CPU сервера.

Які недоліки цієї техніки?

Я подумав про декілька, але це не стосується цієї ситуації:

• Складна реалізація та необхідність вибору, виходячи із запиту браузера, коли надсилати необроблений XML і коли замість цього перетворювати його в HTML. Очевидно, що система не буде набагато складнішою, ніж реальна. Єдина зміна, яку слід внести, - це додати посилання на файл XSL до кожного XML та додати перевірку браузера.
• Більше використання IO та пропускної здатності, оскільки файл XSLT завантажуватиметься браузерами, а не кешується сервером. Я не думаю, що це буде проблемою, оскільки файл XSLT буде кешований браузерами (як, наприклад, зображення, або CSS, або файли JavaScript).
• Можливо, деякі проблеми на стороні клієнта, як, можливо, проблеми при збереженні сторінки в деяких браузерах.
• Складність відладки коду: неможливо отримати джерело HTML, який браузер фактично використовує, оскільки єдиним відображуваним джерелом є завантажений XML. З іншого боку, я рідко переглядаю HTML-код на стороні клієнта, і в більшості випадків він є непридатним безпосередньо (видаляється пробіл).

Веб-переглядачі не можуть прогресивно надавати XSLT

Це означає, що більше нічого не завантажується і нічого не відображається, поки всі дані та весь таблиця стилів не завантажуються та обробляються.

Ви пропускаєте прогресивне відображення та попереднє завантаження зображень, CSS та JS.

Початкове завантаження затримується іншим запитом

Для невеликих файлів (<20 кбіт) кількість запитів, а не пропускна здатність, є вузьким місцем для передової продуктивності, і більшість сторінок і таблиць стилів потраплять до цієї категорії.

Якщо у вас є великі сторінки, то це ще гірше - дивіться перший пункт.

Напевно, ви не зберігаєте жодну пропускну здатність

Сам XSLT є досить багатослівним і, можливо, потрібно буде містити шаблони для всього сайту та логіку для всіх рідкісних випадків, а не лише для речей, що використовуються на поточній сторінці.

Ви все ще повинні включати всі дані, помічені в головному XML-файлі, який ви надсилаєте, наприклад, якщо ви надсилаєте повідомлення в блозі, XSLT не може зробити жодної магії, щоб зробити її значно меншою. Якщо ви надсилаєте складні дані, то в будь-якому разі буде багато розмітки.

Схованки завищені

Кеші браузера не такі великі :

40-60% користувачів Yahoo! Мають порожній кеш, і ~ 20% усіх переглядів сторінок виконуються з порожнім кешем.

а на мобільних пристроях, де затримка робить додаткові запити найдорожчими, кеші ще гірші .

Перевірте показник відмов - це користувачі, які не користуються кешеним XSLT, і навіть платять додаткову ціну, щоб завантажити таблицю стилів і чекати, коли вона буде оброблена.

gzip є зворотним XSLT

Більшість перетворень, здійснених через XSLT, зводиться до зміни тривалої розмітки на більш багатослівну та додавання повторень. Але gzip чудово знімає повторення / надмірність з файлів!

У будь-якому випадку ви повинні використовувати gzip (відправляти XML нестисненим - марно). Велика ймовірність, що розмір обробленого документа gzipped буде приблизно таким же, як gzipped розмір необробленої XML - але вам не доведеться надсилати зайвий XSLT, і браузери зможуть розпочати рендерінг, як тільки надійдуть перші пакети.

Клієнти можуть бути повільними

Навіть припускаючи найкращий випадок завантаження з кешу, обробка XSLT на стороні клієнта відбувається швидше, лише якщо CPU користувача швидший, а їх XSLT двигун - швидший.

На стороні сервера ви можете робити всілякі фокуси з оптимізації (наприклад, кешовані оброблені фрагменти або навіть цілі сторінки). Ви можете використовувати найновіший, найшвидший процесор XSLT (у браузерах є лише XSLT 1.0 і, ймовірно, не дуже оптимізовано). І на вашому сервері, ймовірно, є процесор, який підтримує чисті дешеві офісні комп'ютери, телефони тощо.

Немає причин, чому цей сервер не повинен масштабуватись, а також безпосередньо генерувати HTML. Існує також не так багато причин для великих постійних накладних витрат порівняно з PHP. Очевидно, є XSLT> JVM / CLR компілятори, і я гадаю, що ви навіть можете перевести його на рідний код.

Однак ідея транспортування даних та структури презентації окремо є хорошою.
Це може заощадити багато пропускної здатності та навіть продуктивність сервера. Але pomeL згадав ряд моментів.

Для належної підтримки у веб-переглядачах може допомогти xslt.js.

Особисто я не прихильник XML, тому я б використовував JSON, а не JS шаблон двигуна, який буде виконуватися в браузері. Або якийсь механізм шаблону, який перетворює розмітку шаблону у виконуваний js на стороні сервера, який використовується для візуалізації на стороні клієнта.
JavaScript досить швидкий і доступний практично скрізь. JSON і JS набагато компактніші, ніж XML та XSLT.

Надсилання компактного XML та кешування XSLT на клієнті може навіть зберегти вашу пропускну здатність.

Ви залишаєте будь-які браузери, які не підтримують XSLT, як смартфони. Але ви все одно повинні створити спеціалізовану версію для них.

Основна проблема полягала в тому, що лише кілька браузерів добре підтримували цю проблему, тому створити нову платформу для підтримки не варто. Крім того, більш старі версії IE не підтримували це добре, і якщо я правильно пригадую, принаймні один IE мав інший діалект XSLT, що створює всілякі проблеми.