Сколько стоит один запрос на сервер

Ответ 1

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

Я часто использую PageSpeed ​​и обычно следую за документально подтвержденными рекомендациями: https://developers.google.com/speed/docs/insights/about.

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

Ответ 2

Трудный вопрос:)

Конечно, тривиальный ответ заключается в том, что больше запросов занимает больше времени, но это не обязательно так просто.

• браузеры открывают несколько http-соединений для одного и того же хоста, см. http://sgdev-blog.blogspot.hu/2014/01/maximum-concurrent-connection-to-same.html. Потому что, не используя параллельную загрузку, а загружая один огромный файл, рассматривается как узкое место производительности http://www.sitepoint.com/seven-mistakes-that-make-websites-slow/
• веб-серверы, по возможности, должны использовать кодирование содержимого gzip. Поэтому размер текстовых ресурсов, таких как HTML, JS, CSS, довольно сжат.
• большинство этих активов являются статическим контентом, поэтому стандартный веб-сервер должен использовать кэширование etag на них. Это означает, что в следующий раз загрузка будет равна 26 байтам, так как сервер говорит "не изменен" вместо отправки 32-байтного кода JavaScript снова
• Из-за кэша etag весь веб-сайт должен быть кэшируемым (я предполагаю, что вы программируете игру или что-то в этом роде, а не какую-то страницу сервлета старой школы J2EE).
• Я бы предложил сделать 2-4 больших файла и загрузить их, если вы действительно хотите пойти на большие файлы

Итак, соединим:

• Если у вас есть только статический контент, то это все равно, потому что кэширование etag будет сокращать любую реальную загрузку с сервера, сервер возвращает 304 Не измененный ответ
• Если у вас есть сгенерированный динамический контент (например, страницы сервлета), сохраните JS и CSS отдельно, так как они могут быть кэшированы отдельно, и нужно загружать только страницу сервлета.
• проверьте, что ваш сервер поддерживает кодировку содержимого gzip для сжатия, это очень помогает:)
• Если у вас есть несколько динамических материалов (например, mutliple динамически меняющихся изображений), имеет смысл представить их как 2-4 отдельных изображения, чтобы использовать параллельные HTTP-соединения для загрузки (хотя я вряд ли могу представить этот случай использования в реальная жизнь)

Пожалуйста, убедитесь, что вы не используете статический контент динамически. То есть попробуйте загрузить изображение в веб-браузер, откройте представление сетевого трафика, перезагрузите F5 и убедитесь, что вы получаете 304 Не модифицировано с сервера, а не 200 OK и реальный трафик. Самая большая оптимизация производительности заключается в том, что вы ничего не извлекаете с сервера, и при правильном использовании он выходит из коробки:)

Ответ 3

Ваш вопрос не подлежит ответу на реальный общий характер.

Есть несколько причин сочетать скрипты и таблицы стилей.

Браузеры, использующие HTTP/1.1, будут открывать несколько соединений, обычно 2-4 для каждого хоста. Поскольку почти каждый сайт имеет фактический HTML файл и по крайней мере один другой ресурс, такой как таблица стилей, script или изображение, эти соединения создаются правильно, когда вы загружаете начальный URL, например index.html.

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

Тем не менее, вы можете разделить свои файлы на несколько хостов (например, дополнительный static.example.com), что увеличивает количество хостов/соединений и ускоряет загрузку. С другой стороны, это приводит к дополнительным издержкам из-за большего количества подключений и дополнительных запросов DNS.

С другой стороны, есть веские причины оставить ваши файлы расколотыми.

Самым важным является HTTP/2. HTTP/2 использует только одно соединение и мультиплексирует все загрузки файлов по этому соединению. Есть несколько демонстраций в Интернете, которые демонстрируют это, например. http://www.http2demo.io/

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

Тем не менее, если у вас есть ресурсы, вы можете использовать все свои файлы отдельно, используя HTTP/2 для клиентов, которые его поддерживают. Если у вас много старых клиентов, вы можете отказаться от комбинированных файлов для них, когда они делают запросы с использованием HTTP/1.1.

Ответ 4

Я думаю, что у @DigitalDan есть лучший ответ.

Но вопрос противоречит реальному, как мне сделать загрузку страницы быстрее? Или, по крайней мере, APPEAR для загрузки быстрее...

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

