Único arquivo .css enorme versus vários arquivos .css específicos menores? [fechadas]


258

Existe alguma vantagem em ter um único arquivo .css de monstro que contém elementos de estilo que serão usados ​​em quase todas as páginas?

Eu estou pensando que, para facilitar o gerenciamento, eu gostaria de extrair diferentes tipos de CSS em alguns arquivos e incluir todos os arquivos no meu principal, <link />isso é ruim?

Estou pensando que isso é melhor

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

vs.

  1. site.css

Você já viu alguma dificuldade em fazer isso de uma maneira ou de outra?


1
Esta é uma pergunta REALMENTE antiga, mas, enfrentando o mesmo problema, encontrei a que considero a melhor solução , caso outra pessoa chegue a esta página. Vários arquivos compactados com PHP e enviados através de uma única solicitação.
Francisco Presencia

3
@FrankPresenciaFandos fazer isso é aceitável para um site de baixo tráfego, mas executar esse script repetidamente em sites de alto tráfego parece um pouco complicado. Se você usa um script de construção, pode ter o melhor dos dois mundos e ainda manter um servidor Web de alto desempenho, pois ele não está executando o script php (sempre).
usar o seguinte código

2
Ele seria executado apenas toda vez que o css fosse alterado e você teria que incluir o arquivo css resultante.
Francisco Presencia 22/02

Respostas:


85

Um compilador CSS como Sass ou LESS é um ótimo caminho a percorrer. Dessa forma, você poderá fornecer um único arquivo CSS minimizado para o site (que será muito menor e mais rápido que um arquivo de origem CSS único normal), mantendo o melhor ambiente de desenvolvimento, com tudo ordenadamente dividido em componentes.

Sass e LESS têm a vantagem adicional de variáveis, aninhamento e outras maneiras de tornar o CSS mais fácil de escrever e manter. Altamente, altamente recomendado. Eu pessoalmente uso o Sass (sintaxe SCSS) agora, mas usei o LESS anteriormente. Ambos são ótimos, com benefícios semelhantes. Depois de escrever CSS com um compilador, é improvável que você queira ficar sem um.

http://lesscss.org

http://sass-lang.com

Se você não quer mexer com Ruby, este compilador LESS para Mac é ótimo:

http://incident57.com/less/

Ou você pode usar o CodeKit (da mesma equipe):

http://incident57.com/codekit/

WinLess é uma GUI do Windows para compilar MENOS

http://winless.org/


2
Alterando minha resposta aceita aqui, já que esse é realmente o caminho a seguir atualmente. Quando perguntei originalmente, não me sinto como se Sass ou LESS tivessem realmente decolado ainda.
Nate

144

É difícil responder. Ambas as opções têm seus prós e contras na minha opinião.

Pessoalmente, não gosto de ler um único arquivo CSS ENORME, e mantê-lo é muito difícil. Por outro lado, dividi-lo causa solicitações HTTP extras que podem potencialmente atrasar as coisas.

Minha opinião seria uma das duas coisas.

1) Se você sabe que seu CSS NUNCA mudará depois que você o criar, eu criaria vários arquivos CSS no estágio de desenvolvimento (para facilitar a leitura) e os combinaria manualmente antes de ir ao ar (para reduzir solicitações de http)

2) Se você sabe que vai mudar seu CSS de vez em quando e precisa mantê-lo legível, eu criaria arquivos separados e usaria o código (desde que você esteja usando algum tipo de linguagem de programação) para combiná-los em tempo de construção do tempo de execução (a minificação / combinação do tempo de execução é um porco de recursos).

Com qualquer uma das opções, eu recomendo o armazenamento em cache no lado do cliente para reduzir ainda mais as solicitações HTTP.

Edição:
Encontrei este blog que mostra como combinar CSS em tempo de execução usando nada além de código. Vale a pena dar uma olhada (embora eu ainda não o tenha testado).

