html - para - lista de codigos css
¿Un solo archivo.css enorme frente a varios archivos.css específicos más pequeños? (18)
Aquí está la mejor manera:
- Crea un archivo css general con todo el código compartido.
- inserte todo el código CSS de la página específica en la misma página, en la etiqueta o usando el atributo style = "" para cada página
de esta manera solo tienes un css con todo el código compartido y una página html. por cierto (y sé que este no es el tema correcto) también puede codificar sus imágenes en base64 (pero también puede hacerlo con sus archivos js y css). De esta manera, reduce aún más las solicitudes de http a 1.
¿Hay alguna ventaja de tener un solo archivo .css de monstruos que contenga elementos de estilo que se usarán en casi todas las páginas?
Estoy pensando que para facilitar la administración, me gustaría extraer diferentes tipos de CSS en unos pocos archivos, e incluir todos los archivos en mi <link /> es tan malo?
Estoy pensando que esto es mejor
- position.css
- botones.css
- tables.css
- copy.css
contra
- site.css
¿Has visto alguna trampa con hacerlo de una manera frente a otra?
Esta es una pregunta difícil de responder. Ambas opciones tienen sus pros y sus contras en mi opinión.
Personalmente, no me gusta leer a través de un solo archivo HUGE CSS, y mantenerlo es muy difícil. Por otro lado, dividirlo provoca solicitudes http extra que potencialmente podrían ralentizar las cosas.
Mi opinión sería una de dos cosas.
1) Si sabes que tu CSS NUNCA cambiará una vez que lo hayas construido, crearía varios archivos CSS en la etapa de desarrollo (para facilitar la lectura) y luego los combinaré manualmente antes de publicarlos (para reducir las solicitudes de http)
2) Si sabe que va a cambiar su CSS de vez en cuando, y necesita mantenerlo legible, crearía archivos separados y usaría código (siempre que esté usando algún tipo de lenguaje de programación) para combinarlos en tiempo de compilación en tiempo de ejecución (la combinación / combinación de tiempo de ejecución es un cerdo de recursos).
Con cualquiera de las dos opciones, recomendaría encarecidamente el almacenamiento en caché en el lado del cliente para reducir aún más las solicitudes http.
EDITAR:
Encontré este blog que muestra cómo combinar CSS en tiempo de ejecución utilizando solo código. Vale la pena echarle un vistazo (aunque todavía no lo he probado).
EDIT 2:
Me decidí a usar archivos separados en mi tiempo de diseño, y un proceso de compilación para minimizar y combinar. De esta manera puedo tener un css separado (manejable) mientras desarrollo y un archivo minificado monolítico adecuado en tiempo de ejecución. Y todavía tengo mis archivos estáticos y menos gastos generales del sistema porque no estoy haciendo compresión / minimización en tiempo de ejecución.
Nota: para los compradores, sugiero que utilice bundler como parte de su proceso de compilación. Ya sea que esté compilando desde su IDE, o desde un script de compilación, el bundler se puede ejecutar en Windows a través del archivo ejecutable incluido o se puede ejecutar en cualquier máquina que ya esté ejecutando node.js.
Estoy usando Jammit para tratar con mis archivos css y uso muchos archivos diferentes para facilitar la lectura. Jammit hace todo el trabajo sucio de combinar y comprimir los archivos antes de la implementación en producción. De esta manera, tengo muchos archivos en desarrollo pero solo un archivo en producción.
Hay un punto de inflexión en el que es beneficioso tener más de un archivo css.
Un sitio con 1M + páginas, que el usuario promedio probablemente solo verá 5 veces, podría tener una hoja de estilo de proporciones inmensas, por lo que tratar de ahorrar la sobrecarga de una sola solicitud adicional por carga de página al tener una descarga inicial masiva es falso economía.
Estire el argumento al límite extremo: es como sugerir que debería haber una hoja de estilo grande mantenida para toda la web. Claramente sin sentido.
Sin embargo, el punto de inflexión será diferente para cada sitio, por lo que no hay una regla estricta y rápida. Dependerá de la cantidad de css únicos por página, el número de páginas y el número de páginas que el usuario promedio pueda encontrar de forma rutinaria al usar el sitio.
He creado un enfoque sistemático para el desarrollo de CSS. De esta manera puedo utilizar un estándar que nunca cambia. Primero comencé con el sistema de 960 grillas. Luego creé líneas individuales de css para diseños básicos, márgenes, rellenos, fuentes y tamaños. Luego los coloco según sea necesario. Esto me permite mantener un diseño consistente en todos mis proyectos y utilizar los mismos archivos css una y otra vez. Porque no son específicos. Aquí hay un ejemplo: ---- div class = "c12 bg0 m10 p5 white fl" / div --- Esto significa que el contenedor tiene 12 columnas de ancho, utiliza bg0 tiene márgenes de relleno de 10px de 5, el texto es blanco y flota izquierda. Podría cambiar esto fácilmente eliminando o agregando un nuevo, lo que llamo un estilo "ligero", en lugar de crear una clase única con todos estos atributos; Simplemente combino los estilos individuales mientras codifico la página. Esto me permite crear cualquier combinación de estilos y no limita mi creatividad ni me permite crear una cantidad masiva de estilos que sean similares. Sus hojas de estilo se vuelven mucho más manejables, minimizadas y le permiten reutilizarlo una y otra vez. Este método me ha parecido fantástico para un diseño rápido. También ya no diseño primero en PSD sino en el navegador, que también ahorra tiempo. Además, como también he creado un sistema de nombres para mis fondos y atributos de diseño de página, simplemente cambio mi archivo de imagen al crear un nuevo proyecto. (Bg0 = fondo del cuerpo de acuerdo con mi sistema de nombres) Eso significa que si anteriormente tenía un blanco el fondo con un proyecto simplemente cambiándolo a negro simplemente significa que en el próximo proyecto bg0 será un fondo negro u otra imagen ... Todavía no he encontrado ningún problema con este método y parece que funciona muy bien.
Históricamente, una de las principales ventajas de tener un solo archivo CSS es el beneficio de la velocidad cuando se usa HTTP1.1.
Sin embargo, a partir de marzo de 2018, más del 80% de los navegadores ahora admiten HTTP2. HTTP2 permite que el navegador descargue múltiples recursos simultáneamente, así como poder empujar recursos de forma preventiva. Tener un solo archivo CSS para todas las páginas significa un tamaño de archivo mayor al necesario. Con un diseño adecuado, no veo ninguna ventaja en hacer esto que no sea más fácil de codificar.
El diseño ideal para HTTP2 para el mejor rendimiento sería: -Tener un archivo CSS central que contenga los estilos comunes utilizados en todas las páginas. -Tenga la página específica de CSS en un archivo separado -Utilice HTTP2 push CSS para minimizar el tiempo de espera (se puede usar una cookie para evitar pulsaciones repetidas) -Opcionalmente separe por encima del doblez de CSS y presione este primero y cargue el CSS restante más tarde (útil por poco) - dispositivos móviles de ancho de banda) - También puede cargar el CSS restante para el sitio o páginas específicas después de que la página se haya cargado si desea acelerar futuras cargas de páginas.
La ventaja de un solo archivo CSS es la eficiencia de transferencia. Cada solicitud HTTP significa una respuesta de encabezado HTTP para cada archivo solicitado, y eso requiere ancho de banda.
Sirvo mi CSS como un archivo PHP con el tipo mime "text / css" en el encabezado HTTP. De esta manera, puedo tener varios archivos CSS en el lado del servidor y usar PHP incluido para insertarlos en un solo archivo cuando el usuario lo solicite. Cada navegador moderno recibe el archivo .php con el código CSS y lo procesa como un archivo .css.
Las hojas de estilo monolíticas ofrecen muchos beneficios (que se describen en las otras respuestas), sin embargo, dependiendo del tamaño general del documento de la hoja de estilo, podría tener problemas en IE. IE tiene una limitación con la cantidad de selectores que leerá de un solo archivo . El límite es de 4096 selectores. Si su hoja de estilo monolítica tendrá más que esto, querrá dividirla. Esta limitación solo levanta su cabeza fea en IE.
Esto es para todas las versiones de IE.
Ver el blog de Ross Bruniges y la página de MSDN AddRule .
Normalmente tengo un puñado de archivos CSS:
- Un archivo css "global" para reinicios y estilos globales.
- Archivos css específicos del "módulo" para páginas agrupadas lógicamente (tal vez todas las páginas en un asistente de pago o algo así)
- archivos css específicos de "página" para anulaciones en la página (o, poner esto en un bloque en la página individual)
Realmente no estoy demasiado preocupado con las solicitudes de múltiples páginas para archivos CSS. La mayoría de las personas tienen un ancho de banda decente y estoy seguro de que hay otras optimizaciones que tendrían un impacto mucho mayor que la combinación de todos los estilos en un solo archivo CSS monolítico. La compensación es entre la velocidad y la capacidad de mantenimiento, y siempre me inclino por la capacidad de mantenimiento. Sin embargo, el compersor de YUI suena bastante bien, podría tener que comprobarlo.
Prefiero múltiples archivos CSS durante el desarrollo. La gestión y depuración es mucho más fácil de esa manera. Sin embargo, sugiero que, en el momento de la implementación, utilice una herramienta de reducción de CSS como YUI Compressor que fusionará sus archivos CSS en un solo archivo monolítico.
Prefiero múltiples archivos CSS. De esa manera, es más fácil intercambiar "pieles" dentro y fuera como desees. El problema con un archivo monolítico es que puede salirse de control y es difícil de administrar. ¿Qué pasa si quieres fondos azules pero no quieres que cambien los botones? Solo modifica tu archivo de fondos. Etc.
Quieres los dos mundos.
Quieres múltiples archivos CSS porque tu cordura es algo terrible de desperdiciar.
Al mismo tiempo, es mejor tener un solo archivo grande.
La solución es tener algún mecanismo que combine los múltiples archivos en un solo archivo.
Un ejemplo es algo como
<link rel="stylesheet" type="text/css" href="allcss.php?files=positions.css,buttons.css,copy.css" />
Luego, el script allcss.php se encarga de concatenar los archivos y entregarlos.
Idealmente, la secuencia de comandos verificará las fechas de modificación en todos los archivos, creará un nuevo compuesto si alguno de ellos cambia, luego lo devolverá y luego comparará con los encabezados HTTP If-Modified para no enviar CSS redundantes.
Esto te da lo mejor de ambos mundos. Funciona muy bien para JS también.
SASS y LESS hacen que todo esto sea realmente un punto discutible. El desarrollador puede configurar archivos de componentes efectivos y en la compilación combinarlos todos. En SASS, puede desactivar el modo comprimido mientras está en desarrollo para facilitar la lectura y volver a activarlo para la producción.
Al final, un solo archivo CSS minificado es lo que desea, independientemente de la técnica que utilice. Menos CSS, menos solicitudes HTTP, menos demanda en el servidor.
Solo puede usar un archivo css para el rendimiento y luego comentar secciones como esta:
/******** Header ************/
//some css here
/******* End Header *********/
/******** Footer ************/
//some css here
/******* End Footer *********/
etc
Tal vez echar un vistazo a la compass , que es un marco de creación de código abierto de CSS. Se basa en Sass por lo que admite cosas geniales como variables, anidamientos, combinaciones e importaciones. Especialmente las importaciones son útiles si desea mantener archivos CSS pequeños más pequeños pero combinarlos en 1 automáticamente (evitando múltiples llamadas HTTP lentas). Compass agrega a esto un gran conjunto de mixins predefinidos que son fáciles de manejar en diferentes navegadores. Está escrito en Ruby pero se puede usar fácilmente con cualquier sistema ...
Tener solo un archivo CSS es mejor para el tiempo de carga de sus páginas, ya que significa menos solicitudes HTTP.
Tener varios archivos CSS pequeños significa que el desarrollo es más fácil (al menos, creo que sí: tener un archivo CSS por módulo de su aplicación facilita las cosas) .
Entonces, hay buenas razones en ambos casos ...
Una solución que le permitiría obtener lo mejor de ambas ideas sería:
- Para desarrollar utilizando varios pequeños archivos CSS.
- es decir, más fácil de desarrollar
- Para tener un proceso de compilación para su aplicación, eso "combina" esos archivos en uno
- Ese proceso de compilación también podría minimizar ese gran archivo, por cierto
- Obviamente, significa que su aplicación debe tener algunas cosas de configuración que le permitan pasar del "modo de archivos múltiples" al "modo de archivo mono".
- Y para usar, en producción, solo el archivo grande.
- es decir, cargar páginas más rápido
También hay algún software que hace que la combinación de archivos CSS en tiempo de ejecución, y no en tiempo de compilación; pero hacerlo en tiempo de ejecución significa consumir un poco más de CPU (y Obvisouly requiere algún mecanismo de almacenamiento en caché, para no volver a generar el archivo grande con demasiada frecuencia)
Un compilador de CSS como Sass o LESS es una gran manera de ir. De esa manera, podrá entregar un único archivo CSS minimizado para el sitio (que será mucho más pequeño y más rápido que un archivo fuente CSS único normal), mientras mantiene el mejor entorno de desarrollo, con todo perfectamente dividido en componentes.
Sass y LESS tienen la ventaja adicional de las variables, el anidamiento y otras formas de hacer que CSS sea más fácil de escribir y mantener. Muy recomendable. Personalmente uso Sass (sintaxis SCSS) ahora, pero usé MENOS anteriormente. Ambos son geniales, con beneficios similares. Una vez que haya escrito CSS con un compilador, es poco probable que quiera hacerlo sin uno.
Si no quieres perder el tiempo con Ruby, este compilador LESS para Mac es genial:
O podrías usar CodeKit (por los mismos tipos):
http://incident57.com/codekit/
WinLess es una GUI de Windows para comipiling LESS
Una hoja de estilo agrupada puede ahorrar el rendimiento de carga de la página, pero mientras más estilos haya, más lento es el navegador que muestra las animaciones en la página en la que se encuentra. Esto se debe a la gran cantidad de estilos no utilizados que pueden no estar en la página en la que se encuentra, pero el navegador aún tiene que calcular.
Consulte: https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/
Ventajas de las hojas de estilo incluidas: - rendimiento de carga de la página
Desventajas de las hojas de estilo incluidas: - un comportamiento más lento, que puede causar interferencias durante el desplazamiento, la interactividad, la animación,
Conclusión: para resolver ambos problemas, para la producción, la solución ideal es agrupar todo el css en un archivo para guardar las solicitudes http, pero usar javascript para extraer de ese archivo, el css de la página en la que se encuentra y actualizar el encabezado con él. .
Para saber qué componentes compartidos se necesitan por página y para reducir la complejidad, sería bueno haber declarado todos los componentes que utiliza esta página en particular, por ejemplo:
<style href="global.css" rel="stylesheet"/>
<body data-shared-css-components="x,y,z">