Один величезний .css файл порівняно з кількома меншими конкретними .css файлами? [зачинено]

Чи є якась перевага мати один файл .css монстра, який містить елементи стилю, які будуть використовуватися майже на кожній сторінці?

Я думаю, що для зручності управління я хотів би витягнути різні типи CSS в кілька файлів і включити кожен головний файл в моє головне, <link />це погано?

Я думаю, що це краще

1. позицій.css
2. кнопки.css
3. таблиці.css
4. copy.css

vs.

1. site.css

Ви бачили будь-які приїзди, коли це робилося в один бік проти іншого?

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

Sass та LESS мають додаткову перевагу змінних, вкладення та інших способів полегшити CSS для запису та обслуговування. Настійно, дуже рекомендується. Я особисто використовую Sass (синтаксис SCSS) зараз, але раніше використовував LESS. Обидва чудові, з подібними перевагами. Після того, як ви написали CSS з компілятором, навряд чи ви хочете обійтися без одного.

http://lesscss.org

http://sass-lang.com

Якщо ви не хочете возитися з Ruby, цей менший компілятор для Mac чудово:

http://incident57.com/less/

Або ви можете використовувати CodeKit (тими самими хлопцями):

http://incident57.com/codekit/

WinLess - це графічний інтерфейс Windows для компіляції менше

http://wverage.org/

На це важко відповісти. На мою думку, обидва варіанти мають свої плюси і мінуси.

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

Моя думка була б однією з двох речей.

1) Якщо ви знаєте, що ваш CSS НІКОЛИ не змінюватиметься, коли ви його створили, я створив би декілька файлів CSS на стадії розробки (для читабельності), а потім об'єднав їх вручну перед початком роботи (щоб зменшити запити http)

2) Якщо ви знаєте, що збираєтесь змінювати свій CSS час від часу, і вам потрібно зробити його читабельним, я буду створювати окремі файли та використовувати код (за умови, що ви використовуєте якусь мову програмування), щоб комбінувати їх у час збирання часу виконання (мінімізація / комбінація часу виконання - це ресурс).

З будь-яким варіантом я б настійно рекомендував кешування на стороні клієнта, щоб ще більше зменшити http-запити.

EDIT:
Я знайшов цей блог, який показує, як комбінувати CSS під час виконання, використовуючи лише код. Варто подивитися (хоч я ще цього не перевіряв).

EDIT 2:
Я вирішив використовувати окремі файли під час мого проектування та процес збирання для мінімізації та комбінування. Таким чином, я можу мати окремий (керований) CSS під час розробки та належний монолітний мінімізований файл під час виконання. І в мене ще є свої статичні файли та менше системних накладних витрат, оскільки я не роблю стиснення / мінімізацію під час виконання.

Примітка: для ваших покупців там, я настійно пропоную використовувати bundler як частину вашого процесу збирання. Незалежно від того, що ви будуєте в межах свого IDE або зі скрипту збирання, bundler може виконуватися в Windows через включений exeабо може бути запущений на будь-якій машині, яка вже працює node.js.

Я віддаю перевагу декілька файлів CSS під час розробки. Керування та налагодження набагато простіше. Однак я пропоную прийти на час розгортання, замість цього ви використовуєте інструмент мінімізації CSS, наприклад YUI Compressor, який об'єднає ваші CSS-файли в один монолітний файл.

Ви хочете обох світів.

Вам потрібно кілька CSS-файлів, тому що ваш розум - це страшна річ.

При цьому краще мати один, великий файл.

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

Один із прикладів - щось подібне

<link rel="stylesheet" type="text/css" href="allcss.php?files=positions.css,buttons.css,copy.css" />

Потім сценарій allcss.php обробляє об'єднання файлів та їх доставку.

В ідеалі сценарій перевірятиме дати моди для всіх файлів, створює новий композит, якщо будь-який з них змінюється, потім повертає цей композит, а потім перевіряє відповідні заголовки HTTP-модуля, щоб не надсилати зайві CSS.

Це дає вам найкраще з обох світів. Також чудово працює для JS.

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

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

Отже, в обох випадках є вагомі причини ...

Рішенням, яке дозволить вам отримати найкращі з обох ідей, було б:

• Розробка за допомогою декількох невеликих файлів CSS
  • тобто легше розвиватися