EDIÇÃO 2:
Decidi usar arquivos separados no meu tempo de design e um processo de compilação para minimizar e combinar. Dessa maneira, posso ter css separado (gerenciável) enquanto desenvolvo e um arquivo minificado monolítico adequado em tempo de execução. E ainda tenho meus arquivos estáticos e menos sobrecarga do sistema porque não estou fazendo compressão / minificação em tempo de execução.

nota: para os compradores por aí, sugiro o uso do bundler como parte do seu processo de criação. Esteja você construindo a partir do seu IDE ou de um script de construção, o empacotador pode ser executado no Windows via incluído exeou pode ser executado em qualquer máquina que já esteja executando o node.js.


Além de menos solicitações HTTP, existe alguma vantagem no único arquivo monolítico? Meu css pode mudar com o tempo, mas o número de usuários será muito pequeno, sendo mais acessado por meio de conexões de alta velocidade. Então eu acho que a vantagem de vários arquivos será muito maior do que menos http solicitações ...
Nate

1
menos solicitações HTTP É o motivo. reter visitantes é a prioridade número 1; portanto, se sua página carregar lentamente, é menos provável que eles permaneçam. Se você tem a capacidade de combinar (eu vejo que você está usando asp.net), eu recomendo fazê-lo. É o melhor dos dois mundos.
Chase Florell

3
"Então, acho que a vantagem de vários arquivos será muito maior que menos solicitações de HTTP ..." Não, não, não ... exatamente o oposto. Com uma conexão de alta velocidade, o tempo gasto no processamento de solicitações HTTP é o gargalo. A maioria dos navegadores, por padrão, baixa apenas dois arquivos por vez, para que eles façam 2 solicitações, esperem, baixem os arquivos css rapidamente, enviem mais 2 solicitações, esperem, baixem os arquivos rapidamente. Ao contrário de uma solicitação HTTP para um arquivo css, ele é baixado rapidamente. A comunicação com o servidor seria a parte lenta.
Isley Aardvark

1
Você pode criar e testar recursos com folhas de estilo separadas e combiná-las em um mongo por vez. Dessa forma, você não está mantendo um arquivo mongo, mas muitos arquivos menores. Fazemos isso, além de compactar todo o espaço em branco e comentários que facilitam a leitura dos seres humanos, mas não fazem sentido para as suas páginas da web.
Sem reembolsos Sem retornos

2
Seria ter essa resposta atualizada agora que o http2 reduz a vantagem de menos solicitações.
DD.

33

Eu prefiro vários arquivos CSS durante o desenvolvimento. Gerenciamento e depuração é muito mais fácil dessa maneira. No entanto, sugiro que, no momento da implantação, você use uma ferramenta de redução de CSS como o YUI Compressor, que mesclará seus arquivos CSS em um arquivo monolítico.


@ Randy Simon - mas e se editarmos css diretamente no ftp sempre.
Jitendra Vyas

15
Não conheço sua configuração, mas isso não me parece uma boa ideia. Você deve testar as alterações antes de enviá-las para fora.
Randy Simon

1
@RandySimon o link do Compressor YUI está quebrado.
reformado

16

Você quer os dois mundos.

Você deseja vários arquivos CSS porque sua sanidade é uma coisa terrível a se perder.

Ao mesmo tempo, é melhor ter um único arquivo grande.

A solução é ter algum mecanismo que combine os vários arquivos em um único arquivo.

Um exemplo é algo como

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

Em seguida, o script allcss.php trata da concatenação e entrega dos arquivos.

Idealmente, o script verifica as datas de modificação em todos os arquivos, cria um novo composto se algum deles mudar, depois retorna esse composto e depois verifica os cabeçalhos HTTP If-Modified para não enviar CSS redundante.

Isso oferece o melhor dos dois mundos. Funciona muito bem para JS também.


7
no entanto, a compactação / redução do tempo de execução possui sobrecarga do sistema. Você tem que pesar os prós e contras. Se você tem um site de alto tráfego, essa não é uma solução ideal.
usar o seguinte código