https://www.youtube.com/watch?v=EVEiIlJSx_Y

Ответ 5

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

Выше анализа анализа диаграммы для моего веб-приложения, что вам нужно рассмотреть, это

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

По каждому запросу мы имеем:

request start + initial connection + SSL negotiation+ time to first byte + content download

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

Ответ 6

На самом деле очень актуальный вопрос (тема), с которым сталкивается многие веб-разработчики.

Я также добавлю свой ответ среди других участников этого вопроса.

Введение перед тем, как ответить

Высокопроизводительные веб-сайты в зависимости от разных факторов, вот некоторые соображения:

• Размер веб-сайта
• Тип контента сайта (основной контент Текст, изображение, видео или смесь)
• Трафик на вашем сайте (Сколько людей посещает ваш сайт в среднем)
• Расположение веб-хоста и ваше основное местоположение посетителя (в вашей стране, регионе и во всем мире), это имеет большое значение, если у вас есть веб-сайт для Европы, а ваш хост находится в США.
• Технология веб-хост-сервера (аппаратная), я предпочитаю диски SSD.
• Как настраивается и оптимизируется веб-сервер (программное обеспечение)
• Это динамический или статический веб-сайт
• Если динамический, как ваш код и база данных структурированы и разработаны

Определив свою потребность, вы сможете найти правильную стратегию.

Что касается вашего вопроса вообще

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

Стив Соудерс 14 советов:

• Сделать меньше HTTP-запросов
• Используйте сеть доставки контента (CDN)
• Добавить заголовок Expires
• Компоненты Gzip
• Поместите стильные листы вверху
• Поместите скрипты в нижнюю часть
• Избегать CSS-выражений
• Сделайте JavaScript и CSS внешними, если это возможно.
• Уменьшить поиск DNS
• Свернуть JavaScript
• Избегать перенаправления
• Удалить скрипты дубликатов
• Конфигурирование ETages
• Сделать Ajax Cacheable

Относительно вашего вопроса

Итак, если принять во внимание js/css, следующее поможет много:

• Лучше иметь разные коды для разных файлов.
  Пример: у вас могут быть page1, page2, page3 и page4.
  page1 и page2 использует js1 и js2
page3 использует только js3
page4 использует все js1, js2 и js3
  Поэтому будет неплохо иметь JavaScript в 3 файлах. Вам не нужно включать все, что у вас есть, что вы не используете.
• CSS Sprites
• CSS наверху и JS в конце
• Мини-код JavaScript
• Поместите свой JavaScript и CSS во внешние файлы
• CDN, если вы используете jQuery, например, не загружайте его на свой сайт, просто используйте рекомендуемый адрес CDN.

Заключение

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

Удачи.

Ответ 7

Ответ на ваш вопрос действительно зависит.

Конечная цель оптимизации загрузки страницы заключается в том, чтобы ваши пользователи быстро чувствовали, что ваша загрузка страницы.

некоторые предложения:

• не объединяются общие библиотеки js css файлов, таких как jquery coz, которые они, возможно, уже кэшировали с помощью brower, когда вы посещали другие сайты, поэтому вам даже не нужно их загружать;

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

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

• пользователь может использовать телефон с медленной или несогласованной скоростью сети 3g/4g, поэтому даже 50 тысяч данных или еще 2 запроса делают их очень разными:

Ответ 8

Действительно плохо иметь много 100-строчных файлов, а также очень плохо иметь только один или два больших файла, хотя для каждого типа css/js/markup.

Настольные компьютеры имеют в основном высокоскоростное соединение, а мобильный также имеет высокую задержку.

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

Например, я думаю, что это лучший способ пойти сегодня:

1) поместите все необходимое для показа первой страницы/функциональности для пользователя в одном файле, должно быть меньше 100 КБ - это абсолютно необходимо.

2) после этого split или group файлы в размерах, чтобы латентность перестала быть заметной вместе с временем загрузки.

Чтобы сделать его простым и конкретным, если мы предположим: время до первого байта составляет около ~ 200 мс, размер каждого файла должен быть от ~ 120 КБ до ~ 200 КБ, что хорошо для большинства соединений сегодняшнего дня, в среднем.