Должен ли весь мой статический контент находиться в домене без файлов cookie? - PullRequest
0 голосов
/ 25 июля 2011

В настоящее время мы обслуживаем значительную часть статического контента из альтернативного (cookiefree) домена - фактически, это также совершенно другой IP-адрес, если это имеет значение.

Это, безусловно, помогло нам в скорости загрузки страницы, однако не весь контент подается с этого домена.

Общеизвестно, что обслуживание из второго домена происходит быстрее, потому что вы исключаете трафик cookie / сеанса / и т. Д. и , потому что это позволяет использовать более параллельные соединения.

Последнее мне очень интересно: если мы переместим все статическое содержимое в другой домен, основной домен получит только один запрос (для HTML), а все остальные последующие запросы перейдут к другой домен.

Это уменьшит количество одновременных запросов, которые браузер отправит на наш сервер. Разве это не сделает вещи медленнее? Тем более, что наши страницы часто включают много изображений.

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

1 Ответ

1 голос
/ 04 октября 2011

Вы правы, но вам не нужно придерживаться одного домена без файлов cookie ...

Например, вы можете использовать шардинг через субдомены, например, используйте static.domain.com для js / css, а затем image1.domain.com / image2.domain.com / etc для изображений.

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

Для упрощения обслуживания каждый поддомен может быть направлен назад на один и тот же сервер.

Обновление - 12 декабря, 13

В наши дни я бы не стал использовать более 2 осколков (и я бы измерил их с осколками и без них) - Уилл Чен написал хороший пост о «перерасходе» и перегрузке TCP - https://insouciant.org/tech/network-congestion-and-web-browsing/

...