5
@ChaseFlorell - você só fazer a compressão / minification uma vez e cache que ele
Siler

@Siler, eu sei, é por isso que postei minha resposta. stackoverflow.com/a/2336332/124069
Perseguição Florell

14

Ter apenas um arquivo CSS é melhor para o tempo de carregamento das suas páginas, pois significa menos solicitações HTTP.

Ter vários pequenos arquivos CSS significa que o desenvolvimento é mais fácil (pelo menos, acho que sim: ter um arquivo CSS por módulo do seu aplicativo facilita as coisas) .

Então, há boas razões em ambos os casos ...


Uma solução que permita obter o melhor de ambas as idéias seria:

  • Para desenvolver usando vários arquivos CSS pequenos
    • ou seja, mais fácil de desenvolver
  • Para ter um processo de compilação para seu aplicativo, que "combine" esses arquivos em um
    • Esse processo de compilação também pode minificar esse arquivo grande, btw
    • Obviamente, isso significa que seu aplicativo deve ter alguns itens de configuração que permitem mudar do "modo multi-arquivos" para o "modo mono-arquivo".
  • E para usar, na produção, apenas o arquivo grande
    • ou seja, páginas de carregamento mais rápido

Existem também alguns softwares que fazem isso combinando arquivos CSS em tempo de execução, e não em tempo de construção; mas fazê-lo em tempo de execução significa consumir um pouco mais de CPU (e, obviamente, requer algum mecanismo de armazenamento em cache, para não gerar novamente o arquivo grande com muita frequência)


14

Historicamente, uma das principais vantagens x de ter um único arquivo CSS é o benefício de velocidade ao usar o HTTP1.1.

No entanto, em março de 2018, mais de 80% dos navegadores agora suportam HTTP2 que permite que o navegador baixe vários recursos simultaneamente, além de poder enviar recursos de forma preventiva. Ter um único arquivo CSS para todas as páginas significa um tamanho de arquivo maior que o necessário. Com o design adequado, não vejo nenhuma vantagem em fazer isso além de ser mais fácil de codificar.

O design ideal para HTTP2 para melhor desempenho seria:

  • Tenha um arquivo CSS principal que contenha estilos comuns usados ​​em todas as páginas.
  • Tenha CSS específico da página em um arquivo separado
  • Use HTTP2 push CSS para minimizar o tempo de espera (um cookie pode ser usado para evitar repetições)
  • Separe opcionalmente o CSS acima da dobra e empurre-o primeiro e carregue o CSS restante mais tarde (útil para dispositivos móveis de baixa largura de banda)
  • Você também pode carregar o CSS restante para o site ou páginas específicas após o carregamento da página, se desejar acelerar o carregamento de páginas futuras.

1
Essa deve ser a resposta moderna aceita no desempenho do ER. Algumas outras respostas estão desatualizadas.
SparrwHawk

Se você estiver criando um SPA (aplicativo de página única), eu diria que o melhor design é criar todos os seus css e js em dois arquivos completos. "app.js" e "vendor.js" Todo o html e estilos são compilados para JS embutido em vendor.js. Isso significa que "bootstrap.css e bootstrap.js" estão todos em vendor.js e são minimizados com mapas de origem em " vendor.min.js ". A mesma coisa com o aplicativo, exceto que agora você usa um transpiler em linha html para js, portanto, mesmo o html dos seus aplicativos está no arquivo js. Você pode hospedá-los em uma CDN e os navegadores os armazenam em cache. Você pode até compilar imagens para estilos e para JS.
Ryan Mann

12

As folhas de estilo monolíticas oferecem muitos benefícios (que são descritos nas outras respostas), no entanto, dependendo do tamanho geral do documento da folha de estilo, você pode encontrar problemas no IE. O IE tem uma limitação com quantos seletores serão lidos em um único arquivo . O limite é de 4096 seletores. Se sua folha de estilo monolítica tiver mais do que isso, você deverá dividi-la. Essa limitação apenas eleva sua cabeça feia no IE.

