Каковы недостатки отправки 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 тоже может это сделать.

Это означает, что для 50% пользователей возможно перенести обработку XSL с сервера на клиентскую часть (согласно статистике браузера на нескольких веб-сайтах, где я могу захотеть реализовать это). Это означает, что эти 50% пользователей будут получать только XML-файл при каждом запросе, тем самым уменьшая их пропускную способность и пропускную способность сервера (XML-файл намного короче, чем его обработанный аналог HTML), а также уменьшая загрузку ЦП сервера.

Каковы недостатки этой техники?

Я думал о нескольких, но это не относится к этой ситуации:

• Сложная реализация и необходимость выбирать, основываясь на запросе браузера, когда отправлять необработанный XML и когда вместо этого преобразовывать его в HTML. Очевидно, что система будет не намного сложнее, чем фактическая. Единственное изменение - добавить ссылку на файл XSL в каждый XML и добавить проверку браузера.
• Больше ввода-вывода и использования полосы пропускания, поскольку 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 без сжатия бесполезно). Весьма вероятно, что размер обработанного документа в формате gzip будет примерно таким же, как и размер необработанного XML в формате gzip, но вам не нужно будет отправлять дополнительный XSLT, и браузеры смогут начать рендеринг, как только поступят первые пакеты.

Клиенты могут быть медленными

Даже при условии наилучшего случая загрузки из кеша, обработка XSLT на стороне клиента происходит быстрее, только если пользовательский процессор быстрее, а его механизм 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, создавая всевозможные забавные проблемы.