Разгони свой сайт

Средняя веб-страница содержит более 50 объектов, и издержки на число объектов доминируют над всеми остальными задержками при загрузке большинства веб-страниц. Браузеры, следуя рекомендациям спецификации HTTP 1.1, обычно устанавливают не более 2 одновременных соединений с одним хостом. При увеличении числа HTTP-запросов, требуемых для отображения страницы, с 3 до 23 — время, затрачиваемое именно на «чистую» загрузку объектов, от общего времени загрузки падает с 50% до всего 14%.

Если число объектов на странице превышает 4, то издержки на ожидание доступных потоков и разбор чанков для присланных объектов превалируют над общим временем загрузки страницы (от 80% до 86% для 20 и 23+ объектов соответственно) по сравнению со временем, которое уходит на действительную загрузку данных. Время инициализации плюс время ожидания, вызванное ограничением на параллельные соединения, занимают 50–86% от общего времени загрузки страницы.

При увеличении числа подключаемых объектов сверх 10 время, затрачиваемое на инициализацию соединения, возрастает до 80% и более от общего времени, уходящего на получение объектов. Стоит отметить, что можно существенно уменьшить издержки на доставку большого числа объектов (более чем 12 на страницу) включением для сервера keep-alive режима и распределением запросов по нескольким хостам.

Ограничения спецификации HTTP/1.1

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

Спецификация HTTP, приблизительно 1999 года, рекомендует, чтобы браузеры и серверы ограничивали число параллельных запросов к одному хосту двумя. Эта спецификация была написана задолго до существенного расширения каналов загрузки и была рассчитана на соединения с маленькой скоростью загрузки. Большинство браузеров поддерживают это ограничение на число потоков в спецификации, хотя переход на HTTP 1.0 увеличивает число параллельных загрузок до 4. Поэтому большинство браузеров серьезно ограничено этим параметром, если им приходится загружать большое число объектов с одного хоста (по словам Алекса Могилевского, в IE8 это число будет равно 6 из-за определенных издержек на установление нового соединения). Существует два основных пути для обхода этого ограничения (не считая, конечно, тонкой настройки используемого клиентами браузера, о которой рассказывается в восьмой главе):

Отдавать ваши объекты с нескольких серверов.

Создать несколько поддоменов для нескольких хостов.

Чтобы найти подходящий баланс, IE до версии 7 включительно ограничивают пользователей всего восемью одновременными соединениями или двумя соединениями на хост для протокола HTTP 1.1. HTTP 1.0 немного отличается в этом плане, но это уже совсем другая история, потому что все выгоды от постоянных соединений доступны только, если мы будем использовать HTTP 1.1 (или уже так делаем).

Времена меняются

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

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

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

«Режем» соединения