Одно решение, ну, это не убийственное решение для всех случаев, но одно решение - делегировать агрегацию контента на стороне сервера, а не все в конечном браузере.
Это можно сделать с помощью ESIGates .Один из них - Varnish-Esi , но он не охватывает всю спецификацию ESI . Этот (esigate.org) также с открытым исходным кодом и, возможно, с лучшим охватом (еще не тестировался).Система ESI означает, что макет вашего приложения может представлять собой комбинацию различных блоков с разной политикой кэширования (TTL) и разных поставщиков.Сервер ESI будет принимать часть трафика, который вы первоначально депортировали в конечный браузер, так что этот будет стоить вам намного больше пропускной способности , но, по крайней мере, вы получите больший контроль в этом программном обеспечении, а не в других браузерах, используемых клиентами HTTP.
По крайней мере, это может улучшить политику кэширования асинхронной загрузки данных на ваш сервер и таким образом ускорить время отклика.для окончательного браузера (лучшее время отклика, меньше параллельной работы).
Теперь, на более широкой стороне, с точки зрения priority на вашей странице, вы, безусловно, должны определить, что является наиболее важным контентом,тот, с которым пользователь может начать играть, и что такое « украшение » (ну, это подразумевает, что ваш сервис представляет собой хорошее соотношение информации и шума, если ваш сайт ничего не предоставляет, кроме социальных сетейагрегации у вас возникнут проблемы).
Я предполагаю, что поскольку ваше приложение представляет собой небольшое статическое приложение с большимасинхронно загружаемые данные, вы используете много Ajax и не слишком много изменений страницы.Это означает, что после загрузки контента он будет находиться на странице в течение длительного времени.
Таким образом, содержание социальных сетей и других веб-служб задерживается и цепочками вместо большой параллельной нагрузки не должно быть проблем.Может быть, его не будет в первые 15 секунд, но если он останется на странице в течение следующих 15 минут, то это, возможно, не проблема (если самый важный контент уже есть, пользователь может даже не заметить, что декоративный контентбыл недоступен).Один совет по IE6 (а иногда и по IE7), используйте команды SetTimeouts() js везде, чтобы принудительно перерисовывать страницы, вы увидите, что доступный контент отображается быстрее.
Последний совет, если вам нужно сделать какой-то обычный ajaxпроверяет наличие обновленного контента.Если вы действительно проверяете эти данные для 10 контентов каждую минуту, у вас всегда будут проблемы с параллельной загрузкой и большая активность, та же проблема, что и при начальной загрузке, обычно вы можете использовать две вещи для решения этой проблемы, одна из них - COMET семейные долгосрочные HTTP-соединения (так что вы можете вместо этого PUSH-данные и / или получать более быстрые ответы, но только с вашим сервером, настроенным для такого рода HTTP-трафика).Второй добавляет фактор времени для следующих проверок, так что первая проверка выполняется через 1 минуту, следующая - через 2 минуты, затем через 3, 15, 25 и т. Д., В конце вы получаете новыйпроверять только каждый час возможно.И вы можете уменьшить задержку следующей проверки, когда обнаружите некоторую активность пользователя (некоторое взаимодействие с пользователем).Это потому, что вы можете предположить, что пользователь действительно ищет свежие данные только тогда, когда он действительно что-то делает с вашей страницей.Вы сэкономите некоторый пользовательский ЦП, а также поможете загрузить свой сервер.