Один огромный.css файл против нескольких меньших конкретных.файлы css?

на этот вопрос трудно ответить. На мой взгляд, у обоих вариантов есть свои плюсы и минусы.

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

мое мнение было бы одним из двух.

1) Если вы знаете, что ваш CSS никогда не изменится, как только вы его построите, я бы построил несколько файлов CSS в этап разработки (для удобочитаемости), а затем вручную объединить их перед выходом в эфир (для уменьшения http-запросов)

2) Если вы знаете, что собираетесь время от времени менять свой CSS, и вам нужно, чтобы он был читаемым, я бы построил отдельные файлы и использовал код (при условии, что вы используете какой-то язык программирования), чтобы объединить их в время работы время сборки (минимизация/комбинация времени выполнения-это свинья ресурсов).

в любом случае я очень рекомендуется кэширование на стороне клиента для дальнейшего сокращения http-запросов.

EDIT:
я нашел это блог это показывает, как объединить CSS во время выполнения, используя только код. Стоит взглянуть (хотя я еще не тестировал его сам).

EDIT 2:
Я решил использовать отдельные файлы во время разработки и процесс сборки для минимизации и объединения. Так я смогу жить отдельно. (управляемый) css, пока я разрабатываю и правильный монолитный мини-файл во время выполнения. И у меня все еще есть статические файлы и меньше системных накладных расходов, потому что я не делаю сжатие/минимизацию во время выполнения.

примечание: для вас, покупатели там, я настоятельно рекомендую использовать упаковщик как часть процесса построения. Если вы строите из своей IDE или из сценария сборки, bundler может быть выполнен в Windows с помощью включенного exe или можно побежать на любом машина, на которой уже запущен узел.js.

Я предпочитаю несколько файлов CSS во время разработки. Управление и отладка намного проще. Тем не менее, я предлагаю вам вместо этого использовать инструмент CSS minify, такой как Юи компрессора который объединит ваши файлы CSS в один монолитный файл.

наличие только одного файла CSS лучше для времени загрузки ваших страниц, так как это означает меньше HTTP-запросов.

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

Итак, в обоих случаях есть веские причины...

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

• для разработка с использованием нескольких небольших файлов CSS
  • т. е. легче развиваться
• чтобы иметь процесс сборки для вашего приложения, который "объединяет" эти файлы в один
  • этот процесс сборки также может уменьшить этот большой файл, кстати
  • это, очевидно, означает, что ваше приложение должно иметь некоторые настройки, которые позволяют ему переходить из "режима нескольких файлов" в "режим моно-файла".
• и использовать, в производство, только большой файл
  • т. е. более быстрая загрузка страниц

есть также некоторое программное обеспечение, которое делает это объединение файлов CSS во время выполнения, а не во время сборки ; но делать это во время выполнения означает есть немного больше CPU (и, очевидно, требует некоторого кэширования mecanism, чтобы не генерировать большой файл слишком часто)

вы хотите оба мира.

вы хотите несколько файлов CSS, потому что ваше здравомыслие-ужасная вещь, чтобы тратить.

в то же время, лучше иметь один большой файл.

решение состоит в том, чтобы иметь некоторый механизм, который объединяет несколько файлов в один файл.

один пример-что-то вроде

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

затем allcss.PHP-скрипт обрабатывает объединение файлов и их доставку.

в идеале скрипт будет проверять даты мод на всех файлах, создает новый композит, если какой-либо из них изменяется, затем возвращает этот композит, а затем проверяет заголовки HTTP If-Modified, чтобы не отправлять избыточный CSS.

Это дает вам лучшее из обоих миров. Отлично работает и для JS.

монолитные таблицы стилей предлагают много преимуществ (которые описаны в других ответах), однако в зависимости от общего размера документа таблицы стилей вы можете столкнуться с проблемами в IE. IE имеет ограничение на количество селекторов, которые он будет читать из одним файлом. Предел 4096 селекторов. Если у вас монолитная таблица стилей будет больше, чем это, вы захотите ее разделить. Это ограничение только поднимает уродливую голову в IE.

Это для всех версии IE.

посмотреть Ross Bruniges Blog и в MSDN AddRule страницы.

есть переломный момент, когда полезно иметь более одного файла css.

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

растянуть аргумент до крайнего предела - это похоже на предположение, что должна быть одна большая таблица стилей поддерживается для всей сети. Совершенно бессмысленно.

переломный момент будет отличаться для каждого сайта, хотя и так нет никаких жестких правил. Это будет зависеть от количества уникальных css на странице, количества страниц и количества страниц, с которыми средний пользователь может регулярно сталкиваться при использовании сайта.

