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

Question

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

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

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

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

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

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

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

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

Мысли

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

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

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

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

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

1. http://developer.yahoo.com/performance/rules.html
2. http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Persistent_connections

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