하나의 거대한 .css 파일과 여러 개의 작은 특정 .css 파일이 있습니까? [닫은]

거의 모든 페이지에서 사용될 스타일 요소가 포함 된 하나의 monster .css 파일을 사용하면 어떤 이점이 있습니까?

관리하기 쉽도록 여러 유형의 CSS를 몇 개의 파일로 가져오고 모든 파일을 기본 파일에 포함시키는 <link />것이 그렇게 나쁜 것이라고 생각합니다.

나는 이것이 더 낫다고 생각한다

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

vs.

1. site.css

한 가지 방법과 다른 방법으로 수행하는 데 어려움이 있습니까?

Sass 또는 LESS와 같은 CSS 컴파일러는 좋은 방법입니다. 이렇게하면 사이트에 대해 최소화 된 단일 CSS 파일 (일반 단일 CSS 소스 파일보다 훨씬 작고 빠름)을 제공하는 동시에 모든 것이 깔끔하게 구성 요소로 분할되어 가장 멋진 개발 환경을 유지할 수 있습니다.

Sass와 LESS에는 변수 작성, 중첩 및 CSS를보다 쉽게 ​​작성하고 유지 관리 할 수있는 다른 방법이 추가되었습니다. 적극 권장합니다. 개인적으로 Sass (SCSS 구문)를 사용했지만 이전에는 LESS를 사용했습니다. 둘 다 비슷한 이점이 있지만 훌륭합니다. 컴파일러로 CSS를 작성했다면, 컴파일러없이 CSS를 사용하고 싶지 않을 것입니다.

http://lesscss.org

http://sass-lang.com

루비를 엉망으로 만들고 싶지 않다면 Mac 용 LESS 컴파일러가 좋습니다.

http://incident57.com/less/

또는 CodeKit을 (동일한 사람들이) 사용할 수 있습니다.

http://incident57.com/codekit/

WinLess는 LESS를 컴파일하기위한 Windows GUI입니다.

http://winless.org/

이것은 대답하기 어려운 것입니다. 두 가지 옵션 모두 내 의견으로는 장단점이 있습니다.

개인적으로 하나의 거대한 CSS 파일을 읽는 것을 좋아하지 않으며 유지 관리가 매우 어렵습니다. 반면에 분리하면 추가 HTTP 요청이 발생하여 잠재적으로 속도가 느려질 수 있습니다.

내 의견은 두 가지 중 하나입니다.

1) CSS를 작성한 후에는 CSS가 변경되지 않는다는 것을 알고 있다면 개발 단계에서 여러 CSS 파일을 작성하고 (가독성을 높이기 위해) 수동으로 결합하여 라이브로 이동하기 전에 (http 요청을 줄입니다)

2) CSS를 한 번에 한 번 변경하고 읽을 수 있어야한다는 것을 알고 있다면 별도의 파일을 작성하고 코드를 사용하여 (어떤 종류의 프로그래밍 언어를 사용하는 경우) 런타임 빌드 시간 (런타임 축소 / 조합은 리소스 돼지입니다).

두 옵션 중 하나를 사용하면 http 요청을 더 줄이기 위해 클라이언트 측에서 캐싱하는 것이 좋습니다.

편집 : 코드 만 사용하여 런타임에 CSS를 결합하는 방법을 보여주는
이 블로그 를 찾았습니다 . 살펴볼 가치가 있습니다 (아직 테스트하지는 않았지만).

편집 2 :
디자인 타임에 별도의 파일을 사용하고 최소화하고 결합하는 빌드 프로세스를 사용했습니다. 이 방법으로 개발하는 동안 별도의 (관리 가능한) CSS를 가질 수 있으며 런타임에 적절한 모 놀리 식 축소 파일을 만들 수 있습니다. 런타임에 압축 / 축소를 수행하지 않기 때문에 정적 파일과 시스템 오버 헤드가 줄어 듭니다.

참고 : 쇼핑객 을 위해 빌드 프로세스의 일부로 번 들러 를 사용하는 것이 좋습니다 . IDE 내에서 빌드하든 빌드 스크립트에서 빌드 exe하든 번 들러는 포함 된 것을 통해 Windows에서 실행되거나 이미 node.js를 실행중인 모든 시스템에서 실행될 수 있습니다.

