Производительность: запрос JSON и визуализация в JS или запрос всего HTML?

Ответ 1

JSON - это путь. Сеть может быть огромным узким местом, в то время как javascript быстро управляет вещами. Наибольшая разница будет на медленных соединениях. И это определенно стоит разбора. Новые браузеры предлагают собственный JSON, поэтому он должен быть сумасшедшим быстрым.

Еще одна вещь, которую следует учитывать: innerHTML содержит много ошибки (таблицы, формы и т.д..). В этих случаях у вас есть много накладных расходов, чтобы заставить его работать кросс-браузер. Проблемы могут возникнуть неожиданно, что делает ваше приложение менее стабильным.

JSON, однако, позволяет вам решить, хотите ли вы использовать методы innerHTML или DOM в соответствии с содержимым. Это еще одна огромная победа.

Ответ 2

Вам нужно будет измерить время вашей ситуации, потому что ответ будет зависеть от:

Выведенный сервером HTML:

• Время, необходимое на сервере для форматирования данных в формате HTML при низких и высоких нагрузках.
• Время, необходимое для перемещения отформатированного HTML к клиенту при низких и высоких нагрузках.
• Время, необходимое для перерисовки страницы с отформатированным HTML на клиенте, для медленных и быстрых клиентов и браузеров.

Клиентский рендеринг HTML:

• Время, необходимое на сервере для форматирования данных как JSON при низких и высоких нагрузках.
• Время, необходимое для перемещения данных JSON клиенту при низких и высоких нагрузках.
• Время, необходимое клиенту для отображения HTML из данных JSON, для медленных и быстрых клиентов и браузеров.

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

[Добавлено]

Для каждого набора измерений (1, 2, 3) потребуется другой набор инструментов для захвата данных. Я бы выбрал 3 набора репрезентативных данных (самый маленький, средний, самый большой), а затем для каждого набора данных сделайте каждое из перечисленных выше измерений. Обратите внимание, что вам не нужно (и на самом деле не должно) использовать ваше полное приложение - вы действительно просто хотите, чтобы самый маленький фрагмент кода сделал то, что вы хотите. Затем я буду искать различия между обработанными сервером и рендерингом клиента и решить, какой (если он есть) был более важным в моем приложении.

Вы не сможете измерить каждую возможную комбинацию, но если вы выберете самый медленный браузер на самом медленном ПК, вы можете положиться (например, дешевый нетбук) и использовать самое медленное интернет-соединение ( у вас все еще есть учетная запись AOL для проверки, верно?), которая будет показывать вам худший случай, что вас действительно волнует.

Ответ 3

Я бы сказал # 2 - таким образом, он накладывает меньше нагрузки на ваш сервер и позволяет браузеру клиента выполнять работу. Это намного быстрее, потому что оно переносит меньше данных.

Ответ 4

Вам нужно измерять быстрые и медленные компьютеры. JavaScript может занять больше времени, чем время передачи PHP +, но зависит от скорости клиента (и скорости соединения, а также скорости PHP для создания HTML-кода).

Ответ 5

Наверное, нет окончательного ответа. Но учтите, что хотя с точки зрения запроса AJAX, возвращающий JSON, легче, чем запрашивать всю страницу с PHP. Обработка запроса JSON и обновление компонентов страницы имеют более высокую нагрузку на управление.

Вы считали гибрид? AJAX запрашивает, где PHP возвращает небольшие куски HTML.

Ответ 6

Сначала вам нужно сравнить размер в байтах JSON и HTML.

Если JSON не намного меньше, просто отправьте HTML. Использование JavaScript innerHTML для размещения фрагмента HTML на странице очень быстро. Построение дерева DOM из некоторого JSON будет медленнее.

В конечном счете разница во времени для пользователя, вероятно, будет незначительной, если количество JSON/HTML не будет действительно огромным.

Ответ 7

Зависит от типа сайта больше, чем что-либо еще. imo.

• Нужно ли вам грамотно деградировать?
• Какие браузеры могут использовать вашу целевую аудиторию?
• Какими могут быть соединения?
• Сколько будет хитов на сайте?

Можно, например, справедливо предположить, что сайт "tech" будет посещать люди с более быстрыми компьютерами, используя приличные браузеры с быстрыми подключениями.

Если вам нужно поддерживать IE6, я бы опасался слишком большого количества javascript, но это то, что нужно протестировать на самом деле.

Я обычно показываю на сервере, просто его проще, но опять же я делаю сайты с низкой загрузкой внутри сети.

Ответ 8

Это будет действительно зависеть от того, какие данные вы передаете. Если у вас есть статические HTML-элементы на передней панели, вам нужно всего лишь заполнить значения, JSON - это самое быстрое и простое решение. Для этого существует множество, много, много клиентских JS-библиотек. Если это ваше требование, знайте, что при таком подходе ваш HTML уже существует либо на странице, либо в клиентской памяти в качестве шаблона (в зависимости от того, как вы script)

Что касается другого варианта, я бы предложил вам сделать это только в том случае, если у вас есть очень... "сложный" или действительно зависящий от сервера HTML, который может генерировать только сервер... или если вы вставляете HTML из какого-то другого места который поставляет HTML.

Скорость генерации ответа полностью зависит от вашего сервера и от того, как он запрограммирован. Поскольку JSON меньше, он, как правило, быстрее, и существует множество библиотек JSON для всех вариантов программного обеспечения.

Я думаю, вы должны изучить некоторые из более ориентированных на UI фреймворков JS там

Ответ 9

Это было упомянуто Николасом Закасом из Yahoo в его художественном/разговоре на Velocity 2010,

похоже, что вы работаете с javascript, поэтому стоит проверить слайды /pdf.

включает материал от Steve Sounders и массу людей, о которых я никогда не слышал:

http://en.oreilly.com/velocity2010

edit: если я правильно помню, что вывод был html, как правило, лучше из-за медленного js-анализа IE (я думаю!)

Ответ 10

Имейте в виду, что для пользователя, что на самом деле имеет значение, не общее время, а то, как он выглядит.

• Ситуация A) Пользователь нажимает кнопку, ничего не происходит в течение 2 секунд, затем данные грузы.
• Ситуация B) Пользователь нажимает кнопку , он говорит "пожалуйста, подождите" или что-то, тогда данные загружаются 3 секунды позже.

Для большинства пользователей ситуация на самом деле выглядит медленнее.

Итак, что бы вы ни делали, действительно пытайтесь получить прогрессивный рендеринг, работающий на вас, чтобы пользователь увидел, что что-то происходит как можно скорее.