2011-09-07 4 views
3

jQuery 최적화에 대해 많이 읽었으며 선택기를 변경하여 DOM 통과 횟수를 줄이는 방법은 있지만 일반적인 축소 프로세스 외에도 CSS 최적화에 대해 많이 듣지 못했습니다. 문자 수와 서버 요청을 줄이는 것 외에도 CSS 로딩/프로세싱을 최적화 할 수있는 방법이 있습니까? 여러가있는 경우문자 수를 최소화하는 것보다 CSS를 최적화하는 방법이 더 많습니까?

+2

[Reflows & Repaints : CSS 성능으로 인해 JavaScript가 느려 집니까?] (http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your- javascript-slow /) – robertc

+0

"문자 수 감소"란 무엇을 의미합니까? 공백 제거? –

+1

@ Šime 예, 공백을 제거하고 더 짧은 선택기 명령문 (".home p"대 "body .home.container p")을 사용하면 CSS 파일 크기가 줄어들어로드 시간이 단축됩니다. – Ray

답변

6

확실히 성능을 위해 선택기를 최적화 할 수 있습니다. 한 가지 요점은 CSS 파서가 셀렉터를 오른쪽에서 왼쪽으로 읽는 반면, 자바 스크립트 선택기 엔진 (예 : jQuery 등)은 왼쪽에서 오른쪽으로 읽는 것입니다. 기본적으로, 일반적인 원칙은 동일합니다. 일치를 결정하기 위해 검색해야하는 DOM 노드를 줄이기 위해 선택기의 각 부분을 가능한 한 적은 수의 요소로 일치 시키길 원합니다.

즉, 자바 스크립트와 마찬가지로 CSS에서 단일 ID를 선택하는 것이 요소에 대해 가장 빠른 방법입니다. 모든 항목을 *으로 선택하거나 속성 ([href*=foo])을 기준으로 선택하는 것이 가장 느립니다.

읽기 순서는 jQuery 선택기와 CSS 선택기를 최적화하는 것과 다릅니다. ID로 시작하면 속도가 향상되지 않습니다. 예를 들어, 당신이 쓰는 경우 :

#mainContent ul li 

는 jQuery를, 당신은 그것의 아이들을 파고 후, 매우 빠르고 ID를 mainContent와 요소를 찾아 시작하고있다.

CSS에서는 모든 li 요소로 시작하고 나서 ul 조상이 있는지 확인한 다음 #mainContent 안에 있는지 확인합니다. 훨씬 느립니다. 속도

가능한 이익 또한 알아야

그러나, CSS 구문 분석은 자바 스크립트 DOM 탐색보다 훨씬 빠른 - 그래서 당신은 복잡한, '느린'선택기를 많이해야 할 경우에도, 당신 최적화로 성능이 크게 향상되지는 않을 것입니다. 성능 향상에 대한 좋은 기사는 다음과 같습니다 : http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/ - 거대한 복잡한 스타일 시트와 문서 (6000 개의 DOM 요소와 2000 개의 CSS 규칙)를 작성하여 렌더링 시간을 약 20ms 증가시킬 수 있다고 지적했습니다. 더 많은 '정상'페이지를 얻으려면 이익이 20 밀리 초 미만일 가능성이 있습니다.

내 생각에 CSS를 작성하는 동안 선택기 성능을 염두에 두는 것이 좋지만 스타일 시트의 읽기 쉽거나 유지 보수가 쉽지는 않습니다. 대다수의 경우 실제로 불필요하게 느린 선택기를 식별 할 수 없다면 기존 스타일 시트를 최적화 할 필요가 없습니다.

+1

왜이 답변이 투표에 부쳐 졌습니까? 다른 답변보다 더 유익하고 (분명히 더 정확했습니다) ... – Ray

+1

나는 그것이 아래 투표를 한 이유를 알고 싶지 않습니다 ... – Beejamin

1

병합 스타일 시트는이 Lighttpd

처럼, 당신은 또한 당신의 응용 프로그램 (정적 콘텐츠를 제공하는 최적화 된 HTTP 서버)와 같은 다른 서버에 정적 콘텐츠를 호스팅 할 수

(오른쪽 순서를 유지하는 기억)

+0

아, 그래, 그걸 잊어 버렸다. – Ray

2

예, 선택기 일치 효율성 측면에서 CSS를 개선 할 수 있습니다. 선택기를 최대한 구체적으로 지정하면 HTML 렌더러가 일치하는 요소를 DOM에서 검색하는 데 필요한 노력을 줄일 수 있습니다.

예를 들어, 스타일을 지정할 모든 범위가 id #thing 인 요소 내의 div 요소의 직접 하위 요소라는 것을 알고있는 경우. 할 빠를 것 :

#thing > div > span.my-class 

#thing span.my-class 

보다 그 선택기가 일치하는 항목을 찾기 위해 검색 할 수있는 요소를 제한하기 때문이다.

3

나는이 운 좋게 발견 한이 질문에 대한 응답으로 게시 된 자원 사람들의 일부를 읽은 후 (열한 : 여기

주제에 좀 더 좋은 읽기입니다 낡았 던 보석). 그것은 아직도 쓰여졌을 때와 마찬가지로 도움이된다 :

https://developer.mozilla.org/en/Writing_Efficient_CSS

내 연구에서 발견 한 또 다른 큰 장점은 이득이 너무 작기 때문에 깨끗한 (관리 가능한) 코드 또는 의미의 모범 사례를 CSS 효율성을 희생해서는 안된다는 것입니다. 그래도 가능하다면 코드를 깨끗하게 효율적으로 사용하는 것이 좋을 것 같습니다. 여기에 대한 답변을 통해 CSS를 작성할 때 많은 것을 생각해 볼 수 있습니다.

관련 문제