Кілька файлів на CDN проти одного файлу локально


93

Мій веб-сайт використовує близько 10 сторонніх бібліотек javascript, таких як jQuery, jQuery UI, prefixfree, кілька плагінів jQuery, а також мій власний код javascript. В даний час я витягую зовнішні бібліотеки з CDN, таких як Google CDN та Cloudflare. Мені було цікаво, що є кращим підходом:

  1. Витягування зовнішніх бібліотек із CDN (як це роблю сьогодні).
  2. Поєднуючи всі файли в один js та один файл css та зберігаючи їх локально.

Будь-які думки вітаються, якщо вони пояснені. Дякую :)

Відповіді:


139

Значення CDN полягає у ймовірності того, що користувач вже відвідав інший сайт, викликаючи той самий файл із цього CDN, і стає все більш цінним залежно від розміру файлу. Ймовірність цього буде зростати із повсюдністю запитуваного файлу та популярністю CDN.

З огляду на це, витягування відносно великого та популярного файлу з популярного CDN має абсолютний сенс. jQuery і, в меншій мірі, jQuery UI, відповідають цьому законопроекту.

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

Шаблон HTML5 робить досить хорошу роботу, забезпечуючи загальне рішення для цього:

  1. Modernizr завантажується з локального в голову: він дуже маленький і досить сильно відрізняється від екземпляра до екземпляра, тому немає сенсу отримувати його з CDN, і користувачеві не зашкодить занадто завантажувати його з вашого сервер. Це вкладається в голову, тому що CSS, можливо, цим користується, тож ви хочете, щоб його ефекти були відомі до відтворення тіла. Все інше йде внизу, щоб зупинити важчі сценарії, що блокують рендеринг під час їх завантаження та виконання.
  2. jQuery з CDN, оскільки майже всі користуються ним, і він досить важкий. Користувач, ймовірно, вже матиме цей кеш перед тим, як відвідати ваш сайт, і в цьому випадку він негайно завантажить його з кешу.
  3. Усі ваші менші сторонні залежності та фрагменти коду, які, швидше за все, сильно не зміняться, об’єднуються у plugins.js файл, завантажений із вашого власного сервера. Це буде кешовано із заголовком віддаленого терміну дії під час першого відвідування користувача та завантажено з кешу під час наступних відвідувань.
  4. Ваш основний код входить main.js, з ближчим заголовком терміну дії, щоб врахувати той факт, що логіка вашого додатка може змінюватися від тижня до тижня або місяця до місяця. Таким чином, коли ви виправляєте помилку або вводите нову функціональність, коли користувач відвідує через два тижні, це може завантажуватися свіжо, тоді як увесь наведений вище вміст може бути доставлений із кешу.

Для інших ваших основних бібліотек вам слід розглянути їх окремо і запитати себе, чи слід їм слідувати вказівкам jQuery, завантажувати їх окремо з вашого власного сервера або об'єднувати. Приклад того, як ви можете приймати такі рішення:

  • Angular неймовірно популярний і дуже великий. Отримайте з CDN.
  • Twitter Bootstrap має подібний рівень популярності, але у вас є відносно невеликий вибір його компонентів, і якщо у користувача його ще немає, можливо, не варто змушувати їх завантажувати повну інформацію. Сказавши це, те, як він вписується в решту вашого коду, є досить внутрішнім, і ви, швидше за все, не зміните його, не перебудувавши весь сайт - тому ви можете захотіти розміщувати його локально, але зберігати файли окремо від вашого головний plugins.js. Таким чином, ви завжди можете оновити свої plugins.jsрозширення Bootstrap, не примушуючи користувача завантажувати все ядро ​​Bootstrap.

Але тут немає імперативу - ваш пробіг може відрізнятися.


4
Дуже хороша відповідь. Нехай кеш браузера працює для вас. Мені подобається ідея відокремити популярні бібліотеки від об’єднаних файлів.
Джон

3
Дуже корисний аналіз
користувач

8
Дуже хороша відповідь. Також варто зазначити, що CDN дозволить користувачам витягувати файли з "локального" або, принаймні, ближчого (до користувача) сервера. Отже, якщо ваш сервер знаходиться в Європі, наприклад, користувачі з Південної Америки чи Росії, все одно отримуватимуть файли відносно швидко.
H.Wolper
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.