Чи слід поєднувати файли js / css в один файл?


11

Як додатки YSlow, так і Google Page Speed ​​Speed рекомендують поєднувати файли скриптів (і стилів) в один файл, щоб зменшити кількість HTTP-запитів, і я, безумовно, бачу сенс цього, коли файли скриптів узгоджуються на всьому сайті, але для веб-додатків, які мають різні вимоги на сайті.

Як я це бачу, є кілька варіантів:

  1. Поєднайте всі файли, які використовуються на сайті, і кожна сторінка отримує один і той же комбінований файл - недоліком є ​​невикористаний вміст, захаращуючи сценарій (і важче перше завантаження (також перезавантажтесь, коли будь-який компонентний сценарій зміниться))

  2. Комбінуйте файли на основі кожної сторінки - недолік кожної сторінки з різними вимогами отримує різний комбінований файл (важче перше завантаження для кожного типу сторінки)

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

Думки?


Ви робите це неправильно. Або розділіть частини на окремі файли, і скористайтеся програмою розминки (спричиненою більшою кількістю запитів та холодним кешем), або програмуйте комбіновано файли вихідних файлів на сервері та обслуговуйте лише 1 js, css, html-сторінку на жорсткому посиланні. Змішування файлів з різними типами mime = погано.
Еван Плейс

І ... як сказав @Larry Smithmier у своїй відповіді, використовуйте CDN (колишній Google) для доставки загальних бібліотек (наприклад, jquery), щоб повністю уникнути початкових витрат на прогрівання кешу для цих файлів.
Еван Плейс

Відповіді:


11

Варіант 2 - найгірший; це означає, що кожна сторінка з різною комбінацією необхідних сценаріїв JS призведе до HTTP-запиту. Це значно погіршить продуктивність .

Варіант 1 - найкращий. Врешті-решт більшість користувачів відвідають більшість «типів» сторінки вашого веб-сайту, тому все-таки вигідно поєднувати все в один файл, за винятком великих JS-файлів, які потрібні на кількох, рідко відвідуваних сторінках.

Звернення до першої сторінки може бути повільніше, ніж з різними файлами, але це все-таки варто зробити, оскільки кожен другий перегляд сторінки використовує кешований глобальний JS.

Одна порада, хоча; з’єднайте їх автоматично, якщо ви ще цього не зробили!


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

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

4

Я, як правило, поєдную "глобальний Javascript" - jQuery і загальні плагіни - в один файл, а потім подаю додаткові додатки як окремі файли, коли потрібно.

Наприклад, на одному сайті, на якому я запускаю багато сторінок, є таблиці даних на них, тому у мене є global.jsjQuery, DataTables та SuperFish (для мого меню). На сайті є дві сторінки, які використовують "лайтбокс", тому у мене є окремий сценарій для цих двох сторінок.

Для CSS я просто обслуговую один файл для всього сайту і намагаюся зробити CSS максимально загальним - більшість сторінок мають лише кілька унікальних елементів CSS.


1

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

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


1

Я б не пропонував поєднувати їх усіх. Якщо ви використовуєте загальну бібліотеку, ви можете використовувати CDN для доставки ваших javascripts. Потім ви можете скористатися кешуванням браузера (якщо інші сайти використовують той самий CDN) та розподіленою доставкою. Майкрософт та Google мають рішення (я їх чесно не використовував, але я, звичайно, почну), і можуть бути інші. У відповідній записці SO має таке запитання:

Коли браузер автоматично очищає кеш JavaScript?

і перша відповідь - тверде золото.


2
Я вже використовую бібліотеку jQuery, що розміщується в Google, але я мав на увазі, що це питання стосується конкретних файлів для сайту (тобто для сайтів обміну стеками, коли ви задаєте запитання, у якого є сценарій для пошуку подібних питань, сценарій для візуалізації розмітка та пропозиції щодо тегів, усі вони можуть бути розроблені в окремих файлах). Крім того, якщо ви використовуєте jQuery, розміщений js Google, в той час як 1.4 і 1.4.2 надаватимуть вам однаковий вміст (на даний момент), 1.4.2 кешується протягом року, а 1.4 - кешується лише протягом години.
Cebjyre

класна порада! дякую за ознайомлення з тривалістю кешування на розміщеному jQuery.
Ларрі Смітм'є
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.