Подключаем CDN

CDN – это множество веб‑серверов, распределенных географически для достижения максимальной скорости отдачи содержания клиенту. Сервер, который непосредственно будет отдавать файлы пользователю, выбирается на основании некоторых показателей. Например, выбирается сервер с наименьшим числом промежуточных запросов (англ. hop ) до него либо с наименьшим временем отклика.

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

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

80–90% времени загрузки страницы уходит на загрузку ее компонентов: картинок, CSS, скриптов, Flash и т. д. Вместо того чтобы заниматься изменением архитектуры самого приложения, сначала стоит распределить статический контент. Это не только позволяет добиться значительного ускорения загрузки страницы, но также легко реализуется благодаря CDN.

Yahoo! и Google

Yahoo! обеспечивает выдачу YUI (Yahoo! User Interface) библиотек, используя распределенную систему серверов по всему миру бесплатно. Это сервис обеспечивает:

gzip‑сжатие (уменьшает размер файлов от 60% до 90%);;

контроль за кэширующими заголовками;

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

Аналогичный сервис сейчас предоставляет и Google для JavaScript‑библиотек (в том числе, естественно, для всех дополнений от Google, таких как автоматическая страница «Ничего не найдено» (ошибка 404), AJAX API для поиска или Google Maps).

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

Количество DNS‑запросов

Система DNS устанавливает соответствие имен хостов их IP‑адресам, точно так же как телефонный справочник позволяет узнать номер человека по его имени. Когда вы набираете «www.yahoo.com» в адресной строке браузера, преобразователь DNS, к которому обратился браузер, возвращает IP‑адрес узла. DNS‑запрос имеет свою цену. Обычно требуется 20–120 миллисекунд, чтобы его выполнить и получить ответ (в российских реалиях это время обычно больше). Браузер вынужден ожидать завершения DNS‑запроса, т.к. до этого момента он еще не может ничего загружать.

Для повышения быстродействия результаты DNS‑запросов кэшируются. Это кэширование может происходить как на специальном сервере интернет‑провайдера, так и на компьютере пользователя. Информация DNS сохраняется в системном кэше (в Windows за это отвечает служба «DNS Client Service»). Большинство браузеров имеет свой кэш, не зависящий от системного. Пока браузер хранит DNS‑запись в своем кэше, он не обращается к операционной системе для DNS‑преобразования.

Internet Explorer по умолчанию кэширует результаты DNS‑запросов на 30 минут, как указано в переменной реестра DnsCacheTimeout. Firefox кэширует DNS‑ответы на 1 минуту, что видно из установки network.dnsCacheExpiration.

Когда клиентский кэш очищается (как системный, так и у браузера), количество DNS‑запросов возрастает до количества уникальных имен хостов на странице. А это включает в себя собственно адрес самой страницы, картинок, скриптов, CSS‑, Flash‑объектов и т. д. Уменьшение количества уникальных имен хостов уменьшает количество DNS‑запросов.

Однако уменьшение количества уникальных хостов потенциально уменьшает количество параллельных загрузок компонентов страницы. В свете этого обстоятельства наилучшим выходом будет распределение загружаемых компонентов между 2–4 (но не более) уникальными хостами. Это является компромиссом между уменьшением количества DNS‑запросов и сохранением неплохой параллельности при загрузке компонентов страницы.