• Щоб процес складання вашої програми був, він "поєднує" ці файли в один
  • Цей процес збирання може також зменшити великий файл, btw
  • Це, очевидно, означає, що у вашій програмі повинні бути деякі елементи конфігурації, які дозволяють їй переходити з «режиму багатофайлів» до «режиму монофайлів».
• І використовувати у виробництві лише великий файл
  • тобто швидше завантажувати сторінки

Існує також деяке програмне забезпечення, яке поєднує файли CSS під час виконання, а не під час збирання; але робити це під час запуску означає з'їсти трохи більше процесора (і очевидно потрібно трохи кешування меканізму, щоб не повторно генерувати великий файл занадто часто)

Історично однією з головних переваг x при наявності одного CSS-файлу є швидкість вигоди при використанні HTTP1.1.

Однак станом на березень 2018 року понад 80% браузерів зараз підтримують HTTP2, що дозволяє браузеру одночасно завантажувати декілька ресурсів, а також можливість попередньо натискати на ресурси. Наявність одного файлу CSS для всіх сторінок означає більший, ніж необхідний, розмір файлу. При належному дизайні я не бачу жодної переваги в цьому, крім його легшого кодування.

Ідеальним дизайном для HTTP2 для найкращої продуктивності буде:

• Майте основний CSS-файл, який містить загальні стилі, використовувані на всіх сторінках.
• Майте окремий CSS для сторінки в окремому файлі
• Використовуйте HTTP2 push CSS, щоб мінімізувати час очікування (cookie можна використовувати для запобігання повторних натискань)
• За бажанням відокремте верхню частину CSS і натисніть її спочатку та завантажте решту CSS пізніше (корисно для мобільних пристроїв низької пропускної здатності)
• Ви також можете завантажити CSS для сайту або певних сторінок після завантаження сторінки, якщо ви хочете прискорити завантаження майбутніх сторінок.

Монолітні таблиці стилів можуть отримати багато переваг (які описані в інших відповідях), однак залежно від загального розміру документа таблиці стилів ви можете зіткнутися з проблемами в IE. IE має обмеження щодо кількості селекторів, які він прочитає одного файлу . Ліміт - 4096 селекторів. Якщо у вас монолітних таблиць стилів буде більше, ніж цього, ви хочете розділити його. Це обмеження спричиняє лише некрасиву голову в IE.

Це для всіх версій IE.

Дивіться Блог Росса Брунігеса та сторінку MSDN AddRule .

Існує підказка, при якій корисно мати більше одного файлу css.

Сайт з 1М + сторінками, про який середній користувач, ймовірно, коли-небудь бачить, скажімо, 5, може мати таблицю стилів з величезними пропорціями, тому намагання зберегти накладні витрати на додатковий запит на завантаження сторінки шляхом масового початкового завантаження помилково економіка.

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

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

У мене зазвичай є кілька CSS-файлів:

• "глобальний" файл css для скидання та глобальних стилів
• "модульні" специфічні файли css для сторінок, які є логічно згрупованими (можливо, кожна сторінка майстра оформлення замовлення чи щось таке)
• "page" специфічні файли css для переопределення сторінки (або, помістіть це в блок на окремій сторінці)

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

Я віддаю перевагу декілька файлів CSS. Таким чином, легше поміняти "шкурки" на та вгору, як захочете. Проблема одного монолітного файлу полягає в тому, що він може вийти з-під контролю і важко керувати. Що робити, якщо ви хочете синіх фонів, але не хочете, щоб кнопки змінювалися? Просто змініть файл фонів. І т.д.

Можливо, погляньте на компас , який є рамкою для створення авторських прав з відкритим кодом. Це засновано на Sass, тому він підтримує цікаві речі, такі як змінні, гніздування, міксин та імпорт. Особливо імпорт корисний, якщо ви хочете зберігати окремі менші файли CSS, але об'єднувати їх автоматично в 1 (уникаючи декількох повільних HTTP-дзвінків). Компас Compass додає до цього великий набір заздалегідь визначених комбінацій, які прості в обробці матеріалів між браузерами. Це написано в Ruby, але його можна легко використовувати з будь-якою системою ....

ось найкращий спосіб:

1. створити загальний файл css із усім спільним кодом
2. вставити весь конкретний код css сторінки на ту саму сторінку, у тег або за допомогою атрибута style = "" для кожної сторінки

таким чином у вас є лише один css з усім спільним кодом та html-сторінкою. до речі (а я знаю, що це не правильна тема), ви також можете кодувати свої зображення в base64 (але ви також можете це зробити з вашими js та css файлами). таким чином ви зменшуєте ще більше запитів http до 1.

SASS і МЕНШЕ роблять все це справді суперечливим питанням. Розробник може налаштувати ефективні файли компонентів і при компіляції об'єднати їх усі. У режимі SASS ви можете вимкнути стиснутий режим під час розробки для легшого читання та ввімкнути його знову для виробництва.

http://sass-lang.com http://lesscss.org

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

Перевага одного файлу CSS - ефективність передачі. Кожен запит HTTP означає відповідь заголовка HTTP для кожного запитуваного файлу, і він займає пропускну здатність.

Я обслуговую свій CSS як файл PHP з типом mime "text / css" у заголовку HTTP. Таким чином, я можу мати декілька CSS-файлів на стороні сервера і використовувати PHP включає, щоб перемістити їх в єдиний файл на запит користувача. Кожен сучасний браузер отримує файл .php з кодом CSS і обробляє його як файл .css.

Ви можете просто використовувати один файл css для продуктивності, а потім прокоментувати такі розділи:

/******** Header ************/
//some css here

/******* End Header *********/


/******** Footer ************/
//some css here

/******* End Footer *********/

тощо

Я використовую Jammit для роботи зі своїми файлами css і використовую багато різних файлів для читабельності. Jammit виконує всю брудну роботу з комбінування та стискання файлів перед розгортанням у виробництві. Таким чином, у мене є багато файлів у розробці, але лише один файл у виробництві.

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

Дивіться: https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/

Переваги пакетних стилів: - продуктивність завантаження сторінки

Недоліки пакетних таблиць стилів: - повільніша поведінка, що може спричинити скутості під час прокрутки, інтерактивності, анімації,

Висновок: щоб вирішити обидві проблеми, для виробництва ідеальним рішенням є з’єднати весь CSS в один файл, щоб зберегти на http-запитах, але використовувати JavaScript для витягування з цього файлу, CSS для сторінки, на якій ви перебуваєте, та оновлення голови за допомогою неї. .

Щоб знати, які потрібні спільні компоненти на одній сторінці, і щоб зменшити складність, було б непогано оголосити всі компоненти, якими користується ця конкретна сторінка - наприклад:

<style href="global.css" rel="stylesheet"/>
<body data-shared-css-components="x,y,z">

Я створив системний підхід до розробки CSS. Таким чином я можу використовувати стандарт, який ніколи не змінюється. Спочатку я почав із сітки 960. Тоді я створив поодинокі рядки css для основних макетів, полів, заміток, шрифтів та розмірів. Потім я з'єдную їх за потребою. Це дозволяє мені зберігати послідовний макет у всіх моїх проектах і використовувати ті самі файли css знову і знову. Тому що вони не конкретні. Ось приклад: ---- div class = "c12 bg0 m10 p5 white fl" / div --- Це означає, що контейнер має 12 стовпців поперек, використовує bg0 з полями 10px прокладки 5 текст є білим і він плаває зліва. Я міг би легко змінити це, видаливши або додавши новий - Що я називаю "легким" стилем - Замість створення єдиного класу з усіма цими атрибутами; Я просто поєдную єдині стилі, коли кодую сторінку. Це дозволяє мені створювати будь-яку комбінацію стилів і не обмежує мою творчість чи змушує мене створити величезну кількість подібних стилів. Ваші таблиці стилів стають набагато більш керованими, мінімізованими і дозволяють повторно використовувати його знову і знову. Цей метод я виявив фантастичним для швидкого проектування. Я також більше не розроблюю спочатку PSD, а браузер, що також економить час. Крім того, оскільки я також створив систему імен для моїх фонів та атрибутів дизайну сторінки, я просто змінюю файл зображення при створенні нового проекту. (Bg0 = фон тіла відповідно до моєї системи імен) Це означає, що якщо я раніше мав білий тло одного проекту просто змінить його на чорний просто означає, що на наступному проекті bg0 буде чорним фоном або іншим зображенням .....