Следует отметить следующее:
Для относительно небольших объектов (левая часть графика) можно сказать, судя по большому пустому месту над линиями, что пользователь очень слабо использует свой канал; при этом браузер запрашивает объекты так быстро, насколько может. Для такого пользователя эффективное использование входящего канала наступает при загрузке объектов размером 100 Кб и более.
Для объектов размером примерно в 8 Кб можно удвоить эффективную пропускную способность канала, включив постоянные соединения на сервере и распределив запросы по 4 серверам. Это значительное преимущество.
Если пользователь включит конвейерную передачу запросов в своем браузере (для Firefox это будет network.http.pipelining в about:config), число используемых хостов перестанет играть значительную роль, и он будет задействовать свой канал еще более эффективно, однако мы не сможем контролировать это на стороне сервера.
Возможно, более прозрачным будет следующий график, на котором изображено несколько различных интернет-соединений и выведено относительное ускорение для запроса страницы с множеством мелких объектов для случая использования 4 хостов и включения активного соединения на сервере. Ускорение измеряется относительно случая 1 хоста с выключенным keep-alive (0%).
Что тут интересного?
Если вы загружаете много мелких объектов, меньших, чем 10 Кб, оба пользователя — и тот, что находится локально, и тот, что на другом конце континента, — почувствуют значительное ускорение от включения активного соединения и введения 4 хостов вместо одного.
Чем дальше находится пользователь, тем значительнее выигрыш.
Чем больше скорость соединения, тем больше выигрыш. Пользователь с Ethernet-каналом в 100 Мб на расстоянии всего 20 мс от сервера почувствует наибольшее ускорение.
Давайте теперь посмотрим, как размер заголовков влияет на эффективную пропускную способность канала. Предыдущий график предполагает, что размер заголовков составляет 500 байтов дополнительно к размеру объекта, как для запроса, так и для ответа. Как же изменение этого параметра отразится на производительности нашего 1,5 Мб / 384 Кб канала и расстояния до пользователя в 100 мс? Предполагается, что пользователь уже изначально использует 4 хоста и активное соединение.
На графике хорошо видно, что при небольших размерах файлов основные задержки приходятся на исходящий канал. Браузер, отправляющий «тяжелые» запросы на сервер (например, с большим количеством cookie), по-видимому, замедляет скорость передачи данных более чем на 40% для этого пользователя. Естественно, размер cookie можно и нужно регулировать на сервере. Отсюда простой вывод: cookie нужно по возможности делать минимальными или направлять ресурсные запросы на серверы, которые не выставляют cookie.
Все полученные графики являются результатом моделирования и не учитывают некоторые реальные особенности окружающего мира. Но можно взять и проверить полученные результаты в реальных браузерах в «боевых» условиях и убедиться в их состоятельности. Реальное положение дел определенно усугубляет ситуацию, ибо медленные соединения и большие задержки становятся еще больше, а быстрые методы соединения по-прежнему выигрывают.
Рассмотрев методы сжатия, объединения, кэширования и создания параллельных соединений, разумно было бы озадачиться следующим вопросом: какая часть страницы должна загружаться вместе с основным HTML-файлом, а какая — только с внешними файлами?
Было собрано тестовое окружение в виде одной страницы, для которой применены различные оптимизационные техники (заодно было получено реальное ускорение для загрузки произвольной страницы и показано, как все эти техники реально влияют на скорость загрузки страницы).
Кроме того, были проведены теоретические выкладки для определения оптимального распределения загрузки по стадиям с учетом всех аспектов.
Основная идея вариации потока загрузки заключалась в создании минимального количества «белых мест» на диаграмме загрузки. Как видно из рис. 5.7, около 80% при загрузке страницы составляют простои соединений (естественно, что данный график не отражает реальную загрузку открытых в браузере каналов загрузки, однако при уточнении картины ситуация практически не меняется). Параллельные загрузки начинаются только после прохождения «узкого места», которое заканчивается (в данном случае) после предзагрузки страницы — после CSS-файла.