개발 중에 여러 CSS 파일을 선호합니다. 관리 및 디버깅이 훨씬 쉽습니다. 그러나 배포 시간에 CSS 파일을 하나의 모 놀리 식 파일로 병합하는 YUI Compressor 와 같은 CSS 축소 도구를 대신 사용하는 것이 좋습니다 .

당신은 두 세계를 원합니다.

당신의 정신이 끔찍한 일이기 때문에 여러 CSS 파일을 원합니다.

동시에 하나의 큰 파일을 갖는 것이 좋습니다.

해결책은 여러 파일을 단일 파일로 결합하는 메커니즘을 갖는 것입니다.

한 가지 예는

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

그런 다음 allcss.php 스크립트는 파일을 연결하여 전달합니다.

이상적으로 스크립트는 모든 파일에서 mod 날짜를 확인하고 변경 사항이있는 경우 새 합성을 만든 다음 해당 합성을 반환 한 다음 If-Modified HTTP 헤더를 검사하여 중복 CSS를 보내지 않습니다.

이것은 당신에게 두 세계의 최고를 제공합니다. JS에도 효과적입니다.

하나의 CSS 파일 만 있으면 페이지로드 시간에 더 좋습니다. HTTP 요청이 적기 때문입니다.

CSS 파일이 여러 개 있다는 것은 개발이 더 쉽다는 것을 의미 합니다 .

따라서 두 경우 모두 좋은 이유가 있습니다 ...

두 가지 아이디어를 최대한 활용할 수있는 솔루션은 다음과 같습니다.

• 여러 개의 작은 CSS 파일을 사용하여 개발하려면
  • 즉 개발하기 쉽다
• 애플리케이션을위한 빌드 프로세스를 갖기 위해 해당 파일을 하나로 결합합니다.
  • 이 빌드 프로세스는 큰 파일을 축소 할 수도 있습니다.
  • 응용 프로그램에 "다중 파일 모드"에서 "모노 파일 모드"로 전환 할 수있는 구성 요소가 있어야합니다.
• 프로덕션에서는 큰 파일 만 사용하기 위해
  • 즉, 빠른 페이지 로딩

CSS 파일을 빌드 타임이 아닌 런타임에 결합하는 소프트웨어도 있습니다. 그러나 런타임에 그것을 수행한다는 것은 CPU를 조금 더 먹는 것을 의미 합니다 (그리고 큰 파일을 너무 자주 재생성하지 않기 위해서는 약간의 캐싱 메커니즘이 필요합니다)

역사적으로 단일 CSS 파일을 갖는 주요 이점 중 하나는 HTTP1.1을 사용할 때의 속도 이점입니다.

그러나 2018 년 3 월 현재 브라우저의 80 % 이상이 HTTP2 를 지원 하므로 브라우저가 여러 리소스를 동시에 다운로드 할 수있을뿐만 아니라 리소스를 선제 적으로 푸시 할 수 있습니다. 모든 페이지에 단일 CSS 파일이 있으면 필요한 파일 크기보다 큽니다. 적절한 디자인으로 코딩하기 쉬운 것 이외의 다른 이점은 없습니다.

최상의 성능을위한 HTTP2의 이상적인 설계는 다음과 같습니다.

• 모든 페이지에서 사용되는 공통 스타일이 포함 된 핵심 CSS 파일이 있어야합니다.
• 별도의 파일에 페이지 특정 CSS가 있어야합니다.
• HTTP2 푸시 CSS를 사용하여 대기 시간을 최소화하십시오 (쿠키는 반복 된 푸시를 방지하는 데 사용될 수 있음)
• 선택적으로 폴드 CSS 위에서 분리하여 먼저 푸시하고 나머지 CSS를 나중에로드하십시오 (저 대역폭 모바일 장치에 유용)
• 향후 페이지로드 속도를 높이려면 페이지가로드 된 후 사이트 또는 특정 페이지에 대한 나머지 CSS를로드 할 수도 있습니다.

