Реактивные веб-сайты

aOII??AIEA EA·?UO?I?? HTTP-A‡O?OOO‚

Уменьшение времени разрешения доменного имени

Перед тем как браузер смо-

жет установить соединение с веб-

сервером, он должен разрешить

доменное имя, т. е., зная его, вы-

числить IP-адрес сервера. Резуль-

тат может быть закэширован в

браузере и операционной системе

пользователя, и задержки при по-

вторном открытии веб-страницы

не возникнет.

Если же такой записи в кэше

не существует, задержка на время

———————— Page 37————————

36 РЕАКТИВНЫЕ ВЕБ-САЙТЫ

поиска IP-адреса может оказаться значительной и будет зависеть от до-

ступности DNS-сервера, содержащего требуемую информацию (а иногда и

от доступности цепочки таких серверов).

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

разрешением доменного имени — использовать наименьшее количество

различных хостов для размещения внешних объектов веб-страниц, в осо-

бенности для тех объектов, которые требуются для первоначального ото-

бражения страницы.

Идеальным с точки зрения минимизации времени разрешения адре-

са DNS-сервера считается вариант, когда все объекты расположены на

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

зуется хостов, тем больше вероятность того, что браузер сможет повторно

использовать уже установленное соединение.

На практике же почти у всех браузеров существуют ограничения на

количество одновременных соединений с одним хостом. Принимая во

внимание это ограничение, наибольший выигрыш в скорости загрузки

страниц можно получить, распределив загружаемые объекты по несколь-

ким (4-6) хостам. Подробнее об особенностях параллельной загрузки

объектов можно прочитать в пятой главе книги «Разгони свой сайт».

Уменьшение количества редиректов

Иногда возникает необходимость перенаправить браузер с одного

адреса на другой. Причины чаще всего следующие:

? добавить косую черту к имени домена;

? предоставить пользователю документ, перемещенный на другой

адрес;

———————— Page 38————————

7

Обзор методов клиентской оптимизации 3

? позволить пользователю обращаться к документам сайта даже ес-

ли он ошибся в написании адреса (например, не набрал www в на-

чале адреса);

? направить пользователя на другие домены первого уровня, осно-

вываясь на его географическом месторасположении и данных об

используемом им языке;

? направить пользователя на определенные страницы в зависимос-

ти от того, авторизован он или нет;

? направить пользователя на страницы с другим протоколом (HTTP

или HTTPS);

? отследить и сохранить действия пользователя и т. д.

Какой бы ни была причина, каждый редирект порождает дополни-

тельный HTTP-запрос, занимающий определенное время. Поэтому для

страниц, для которых скорость загрузки наиболее критична, число реди-

ректов должно быть сведено к минимуму. Для этого необходимо:

? следить за тем, чтобы ссылки на веб-страницах не вели на адреса,

где заведомо будет срабатывать редирект;

? избегать цепных (последовательных) редиректов;

? использовать минимальное количество альтернативных адресов

для одних и тех же страниц, стараясь предоставить всем пользова-

телям единственный актуальный адрес для каждой страницы;

? использовать внутренние перенаправления — функцию, доступ-

ную в большинстве веб-серверов;

? использовать средства отслеживания информации о пользовате-

ле, не основанные на редиректах;

? предпочитать серверные редиректы клиентским, которые могут

быть заданы при помощи тега или JavaScript-обработчика.

Редиректы, отправляющие браузеру код состояния 300, 301 или

302 и заголовок Location, обрабатываются браузером моменталь-

но, а при выполнении клиентских редиректов браузеру требуется

дополнительное время на разбор полученной веб-страницы. Кро-

ме того, некоторые браузеры могут кэшировать информацию о ре-

директах, тем самым ускоряя повторную загрузку ранее открытых

веб-страниц.

1.4.5.