Isso é para todas as versões do IE.

Consulte o blog Ross Bruniges e a página AddRule do MSDN .


7

Há um ponto de inflexão no qual é benéfico ter mais de um arquivo css.

Um site com mais de 1 milhão de páginas, que o usuário médio provavelmente só verá, digamos 5, pode ter uma folha de estilo de proporções imensas, portanto, tentar salvar a sobrecarga de uma única solicitação adicional por carregamento de página com um download inicial massivo é falso. economia.

Estenda o argumento até o limite extremo - é como sugerir que deve haver uma grande folha de estilo mantida para toda a web. Claramente sem sentido.

O ponto de inflexão será diferente para cada site, portanto, não há regra rígida. Depende da quantidade de css exclusivos por página, do número de páginas e do número de páginas que o usuário comum provavelmente encontrará rotineiramente ao usar o site.


Sim. Esta é a pergunta que eu vim aqui. Todo mundo se concentra no desenvolvimento versus produção. É claro que seu ambiente de desenvolvimento pode ser diferente do seu site ativo, mas qual é o melhor para o site ativo? Ninguém parece realmente resolver isso. Você conhece algum recurso para descobrir onde está o ponto de inflexão?
Dominic P

5

Normalmente, tenho um punhado de arquivos CSS:

  • um arquivo css "global" para redefinições e estilos globais
  • arquivos CSS específicos do "módulo" para páginas agrupadas logicamente (talvez todas as páginas de um assistente de checkout ou algo assim)
  • arquivos CSS específicos da "página" para substituições na página (ou, coloque-o em um bloco na página individual)

Não estou muito preocupado com solicitações de várias páginas para arquivos CSS. A maioria das pessoas tem largura de banda decente e tenho certeza de que há outras otimizações que teriam um impacto muito maior do que combinar todos os estilos em um arquivo CSS monolítico. O trade-off é entre velocidade e manutenção, e eu sempre me inclino para a manutenção. O comparador YUI parece bem legal, talvez eu precise verificar isso.


É isso que faço e está funcionando bem para mim. No máximo, você ganha 3 arquivos CSS para cada página, o que é bastante razoável
Ricardo Nunes

4

Eu prefiro vários arquivos CSS. Dessa forma, é mais fácil trocar e trocar "skins" conforme desejado. O problema com um arquivo monolítico é que ele pode ficar fora de controle e difícil de gerenciar. E se você quiser fundos azuis, mas não quiser que os botões mudem? Apenas altere seu arquivo de plano de fundo. Etc.


o problema é que isso é bastante egoísta do ponto de vista dos desenvolvedores. Quando terminar, você raramente precisará voltar, mas todos os visitantes terão que esperar que as páginas carreguem arquivos css desnecessários. (O mesmo vale para Javascript na minha opinião)
Chase Florell

3
@rockin: Ao verificar um dos meus sites de arquivos com 5 CSS depois de limpar meu cache, descobri que o tempo total necessário para carregar todo o CSS era inferior a dez décimos de segundo. Se as pessoas não podem esperar tanto, acho que precisam de mais Ritalina ou algo assim. O problema é muito maior: retornos de chamada para sites de anúncios, como clique duplo, etc., que podem resultar em grandes atrasos, conforme testemunhado neste mesmo site na semana passada.
Robusto

Uma ótima ferramenta a ser usada para testar a velocidade do site é o Firebug em conjunto com o YSlow. Isso deve fornecer uma representação precisa das velocidades do seu site.
Chase Florell

4

