Один файл .js против отложенной загрузки - PullRequest
4 голосов
/ 04 августа 2011

Сценарий. Вы создаете большое веб-приложение на основе JavaScript, в котором требуется как можно меньше обновлений страницы.Представьте себе 80-100 МБ незавершенного javascript, просто для того, чтобы иметь число для определения «большого».

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

Теперь, теоретически, существует фиксированная стоимость запроса на любой файл вданный сервер, независимо от размера файла.Таким образом, слишком много запросов не было бы желательно.Например, если небольшой файл javascript загружается одновременно с 10 другими файлами малого или среднего размера, может быть лучше сгруппировать их вместе, чтобы сэкономить на стоимости нескольких запросов.

Мой вопроспри условии разумных значений по умолчанию (скажем, клиент имеет соединение 3-5 Мбит / с и приличную часть аппаратного обеспечения), Какой идеальный размер файла для запроса? Слишком большой, и вы вернулись к загрузке слишкомв одно время;слишком мала, и стоимость запроса становится дороже, чем объем возвращаемых данных, что снижает экономию данных в секунду.

Редактировать : все ответы были фантастическими,Я выбрал Бена только потому, что он дал конкретный номер.

Ответы [ 3 ]

3 голосов
/ 04 августа 2011

Инициатива Google Page Speed ​​рассказывает об этом подробнее:

http://code.google.com/speed/page-speed/docs/rules_intro.html

В частности http://code.google.com/speed/page-speed/docs/payload.html

2 голосов
/ 04 августа 2011

Я думаю, ясно, что заставить клиента загружать больше, чем МБ js, прежде чем он сможет что-либо сделать, плохо А также заставить клиента загружать больше всего, что необходимо, тоже плохо. Но есть очевидное преимущество в том, что все это кэшируется.

Факторы, которые будут влиять на цифры:

  1. Время туда-обратно
  2. Время ответа сервера
  3. Размер заголовка (включая файлы cookie)
  4. Техника кеширования
  5. Браузер (см. http://browserscope.com)

Балансирование параллельной загрузки и различные требования к кэш-памяти также являются поводом для беспокойства. Это было частично покрыто недавно Кайлом Симпсоном здесь: http://www.reddit.com/r/javascript/comments/j7ng4/do_you_use_script_loaders/c29wza8

2 голосов
/ 04 августа 2011

Я бы постарался сохранить количество, которое нужно загрузить, чтобы показать страницу (даже если только индикатор загрузки) под 300K. После этого я собирал дополнительные данные по 5 МБ за раз с отображением индикатора загрузки (возможно, индикатора выполнения). У меня была неудачная загрузка 15 Мб на широкополосном Wi-Fi кафе, который в противном случае казался нормальным. Если бы это было настолько плохо, что загрузка <5MB не удалась, я бы не стал винить сайт в том, что он не работал. </p>

Я бы также рассмотрел возможность загрузки двух файлов одновременно, помимо исходного файла <300 КБ, с использованием загрузчика, такого как <a href="http://labjs.com/" rel="nofollow"> LabJS или HeadJS , для программного добавления тегов сценария.

...