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


259

Есть ли какое-то преимущество в том, что у вас есть единственный файл .css monster, содержащий элементы стиля, которые будут использоваться практически на каждой странице?

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

Я думаю это лучше

  1. positions.css
  2. buttons.css
  3. tables.css
  4. copy.css

против

  1. site.css

Видели ли вы какие-либо проблемы с этим одним или другим способом?


1
Это ДЕЙСТВИТЕЛЬНО старый вопрос, но, столкнувшись с той же проблемой, я нашел ту, которая, на мой взгляд, является лучшим решением на тот случай, если кто-то еще попадет на эту страницу. Несколько файлов, которые сжимаются с помощью PHP и отправляются через один запрос.
Франциско Презенсия

3
@FrankPresenciaFandos делает это нормально для сайтов с низким трафиком, но запуск этого сценария снова и снова на сайтах с высоким трафиком, кажется, не совсем удачным. Если вы используете скрипт сборки, вы можете получить лучшее из обоих миров и при этом поддерживать работоспособный веб-сервер, так как он не запускает скрипт php (когда-либо).
Чейз Флорелл

2
Он будет запускаться только каждый раз, когда изменяется css, а затем вам нужно будет включить полученный css-файл.
Франциско Презенсия

Ответы:


86

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

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

http://lesscss.org

http://sass-lang.com

Если вы не хотите возиться с Ruby, этот компилятор LESS для Mac великолепен:

http://incident57.com/less/

Или вы можете использовать CodeKit (от тех же парней):

http://incident57.com/codekit/

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

http://winless.org/


2
Меняя мой принятый ответ здесь, так как это действительно путь в эти дни. Когда я первоначально спросил, я не чувствую, что Sass или LESS действительно взлетели.
Нейт

144

Это трудно ответить. Оба варианта имеют свои плюсы и минусы на мой взгляд.

Лично я не люблю читать через один ОГРОМНЫЙ файл CSS, и поддерживать его очень сложно. С другой стороны, его разделение вызывает дополнительные http-запросы, которые потенциально могут замедлить работу.

Мое мнение будет одной из двух вещей.

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

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

В любом случае я бы настоятельно рекомендовал кэширование на стороне клиента, чтобы еще больше сократить число запросов HTTP.

РЕДАКТИРОВАТЬ:
я нашел этот блог, который показывает, как объединить CSS во время выполнения, используя только код. Стоит взглянуть (хотя я сам еще не проверял).

РЕДАКТИРОВАТЬ 2:
я остановился на использовании отдельных файлов во время разработки, а также процесс сборки для минимизации и объединения. Таким образом, я могу иметь отдельный (управляемый) CSS во время разработки и правильный монолитный минимизированный файл во время выполнения. И у меня все еще есть мои статические файлы и меньше системных издержек, потому что я не делаю сжатие / минификацию во время выполнения.

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


Помимо меньшего количества HTTP-запросов, есть ли преимущество у одного монолитного файла? Мой css может со временем меняться, но количество пользователей будет довольно небольшим, большинство получит доступ через высокоскоростные соединения. Поэтому я думаю, что преимущество нескольких файлов будет намного больше, чем меньшее количество http-запросов ...
Nate

1
меньше HTTP-запросов является причиной. удержание посетителей является приоритетом № 1, поэтому, если ваша страница загружается медленно, вероятность того, что они останутся, меньше. Если у вас есть возможность комбинировать (я вижу, что вы используете asp.net), я очень рекомендую это сделать. Это лучшее из обоих миров.
Чейз Флорелл

3
«Поэтому я думаю, что преимущество нескольких файлов будет намного больше, чем меньшее количество http-запросов…» Нет, нет, нет ... как раз наоборот. При высокоскоростном соединении время, затрачиваемое на обработку HTTP-запросов, является узким местом. Большинство браузеров по умолчанию загружают только два файла одновременно, поэтому браузеры будут делать 2 запроса, ждать, быстро загружать файлы CSS, отправлять еще 2 запроса, ждать, загружать файлы быстро. В отличие от одного HTTP-запроса на один файл CSS, он загружается быстро. Связь с сервером будет медленной частью.
Исли Аардварк