Talvez dê uma olhada na bússola , que é uma estrutura de autoria de CSS de código aberto. É baseado no Sass, então ele suporta coisas legais como variáveis, aninhamento, mixins e importações. Especialmente as importações são úteis se você deseja manter arquivos CSS menores separados, mas combiná-los automaticamente em 1 (evitando várias chamadas HTTP lentas). O Compass adiciona a isso um grande conjunto de mixins predefinidos que são fáceis para lidar com coisas entre navegadores. Está escrito em Ruby, mas pode ser facilmente usado com qualquer sistema ....


3

aqui está a melhor maneira:

  1. crie um arquivo css geral com todo o código compartilhado
  2. insira todo o código css da página específica na mesma página, na tag ou usando o atributo style = "" para cada página

dessa maneira, você tem apenas um css com todo o código compartilhado e uma página html. a propósito (e eu sei que esse não é o tópico certo), você também pode codificar suas imagens em base64 (mas também pode fazê-lo com seus arquivos js e css). dessa forma, você reduz ainda mais solicitações de http para 1.


2

SASS e LESS fazem disso tudo realmente um ponto discutível. O desenvolvedor pode configurar arquivos de componentes eficazes e compilar todos eles. No SASS, você pode desativar o Modo compactado enquanto estiver em desenvolvimento para facilitar a leitura e ativá-lo novamente para produção.

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

No final, um único arquivo CSS minificado é o que você deseja, independentemente da técnica usada. Menos CSS, menos solicitações de HTTP, menos demanda no servidor.


1

A vantagem de um único arquivo CSS é a eficiência da transferência. Cada solicitação HTTP significa uma resposta do cabeçalho HTTP para cada arquivo solicitado, e isso exige largura de banda.

Eu sirvo meu CSS como um arquivo PHP com o tipo mime "text / css" no cabeçalho HTTP. Dessa forma, eu posso ter vários arquivos CSS no lado do servidor e usar o PHP include para enviá-los para um único arquivo quando solicitado pelo usuário. Todo navegador moderno recebe o arquivo .php com o código CSS e o processa como um arquivo .css.


Então, se eu estiver usando o ASP.NET, um manipulador genérico .ASHX seria o caminho ideal a seguir, que os combinará em um único arquivo para obter o melhor dos dois mundos?
Nate