모 놀리 식 스타일 시트는 스타일 시트 문서의 전체 크기에 따라 IE에서 문제가 발생할 수있는 많은 이점 (다른 답변에 설명되어 있음)을 제공합니다. IE는 단일 파일 에서 몇 개의 선택기를 읽을 것인지에 대한 제한이 있습니다 . 한계는 4096 개의 선택기입니다. 당신이 모 놀리 식 스타일 시트라면 이것보다 더 많은 것을 가질 것입니다. 이 제한 사항은 IE의 추악한 부분을 뒤로합니다.

이것은 모든 버전의 IE를위한 것입니다.

참조 로스 Bruniges 블로그 및 MSDN AddRule 페이지를 .

하나 이상의 CSS 파일을 갖는 것이 유리한 팁이 있습니다.

평균 사용자가 5 명만 볼 수있는 1M + 페이지의 사이트에는 막대한 비율의 스타일 시트가있을 수 있으므로 대량의 초기 다운로드를 통해 페이지로드 당 하나의 추가 요청의 오버 헤드를 절약하려고 시도하는 것은 잘못된 것입니다. 경제.

전체 웹에 대해 하나의 큰 스타일 시트가 유지되어야한다고 제안하는 것과 같은 주장을 극한까지 늘리십시오. 분명히 무의미합니다.

팁 포인트는 사이트마다 다르므로 엄격하고 빠른 규칙은 없습니다. 페이지 당 고유 CSS 수, 페이지 수 및 평균 사용자가 사이트를 사용하는 동안 일상적으로 발생할 가능성이있는 페이지 수에 따라 다릅니다.

일반적으로 CSS 파일이 몇 개 있습니다.

• 재설정 및 전역 스타일을위한 "전역"CSS 파일
• 논리적으로 그룹화 된 페이지에 대한 "모듈"특정 CSS 파일 (체크 아웃 마법사의 모든 페이지 또는 기타)
• 페이지의 재정의를위한 "페이지"특정 CSS 파일 (또는 개별 페이지의 블록에 배치)

CSS 파일에 대한 여러 페이지 요청과 관련이 없습니다. 대부분의 사람들은 적절한 대역폭을 가지고 있으며 모든 스타일을 하나의 단일 CSS 파일로 결합하는 것보다 훨씬 큰 영향을 미치는 다른 최적화가 있다고 확신합니다. 트레이드 오프는 속도와 유지 관리 가능성 사이이며 항상 유지 관리 가능성에 의존합니다. YUI comperssor는 꽤 시원하게 들리지만 확인해야 할 수도 있습니다.

여러 CSS 파일을 선호합니다. 이렇게하면 원하는대로 "스킨"을 쉽게 교체 할 수 있습니다. 하나의 모 놀리 식 파일의 문제점은 파일을 제어 할 수없고 관리하기 어렵다는 것입니다. 파란색 배경을 원하지만 버튼을 변경하지 않으려면 어떻게해야합니까? 배경 파일을 변경하십시오. 기타.

오픈 소스 CSS 저작 프레임 워크 인 compass를 살펴보십시오 . Sass를 기반으로 하므로 변수, 중첩, 믹스 인 및 가져 오기와 같은 멋진 것을 지원합니다. 특히 작은 CSS 파일을 별도로 유지하지만 자동으로 여러 개의 느린 HTTP 호출을 피하기 위해 1로 결합하려는 경우 가져 오기가 유용합니다. Compass는 브라우저 간 내용을 쉽게 처리 할 수있는 사전 정의 된 대규모 믹스 인을 추가합니다. 루비로 작성되었지만 모든 시스템에서 쉽게 사용할 수 있습니다 ....

가장 좋은 방법은 다음과 같습니다.

1. 모든 공유 코드로 일반 CSS 파일 만들기
2. 모든 특정 페이지 CSS 코드를 동일한 페이지, 태그 또는 각 페이지에 대해 style = ""속성을 사용하여 삽입

이 방법으로 모든 공유 코드와 html 페이지가있는 CSS가 하나만 있습니다. 그건 그렇고 (그리고 이것이 옳지 않은 주제라는 것을 알고 있습니다) 당신은 또한 base64로 이미지를 인코딩 할 수 있습니다 (그러나 당신은 js와 css 파일로 그것을 할 수도 있습니다). 이런 식으로 더 많은 http 요청을 1로 줄입니다.

