Разве AJAX на загрузке страниц не плохая вещь?

Question

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

Разве это не плохо? Это кажется пустой тратой AJAX-вызова, поскольку они могут просто отобразить эти данные как JavaScript с остальной частью страницы.

Мой банк использует AJAX для получения информации для создания элементов формы для формы «Перевод средств». Эта информация составляет несколько килобайт, поэтому запрос AJAX кажется излишним.

Во время ужина для ботаников, по крайней мере, в видео MIX09 , которое я видел, они запрашивают (через AJAX) набор обедов для отображения на элементе управления картой при загрузке страницы.

Я мог бы понять, если мы говорим о больших объемах данных, которые в противном случае заняли бы слишком много времени, но если бы их было меньше 10-15 КБ, не лучше ли было бы перенести данные с разметкой? Они делают это, чтобы избежать кэширования данных?

Edit: я предлагаю вместо того, чтобы открывать AJAX-вызов к серверу, чтобы получить данные json при загрузке клиентов, просто сделать так, чтобы asp.net (или любой другой) отображал json в содержимом страниц, когда он оказывает все остальное. Я просто почувствовал необходимость указать на это, потому что фактический код на стороне клиента был бы точно таким же, за исключением того, где начинается переменная json.

Answer 1

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

Иногда это может быть более трудоемким, особенно если этот же вызов AJAX при загрузке используется во время страницы в более поздние моменты. Вы можете дублировать код, выполняя его на стороне сервера. Таким образом, существует компромисс между производительностью и объемом кода, который вы хотите написать.

Другим аспектом этого является то, что Javascript иногда используется для защиты от ботов, скребков, вредоносных программ (например, ключей и т. Д.) И т. Д. Как для вашей безопасности, так и для безопасности сайта. Это может означать, например, загрузку элементов страницы с помощью Javascript просто потому, что это усложняет взлом или очистку. Не невозможно, просто сложнее.

Answer 2

Кнопка возврата

Если пользователь нажимает назад / вперед, сервер больше не будет вызываться, поскольку он вытаскивает содержимое из кэша. Однако при вызове ajax при загрузке страницы на стороне клиента сервер всегда будет вызываться.

Answer 3

В целом вы правы, если вы изначально перетягиваете страницу с сервера, зачем делать еще одну поездку, чтобы получить больше данных? Но если данные большие, то вы можете также загрузить страницу, чтобы конечные пользователи могли что-то увидеть, а затем извлекать данные.

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

Плюс, всегда помните, что демонстрации - это просто демонстрации. Парни из Nerd Dinner, вероятно, были более заинтересованы в том, чтобы показать, как использовать AJAX с MVC, чем о других приоритетах.

Во всяком случае, хороший улов.

Answer 4

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

Наличие всего, что создано в javascript, имеет значение для поиска и т. Д., Но, если вы знаете об этом при разработке страницы, это не слишком большая проблема.

Answer 5

Я бы написал исходную страницу на стороне сервера, чтобы включить этот первый потенциальный вызов AJAX, а затем использовал бы реальный AJAX для чего-либо после этого. Вы хотите сделать больше работы для своего конечного пользователя, чтобы сделать его быстрее для конечного пользователя.

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

Answer 6

Я согласен с Адамом. Если у вас есть большая сложная страница, для которой может потребоваться некоторое время для рендеринга вашего сервера, но в которой есть только несколько битов динамического контента, то вы можете получить большие преимущества в производительности от агрессивного кэширования HTML и загрузки динамического контента с помощью Ajax.

В качестве примера представьте главную страницу сайта, которая должна отображать имя пользователя в углу. Все, кто посещает ваш сайт, попадут на эту страницу, поэтому, чем больше кеширования для HTML, тем лучше. Заполнив имя пользователя с помощью Ajax, вы можете предоставить одну и ту же кэшируемую версию HTML для всех и раздельно предоставлять гораздо меньший динамический контент.

Кэшируемость становится еще более важной, если вы работаете с не очень быстрой серверной технологией - в любом случае Ruby on Rails. Вы можете получить хороший прирост скорости на стороне сервера, обслуживая страницы через прокси-сервер, такой как Varnish или Squid, который хранит кэшированную копию каждой обслуживаемой страницы. Последующие запросы на тот же ресурс будут обслуживаться из кэша прокси вместо кода вашего сервера, пока кэш не станет устаревшим.

Answer 7

Просто причина, почему я мог видеть, как это делается:

Выполнение вызова AJAX для загрузки исходных данных может служить способом проверки того, что Javascript включен и что последующие вызовы AJAX должны работать. В противном случае может случиться так, что первый вызов на сервер, выполненный клиентом с использованием JavaScript, не будет работать, и пользователь может быть разочарован тем, почему это не работает, не осознавая, что причина в его настройках безопасности.

Answer 8

против Ajax при загрузке страницы

• Использует дополнительное доступное соединение на вашем сервере для обработки запроса AJAX.
• При попытке завершить звонок вы можете оставить свою страницу вхолостую.
• Не индексируется поисковыми системами.

Для Ajax при загрузке страницы

• Удобный. Хранит данные вне страницы.
• облегчает изменение данных.
• Возможность реализовать кеширование ответа Ajax.
• Создание множества «виджетов», каждый из которых обрабатывает свои собственные вызовы.

Многое из этого также зависит от того, на каком участке находится ваше здание. Вы хотите быть осторожными с большими сайтами, чтобы не полагаться на тонны небольших вызовов Ajax прямо при загрузке страницы.

Answer 9

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

Answer 10

AJAX-вызов при загрузке страницы должен сохранить отделение представления от контента / данных.

Презентация (HTML-страница) может быть кэширована браузером, и вызов AJAX извлекает данные только для обновления пользовательского интерфейса.

Это может привести к очень чистому разделению, а также к некоторым преимуществам в производительности. На самом деле вы передаете меньше информации по сети, поскольку не передаете суп HTML-тега - просто в любом представлении, в котором хранятся ваши данные.