1
Вы можете создавать и тестировать функции с помощью отдельных таблиц стилей и объединять их в одну монго во время сборки. Таким образом, вы сохраняете не один файл Монго, а множество небольших файлов. Мы делаем это, а также сжимаем все пробелы и комментарии, которые облегчают чтение людьми, но не имеют смысла для ваших веб-страниц.
Нет возврата, нет возврата,

2
Теперь этот ответ будет обновлен, так как http2 уменьшает преимущество меньшего количества запросов.
DD.

33

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


@Randy Simon - но что, если мы всегда редактируем css прямо на ftp?
Джитендра Вьяс

15
Я не знаю твоих настроек, но мне это не кажется хорошей идеей. Вы должны тестировать изменения, прежде чем их выдвигать.
Рэнди Саймон

1
@RandySimon Ссылка YUI Compressor не работает.
реформирован

16

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

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

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

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

Одним из примеров является что-то вроде

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

Затем скрипт allcss.php обрабатывает конкатенацию файлов и их доставку.

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

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


7
однако сжатие / минимизация во время выполнения имеет системные издержки. Вы должны взвесить все за и против. Если у вас сайт с высоким трафиком, это не оптимальное решение.
Чейз Флорелл

5
@ChaseFlorell - вы просто делаете сжатие / минификацию один раз и кешируете ее
Siler

@Siler, я знаю, поэтому я отправил свой ответ. stackoverflow.com/a/2336332/124069
Чейз Флорелл

14

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

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

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


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

  • Разработка с использованием нескольких небольших файлов CSS
    • т.е. проще в освоении
  • Чтобы иметь процесс сборки для вашего приложения, которое «объединяет» эти файлы в один
    • Этот процесс сборки может также минимизировать этот большой файл, кстати
    • Это, очевидно, означает, что ваше приложение должно иметь некоторые настройки, которые позволяют ему переключаться из «режима нескольких файлов» в «режим монофайлов».
  • И использовать, в производстве, только большой файл
    • т.е. более быстрая загрузка страниц

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


14

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

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

Идеальная конструкция для HTTP2 для лучшей производительности:

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

1
Это должно быть принятым современным ответом RE. Некоторые другие ответы устарели.
SparrwHawk

Если вы создаете SPA (одностраничное приложение), то я бы сказал, что лучший дизайн - это собрать все ваши css и js в два полных файла. "app.js" и "vendor.js" Все html и стили скомпилированы для встроенного JS в vendor.js. Это означает, что "bootstrap.css и bootstrap.js" находятся в vendor.js и минимизированы с помощью sourcemaps into " vendor.min.js». То же самое и с приложением, за исключением того, что теперь вы используете встроенный транспортер html to js, ​​поэтому даже html ваших приложений находится в файле js. Вы можете разместить их на CDN, и браузеры их кешируют. Вы даже можете компилировать изображения в стили и в JS.
Райан Манн

12

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

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

См. Блог Росса Брунигеса и страницу MSDN AddRule .


7

Существует переломный момент, когда полезно иметь более одного файла CSS.

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

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

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


Да. Это вопрос, о котором я пришел сюда. Каждый фокусируется на разработке против производства. Конечно, ваша среда разработки может отличаться от вашего живого сайта, но что лучше для живого сайта? Никто, кажется, действительно не решает эту проблему. Знаете ли вы какие-либо ресурсы по поиску точки перелома?
Доминик П

5

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

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

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


Это то, что я делаю, и это хорошо работает для меня. Самое большее, вы получаете 3 файла CSS для каждой страницы, что вполне разумно
Рикардо Нуньес

4

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


проблема в том, что это довольно эгоистично с точки зрения разработчиков. Когда вы закончите, вам редко придется возвращаться, но все ваши посетители должны ждать, пока страницы загрузят ненужные CSS-файлы. (То же самое касается Javascript, на мой взгляд)
Чейз Флорелл