Sim, eu usaria um IHttpHandler para combinar o seu CSS em tempo de execução (ver # 2 em minha resposta acima)
Perseguição Florell

@ Nate: Quando eu estava trabalhando no ASP.Net, usamos arquivos de modelo para realizar a mesma coisa.
Robusto

@ Robusto, você poderia explicar o que é um arquivo de modelo? Acho que nunca ouvi falar disso. Eu usei App_Themes, mas isso ainda não combina CSS.
Chase Florell

1
apenas como uma atualização. O uso de um arquivo IHttpHandler ou PHP para combinar css no lado do servidor pode economizar largura de banda e acelerar solicitações, mas também adiciona carga desnecessária no servidor. A melhor maneira de fazer isso é combinar / minificar seus css / js durante a criação / publicação do seu site. Dessa forma, você tem um único arquivo estático que não requer processamento do servidor. Melhor de todos os mundos, bar NENHUM.
Perseguição Florell

1

Você pode apenas usar um arquivo css para obter desempenho e depois comentar seções como esta:

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

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


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

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

etc


4
Isso não facilita a manutenção, pois eu ainda preciso percorrer quilômetros de css não relacionados para obter o que estou procurando ...
Nate

2
@ Nate: Você já pensou em mudar para um editor de texto com funcionalidade de pesquisa decente? Minha preferência pessoal é um único arquivo css e nunca o percorro. Eu apenas digitei "/ classname" (eu uso uma derivada vi) e bam - estou nessa classe.
Dave Sherohman

3
Também é mais difícil de manter em um ambiente de vários desenvolvedores. O que é um "cabeçalho" no seu exemplo acima? E se alguém não estiver pensando geograficamente, mas em termos de elementos básicos de design, como botões ou menus, enquanto outros estiverem pensando de maneira diferente? Para onde vai um menu se estiver em um cabeçalho? Que tal se não for? Eu acho que é mais fácil impor esse tipo de disciplina em arquivos separados. Por que os desenvolvedores de aplicativos não criam apenas uma classe de aplicativos enorme com todos os aparamentos, em vez de uma estrutura com hierarquia de classes? Parece semelhante a mim.
Robusto

E se você não se lembrar do nome da turma que está procurando? Ou como você decide onde adicionar uma nova turma?
Nate

Se é apenas um site de duas páginas, não é realmente tão grande assim. Apenas sugerindo outra maneira de fazer as coisas.
Catfish

1

Estou usando o Jammit para lidar com meus arquivos css e usar muitos arquivos diferentes para facilitar a leitura. O Jammit faz todo o trabalho sujo de combinar e compactar os arquivos antes da implantação na produção. Dessa forma, tenho muitos arquivos em desenvolvimento, mas apenas um arquivo em produção.


0

Uma folha de estilo incluída pode economizar o desempenho do carregamento da página, mas quanto mais estilos houver, mais lento o navegador renderiza animações na página em que você está. Isso é causado pela enorme quantidade de estilos não utilizados que podem não estar na página em que você está, mas o navegador ainda precisa calcular.

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

Vantagens das folhas de estilo incluídas: - desempenho de carregamento da página

Desvantagens das folhas de estilo incluídas: incluídas - comportamento mais lento, que pode causar instabilidade durante a rolagem, interatividade, animação,

Conclusão: Para resolver os dois problemas, para a produção, a solução ideal é agrupar todo o css em um arquivo para economizar em solicitações http, mas use o javascript para extrair desse arquivo, o css da página em que você está e atualize o cabeçalho com ele .

Para saber quais componentes compartilhados são necessários por página e reduzir a complexidade, seria bom ter declarado todos os componentes que essa página em particular usa - por exemplo:

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

-1

Eu criei uma abordagem sistemática para o desenvolvimento de CSS. Dessa forma, posso utilizar um padrão que nunca muda. Primeiro, comecei com o sistema de grade 960. Então criei linhas únicas de css para layouts básicos, margens, preenchimento, fontes e tamanhos. Em seguida, amarro-os conforme necessário. Isso me permite manter um layout consistente em todos os meus projetos e utilizar os mesmos arquivos css repetidamente. Porque eles não são específicos. Aqui está um exemplo: ---- div class = "c12 bg0 m10 p5 white fl" / div --- Isso significa que o contêiner tem 12 colunas, utiliza bg0 tem margens de 10px de 5, o texto é branco e flutua esquerda. Eu poderia facilmente mudar isso removendo ou adicionando um novo - o que chamo de estilo "leve" - ​​em vez de criar uma única classe com todos esses atributos; Simplesmente combino os estilos únicos enquanto codifico a página. Isso me permite criar qualquer combinação de estilos e não limita minha criatividade nem me leva a criar um número enorme de estilos semelhantes. Suas folhas de estilo se tornam muito mais gerenciáveis, minimizadas e permitem que você a reutilize repetidamente. Este método eu achei fantástico para o design rápido. Eu também não projeto mais primeiro no PSD, mas no navegador, o que também economiza tempo. Além disso, como também criei um sistema de nomes para meus atributos de plano de fundo e design de página, simplesmente altero meu arquivo de imagem ao criar um novo projeto. (Bg0 = plano de fundo do corpo de acordo com meu sistema de nomes) Isso significa que se eu já tivesse um branco background com um projeto simplesmente mudando para preto significa simplesmente que no próximo projeto bg0 será um background preto ou outra imagem .....


12
Você sabe para que servem os parágrafos?
em1

Esse é o "UI Framework", como o Bootstrap ou outros, depois que você souber o léxico em que está pronto, é tudo sobre a curva de aprendizado e a aceitação dos termos usados. Ainda assim, posso pensar em alguns casos muito específicos em que seu exemplo terá dificuldade em atender aos requisitos dos designers.
21313 augurone
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.