Что быстрее?Ajax загружает JSON или Ajax загружает полный вывод

Question

Я хотел увидеть разные взгляды / мнения по этому поводу.

У меня есть Jquery, вызывающий функцию через ajax. Загружает данные двумя способами:

1. Сценарий ajax загружает данные JSON с того же сервера, а затем использует JS для их анализа и добавления в html.

2. Сценарий ajax загружает полный html / скрипт, настроенный напрямую через этот php-скрипт, который вызывается, а затем JS добавляет его в html div.

Я бы предположил, что # 1 быстрее, поскольку он загружает базовый массив JSON, а затем использует JS для его анализа и добавления в html.

Мнения

Спасибо!

Answer 1

Есть много переменных. # 1 может быть быстрее, при условии, что ваш JavaScript не собирает полученный результат по частям и при условии, что данные заметно меньше, чем эквивалентная разметка. Если вы собираете результат по частям или если данные не намного меньше разметки, это может быть медленнее. Это также зависит от скорости сетевого подключения пользователя от скорости его процессора и браузера (Chrome довольно быстрый, IE7 довольно медленный) и т. Д.

По частям: например, если вы загружаете таблицу из 200 строк и строите строки следующим образом:

// ...stuff that initializes `tableBody` and clears out old stuff...
for (index = 0; index < stuff.length; ++index) {
    tr = $("tr");
    tr.append("td").html(stuff[i].a);
    tr.append("td").html(stuff[i].b);
    tr.append("td").html(stuff[i].c);
    tableBody.append(tr);
}

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

Если, однако, вы делаете это примерно так:

markup = [];
for (index = 0; index < stuff.length; ++index) {
    markup.push("<tr>");
    markup.push("<td>" + stuff[i].a + "</td>");
    markup.push("<td>" + stuff[i].b + "</td>");
    markup.push("<td>" + stuff[i].c + "</td>");
    markup.push("</tr>");
}
tableBody.append(markup.join(""));

... вы в лучшей форме, потому что там вы получаете максимальное повторное использование благодаря способности браузера быстро анализировать HTML (что, по сути, то, что делают браузеры и для чего они оптимизированы).

На первый взгляд может показаться немного нелогичным, что создание строки и ее передача в браузер может быть быстрее (даже заметно быстрее), чем построение структуры напрямую с помощью методов DOM или jQuery. Но чем больше вы думаете об этом, тем более очевидно (и да, я проверил это ), почему это так. DOM - это абстракция, которую браузер должен сопоставить со своими внутренними структурами, и каждый вызов метода DOM пересекает пограничный слой между JavaScript и механизмом DOM браузера. В отличие от этого, добавление в массив выполняется быстро, join - быстро (даже в современных браузерах быстрое совпадение строк). Передача в браузере полной строки сводит к минимуму количество поездок между слоями и позволяет браузеру создавать свои внутренние структуры напрямую, не беспокоясь об их эквивалентах DOM (до тех пор, пока вы не попросите их позже). Последний раз я проверял это пару лет назад, и результаты были впечатляющими. Я должен попробовать это снова с текущими браузерами; хотя сегодня нет времени ...

Answer 2

Сказать, какое из этих двух решений быстрее, невозможно: все зависит от того, что вы делаете, будь то на стороне PHP или на стороне JS.

Что вам следует делатьрассмотрим, в основном, насколько трудной может быть разработка этих решений - и если это означает дублирование некоторых усилий:

• PHP работает на вашем сервере;вы контролируете окружающую среду;и вам не нужно адаптировать свой код для каждого типа браузера.
• Если вы отображаете некоторые вещи с помощью Ajax, скорее всего, вы захотите отображать и те, которые используют не-Ajax - что означает, что вы можетеуже есть некоторый PHP-код для его рендеринга;если это так, то для его дублирования в JS может потребоваться больше работы, а просто использовать его повторно.

Выполнение действий на вашем сервере означает:

• Вероятно,немного большее использование сети: отправка HTML вместо данных может означать большую полезную нагрузку - но при использовании сжатия это не должно иметь большого значения.
• Чуть больше нагрузки на ваш сервер (вы можете кэшировать некоторые вещихотя) - но рендеринг обычно требует меньше ресурсов, чем получение данных из вашей базы данных

В конце, если я могу указать вам ответ, который я дал на этот вопрос: Почему плохая практика - возвращать сгенерированный HTML вместо JSON?Или это?

Answer 3

Вы должны использовать document.createDocumentFragment, что приведет к повышению производительности. Присоединение к этому фрагменту только использует память и не изменяет сам DOM, пока вы не будете готовы. Я считаю, что document.createElement по-прежнему превосходит innerHTML, потому что он обходит разбор строк. Вы всегда можете запустить несколько тестов, чтобы увидеть результаты.

Тест: http://jsperf.com/innertext-vs-fragment Источник: https://developer.mozilla.org/en-US/docs/Web/API/document.createDocumentFragment

Answer 4

Бенчмаркинг покажет вам, что быстрее всего.

Answer 5

Мой собственный опыт недавно обнаружил, что использование innerHTML для больших кусков HTML значительно быстрее, чем создание его с document.createElement().Это намного быстрее, так что я больше не беспокоюсь о тестировании скорости.Разница в скорости незначительна для небольших, неглубоких структур, и для них я все равно сделаю это с createElement(), но все более сложное добавляется в виде строки.

Раньше я довольно скептически относился к innerHTML, поэтому было неожиданностью, когда я сел и написал свои тесты.

Я бы порекомендовал вам попробовать и написать свои собственные тесты скорости.

Answer 6

Ответ на этот вопрос зависит от многих факторов, в том числе:

• Скорость клиентского компьютера (старые машины обычно подавляются сложным анализом JS и вычислениями)
• Скорость сети иразмер сгенерированного контента (это в основном относится к большим наборам данных, которые преобразуются в гораздо больший HTML)
• Характер манипулирования данными, который выполняет функция