@toomanyairmiles частично верен - цель этого метода - позволить параллельные соединения от веб-браузера к серверу. Веб-браузеры должны позволять минимум два одновременных подключения к одному хосту, но многие новые браузеры могут управлять до 60. Независимо, одновременные одновременные соединения между браузером и веб-сервером (ами) являются основным узким местом в скорости.
С ресурса Google :
Спецификация HTTP 1.1 (раздел 8.1.4) гласит, что браузеры должны разрешать не более двух одновременных подключений на одно имя хоста (хотя более новые браузеры допускают нечто большее: см. Список Browserscope). Если HTML-документ содержит ссылки на больше ресурсов (например, CSS, JavaScript, изображения и т. Д.), Чем максимально допустимое на одном хосте, браузер выдает запросы на такое количество ресурсов и ставит в очередь остальные. Как только некоторые запросы завершаются, браузер выдает запросы на следующее количество ресурсов в очереди. Он повторяет процесс до тех пор, пока не загрузит все ресурсы. Другими словами, если страница ссылается на более чем X внешних ресурсов с одного хоста, где X - максимально допустимое количество подключений к хосту, браузер должен загружать их последовательно, по X за раз, получая 1 RTT для каждого X ресурсов. Общее время приема-передачи равно N / X, где N - количество ресурсов, которое нужно извлечь с хоста. Например, если браузер разрешает 4 одновременных подключения на одно имя хоста, а страница ссылается на 100 ресурсов в одном домене, для каждого из 4 ресурсов будет использоваться 1 RTT, а общее время загрузки - 25 RTT.
Таким образом, способ обойти это состоит в том, чтобы «разделить» запросы на разные домены или хосты:
Опять же с того же ресурса Google:
Баланс распараллеливаемых ресурсов по именам хостов.
Запросы для большинства статических ресурсов, включая изображения, CSS и другие двоичные объекты, могут быть распараллелены. Балансируйте запросы ко всем этим объектам как можно больше между именами хостов. Если это невозможно, как правило, убедитесь, что ни один хост не обслуживает более чем на 50% больше среднего по всем хостам. Так, например, если у вас 40 ресурсов и 4 хоста, каждый хост должен обслуживать в идеале 10 ресурсов; в худшем случае ни один хост не должен обслуживать более 15. Если у вас есть 100 ресурсов и 4 хоста, каждый хост должен обслуживать 25 ресурсов; ни один хост не должен обслуживать более 38.
Но есть еще одна часть головоломки. Каждый запрос обычно идет со своими издержками, обычно в форме файлов cookie. Статические элементы, такие как изображения, CSS и JavaScript, не должны передавать данные cookie, поэтому обслуживание их из (суб) доменов без cookie может привести к более быстрым круговым поездкам:
Статическое содержимое, например изображения, файлы JS и CSS, не обязательно должно сопровождаться файлами cookie, поскольку пользователь не взаимодействует с этими ресурсами. Вы можете уменьшить задержку запроса, обслуживая статические ресурсы из домена, который не обслуживает файлы cookie. Этот метод особенно полезен для страниц, ссылающихся на большие объемы редко кэшируемого статического содержимого, такого как часто меняющиеся миниатюры изображений или редко используемые архивы изображений. Мы рекомендуем этот метод для любой страницы, которая обслуживает более 5 статических ресурсов. (Для страниц, которые обслуживают меньше ресурсов, чем это, это не стоит затрат на настройку дополнительного домена.)
Чтобы зарезервировать домен без файлов cookie для обслуживания статического содержимого, зарегистрируйте новое доменное имя и настройте базу данных DNS с записью CNAME, которая указывает новый домен на существующую запись домена A. Настройте веб-сервер для обслуживания статических ресурсов из нового домена и не разрешайте установку файлов cookie в этом домене. На своих веб-страницах укажите имя домена в URL-адресах для статических ресурсов.