SASS와 LESS는이 모든 것을 진정으로 지적합니다. 개발자는 효과적인 구성 요소 파일을 설정하고 컴파일 할 때이를 모두 결합 할 수 있습니다. SASS에서는 개발 중에 압축 모드를 해제하여 더 쉽게 읽을 수 있도록하고 프로덕션을 위해 다시 전환 할 수 있습니다.

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

결국 하나의 축소 된 CSS 파일은 사용하는 기술에 관계없이 원하는 것입니다. 더 적은 CSS, 더 적은 HTTP 요청, 더 적은 서버 요구.

단일 CSS 파일의 장점은 전송 효율성입니다. 각 HTTP 요청은 요청 된 각 파일에 대한 HTTP 헤더 응답을 의미하며 대역폭이 필요합니다.

HTTP 헤더에 "text / css"MIME 유형을 가진 PHP 파일로 CSS를 제공합니다. 이렇게하면 서버 측에 여러 CSS 파일을 가질 수 있으며 사용자가 요청할 때 PHP include를 사용하여 단일 파일로 푸시 할 수 있습니다. 모든 최신 브라우저는 CSS 코드가 포함 된 .php 파일을 받아서 .css 파일로 처리합니다.

성능을 위해 하나의 CSS 파일을 사용하고 다음과 같은 섹션을 주석 처리 할 수 ​​있습니다.

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

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


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

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

기타

Jammit 을 사용하여 CSS 파일을 처리하고 가독성을 위해 많은 다른 파일을 사용하고 있습니다. Jammit은 프로덕션 환경에 배포하기 전에 파일을 결합하고 압축하는 모든 더러운 작업을하지 않습니다. 이런 식으로 개발에 많은 파일이 있지만 프로덕션에는 하나의 파일 만 있습니다.

번들로 제공되는 스타일 시트는 페이지로드 성능을 절약 할 수 있지만 스타일이 많을수록 브라우저가 현재 페이지에서 애니메이션을 렌더링하는 속도가 느려집니다. 이것은 페이지에 없을 수도 있지만 브라우저가 여전히 계산해야하는 막대한 양의 사용되지 않는 스타일로 인해 발생합니다.

참조 : 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">

CSS 개발에 대한 체계적인 접근 방식을 만들었습니다. 이렇게하면 절대 변하지 않는 표준을 활용할 수 있습니다. 먼저 960 그리드 시스템으로 시작했습니다. 그런 다음 기본 레이아웃, 여백, 패딩, 글꼴 및 크기를 위해 한 줄의 CSS를 만들었습니다. 그런 다음 필요에 따라 함께 묶습니다. 이를 통해 모든 프로젝트에서 일관된 레이아웃을 유지하고 동일한 CSS 파일을 반복해서 활용할 수 있습니다. 그들은 구체적이지 않기 때문에. 예를 들면 다음과 같습니다. ---- div class = "c12 bg0 m10 p5 흰색 fl"/ div --- 컨테이너가 12 열이고 bg0을 사용하면 여백이 10px 인 5의 여백이 5이고 텍스트가 흰색이며 뜹니다. 왼쪽. 새로운 속성을 제거하거나 추가하여이를 쉽게 변경할 수 있습니다. "라이트"스타일이라고 부르는 것입니다. 이러한 모든 속성을 가진 단일 클래스를 만드는 대신; 페이지를 코딩 할 때 단일 스타일을 결합하기 만하면됩니다. 이를 통해 스타일 조합을 만들 수 있으며 창의력을 제한하거나 비슷한 스타일을 만들 수 없습니다. 스타일 시트는 훨씬 관리하기 쉽고 최소화되어 반복해서 재사용 할 수 있습니다. 이 방법은 빠른 디자인에 환상적인 것으로 나타났습니다. 또한 더 이상 PSD를 먼저 디자인하지 않고 브라우저를 사용하여 시간을 절약합니다. 또한 배경 및 페이지 디자인 속성에 대한 이름 지정 시스템을 만들었으므로 새 프로젝트를 만들 때 이미지 파일을 간단히 변경합니다. (bg0 = 이름 지정 시스템에 따라 본문 배경) 즉, 이전에 흰색이 있었다면 하나의 프로젝트가 단순히 검은 색으로 바뀌는 배경은 단순히 다음 프로젝트에서 bg0이 검은 배경 또는 다른 이미지가 될 것임을 의미합니다 .....