Стоимость запроса HTTP и стоимость страницы?

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

Другим подходом, который я видел, является сохранение javascript в самой странице, особенно для javascript, специфичного для этой страницы, и не разделяемого на других страницах.

Но мой вопрос таков:

В какой момент мой javascript становится слишком большим, что становится более эффективным вытащить script в отдельный файл и разрешить дополнительный запрос для отдельного js файла?

Другими словами, как измерить, сколько байтов соответствует стоимости одного запроса?

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

Конечно, я знаю несколько факторов: скорость клиента, скорость полосы пропускания, латентность. Но должен быть поворотным пунктом, где имеет смысл делать одно над другим.

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

Мысли?

Ответ 1

Если вы просто посмотрите на цифры и предположите среднее время кругового хода для запроса 100 мс и средней скорости соединения 5 Мбит/с, вы можете прийти к числу, которое говорит, что до 62,5 КБ можно добавить в страница, прежде чем разбить ее на отдельный файл, станет полезной. Предполагая, что сжатие gzip включено на вашем сервере, тогда реальный объем JavaScript, который вы можете добавить, еще больше.

Но это число игнорирует ряд важных соображений. Например, если вы переместите свой JavaScript в отдельный файл, пользовательский браузер может кэшировать его более эффективно, так что пользователь, который попадает на вашу страницу 100 раз, может загружать только файл JavaScript один раз. Если вы этого не сделаете и считаете, что ваша веб-страница имеет какой-либо динамический контент, то один и тот же пользователь должен будет загружать весь script каждый раз.

Еще одна проблема, которую следует учитывать, - это ремонтопригодность страницы. Как правило, чем больше добавляется JavaScript, тем сложнее становится поддерживать вашу страницу и вносить изменения и обновления без появления ошибок и других проблем. Таким образом, даже если у вас недостаточно 62,5 Кбайт JavaScript и даже если вы не заботитесь о кешировании, вы должны спросить себя, может ли отдельный файл JavaScript улучшить ремонтопригодность, и если да, то ли это стоит жертвовать этой ремонтопригодностью для немного более быстрой загрузки страницы.

Таким образом, здесь нет точного ответа, но, как правило, я считаю, что если JavaScript - это материал, который действительно является неотъемлемой частью страницы (onclick handlers, эффекты/анимации, другие вещи, которые напрямую взаимодействуют с элементами на страница), то она принадлежит со страницей. Но если у вас есть куча другого кода, который ваши обработчики, эффекты и другие вещи используют больше как утилиту library/helper, тогда этот код можно перенести в отдельный файл. Благодарите за поддержку вашего кода за размер страницы и время загрузки. Это моя рекомендация, так или иначе.

Ответ 2

При правильном наборе заголовков (далекие будущие заголовки видят: 1), потянув js в отдельный файл, почти всегда лучший выбор, так как все последующие запросы на страницу не будут делать никакого запроса или соединения вообще для файла js,

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

Что касается размера байта, равного стоимости http-соединения, это трудно определить из-за переменных, которые вы упомянули, а также многих других. Запросы HTTP-ресурсов могут кэшироваться в узлах по пути к пользователю, их можно сопоставить во многих ситуациях, и одно соединение можно повторно использовать для множественного запроса (см. 2).

Размер страницы по-прежнему чрезвычайно важен в Интернете. Мобильные браузеры становятся все более популярными и наряду с этими шероховатыми соединениями через мобильные провайдеры. Постарайтесь сохранить размер файла.

Дополнение: Следует отметить, что основные достижения по размеру страницы могут быть достигнуты путем минимизации и gzip, которые очень просты в использовании благодаря хорошим инструментам сборки и веб-серверам соответственно.

Ответ 3

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

По моему собственному опыту, я думаю, что это частично сводится к модуляции и компромиссам. Так, например, имеет смысл собрать вместе javascript, который является общим для всего вашего сайта. Если вы обслуживаете активы из CDN и устанавливаете правильные заголовки HTTP (Cache-Control, Etag, Expires), вы можете получить большой прирост производительности.

Верно, что вы понесете стоимость браузера, делающего запрос, и получите 304 Not Modified с сервера, но этот ответ, по крайней мере, будет быстрым, чтобы пройти через провод. Тем не менее, вы, как правило, по-прежнему несете расходы на обработку вашего запроса сервером и решите, что актив не изменился. Здесь широко используются веб-прокси, такие как Squid, Varnish и CDN.

По теме CDN, особенно в отношении JavaScript, имеет смысл вытаскивать библиотеки, такие как jQuery, из одного из общедоступных CDN. Например, Google выпускает множество самых популярных библиотек, доступных через CDN, который почти всегда будет быстрее, чем вы обслуживаете его с вашего собственного сервера.

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

Но, чтобы действительно сварить его, я не стал бы слишком беспокоиться о "байтовой стоимости запроса" и "общем размере загрузки в байтах" - вам нужно будет запускать сайт с высоким трафиком, чтобы беспокоиться о этот материал. И это обычно не проблема, так как, как только вы доберетесь до определенного уровня, вы действительно не сможете выдержать какой-либо объем трафика без CDN или другого слоя кеширования перед вами.

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

Надеюсь, что это поможет.