3
@rockin: Проверяя один из моих сайтов с 5 CSS-файлами после очистки моего кэша, я обнаружил, что общее время, необходимое для загрузки всего CSS, составляет менее одной десятой секунды. Если люди не могут ждать так долго, я думаю, что им нужно больше риталина или чего-то еще. Гораздо более серьезной проблемой являются обратные вызовы на такие рекламные сайты, как двойной клик и т. Д., Что может привести к ОГРОМНЫМ задержкам, о чем свидетельствует этот сайт на прошлой неделе.
Робусто

Отличный инструмент для тестирования скорости сайта - это Firebug в сочетании с YSlow. Это должно дать вам точное представление о скорости вашего сайта.
Чейз Флорелл

4

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


3

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

  1. создать общий файл CSS со всем общим кодом
  2. вставьте весь код CSS конкретной страницы на ту же страницу, в тег или используя атрибут style = "" для каждой страницы

Таким образом, у вас есть только один CSS со всем общим кодом и HTML-страницы. Кстати (и я знаю, что это не правильная тема) вы также можете кодировать свои изображения в base64 (но вы также можете сделать это с вашими файлами js и css). таким образом вы уменьшаете еще больше запросов http до 1.


2

SASS и LESS делают все это действительно спорным. Разработчик может настроить эффективные файлы компонентов и при компиляции объединить их все. В SASS вы можете отключить режим Compressed во время разработки для удобства чтения и включить его снова для производства.

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

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


1

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

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


Так что, если я использую ASP.NET, универсальный обработчик .ASHX будет идеальным путем, который объединит их в один файл, чтобы получить лучшее из обоих миров?
Nate

Да, я бы использовал IHttpHandler для объединения вашего CSS во время выполнения (см. № 2 в моем ответе выше)
Чейз Флорелл

@Nate: Когда я работал в ASP.Net, мы использовали файлы шаблонов, чтобы выполнить то же самое.
Робусто

@Robusto, не могли бы вы объяснить, что такое файл шаблона? Я не думаю, что когда-либо слышал об этом. Я использовал App_Themes, но это все еще не объединяет CSS.
Чейз Флорелл

1
просто как обновление. Использование IHttpHandler или файла PHP для объединения CSS на стороне сервера может сэкономить пропускную способность и ускорить запросы, но также добавляет ненужную нагрузку на сервер. Лучший способ сделать это - объединить / минимизировать ваши css / js во время сборки / публикации вашего сайта. Таким образом, у вас есть один статический файл, который не требует обработки сервером. Лучшие из всех миров, бар NONE.
Чейз Флорелл

1

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

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

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


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

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

и т.д


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

2
@Nate: Рассматривали ли вы переход к текстовому редактору с достойной функцией поиска? Мое личное предпочтение - один файл CSS, и я никогда не пролистываю его. Я просто набираю "/ classname" (я использую производную vi) и bam - я в этом классе.
Дейв Шерохман

3
Это также сложнее поддерживать в среде нескольких разработчиков. Что такое «заголовок» в приведенном выше примере? Что если кто-то думает не географически, а с точки зрения базовых элементов дизайна, таких как кнопки или меню, в то время как другие думают иначе? Куда уходит меню, если оно в шапке? Как насчет того, если это не так? Я думаю, что легче применять такую ​​дисциплину в отдельных файлах. Почему разработчики приложений просто не создают один огромный класс приложений со всеми элементами вместо структуры с иерархией классов? Кажется, похоже на меня.
Робусто

Что если вы не помните название класса, который вы ищете? Или как вы решаете, где добавить новый класс?
Ноябрь

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

1

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


0

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

Смотрите: https://benfrain.com/css-performance-revisited-selectors-bloat-exорого-styles/

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

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

Вывод: для решения обеих проблем идеальным решением для производства является объединение всех CSS в один файл для сохранения по запросам http, но использование Javascript для извлечения из этого файла CSS для страницы, на которой вы находитесь, и обновления заголовка с его помощью. ,

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

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

-1

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


12
Вы знаете, для чего параграфы?
Em1

Это «UI Framework», как в Bootstrap или других, когда вы знаете лексикон, который вам подходит, все дело в кривой обучения и принятии используемых терминов. Тем не менее, я могу вспомнить некоторые очень конкретные случаи, когда ваш пример будет бороться за удовлетворение требований дизайнеров.
Авгурон
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.