Яка перевага розміщення статичних ресурсів в окремому домені?

Я помічаю, що багато сайтів розміщують свої ресурси на окремому домені від основного сайту, наприклад, StackExchange за допомогою sstatic.net, Barnes & Noble за допомогою imagesbn.com тощо.

Я розумію, що статичні ресурси є вигідними для того, щоб розмістити свої статичні ресурси на окремому хості, можливо, завдяки ефективному веб-серверу статичних файлів, такому як nginx, і звільнити основний сервер, щоб зосередитись на поданні динамічного контенту. Аналогічно, логічний аутсорсинг на спільний CDN, наприклад, на облачному напрямку Akamai.

Яка ж користь від використання окремого домену в іншому випадку? Чому sstatic.net замість static.stackexchange.com?

Оновлення : Кілька відповідей пропускають основне питання. Я розумію, що розбиття між кількома хостами є користю - паралельні завантаження, більш тонкий веб-сервер тощо. Але що є більш невловимим, це те, чому кілька доменів . Чому sstatic.net, а не static.stackexchange.com як хост для спільних ресурсів? Поки що це стосується лише однієї відповіді.

На багатьох сайтах встановлено досить багато файлів cookie, ці файли cookie мають на меті підтримувати певний стан.

Поміщаючи статичні (без стану) ресурси на абсолютно інший домен, ви можете зменшити розмір запитів http. У деяких випадках існує стільки файлів cookie, що один HTTP-запит потребує передачі двох пакетів TCP. Отже, наявність окремого домену є одним із способів зменшити кількість пакетів для запиту різних частин сторінки.

Інші методи з тією ж метою - це об'єднання багатьох зображень в один спрайт та об'єднання всіх Javascript в один файл.

Крім використання CDN, використання окремих доменів для статичних даних також означає:

1. Ви можете використовувати легкий веб-сервер, який не повинен завантажувати всі модулі / розширення, які ваш веб-сервер з динамічним вмістом повинен завантажувати при кожному запиті. Якщо не потрібно сканувати кожен каталог на шляху URI для читання файлів .htaccess, це також збільшує кількість одночасних запитів, якими може оброблятися сервер.

2. Додавання додаткового субдомену означає, що ви збільшуєте кількість паралельних завантажень, які може виконувати браузер.

3. Якщо налаштовано належним чином (наприклад, розміщення вашого веб-сайту www.example.comзамість example.com), ви також можете скористатись субдоменом, який не містить файлів cookie, скоротивши трафік та зворотній шлях.

Єдиний мінус - якщо ви використовуєте сеанси SSL, вам потрібен підписаний сертифікат та окремий статичний IP для додаткових доменів. Але переваги переважують цю незначну незручність у більшості випадків.

Редагувати:

Вибачте, я неправильно прочитав ваше запитання. Якщо ви запитуєте, чому деякі користувачі використовують окремі SLD, на це відповість дужка №3. Це також пояснено на sstatic.net :

Якщо ваш домен www.example.org, ви можете розмістити статичні компоненти на static.example.org. Однак якщо ви вже встановили файли cookie на домені верхнього рівня example.org на відміну від www.example.org, усі запити до static.example.org включатимуть ці файли cookie. У цьому випадку ви можете придбати цілком новий домен, розмістити там свої статичні компоненти та зберегти файл cookie-домену. Yahoo! використовує yimg.com, YouTube використовує ytimg.com, Amazon використовує images-amazon.com тощо.

Але втілений також згадує хороший момент щодо використання окремої загальної SLD замість піддомену існуючої SLD, коли ви користуєтесь великою мережею сайтів, які діляться певними активами.

Нарешті, як зазначає Нільс Базіс, частина причини усунення файлів cookie - мінімізація кількості пакетів, які використовуються для виконання запиту. Я думаю, що в керівництві YSlow зазначено, що більшість мереж мають максимальний розмір пакета в 1500 байт, тож утримуючи його під 1500 байтами, це зменшить накладні витрати TCP. Це також демонструє ще одну перевагу використання sstatic.netзамість static.webmasters.stackexchange.com.

Lèse majesté висвітлював основні моменти, але для подальшого розширення додам, що наявність одного домену для всіх різних сайтів Stack Exchange означає, що хтось, хто їх переглядає, завантажує статичний вміст, такий як JavaScripts, лише один раз. Наприклад, перейшовши до Superuser, користувач буде використовувати кешований вміст, оскільки він знаходиться з того самого місця.

Є ще корисна інформація про Yahoo та Google про це.

Основна причина - печиво. Те, що Нільс запропонував у своїй відповіді, є лише другорядним наслідком, а не справжньою причиною. Без файлів cookie розмір запиту менший, тому це економить деяку пропускну здатність.

Однак реальна різниця пов'язана з кешем браузера. Оскільки вміст є статичним (тобто не змінюється), браузери можуть кешувати його на локальному жорсткому диску і уникати завантаження файлу з Інтернету щоразу. Замість цілого файлу веб-сервер просто надсилає відповідь 304, тобто зміст не змінився.

Коли сайт використовує файли cookie, браузери вважають, що вміст файлу може відрізнятися для різних користувачів, тому вони не кешують ці файли. Обслуговування файлу з домену, що не містить файлів cookie, гарантує належне функціонування кешування браузера.

Це основна причина, оскільки це покращує час завантаження та значно зменшує пропускну здатність.

Старі браузери обмежені лише двома паралельними завантаженнями на ім’я хоста.

Розбиття елементів веб-сторінки на декілька доменів називається загостренням домену . Це дозволяє паралельно завантажувати більше ресурсів, скорочуючи загальний час завантаження сторінки.

Оптимальна кількість доменів, які слід розділити, становить 2-4. Після 4 доменів час відгуку погіршується .