Есть ли какое-то преимущество в том, что у одного монстра есть файл .css, содержащий элементы стиля, которые будут использоваться почти на каждой странице?
Я думаю, что для удобства управления я хотел бы вытащить различные типы CSS в несколько файлов и включить каждый файл в мой основной <link />, это плохо?
Я думаю, что это лучше
против.
Видели ли вы какие-то хотча с тем, чтобы сделать это одним способом против другого?
Это сложно ответить. Оба варианта имеют свои плюсы и минусы, на мой взгляд.
Мне лично не нравится читать через один большой файл CSS, и его поддерживать очень сложно. С другой стороны, разделение его вызывает дополнительные HTTP-запросы, которые могут замедлить работу.
Мое мнение было бы одним из двух.
1) Если вы знаете, что ваш CSS НИКОГДА не изменится после его создания, я бы создал несколько файлов CSS на стадии разработки (для удобства чтения), а затем вручную объединил их перед тем, как начать жить (чтобы уменьшить HTTP-запросы )
2) Если вы знаете, что время от времени вы будете менять свой CSS, и вам нужно его читать, я бы создал отдельные файлы и использовал код (при условии, что вы используете какой-то язык программирования) объединить их в время выполнения времени выполнения (минимизация/комбинация времени выполнения - это ресурс свиньи).
С помощью любой опции я бы настоятельно рекомендовал кэширование на стороне клиента, чтобы еще больше уменьшить HTTP-запросы.
EDIT: Я нашел этот блог, в котором показано, как объединить CSS во время выполнения, используя только код. Стоит взглянуть на (хотя я еще не проверял его сам).
РЕДАКТИРОВАТЬ 2:
Я решил использовать отдельные файлы в свое время разработки и процесс сборки, чтобы минимизировать и объединить. Таким образом, я могу иметь отдельный (управляемый) css во время разработки и собственный монолитный миниатюрный файл во время выполнения. И у меня все еще есть статические файлы и меньше системных издержек, потому что я не выполняю сжатие/минимизацию во время выполнения.
Примечание: для вас есть покупатели, я предлагаю использовать bundler как часть процесса сборки. Независимо от того, строите ли вы из своей среды IDE или из сборки script, пакет может быть запущен в Windows с помощью включенного exe или может быть запущен на любом компьютере, который уже запущен node.js.
Компилятор CSS, такой как Sass или LESS, - отличный способ. Таким образом, вы сможете предоставить единый, минимизированный CSS файл для сайта (который будет намного меньше и быстрее обычного обычного исходного файла CSS), сохраняя при этом самую приятную среду разработки, при этом все будет аккуратно разбито на компоненты.
Sass и LESS имеют дополнительное преимущество в переменных, вложенности и других способах упрощения написания и обслуживания CSS. Очень рекомендуется. Я лично использую Sass (синтаксис SCSS) сейчас, но раньше использовал LESS. Оба отличные, с аналогичными преимуществами. Как только вы написали CSS с компилятором, вряд ли вы захотите обойтись без него.
Если вы не хотите возиться с Ruby, этот компилятор LESS для Mac велик:
Или вы можете использовать CodeKit (теми же парнями):
http://incident57.com/codekit/
WinLess - это графический интерфейс Windows для компиляции LESS
Я предпочитаю несколько файлов CSS во время разработки. Управление и отладка намного проще. Тем не менее, я предлагаю, чтобы пришло время развертывания, вместо этого вы используете инструмент минимизации CSS, например YUI Compressor, который объединит ваши файлы CSS в один монолитный файл.
Только один CSS файл лучше подходит для загрузки ваших страниц, так как это означает меньше HTTP-запросов.
Наличие нескольких небольших CSS файлов означает, что разработка проще (по крайней мере, я так думаю: наличие одного CSS файла на модуль вашего приложения упрощает).
Итак, в обоих случаях есть веские причины...
Решение, которое позволит вам получить лучшее из обеих идей, будет:
Существует также программное обеспечение, которое объединяет файлы CSS во время выполнения, а не во время сборки; но выполнение этого во время выполнения означает потребление немного большего количества CPU (и обязательно требует некоторого кэширования mecanism, чтобы не слишком часто генерировать большой файл)
Вы хотите оба мира.
Вам нужно несколько файлов CSS, потому что ваше здравомыслие - это ужасная вещь, которую нужно тратить.
В то же время лучше иметь один большой файл.
Решение состоит в том, чтобы иметь некоторый механизм, который объединяет несколько файлов в один файл.
Один пример - это что-то вроде
<link rel="stylesheet" type="text/css" href="allcss.php?files=positions.css,buttons.css,copy.css" />
Затем команда allcss.php script выполняет конкатенацию файлов и доставку их.
В идеале script будет проверять даты мод во всех файлах, создает новый составной, если какой-либо из них изменяется, а затем возвращает этот составной элемент, а затем проверяет HTTP-заголовки If-Modified, чтобы не отправлять избыточные CSS.
Это дает вам лучшее из обоих миров. Отлично подходит для JS.
Монолитные таблицы стилей предлагают много преимуществ (которые описаны в других ответах), однако в зависимости от общего размера документа таблицы стилей, который может возникнуть в IE. IE имеет ограничение на количество селекторов, которые он будет читать из одного файла. Предел - 4096 селекторов. Если у вас монолитная таблица стилей будет больше, вам нужно разбить ее. Это ограничение только подтверждает его уродливую голову в IE.
Это для всех версий IE.
Существует точка опроса, в которой полезно иметь более одного файла css.
Сайт с 1M + страницами, который средний пользователь может увидеть только когда-либо, например, 5 из, может иметь таблицу стилей огромных пропорций, поэтому, пытаясь сохранить накладные расходы на один дополнительный запрос на загрузку страницы, имея массивный начальный загрузка - это ложная экономия.
Протяните аргумент до крайнего предела - это похоже на предложение о том, что для всей сети должна быть одна большая таблица стилей. Совершенно бессмысленно.
Точка перелома будет различной для каждого сайта, хотя там нет жесткого и быстрого правила. Это будет зависеть от количества уникальных CSS на странице, количества страниц и количества страниц, с которыми обычный пользователь может часто сталкиваться при использовании сайта.
Возможно, взгляните на compass, который является открытым исходным кодом CSS. Он основан на Sass, поэтому он поддерживает классные вещи, такие как переменные, вложенность, микшины и импорт. Особенно импорт полезен, если вы хотите сохранить отдельные файлы CSS, но объединить их в 1 автоматически (избегая нескольких медленных HTTP-вызовов). Компас добавляет к этому большой набор заранее определенных миксинов, которые легко обрабатывают кросс-браузерные вещи. Он написан на Ruby, но его можно легко использовать с любой системой.
Я предпочитаю несколько файлов CSS. Таким образом, проще поменять "шкуры" внутрь и снаружи по вашему желанию. Проблема с одним монолитным файлом заключается в том, что он может выйти из-под контроля и с ним трудно справиться. Что делать, если вы хотите синий фон, но не хотите, чтобы кнопки менялись? Просто измените свой фоновый файл. Etc.
Обычно у меня есть несколько файлов CSS:
На самом деле я не слишком заинтересован в нескольких запросах страниц для файлов CSS. У большинства людей есть приличная пропускная способность, и я уверен, что есть и другие оптимизации, которые будут иметь гораздо большее влияние, чем объединение всех стилей в один монолитный файл CSS. Компромисс между скоростью и ремонтопригодностью, и я всегда склоняюсь к ремонтопригодности. Компилятор YUI звучит довольно круто, хотя мне, возможно, придется это проверить.
вот лучший способ:
таким образом у вас есть только один css со всем общим кодом и html-страницей. Кстати (и я знаю, что это неправильная тема), вы также можете кодировать свои изображения в base64 (но вы также можете сделать это с помощью js и css файлов). таким образом вы уменьшаете еще больше http-запросов до 1.
SASS и LESS делают все это действительно спорным. Разработчик может настроить эффективные файлы компонентов, а на компиляции их объединяют. В 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 выполняет всю грязную работу по объединению и сжатию файлов перед развертыванием в процессе производства. Таким образом, у меня есть много файлов в разработке, но только один файл в производстве.
Я создал системный подход к разработке CSS. Таким образом, я могу использовать стандарт, который никогда не меняется. Сначала я начал работу с сеткой 960. Затем я создал отдельные строки css для основных макетов, полей, дополнений, шрифтов и размеров. Затем я связываю их вместе по мере необходимости. Это позволяет мне сохранять согласованный макет во всех моих проектах и использовать одни и те же файлы css снова и снова. Потому что они не являются конкретными. Вот пример: ---- div class= "c12 bg0 m10 p5 white fl" /div --- Это означает, что контейнер имеет 12 столбцов в поперечнике, использует bg0 имеет поля 10px padding из 5, текст белый, и это плавает влево. Я мог бы легко изменить это, удалив или добавив новое - то, что я называю "легким" стилем, - вместо создания одного класса со всеми этими атрибутами; Я просто комбинирую отдельные стили, когда я кодирую страницу. Это позволяет мне создавать любую комбинацию стилей и не ограничивать мое творчество или заставлять меня создавать огромное количество стилей, которые похожи. Ваши таблицы стилей становятся намного более управляемыми, минимизированными и позволяют повторно использовать его снова и снова. Этот метод, который я нашел фантастическим для быстрого дизайна. Я также больше не разрабатываю первую в PSD, а в браузере, что также экономит время. Кроме того, поскольку я также создал систему именования для своих фонов и атрибутов дизайна страницы, я просто меняю свой файл изображения при создании нового проекта. (Bg0 = основной фон в соответствии с моей системой именования). Это означает, что если бы я раньше имел белый фон с одним проектом, просто меняя его на черный, просто означает, что на следующем проекте bg0 будет черным фоном или другим изображением..... Я еще не нашел ничего плохого в этом методе, и, похоже, он работает очень хорошо.
Связанная таблица стилей может сохранять производительность загрузки страницы, но чем больше стилей, тем медленнее браузер отображает анимацию на странице, на которой вы находитесь. Это вызвано огромным количеством неиспользуемых стилей, которые могут отсутствовать на странице, на которой вы находитесь, но браузер все еще должен рассчитывать.
Смотрите: 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">