Правило "все, що потрібно, перш ніж сторінка почне рендерінг, має бути з того самого сервера", як правило, стосується вашогосервери чи інші менші ресурси - ситуації, коли пошук DNS може зайняти помітну частку секунди (яка може швидко скластись, якщо ваші об’єкти розсіяні навколо багатьох доменів). За допомогою загальнодоступних публічних ресурсів, таких як кеш-пам'ять jQuery та інших бібліотек Google, є хороший шанс, що веб-переглядач вашого відвідувача вже здійснив пошук DNS сьогодні (тому що інші сайти посилаються на вміст цієї служби) і, ймовірно, має файл у кеші, так що ні передачу потрібно зробити (або якщо запит буде зроблено, він може отримати лише коротку відповідь "304 - не змінено"). Навіть якщо для об’єкта потрібне повне завантаження, мережа доставки вмісту Google для більшості користувачів буде швидшою, ніж ваша менша операція.
Одне пов’язане правило: об’єкти, які не потрібні для правильної функції сторінки (як бачить користувач), слід посилатися якомога пізніше у головному відповіді HTTP. Наприклад, такі речі, як сценарії, необхідні для рекламних / статистичних послуг (наприклад, Google Analytics та її інк) - надайте користувачеві ваш вміст якомога швидше, а потім завантажте фонові матеріали, які вас справді цікавлять. Я заблокував пару служб оголошень / статистики (зіставивши їх у 127.0.0.1 у моєму файлі хостів), оскільки вони часто занадто повільні, а сайти, які посилаються на них рано, просто дають мені порожню сторінку, а сценарії чекають замість цього з посиланням на них із запізненням, щоб я міг прочитати вміст, який я там перебуваю, тоді як інші речі мандрують на задньому плані.
Корисність домену без файлів cookie для статичного вмісту - це питання масштабу. Якщо у вас є один 10-байтовий ідентифікатор сеансу в файлах cookie та десять тисяч відвідувачів на день, що вимагають ~ 20 статичних об'єктів за відвідування, ви економите лише ~ 118 Мбіт пропускної здатності на місяць (20 * 20 * 10000 * 31/1024/1024). Якщо, з іншого боку, ваш веб-сайт зберігає один-два Кбайт у файлах cookie, різниця може бути набагато вагомішою, особливо якщо хтось із ваших користувачів отримує доступ до сайту через повільне з'єднання (наприклад, GPRS через прив’язку до мобільного телефону або понад - переповнене посилання Wi-Fi у зоні з високими перешкодами) або якщо ви отримуєте мільйони відвідувань на день.
Підводячи підсумок, для моїх налаштувань сценарії, які повинні бути завантажені, перш ніж сторінка зможе відобразити:
- ajax.googleapis.com чи подібні
- оригінальне ім'я хоста сторінки, що дзвонить
- статичний домен без файлів cookie
Для ресурсів, які не є важливими для початкового візуалізації сторінки, зверніться до них якомога пізніше та скасуйте вищевказаний список налаштувань (хоча різниця між оригінальним іменем хоста та доменом, що не містить файлів cookie, швидше за все, не суттєва, якщо ви не працюєте в масовому масштабі ).
With common public resources ... there is a good chance that your visitor's browser has already done that DNS lookup todayОсобисто мені не було б комфортно покладатися на це для свого сайту. Я хотів би, щоб це було якомога швидше в якомога більшій кількості ситуацій. Незважаючи на те, ви заробляєте хороші бали. +1