Есть вопрос?
Зайди на форум

Поиск на сайте: Advanced

Denix - новый дистрибутив Linux. Русификация Ubuntu и установка кодеков

dkws.org.ua
Форум сайта dkws.org.ua
 
Главная    ТемыТемы    АльбомАльбом    РегистрацияРегистрация 
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 

Помогаем браузеру оптимизировать веб-страницу

 
Начать новую тему Ответить на тему    Список форумов dkws.org.ua -> Сеть
 
Автор Сообщение
den

Старожил


Зарегистрирован: 31.01.2006
Сообщения: 13870
Откуда: Кировоград, Украина

СообщениеДобавлено: Ср Май 07, 2014 12:52 pm    Заголовок сообщения: Помогаем браузеру оптимизировать веб-страницу
Ответить с цитатой

Вот как можно помочь браузеру оптимизировать наши страницы

<link rel="dns-prefetch" href="//hostname_to_resolve.com"> 1
<link rel="subresource" href="/javascript/myapp.js"> 2
<link rel="prefetch" href="/images/big.jpeg"> 3
<link rel="prerender" href="//example.org/next_page.html?quot;> 4

1. Предварительное разрешение определенного имени узла
2. Предварительная выборка критически важного ресурса, который будет найден далее на этой странице
3. Предварительная выборка ресурса, который может понадобиться для этой или будущей страницы
4. Предварительный рендеринг определенной страницы
Вернуться к началу
Посмотреть профиль Отправить личное сообщение dhsilabs@jabber.ru
den

Старожил


Зарегистрирован: 31.01.2006
Сообщения: 13870
Откуда: Кировоград, Украина

СообщениеДобавлено: Ср Май 21, 2014 1:29 pm    Заголовок сообщения:
Ответить с цитатой

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

Техника доменного шардинга (domain sharding) известна уже довольно давно и особенно актуальной была в пору популярности таких браузеров как IE6 и IE7. Данные браузеры строго следовали положениям спецификации протокола HTTP и имели ограничение на количество одновременных соединений с сервером сайта — не более двух. Однако современные браузеры допускают не менее 6 соединений, а последние версии Opera и вовсе 16 *. Так ли уместен этот трюк на сегодняшний день?

Принципы доменного шардинга
Идея шардинга была простой до нельзя — вместо того, чтобы использовать одно доменное имя, можно попробовать обмануть браузер с помощью следующей конфигурации DNS:
s1.domain.com CNAME s.domain.com
s2.domain.com CNAME s.domain.com
s3.domain.com CNAME s.domain.com
s.domain.com A 192.168.1.1
В итоге, используя различные домены в ссылках на ресурсы, мы можем увеличивать количество параллельных соединений пропорционально количеству псевдонимов (канонических записей). Впрочем, ряд исследований указывал на то, что эффективным является использование 2-4 шардов, что и стало негласным правилом для большинства веб-разработчиков.

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

<meta http-equiv="x-dns-prefetch-control" content="on">
<link rel="dns-prefetch" href="http://s1.domain.com">
<link rel="dns-prefetch" href="http://s2.domain.com">
<link rel="dns-prefetch" href="http://s3.domain.com">
Таким образом, пользовательский браузер попытается преобразовать доменные имена в соответствующие IP адреса еще до того, как они встретятся при загрузке стилей или изображений.

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

Фактически общее ограничение для большинства браузеров составляет 30-35 параллельных соединений. Но не стоит забывать, что существует также ограничение и на скорость соединения, как со стороны пользователя, так и со стороны хостинг-провайдера. Сравнить это можно с желанием скачать одновременно несколько фильмов — так или иначе итоговое время все равно будет ограничено шириной канала.

По этой причине для файлов размером 50-150 кБ узким местом может стать скорость соединения даже для незначительного количества допустимых соединений, к таким файлам, как правило, относятся JPEG изображения и JavaScript файлы.

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

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

Шаг за шагом
Предположим, что все статические ресурсы сайта находятся на сервере с именем

s.domain.com
а шарды для данного сервера будут получать следующие имена

s1.domain.com
s2.domain.com
...
Оптимальный вариант реализации в общем случае будет чем-то напоминать секционирование при проектировании баз данных.

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

s.domain.com
Файлы JavaScript мы будем ассоциировать также с этим доменным именем.

После загрузки HTML документа и всех основных стилей постепенно начнется процесс получение остальных объектов и рендеринг страницы. Так как обычно загрузку скриптов пытаются сделать максимально отложенной или она вовсе может происходить при участии сторонних серверов, то основные усилия браузера будут брошены на загрузку требуемых изображений. Поэтому большие по размеру изображения можно привязать, например, к поддомену:

s1.domain.com
а небольшие PNG или GIF изображения к поддоменам:

s2.domain.com
s3.domain.com
Естественно, если количество таких небольших файлов менее 6-8, то достаточно и одного псевдонима. Таким образом, получаем до 18 параллельных соединений.

С файлами скриптов существует один нюанс и для таких браузеров как Internet Explorer и Opera, где до сих пор имеют место блокировки при загрузке JavaScript*. Выглядеть это будет приблизительно так

Блокировка при загрузке файлов JavaScript в браузере Opera
Сколько бы ни было допустимых соединений, файлы все равно буду грузиться последовательно. Поэтому, если среди ваших пользователей, например, браузер Opera крайне популярен, то стоит позаботиться об объединенном общем JavaScript файле или использовать асинхронную и отложенную загрузку скриптов.

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

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

Оригинал http://webperformance.ru/2011/05/20/effective-domain-sharding/

(там же есть картинки)
Вернуться к началу
Посмотреть профиль Отправить личное сообщение dhsilabs@jabber.ru
Показать сообщения:   
Начать новую тему Ответить на тему    Список форумов dkws.org.ua -> Сеть Часовой пояс: GMT
Страница 1 из 1
 Главная страница сайта
 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
© Колисниченко Денис