обычно у меня есть несколько файлов CSS:

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

Я не слишком обеспокоен несколькими запросами страниц для файлов CSS. Большинство людей приличная пропускная способность, и я уверен, что есть другие оптимизации, которые будут иметь гораздо большее влияние, чем объединение всех стилей в один монолитный файл CSS. Компромисс между скоростью и ремонтопригодностью, и я всегда склоняюсь к ремонтопригодности. Yui comperssor звучит довольно круто, хотя, возможно, мне придется проверить это.

возможно, взгляните на компас, который является открытым исходным кодом CSS в рамках разработки. Он основан на Сасс таким образом, он поддерживает классные вещи, такие как переменные, вложенность, миксины и импорт. Особенно импорт полезен, если вы хотите сохранить отдельные меньшие файлы CSS, но объединить их в 1 автоматически (избегая нескольких медленных HTTP-вызовов). Compass добавляет к этому большой набор предопределенных миксинов,которые просты в обращении с кросс-браузером. Это написано в Ruby, но его можно легко использовать с любой системой....

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

вот лучший способ:

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 includes, чтобы толкать их в один файл по запросу пользователя. Каждый современный браузер получает .php-файл с кодом CSS и обрабатывает его как .стиль CSS файл.

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

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

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


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

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

etc

Я использую Jammit чтобы иметь дело с моими файлами css и использовать много разных файлов для удобства чтения. Jammit выполняет всю грязную работу по объединению и сжатию файлов перед развертыванием в производстве. Таким образом, у меня есть много файлов в разработке, но только один файл в производстве.

исторически одним из основных преимуществ x в наличии одного файла CSS является преимущество скорости при использовании HTTP1.1.

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

идеальным дизайном для HTTP2 для лучшей производительности будет: -Есть основной файл CSS, который содержит общие стили для всех страниц. - Есть страница конкретного CSS в отдельном файле - Используйте HTTP2 push CSS для минимизации времени ожидания (файл cookie может использоваться для предотвращения повторных толчков) - Опционально отделите выше сгиба CSS и нажмите это сначала и загрузите оставшийся CSS позже (полезно для мобильных устройств с низкой пропускной способностью) - Вы также можете загрузить оставшиеся CSS для сайта или определенных страниц после загрузки страницы, если вы хотите ускорить загрузку страниц.

Я создал системный подход к разработке CSS. Таким образом я могу использовать стандарт, который никогда не меняется. Сначала я начал с системы 960 grid. Затем я создал отдельные строки css для основных макетов, полей, отступов, шрифтов и размеров. Затем я связываю их вместе по мере необходимости. Это позволяет мне поддерживать согласованный макет во всех моих проектах и использовать одни и те же файлы css снова и снова. Потому что они не конкретны. Вот пример: - - - - div class= " C12 bg0 M10 P5 белый fl " / div - - - это означает, что контейнер имеет 12 столбцов поперек, использует bg0 имеет поля 10px заполнения 5 текст белый, и он плавает влево. Я мог бы легко изменить это, удалив или добавив новый - то, что я называю "легким" стилем - вместо создания одного класса со всеми этими атрибутами; я просто объединяю отдельные стили, когда я кодирую страницу. Это позволяет мне создавать любую комбинацию стилей и не ограничивает мое творчество или заставляет меня создавать огромное количество стилей, которые подобный. Ваши таблицы стилей становятся намного более управляемыми, минимизированными и позволяют повторно использовать их снова и снова. Этот метод я нашел фантастическим для быстрого дизайна. Я также больше не проектирую сначала в PSD, а в браузере, что также экономит время. Кроме того, поскольку я также создал систему именования для моих фонов и атрибутов дизайна страниц, я просто меняю файл изображения при создании нового проекта.(bg0 = фон тела в соответствии с моей системой именования) это означает, что если я ранее был белый фон с одним проектом просто изменить его на черный, просто означает, что на следующем проекте bg0 будет черный фон или другое изображение..... Я еще не нашел ничего плохого в этом методе, и, похоже, он работает очень хорошо.

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

см.: https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/

в комплекте таблицы стилей преимущества: - загрузка страниц производительность

в комплекте таблицы стилей недостатки: - медленнее поведения, которые могут вызвать choppyness во время прокрутки, интерактивность, анимация,

вывод: Чтобы решить обе проблемы, для производства идеальным решением является объединение всех css в один файл для сохранения по http-запросам, но использовать javascript для извлечения из этого файла css для страницы, на которой вы находитесь, и обновить голову с ним.

чтобы узнать, какие общие компоненты необходимы на странице, и для уменьшения сложности было бы неплохо объявить все компоненты, которые использует эта конкретная страница - например:

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